But as Linux edges closer to dropping 32-bit x86 completely -- most distros already have -- I think NetBSD may suddenly regain some relevance in this specific area.
There's also a new initiative to improve its jails facility:
I am not here to tell you what to like or not, but doing my English Literature 'O' and 'A' levels were among my favourite parts of all my schooling, and even the books and plays and poems that I forced myself to wade through and hated have informed me for the rest of my life. Poems I hated at 15 I realised I loved deeply 30 or 40 years later.
And I really loved this essay. It's the single best piece of writing on "AI" I have read yet.
It is very odd to me to watch OStree-based distros starting to take off and win recruits.
The only reason Red Hat needed to invent this very complex mechanism was because RH does not officially have a COW-snapshot capable filesystem in its enterprise distro.
A filesystem with snapshots makes software installation transactional. You take a snapshot, install some software, and if it doesn't work right, you can revert to the snapshot. (With very slightly more flexible snapshots, you can limit the snapshot to just some part of the directory tree, but this is not essential; it merely permits more flexibility.)
In other words, you are a long way toward what in database language is called ACID:
Atomicity, consistency, isolation, durability. It makes your software inastallation transactional: an update either happens completely (A), you can check it is valid (C) and works (I), or it can be totally reverted, and the system restored to the earlier state (D).
That's a good thing. It means you can safely automate software deployment knowing that if it goes wrong you have an Undo mechanism. Databases got this 50+ years ago; in the 21st century it's making its way to FOSS OSes.
Do this in the filesystem and it's easy. SUSE's implementation is so simple, it's basically a bunch of shell scripts, and it can be turned on and off. You can run an immutable OS, reboot for updates, and if you need, disable it, go in and fix the system, and then turn it back on again.
This is because SUSE leans very heavily on Btrfs and that is the critical weakness -- Btrfs is only half finished and is not robust.
But RH removed Btrfs from RHEL and Btrfs was the only GPL COW filesystem, so core infrastructure in the distro means no COW on RH. Oracle Linux has Btrfs -- the FS was developed at Oracle, after all -- and so does Alma.
(Yes I know, Fedora put it back, but the key thing is, it only uses Btrfs only for compression so that Flatpak looks less horrendously inefficient. Fedora doesn't use snapshots.)
With no COW FS, RH had to invent a way to do transactional updates without filesystem support. Result, OStree. Git, but for binaries.
And yes, everyone developing FOSS uses Git, but almost nobody understands Git:
You know that if there's an Xkcd about it, it must be true.
Embedding something you don't understand in your OS design is a VERY BAD PLAN.
With OStree your FS is a virtual one, it's not real, it's synthesized on the fly from a local repository. The real FS is hidden and can't be hand-edited or anything. It generates the OS filesystem tree on the fly, you see. OS-tree.
Use it just for GUI apps, that's Flatpak.
Use it for the whole OS, that's OStree. It is so mind-shreddingly complicated that you can't do package management any more, you can't touch the underlying FS. So you need a whole new set of layers on top: virtual directories on top of the main virtual directory, and some bits with extra pseudo-filesystems layered on top of that to make some bits read-write.
It's like the scene in the Wasp Factory where under the skull plate it's just writhing maggots. I recall in horror and revulsion when I see it.
So it's deeply bizarre to read blog posts praising all the cool stuff you can do with it.
That is pretty obviously how it started, and for the very reasons you describe. But there have been some other benefits that have come out of going down this alternate path as well.
In particular, the remote composability and local deployment is extremely useful for "cattle" edge system deployment. Installing a package reacts to what's currently on the system when installing. Even something as simple as the order you install your packages in can affect the result. Not having to run an entirely duplicate "golden" system to generate snapshots on and then push them to the cattle from is a pretty nifty benefit.
> In particular, the remote composability and local deployment is extremely useful for "cattle" edge system deployment.
A legitimate point, but I feel that there must be better, cleaner, simpler, more elegant ways of doing this.
I mean, Nix does this and it's clean in its way, but the price is, a filesystem layout that is not navigable or maintainable by humans. IMHO and that of many people, that's a price too high, but it shows that there are alternative routes.
> A filesystem with snapshots makes software installation transactional. You take a snapshot, install some software, and if it doesn't work right, you can revert to the snapshot. (With very slightly more flexible snapshots, you can limit the snapshot to just some part of the directory tree, but this is not essential; it merely permits more flexibility.)
Eh, you don't typically have a lock mechanism for the filesystem equivalent to that of a database.
Who's to say something like this doesn't happen:
- snapshot fs
- op/system adjust firewall rules
- "you" install updates
- you rollback
- firewall rules is now missing patches
Don't get me wrong zfs is great - but it doesn't come with magical transactions.
A snapshot is taken before installing updates, so you'd get two snapshots from your example. Rolling back would leave you right after adjusting firewall rules.
> Don't get me wrong zfs is great - but it doesn't come with magical transactions.
I never said it did!
But if you have a snapshotting FS underneath, transactional software maintenance becomes an order or two of magnitude easier to achieve.
The underlying philosophies of Unix are "keep it in files" and "keep it simple". That's why it didn't even have a file-hiding mechanism -- the dot-file thing was an accental, emergent property.
Keep it simple, keep it visible, keep it human-readable and human-fixable.
Because the more complex you make it, the more likely it is to go wrong, and some poor sap is going to have to fix it. Do not get in their way. Instead, think about them, allow for that, and help keep their life easy.
Yawn. You again. Hater!1!! ;-> Mine is still running, after all these (two) years abusing it. Even with installing(not really, much more complicated) some Windoze into a subvolume of it by means of WinBtrfs. I can either boot that Windows natively, or from the same install into a VM, by means of what once were called bootmanager profiles. Automagically chosen. Without having to reserve space for NTFS, VFAT(excluding UEFI/boot), or anything else. Its just a fucking folder, like any other.
> But RH removed Btrfs from RHEL and Btrfs was the only GPL COW filesystem
There is NILFS(2) which is GPL. Lacks some features, but that could have been worked around, or implemented?
> I recall in horror and revulsion when I see it.
You have total recall of recoiling in horror? What a trip... ;-)
That aside, it's all cargo-cult anyway, because of this thing called FHS. Which seems crazy, because in a world of open-source, which can be compiled almost any way one could wish for, why not just use slashpkg, Gobolinux or similar stuff?
“Once is happenstance. Twice is coincidence. Three times is enemy action.”
I saw Btrfs die so many times, I know what to suspect.
The official internal guidance was: give it all your disk space. Make the volumes so big that they will never fill up.
Well, if I could trust it, I might, but I know I can't trust it, so I want my data safe somewhere else. And the company wouldn't provide me with 2 or 3 disk drives so `/home` could live on another physical volume.
And once you've watched your primary work OS self-destruct again, well, if you're me, you reinstall with dual-boot so you have something else to fall back on if it happens again. As it did happen again. Repeatedly.
> You have total recall of recoiling in horror? What a trip... ;-)
OK, my bad. Brain/finger error.
> why not just use slashpkg, Gobolinux or similar stuff?
Yes. It's looking a little bit abandoned, but there is more to it than that single URL.
Maybe a dozen small sites, globally, collecting 'recipes', and still very incomplete.
Partial overlap with hardcore refuseniks who prefer different init-systems, libc's and building whole mini-distros around other concepts. Starting and running f...ing fast.
Yes, in containers/VM's too.
Since you are a writer, you could create some nice stories about the different systems-universes, which could have been if only... ;-)
Which also could help with your PTSD regarding Btrfs, which you DO suffer from.
Lemme tell you why that is from my POV:
I didn't use it in it's early days. So whatever imperfections of its code and tools, or interactions with kernels/libraries of that time escaped me.
I tortured it by pulling the power plug of the systems it's running on multiple times, under different conditions. Like from mostly idling to extreme load. Dozens of times, meanwhile. Sometimes full to the brim. I'm using it on everything, ranging from internal SATA-SSD, NVME, and external disks(real rotating rust) even over f...ing USB2 with UASP. Even using some compression, no DEDUP or RAID though. Still nothing bad ever happened.
Maybe because I'm using it on a 'gaming-distro', often considered b0rkn by 'professionals? Shrug?
So whenever I'm seeing you rambling about that stuff, that's what you'll get from me:
Shrug?
(Until it happens to me, then I'll shout I repent! I repent! Such brazen foolishness of mine! Forgive my ignorance!)
You are. It's Arnold's first attempt at being/becoming Ace. He stumbles over the phrase, and the "old" Ace tells him he was once like him too, and "there's an Ace inside you, too" (Lister/Cat, I can't remember which: "Yeah, so deep he's been buried..." or something to that effect).
https://www.theregister.com/2012/12/12/linux_no_longer_runs_...
reply