Readit NewsThat's ridiculous. No OS in his right mind would flush FPU regs to 64 bits only, because that would break many things, most obviously "real" 80 bit FP which is still a thing and the only reason x87 instructions still work. It would even break plain equality comparisons making all FP useless.
For 64 bit FP most compilers prefer SSE rather than x87 instructions these days.
Never, for sure.
enoX should always stay stable, as it's the BIOS (in some ACPI table) telling that this device/port has this ID.
ensX means the NIC in PCIe slot X, but in your PCIe tree you can have PCIe bridges, so technically you could have multiple NIC in the same slot (what the BIOS declare as a slot), so there was a lot of breaking NIC naming changes over the years in systemd to figure out the right heuristics that are safe, enabling/disabling slot naming if there is a PCIe bridge, but just in some cases.
Also for historical reasons the PCIe slot number was read indirectly leading to some conflicts in some cases (this was fixed in systemd 257)
Every year's cope with systemd.
From my build box:
chroot $MOUNTPOINT/ /bin/bash -c "http_proxy=$aptproxy apt-get -y --purge --allow remove-essential install sysvinit-core sysvinit-utils systemd-sysv- systemd-"
After this fix, sysvinit builds with debootstrap were almost identical as to bookworm. This includes for desktops.
As per with bookworm through buster, you'll still need something like this too:
$ cat /etc/apt/preferences.d/systemd
# this is the only systemd package that is required, so we up its priority first...
Package: libsystemd0
Pin: release trixie
Pin-Priority: 700
# exclude the rest
Package: systemd
Pin: release *
Pin-Priority: -1
Package: *systemd*
Pin: release *
Pin-Priority: -1
Package: systemd:i386
Pin: release *
Pin-Priority: -1
Package: systemd:amd64
Pin: release *
Pin-Priority: -1Passkeys is an interface between your password manager and a website without all the fluff with filling or copy-pasting passwords.
I've been using Ctrl+Q, it replaces an almost completely useless key combo (flow control if I'm not mistaken), and is easy to press.
bind C-a send-prefixAlso for a 20B model, you only really need 20GB of VRAM: FP8 is near-identical to FP16, it's only below FP8 that you start to see dramatic drop-offs in quality. So literally any Mac Studio available for purchase will do, and even a fairly low-end Macbook Pro would work as well. And a 5090 should be able to handle it with room to spare as well.
But before we even go there, we have to consider an all-SSD solution. SSDs are so cheap nowadays. It’s a trivial cost to buy a 2-4TB SSD. Heck, even an 8TB SSD is reasonably affordable, only about $600.
So first step is justifying a complicated caching setup. Why cache at all when you can just use all SSD storage and bring the complexity down a whole lot?
And if you’re using more than 2-8TB of storage and you’re in the spinning disk territory, why are you not using a dedicated NAS solution like TrueNAS?
This solution just seems like one of the worst possible choices.
- there had been no raidz expansion (but now is, so this point is crossed)
- ZFS degrades read latency with the number of drives in array, while mdraid/lvm scales linearly - this is the price you pay for your checksums
- write-cache options on ZFS are atrotious, ZIL/SLOG are nothing compared to dm_writecache - I can stream 2GB/s full of sync writes until my cache drive is filled up, and it also provides reads to freshly written data, without going to backing pool
So, saying "why not ZFS" or "go buy some SSDs" is not really productive for promoting ZFS - it just underscores that "for ZFS" crowd are zealots.