GoboLinux
gobolinux.org
gobolinux.org
Paraphrasing: "Yes we know this is different. Yes it is very simple. You may not be used to it, but it is easier to understand and work with. You don't have to use this. We like this and we are happy."
> make all programs relocatable - I would love to see that, but that would either mean: rewrite every app in the world to use `libprefix`
I’m curious about what they mean by `libprefix`. A web search doesn’t turn up any useful results.
Linux filesystems are generally case sensitive.
MacOS is better though.
The average person never sees this stuff. Linux is widely used as a server OS and it still has taken a long time for new appraoches to get traction.
That's true, but also irrelevant. The file system can be a mess on MacOS because most MacOS users will never actually interact with the file system in any meaningful way. Apple obscures the file system away from its users by design. If you ask the average Mac user where on the computer their files are stored, they'll likely tell you something like, "They're all in the Photos app". On the other hand, even a fairly novice linux/unix user will almost certainly end up interacting with filesystem directly at some point, probably a lot.
The Unix under the hood is just standard stuff and Apples hides away detritus like .plist files. And sandboxed apps have their own little stub filesystems too.
Anyway I like the idea of GoboLinux a lot but kind of think GUIX, just abstracting it away might be the right approach.
The external monitor fiasco is a dealbreaker for me.
In many ways they are essentially a sort of iPad with a keyboard and a USB port or 2 instead of an iPad or Apple Lightning connector.
The GPU is very closely coupled to the CPU inside the SoC, as is the RAM and the soldered-in flash nonvolatile storage.
You can't just boot them off USB. You can't just plug in extra drives. You can't add more memory or bigger SSDs without extremely elaborate desoldering of BGA parts.
These are not "PCs with an Arm ISA chip". They're a whole computer, disks and all, in a single closed package, without all the buses and connectors of COTS x86 kit -- which is _why_ they are so much faster.
https://www.macworld.com/article/675869/how-to-connect-two-o...
https://apple.stackexchange.com/questions/463371/how-to-supp...
DisplayLink is a standard for connecting GPUs over USB. It's slow but it kinda sorta works -- I have an ancient DisplayLink 7" USB display. Works great on Windows, and I could have a tiny second screen with a console prompt on it, or Task Manager or something, when working on the move on a laptop.
I use both. I see no improvement whatsoever in the BSD approach.
Unless you mean stuff like configuration? I think user configuration would still reside somewhere under the user's home dir
2. /sbin, as distinct from /bin, is for system management programs (not normally used by ordinary users) needed before /usr is mounted.
3. /usr/bin is for distribution-managed normal user programs.
4. There is a /usr/sbin with the same relationship to /usr/bin as /sbin has to /bin.
5. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning.
6. /usr/local/sbin, as you can probably guess at this point, is to /usr/local/bin as /usr/sbin to /usr/bin.
One downside to Program Files type structure is that there's probably going to be some duplicate libraries lying around. However, as someone who's battled version skews due to clashing maintainer mindsets: that's been a much bigger pain in my ass than a few wasted kbs!
source: http://lists.busybox.net/pipermail/busybox/2010-December/074...
An interesting idea, but I have to figure the majority of Unix sites kept /usr on the local machine like always.
BSDs still make the distinction but Linux moved on a while ago.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
I can’t find an exact date but here’s a stack overflow discussion about the topic from 2016: https://unix.stackexchange.com/questions/266517/why-is-bin-a...
similarly /lib and /lib64 are pointers to /usr/lib
It might be interesting in a vm to remove those symlinks and see what breaks. Presumably a lot.
From a distro sense everything makes sense. dpkg -S this-file will tell me quickly why a /usr file is there. The distro is supposed to paint the picture for you.
What are the parts you think are the worst messes?
? What do you have in mind? I don't recall that being for applications
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.htm...
Losing human readability, when that was the primary Gobo design goal, is a fearfully high price to pay, as I explained upthread:
Also, there’s no actual use case for Nix store paths with the hashes stripped out. The actual path can easily be derived from whatever is at the root of the dependency. Things like Nix expressions, the result symlink, the system environment in /run/sw/current-system, and PATH. Those are “human readable.” From there, you can get the actual store paths. It doesn’t matter that they’re prefixed with a hash because they still have human readable names at the end, allowing you tell what they contain.
It’s similar to inspecting memory. You don’t want to start by examining raw bytes in memory dumps. It’s far more easier and meaningful to start by chasing variables instead.
https://news.ycombinator.com/item?id=39539010
What I am saying is that choosing this flat directory store, one that is very hard for humans to read, parse and navigate, is on its own a major disincentive for many people.
The traditional and lavishly-documented Unix filesystem layout is comforting and familiar to hundreds of thousands of people (at a very conservative estimate!) and throwing it away was a poorly-considered move that on its own will make many people refuse to even consider Nix and its kin.
If a project decides to replace it then it needs multiple compelling reasons, and just "search paths will sort it" and "this keeps pathnames short" is not good enough.
What I am suggesting is that if automatic directory name management (via hashes or whatever) were combined with a more human-readable tree, this type of tool would have a much better chance of success.
Even if it were less efficient.
Even if it were more work for the developers.
The benefits of the Nix approach are only compelling to a relatively small number of people and the price is too high for many. That's why after over 20 years, adoption is minimal. That's why work continues on Debian and all the other traditional distros. That's why since Nix was invented in 2003 (AFAIK) we have had AppImage and Snap and Flatpak.
Because this stuff is too hard for ordinary folks.
This is why functional languages as a whole have made so little impact on mainstream computing. They bring great benefits for those smart enough to understand them, but for the rest of us, for ordinary dumb jocks like me, it's too hard.
http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...
The same goes for Lisp's prefix notation, and for Forth's and Postscript's postfix notation and Reverse Polish Notation in general.
After coming up on 40 years in the industry, I am convinced that some of this stuff really does have compelling advantages, but it's not compelling enough which is why tens of $millions are being spent on inferior tools such as Flatpak.
And under the hood, Flatpak uses Ostree, and Ostree uses Git, and TBH I reckon about 1% of 1% of the thousands of people using Git and anything related to it actually understand how it works.
This kind of thing is just too complicated for ordinary minds.
Computers are not for computer scientists. Computers should be for everyone. The goal of making this stuff easier to understand is more important than the goal of making it better in some theoretical way.
The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... *trust* that your path and so on will work and stuff will just get found somehow.
You have to let go of navigating your own filesystem.
That's just too much for a lot of people. The filesystem layout is one of Unix's defining characteristics.
Whereas Gobo's goal is the opposite: yes, let us discard the traditional filesystem layout, but let's do it by making it more human readable instead.
You can work out where things are without knowing. There's better isolation. It's like semantic versioning, applied to the filesystem: a semantic filesystem layout, where folder names encapsulate versioning info and are more meaningful than the old 1970s reduce-typing-effort-at-all-costs approach.
Nix says ignore paths, ignore directories, you don't need them, we'll manage that for you.
Gobo says forget traditional paths, here are some better ones that you will find easier and more useful.
For me, that's an attractive proposition.
In real life, it seems that both were too much for most people.
My suggestion would be: why not merge them? Try to bring the advantages of Gobo -- readable, meaningful directory paths -- to a version of Nix.
Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree:
/gonix/apps/gui/productivity/images/krita/5.1/
/gonix/apps/console/shell/bash/5.2/
/gonix/apps/programming/compilers/fpc/3.1/
/gonix/libraries/c/glibc/2.39
/gonix/apps/console/editors/vim/9.1
I am totally making these up, you understand, they're merely illustrative examples.
Not really trust. Nix and Guix are not magic.
You can still use ldd to figure out what (now exact!) library anything is gonna use. Guix and Nix use the rpath feature.
And your profile directory in Guix is a normal directory called $HOME/.guix-profile . Currently, it has "bin" and "share" and "sbin" and "libexec" and "lib" and so on in there. That is what the end user uses. Entries in those do link to /gnu/store/xyz/bin/xyz (using regular symlinks), yes.
>Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree:
One hash represents all the dependencies of that package, too.
One directory name in Guix's /gnu/store encodes both the direct sources and all the dependencies, all the way up to a bootstrap root (the latter of about 250 Bytes of binary). If any of the dependencies of bash changes, the hash will change, too. That also means that you will have multiple /gnu/store/*-bash-5.1.16 in there in a normal system.
But in your proposed case, you'd have to introduce some magical things which figure out and STORE the dependencies somehow differently in the background. Guix doesn't do that. It stores that in the file system, the end (as in directly in the file system, not as in "the system database blob is in file /foo"). No magical extra store.
That said, it would be possible to only change the guix profile layout to be what you suggest, and then still have symlinks to /gnu/store/<hash>-xyz in there. Probably like 5 h of work, and end user programs most likely will work on the first try. Patches welcome.
See guix/profiles.scm for what creates the profile. %user-profile-directory is $HOME/.guix-profile . profile-derivation is the function you want to change.
You can also use guix on top of whatever other Linux distribution and try it out like that. The package manager (which makes the profiles) also supports containers--so you can safely try out whether your change works.
Did I say they were? I didn't mean to.
I've researched Nix. I've written about it. Nix people contacted me to thank me for doing so.
https://www.theregister.com/2022/12/13/nixos_2211_raccoon/
https://www.theregister.com/2021/12/03/nixos_linux_os_design...
The reader comments I get is that a non-human-readable filesytem (or only marginally so, by ignoring the hashes and looking in the new single-level hierarchy for recognisable fragments of names) is just too high.
They don't have enough of a problem with how things are to choose a whole new method with this very high price.
(Which is the same reason Plan 9 flopped, as I have both written about and spoken publicly at FOSDEM about this month.)
https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-...
https://www.theregister.com/2024/02/21/successor_to_unix_pla...
> You can still use ldd
I submit that this is rocket science to the majority of Linux users and is not a sufficient answer.
> And your profile directory in Guix is a normal directory
I confess I've not looked at Guix yet.
But saying that, I don't think having a normal homedir isolated in a partition full of alien weirdness is enough, TBH.
> One hash represents all the dependencies of that package, too.
I am not sure that I understand what this means, but is there any reason this could not be combined with my proposal?
> That said, it would be possible to only change the guix profile layout to be what you suggest
Interesting. Suboptimal but interesting. Would make it a little less intimidating, I suspect.
> You can also use guix on top of whatever other Linux distribution
Again, as I said, for most of us, it's a very cognitively expensive extra step to solve a problem we simply don't have.
That can't be true, can it? I guess it depends on the definition of "users."
As an example: Windows Services for Linux 2 used a special init daemon to interact with the host OS.
That meant no systemd. That meant that the `systemctl` program wasn't there.
This baffled legions, armies, of wannabe sysadmins.
https://stackoverflow.com/questions/55579342/why-systemd-is-...
https://superuser.com/questions/1785697/systemd-in-wsl-on-wi...
https://github.com/microsoft/WSL/issues/9477
https://askubuntu.com/questions/1132230/unable-to-run-any-sy...
People on the whole have no idea how this stuff works, and they just copy magic incantations from StackOverflow to get stuff to happen. If that doesn't work, then this OS is broken. The end.
For these guys, WSL was broken.
Result:
MS hired Lennart Poettering.
https://www.theregister.com/2022/07/07/lennart_poettering_re...
He "fixed" it. Systemd now works in WSL2. All those guides for noobs now work. Everyone is happy.
In a world where tools like Flatpak and Snap are proliferating and it's driving deep divisions between Linux distros, if you think the average person struggling with Linux is going to use `ldd` to work out where the dependencies for something live, I'm afraid you are a deep guru who lives on a different plane of existence.
We now have widely-used packaging systems which simply embed an apps entire dependency tree into a package to avoid people having to work out the difference between `apt` and `rpm`. Thousands of terabytes of disk are being burned to make this stuff go away.
Yes, this is too hard. Way too hard.
> I'm afraid you are a deep guru who lives on a different plane of existence.
I'll take that as an amusing tip of the cap, I hope that is how it was intended. I don't know if I consider myself a deep guru, but if something doesn't run when I expect it to, I do tend to reach for ldd pretty quickly.
(I used to use it at work when I still ran Windows, even after the official systemd support, because Microsoft's implementation had some problems)
> People on the whole have no idea how this stuff works, and they just copy magic incantations from StackOverflow to get stuff to happen. If that doesn't work, then this OS is broken. The end.
I don't think small, weird Linux distros like NixOS or GuixSD or GoboLinux really have the resources to support careless users of that kind, or stand to gain much from them. Projects like that are seeking contributors more than they are seeking users at all!
Is this a tragic flaw? Or is it just a mundane fact about a project that can still thrive in its niche?
PS: Any idea why Microsoft 'needed' a special init system for WSL2 anyway? Full fat systemd systems boot in like 8 seconds anyway! WSL's imitators on macOS (e.g., Lima, Orbstack) work with regular Linux distros and just leave the init system intact.
You're missing the point. It's not what the distros need from the people. It's what the people need from the distros.
Linux software packaging is junk. It's vastly over-complex, it's horribly fragile, there are multiple rival systems (apt, rpm/dnf, pacman, apk, etc. etc.) and none work with each other and none is a complete answer, and as a result, there are now 2nd level schemes on top of that (appimage, snap, flatpak, docker, etc.) and those reproduce the problems -- they are incomplete, incompatible, etc. -- and they reproduce it with a level of bloat that makes their packages 100x bigger and 100x slower to download and update.
Android just makes this work and has several _billion_ active daily users, who rarely have big issues. I've never heard of anyone "bricking" their phone installing an app. It's more reliable than Windows with 100x as many users.
That is what Linux needs, and it needs it yesterday, lest it become a weird way of packaging apps for Windows boxes. ("Oh, yeah, that? You need to install a wrapper thingie first, then it will work. Install this wsl thing and it'll run.")
We need a better answer. Nix is better in many important ways: it solves these problems, but it does so at a cost, and the sort of people who like Nix don't realise, or don't care, that the cost is terrfying for ordinary mortals.
Gobo survived 20y of neglect by being better in different ways. It makes the existing filesystem less cryptic.
Nix throws it away and tells you that you don't need it.
Better to say "hey, look, we give you a better filesystem" than to be that bearded mystic on a mountain saying "for true enlightenment, you do not need a filesystem".
> Any idea why Microsoft 'needed' a special init system for WSL2 anyway?
Um. Have you used it? This is _not_ just a VM.
It seamlessly extends Windows so that Windows can run Linux binaries.
It is not another OS in a box.
I'm not saying it's perfect -- it is not -- but it's about 20 years ahead of simple VM solutions.
And it does that by integrating with the guest OS via a special init system.
Yes, I used it every day at work for most of a year! Its showstopping bugs (a killer memory leak, freezes after suspend, data loss issues (!!), native systemd support making Emacs freeze somehow (???)) are a big part of why I finally took the leap to macOS at work.
How much do you use WSL? Because its bugs go well beyond rough edges and those reliably show up if you actually use it for most of your work every day.
> This is _not_ just a VM.
Sure it is! It's a VM with the following features/integrations that start working without any manual configuration:
- nice management interface that can download distros for people
- filesystem sharing via 9pfs, which is cool but unfortunately too slow for serious use
- a pair of command-line interfaces for invoking commands on each side from the other
- this doesn't involve the init system btw. it just uses good old binfmts on the Linux side with the Linux-side wsl command, just like some users do with wine for Windows binaries or qemu for RISCV Linux binaries
- automatically forwards network traffic between the Windows host and Linux guests so that users don't have to manually configure port forwarding
- a shared display server (Wayland implementation) on the host side and some plumbing to automatically forward its sockets to guest VMs
That's it. There's no other magic.
> It seamlessly extends Windows so that Windows can run Linux binaries.
I wouldn't characterize that feature as seamless— in fact it's so bad that you can't reliably pipe the output of WSL commands evoked from the Windows side into a Windows-side pager or clip.exe (sometimes wsl.exe would just hang or eat the output). And then there's the PATH translation issues, which often have to be handled quite manually with subshells calling cygpath or wslpath or whatever.
That particular feature is so bad that I hardly ever used it! I'm astonished to hear you call it 'seamless'. Have you ever tried to share a Yubikey for SSH auth and GPG encryption between the Windows host and Linux guests on WSL2? How 'seamless' was that for ya?
> I'm not saying it's perfect -- it is not -- but it's about 20 years ahead of simple VM solutions.
The things I compared it to (Lima, Orbstack) have the exact same features without ever having replaced systemd. Lima uses cloud-init as the interface for injecting its startup hooks. Idk what Orbstack does. Lima is definitely jankier than WSL2 (which is saying a lot, unfortunately), but Orbstack seems solid.
Anyway, both of them reproduce the port forwarding, filesystem sharing, and command forwarding that WSL2 has without replacing systemd, and Lima is older than the systemd integration for WSL2. Have you used either tool? There's no way WSL2 is even one decade ahead of either, though it might be a couple years ahead of Lima.
Me, no, I have only played around with it. From a technical level, I personally preferred WSL1, which I thought was more elegant. I am happy to concede your points as it certainly sounds like you have more experience with it than me.
WSL2 is just a VM, yes, I totally agree -- but a much better-integrated one than most non-techies could ever hope to achieve, and still better than most techies could achieve unless they really knew their stuff and they were competent in both of 2 different OSes.
From what I've seen over my working life, I'd say about 0.1% of Windows users would have the level of knowledge needed, and possibly more Linux ones -- but they mostly wouldn't want it or care.
My personal impression is that it's an attempt at the classic MICROS~1 "embrace and extend" manoeuvre on Linux.
No, I've never tried the Mac tools you mention, and I don't own a Yubikey or anything like it. I try new distros almost daily on my Mac but I have no need of any integration -- I am not a developer. I review distros sometimes, though, and occasionally things like hypervisors:
https://www.theregister.com/2023/09/29/utm_apple_hypervisor_...
Same. WSL1 was ambitious, wild, and incredibly impressive despite the flaws that eventually convinced Microsoft to start over with WSL2.
> WSL2 is just a VM, yes, I totally agree -- but a much better-integrated one than most non-techies could ever hope to achieve, and still better than most techies could achieve unless they really knew their stuff and they were competent in both of 2 different OSes.
Agreed! WSL2 has a very impressive OOTB experience in terms of getting you from nothing to a VM that you can use. It would be a lot of work to set up comparable integrations yourself.
> My personal impression is that it's an attempt at the classic MICROS~1 "embrace and extend" manoeuvre on Linux.
Unfortunately I can't disagree. People seem to think that MICROS~1 is dead, but as far as I can tell they're in a very similar monopoly position with more or less the same interests now as they've ever had.
> No, I've never tried the Mac tools you mention, and I don't own a Yubikey or anything like it. I try new distros almost daily on my Mac but I have no need of any integration -- I am not a developer. I review distros sometimes, though, and occasionally things like hypervisors:
In that case, Orbstack and Lima might be tools worth your writing, the same way hypervisors and virtualization apps are! They're attempting to be WSL2-alikes but they don't use their own hypervisors (Lima supports qemu and Apple's virtualization framework, idk about Orbstack.)
My slightly educated guess would be on the point that in WSL2 distros, those do share the same running kernel, the same network stack and probably couple of other things under the hood (something about binfmt?).
From the product perspective, booting another instance (say I have Ubuntu 22.04 and 18.04 both available) in ~ 1 second, can be seen, and even proved with some A/B testing, as a huge advantage.
PS C:\Users\coolcold> wsl -t 'Ubuntu-18.04'
The operation completed successfully.
PS C:\Users\coolcold> wsl -l -v
NAME STATE VERSION
* Ubuntu-22.04 Running 2
Ubuntu-18.04 Stopped 2
PS C:\Users\coolcold> netsh wlan show interfaces|wsl -d 'Ubuntu-18.04' -- fgrep Mbps
Receive rate (Mbps) : 390
Transmit rate (Mbps) : 390
For me at least, they went to more trouble than it's worth for that ~6-7 second gain, given that a normal systemd distro will boot in 7 or 8 seconds anyway. Maybe the difference is bigger on spinning rust. But when I used WSL regularly I was in one VM all day every day. It was always running, so I really wasn't worried about the 10 seconds it took to start up or whatever.
At the same time, their custom init setup caused compatibility issues with my distro of choice and some applications (somehow). So it didn't come for free.
> /gonix/apps/gui/productivity/images/krita/5.1/
> /gonix/apps/console/shell/bash/5.2/
> /gonix/apps/programming/compilers/fpc/3.1/
> /gonix/libraries/c/glibc/2.39
> /gonix/apps/console/editors/vim/9.1
This is a nice illustrative example that works well when the only difference between software packages is semantic versions. The reality is that there can be many variants of packages and using something like a hash of package inputs is very practical. Take for example a library called GDAL, which has an insane amount of configure flags. It is quite common for scientific software to be tuned and package maintainers cannot supply a one-size-fits-all solution.
For instance, we could still embed the hash in the directory name, in much the same way that many Linux programs use build numbers.
/gonix/apps/console/editors/vim/9.1~246dea34451dbdda21
The core things that I'm getting at here are:
1. Put the human-readable part first because humans see that first.
2. Retain hierarchical layouts. For humans this makes things more manageable and accessible, while for programs, as long as it's computationally-parseable the impact is negligible.
3. Lean in to the hierarchy. If it's necessary to duplicate slightly different versions of dependencies for different programs, then put them inside that program's hierarchy. That's one of its reasons for existing.
4. Embed the hash anywhere a simple regex can find it, no problem; tab-completion can sort that out.
All I am trying to suggest is that a Nix/Guix/successor/replacement type tool could focus more on ordinary joes who find it hard to remember the difference between `/bin` and `/usr/bin` as it is, and make stuff human-readable first and machine-readable second.
$ spack find -p
...
cmake@3.27.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x6g5fl54kgt4nqmgnajrtfycivokap2p
cmake@3.27.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x4bznyafesvpdbplqhmnwwvy2zj5fdzs
coreutils@9.3 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/coreutils-9.3-vlwyg7d3ysxfoom3erl6ai4yy7fuf2jn
curl@8.4.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.4.0-zjz6twa32vxnevika34kkrxjwo27z6vj
curl@8.6.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.6.0-da5tk7aqaqp6zdligjmahzwohzut65qc
diffutils@3.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/diffutils-3.9-lau4vo7zlsktmbhyn3pf3x72nxhihsaq
double-conversion@3.3.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/double-conversion-3.3.0-zihvj7vzedapjprk76awr7qied3k45n6
emacs@29.2 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/emacs-29.2-x5v4wdhp4vfsuxquadackqckdvxrppwi
expat@2.5.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/expat-2.5.0-hmdysf6hcrzuhcxu7fkecpvskzxecgps
findutils@4.9.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/findutils-4.9.0-atynmdjhdjpb2ipurlk7cxtdep77m7mu
fish@3.6.1 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/fish-3.6.1-sg3ws3rmbfgdfyhvjnhd5agepguj4yf2
flex@2.6.3 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/flex-2.6.3-quw6ammnjxfutqtqcifvjfsp5nyqpeab
freetype@2.11.1 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/freetype-2.11.1-ue2ofutkkawtzvcl47pqts4lasm5lgha
gawk@5.2.2 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gawk-5.2.2-jld7vb24rls64nbzkyxcp4alluyedfzv
gdbm@1.23 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gdbm-1.23-amtpuskagocirjhffgqrjas3bfbnzixi
...
config:
install_tree:
root: $spack/opt/spack
projections:
all: "{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}"
[1] https://spack.readthedocs.io/en/latest/config_yaml.html#conf...
Thanks for this -- I'll read up on it.
The only one that doesn’t quite work out is 3. Dependencies are vendored like that when it’s a patched version that can only ever be used with one package, but in general it helps more to have the regular structure to let them be shared. Otherwise we would have to move them when a new dependent appears and some other kinda funky things. I have played with having each package get a “view” of links to all its deps in its prefix, but it’s a high cost in inodes for an only moderate increase in observability. Pretty easy to generate your own (there’s literally a command for it) so not sure if it’s worth it.
> You have to let go of navigating your own filesystem.
Your broader point makes sense in that I get how a user-navigable filesystem is attractive, especially in the context of store paths being exposed to users as they are embedded in binaries and scripts. But I think the above is an overstatement.
Stuff on NixOS gets on your path the exact same way as it does on any distro: a bit of shell! Users can read through the `set-environment` script and the config NixOS generates for their shell in /etc and all that. They can check what binaries are on their PATH with `which -a` as usual. They can ask their shell where a given variable was defined using the usual tools it offers.
And the human-readable part of the filesystem does exist, just on top of the Nix store. The symlinks under /nix/var/nix/profiles/... or /run/current-system/sw are about as human-friendly as Unix ever is, imo.
Perhaps NixOS could do more to make those 'official', foreground them and document them, and even provide more loosely versioned paths to them like you suggest (making it easier to impurely manually build against them).
Secondly, from my position as a tech writer (for about 25 years) overlapping for well over a decade with some 20-odd years as a software tech support person and trainer, I think you are dramatically over-estimating the level of understanding of the average Linux user.
A Linux user can be expected to be a bit more clueful than a Windows user, but not much. They probably understand the concept of a "directory tree" and know that there are "files", some "executable", in "directories", one of which is "current", and stuff like that, but you can not rely on them grasping advanced concepts such as "search paths" and "links" (of different kinds, no less!)
The idea that there's a second, "more standard" tree, and it's optionally overlayed on top of the flat software-managed Nix tree, made up of symbolic links, and that you don't need to know where things are because the software magically makes sure that the OS can find them... I'm sorry but after coming up on 40 years in tech, my reaction to that might be captured by the crying-laughing emoticon. You could no more explain that to the average distro-hopper than you could explain it to a Labrador dog.
How it gets set? Don't care. A script is what I'd assume, sure, but that's no more important than the colour of the script's author's hair.
I'm saying that, professionally, as a writer, I have now presented the concept to smart interested users that they let go of the filesystem hierarchy and just let the OS manage that, and I'd say about 9 out 10 of my readers responded "oh to h3ll with that! No WAY!"
It is a step _much_ too far. It's comparable but worse than self-driving cars to these folks.
To refer to memes again, you need the god-level intellect step of the intelligence meme: https://imgflip.com/i/45rmf2
... to grasp the concept that you don't need to know where files are so long as the OS knows.
This is not one step too far. It is a two-year backpacking trip across all of Asia too far.
This is easy for me to believe :)
> you can not rely on [Linux users] grasping advanced concepts such as "search paths" and "links" (of different kinds, no less!)
Those are required for understanding how conventional Linux distros work, too, though. So the users who won't understand $PATH on NixOS are also users who don't understand how $PATH works on Ubuntu.
I will admit that there's a difference here in that you can have a very half-assed understanding of Ubuntu, and even a half-assed understanding of NixOS probably has a higher skill/knowledge floor.
And maybe I've unthinkingly assumed that half-assed understandings are worth less than they really are, at least psychologically. I have a very half-assed understanding of how my car works, but having it not be a complete wonder and mystery to me does give me more confidence in driving the thing— even if most of my knowledge of how it works is too incomplete to be practically useful and I'll always take it to a specialist if it has problems.
> You could no more explain [the Nix symlink forest] to the average distro-hopper than you could explain it to a Labrador dog.
Maybe the average distro-hopper matters because the average Linux user is a distro-hopper. But I think distro-hoppers are kind of a pathological case here, because distro-hopping is precisely the habit of throwing your hands up, blasting away your whole setup, and clicking Next Next Next instead of learning how your system works. Of course distro-hoppers are going to struggle to understand how their distros work! To distro-hop is to enact a commitment to not understanding your distro!!
I also wonder if this is really true, and this is probably the part where I am just naive. But a forest of symlinks would be super easy to diagram perfectly faithfully, and I think a visual aid like that could go a really long way for the average person.
> the concept that you don't need to know where files are so long as the OS knows.
Have you seen this article, posted to HN to some infamy, about how zoomers don't expect to know/care where their files are, and are in fact somewhat baffled at the very question of where they've saved something?
https://www.theverge.com/22684730/students-file-folder-direc...
I what that generational gap says for the viability (in terms of user acceptance) of the Nix store in all its ugly glory in the future.
I want to be clear that I do think some of your suggestions for laying out the files differently (like Spack apparently does) are perfectly reasonable. There are technical and historical reasons that the store is hash-first, but maybe they're worth re-evaluating. Sometimes I think the real winner, some day, in terms of executing this idea beautifully and in a user-friendly way, will be on a 'brand new' OS where a different executable format and/or a different kind of filesystem can mean the Nix store or its equivalent doesn't need to be exposed as bare files at all. One Nix hacker has actually proposed doing something like that on top of the Linux kernel, but I think RedoxOS already uses some ideas like this.
Fair point. :-)
> I what that generational gap says for the viability (in terms of user acceptance) of the Nix store in all its ugly glory in the future.
I think there's a word, or several, or maybe just a letter or two, missing here.
But yes, I thought of that, too.
What irks me a little is that the Nix folks I've spoken to seem to feel that they have simply fixed this issue now, and nothing more need be done. While in fact I think there is a lot more work to be done here, and maybe GoboLinux and Spack and things show the way.
The (to me) madness of things like Btrfs volumes, layering another filesystem namespace on top of the Unix one, allowing insanity like multiple distros in one partition:
https://unix.stackexchange.com/questions/742392/can-i-use-bt...
Or installing Windows on Btrfs:
https://www.lilysthings.org/blog/windows-on-btrfs/
Hints at other approaches. As in: why not both? Maybe it's possible to have multiple _views_ of a filesystem, so via one API you "see" a flat namespace with hashed directories, and with another a conventional hierarchical one -- just as a Gmail account can be viewed as flat and hierarchical at the same time using an IMAP client.
This isn't over. There's some distance to go yet.
Oops, I certainly did accidentally a whole word there ;)
> What irks me a little is that the Nix folks I've spoken to seem to feel that they have simply fixed this issue now, and nothing more need be done. While in fact I think there is a lot more work to be done here, and maybe GoboLinux and Spack and things show the way.
I think you're probably right. I'm sure there are others in the Nix community who agree, but presenting a facsimile of a normal filesystem, or reversing the decision about the order in which to put hashes and the human-readable part of filenames (which has compatibility and performance implications that others will fight against it for), these things are pretty far outside what most people who love and contribute to Nix care about. And I don't mean that to say that Nix contributors are aloof, but to emphasize that the people on the Nix core team and other contributors to the ecosystem all have long laundry lists of features that solve problems that are deeply interesting to them or professional vital for them/their company. And those laundry lists don't include backwards-incompatible, far-reaching changes for the sake of what it feels like for newbies and casual users to look at the filesystem on NixOS for the first time.
I kinda suspect that if this changes in the Nix world it will be because Spack's approach becomes popular and widely praised for a long time, so that there is a long period in which the change is seen as an obvious choice despite it seeming like a 'minor' issue to technical stakeholders. But I can picture it happening.
> Hints at other approaches. As in: why not both? Maybe it's possible to have multiple _views_ of a filesystem, so via one API you "see" a flat namespace with hashed directories, and with another a conventional hierarchical one -- just as a Gmail account can be viewed as flat and hierarchical at the same time using an IMAP client.
GoboLinux does have a mechanism like this, IIRC, called 'GoboHide'. So if you run ./configure && make && make install on GoboLinux, autoconf and automake or whatever will find a /usr/lib, and if you run ls against that dir, it will succeed. But you won't see it with `ls /`. NixOS could add this kind of feature, but I'm store paths will still leak out in the settings screens of applications and the outputs of various commands, so it's not quite what we're looking for. That latter problem seems impossible to fix without patching applications, because hard coding store paths in them is an important part of how Nix works. That suggests to me that maybe the Spack way is better— at least then leakage of store paths isn't as shocking to users.
> madness of things like Btrfs volumes, layering another filesystem namespace on top of the Unix one, allowing insanity like multiple distros in one partition
Have you played with Bedrock Linux at all? That might be a fun one. That distro layers other distros together into a single functional whole. So in addition to living on a single partition, you also might have X11 from one distro, systemd from another, and command line utilities from a smattering of 3 others, all running as one system!
> Or installing Windows on Btrfs
I have also tried once to install macOS on ZFS, which apparently can be done. I might try again soon, since I have real Apple hardware to do it on. Last time I tried that on a Hackintosh but quickly ran up against my lack of macOS knowledge.
I suspect you're right. :-(
I have sympathy for the "servers as cattle" approach, but then again, the Linux world is in danger of forgetting where it comes from: from enthusiasts having fun. From people hacking around, learning, exploring, for a laugh, partly because it's free.
And as a vegetarian since my teens, but a sysadmin since my 20s, I have more sympathy for cattle than sysadmins. Sysadmins have choices, and can learn from their forerunners' mistakes. If they don't: tough. Sympathy gone.
I know about GoboHide, yes.
> Have you played with Bedrock Linux at all?
I know of it, but I haven't. I should.
> I have also tried once to install macOS on ZFS, which apparently can be done.
Well, could once. Probably not any more: Apple backed away from ZFS about 15 years ago or so.
https://arstechnica.com/gadgets/2016/06/zfs-the-other-new-ap...
No, you still can! Booting from it isn't a mainstream use case for it, but a port of ZFS to macOS is still alive today.
Project website: https://openzfsonosx.org/
Instructions for using it for /: https://openzfsonosx.org/wiki/ZFS_on_Boot
It installs and creates filesystems just fine. The only part I haven't successfully tested myself within the last year or two is actually booting from it.
> I have sympathy for the "servers as cattle" approach, but then again, the Linux world is in danger of forgetting where it comes from: from enthusiasts having fun. From people hacking around, learning, exploring, for a laugh, partly because it's free.
One thing I believe deeply is that no one ever really masters the Unix environment without living in it. Without a solid foundation of interactive use, programming with the shell as your REPL, puttering around your filesystem with `cd`, you'll never properly learn your way around. 'Learning Linux' in a 'cloud-native' context tends to mean being alienated from all of that, and I think it profoundly hampers the development of fluency and comfort with the system.
To get that from a box (server or desktop), it has to be a home to you, and homes aren't disposable (the Impermanence framework for NixOS aside).
I do think NixOS has a place there, in keeping computing fun and exciting. For me, it was the first truly interesting distro (at least among those I'd consider usable/practical for me) in a long time. (This was back in 2015 or so.) I was a desktop Linux hobbyist before I took up any devops-related work, and for several years, NixOS singlehandedly breathed new life into that hobby for me. As far as I can tell, this is not an uncommon reaction to NixOS among enthusiasts, if not among casual Linux users.
I knew it was around -- I have written about ZFS several times -- but if it's not in the kernel I didn't think you could boot from it any more, and in recent versions of macOS you can't readily add new kernel extensions any more.
(It is possible, by disabling some of the security settings, but it's very much not trivial.)
> no one ever really masters the Unix environment without living in it.
An interesting take. I can't really argue with that.
> NixOS has a place there, in keeping computing fun and exciting
Interesting!
Spack supports the notion of arbitrary "views" of the store, which can be defined declaratively [1]. Apparently we need to write more highlight blog posts and submit them here b/c people don't seem to know about this stuff :)
For example, if you want to make a view that included only things that depend on MPI (openmpi, mpich, etc.), but not things built with the PGI compiler, in directories by name, version, and what compiler was used to build, you could write:
view:
mpis:
root: /path/to/view
select: [^mpi]
exclude: ['%pgi@18.5']
projections:
all: '{name}/{version}-{compiler.name}'
link_type: symlink
If you wanted a different layout you might do:
view:
myview:
projections:
zlib: "{name}-{version}"
^mpi: "{name}-{version}/{^mpi.name}-{^mpi.version}-{compiler.name}-{compiler.version}"
all: "{name}-{version}/{compiler.name}-{compiler.version}"
You can choose to map everything into a single prefix too:
view:
default:
root: ~/myprefix
There are options for choosing what types of links to use and what types of dependencies to link in, e.g., you could exclude build dependencies if you didn't want the cmake you built with to be linked in.
[1] https://spack.readthedocs.io/en/latest/environments.html#fil...
100% you do. I find the term a bit odd, but I've been a "Linux professional" for coming up on 30 years now and I've never even heard of this stuff before.
There is _so much_ in the Linux world that is just badly explained, or not explained, and it's very hard to find cogent explanations. Trying to find them, summarise them, and in some cases, just write them myself is a large part of my job...
And it's a huge field.
One of the reasons some things dominate the headlines is that the creators spend a significant amount of time and effort on outreach. On just talking about what they are doing, why.
That's why there are tonnes of stories about GNOME, KDE, systemd, Flatpak, Snap, Btrfs, ZFS, etc. They talk. They explain.
It's also why there are next to none about Nix, Guix, Spack, and legions of others. They don't.
To pick a trivially small example: Nix talks about being declarative, but it doesn't explain what "declarative" means. And it mentions "purely functional" but it doesn't explain that either. Those things right there are worth about 1000-2000 words of explanation per word. Omit that, and the original message becomes worthless, because it becomes insiders-only.
As it happens through decades of reading about Lisp and things, I more or less get it, but not well, and I struggle to explain it.
What have you found yourself (or customers or other users or whatever) using it for in practice?
https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...
The Unix filesystem layout was bodged together on the fly as Dennis and Ken got more disk drives to attach to their elderly DEC PDP computers.
http://lists.busybox.net/pipermail/busybox/2010-December/074...
It's not gonna happen without somebody making it happen. Be somebody. Systemd is influential because the people making it often are those somebodies but the fact is anyone can be that somebody, you don't need their blessing or that of some standards body to make anything.
I went as far as getting rid of libc. Made a lisp that runs directly on top of Linux using nothing but system calls. It can do anything other software can do: I run strace on a program, my lisp can do what it does if it just replicates those system calls, doesn't matter if it's simple I/O or mounting disks. I want to eventually boot Linux directly into it.
You may get a better result with a device that has a usb dongle. Logitech models reportedly work. The Corsair unit I just bought works well for instance.
Leitner works despite having crap audio over usb.
I don't think that's a valid claim. Something being organized on principles that are different from yours is not the same as it being disorganized in itself.
Either way that old situation is a mess in my opinion, you are of course free to have yours.
I don't prefer to call it that. In fact, it's almost the exact opposite of technical debt, which is generally the result of trying to change things too much, too quickly.
Having stable conventions that account for edge cases that are addressed sufficiently to the point that we don't have to think about them is an asset, not debt, and the principle of Chesterton's Fence ought to always be applied when proposing changes that drastically alter long-established conventions.
Nothing makes me feel dumber than trying to figure out where the heck anything is or gets placed in my Ubuntu machine.
Fun comes when you have things like minecraft launchers that contain everything and all the worlds and saves inside the bundle.
You also _should_ write to a third party folder, preferably `~/Library/Application\ Support`. It's what it's for, after all.
And this is made somewhat worse by Linux file managers trying to hide any part of the filesystem that’s not your home folder or mounted drives.
I get why it’s done, the directory structure of your average Linux install is an absolute maze that’s sometimes confusing even for the technically inclined, let alone the home users targeted by major distributions. It’s ultimately treating the symptom and not the cause, though, and I think more Linux distributions should give serious thought to modernizations of their filesystem structures (as Gobo has).
It’s tempting to play with this myself. My goals would be to come up with a structure that’s reasonably self-explanatory, guides novices away from the dragons, and allows file managers to hide very little (maybe nothing) without consequence.
"dev" is obviously for developers. "run" is where the apps are located. "bin" is the recycle bin.
Corporate jargon is how companies hide away inefficiencies and illegalities. Now, jargon is usually not that, but most of the time it is. The same way programmers said a kilobyte is 1024 bytes (seriously?)
To add to your point, yes, do ask a random person what notepad.exe doe vs what vi or emacs does.
While I agree with that in principle, in practice that's not true for a lot of applications that put a lot of stuff into ~/Library and /Library, and it's not unusual to see multi-step manual instructions on how to uninstall some apps on macOS. (Especially important if those apps add Login items) Windows' Add/Remove Programs at least gives a central space to trigger an uninstall, and most apps stick to it properly.
Whether literally any shell can, I don't know. With zsh, bash and tcsh it is certainly possible.
set completion-ignore-case on
> To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab.
You know why it never bothers me when I navigate in PowerShell (or cmd.exe for that matter)?
Because the shell is helpful for me and don't try to force me to conserve precious ticks and memory of PDP-11 lacking any usability.
It's always amusing to hear 'case sensitivity rUl3z!' fans who totally miss what it's just the result of the constraints of the original systems. It's not a feature.
More so, it's explicitly addressed:
>> To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab.
>> https://gobolinux.org/doc/articles/clueless.html
Just 'set completion-ignore-case On' and have your life immensively better. Why? Because you now would need one less Shift keystroke per every filename starting with capitalised letter even if you don't use GoboLinux.
Or continue like it's still 1977, why not, your VT100, your rules.
EDIT: oh, noticed this later:
> Why bother installing another shell instead of just sticking with bash for normal navigation?
Yes, you don't even bother to know your own shell.
Just saying... macOS does this by default, and a few months ago, I tried to delete a folder called `~/ladybird` and accidentally nuked `~/Library` instead. I wasn't expecting it to autocomplete a filename with a different case.
For non-Mac users, `~/Library` holds more or less all the state for your user account. With it gone, not only do you lose all settings and things, you can't even log in. I had a machine in a very unstable condition and no time to fix it.
I put it to sleep, left it for a month or so until I had a couple of hours spare, created a new user account with admin rights, copied all my files to that account, removed my damaged account, rebooted, created a new user account for myself, copied all my files back in, reset permissions as appropriate, and then logged in to it.
I then had to re-configure all my apps, which took most of the time. Now the machine was stable again, I cleared out the stuff in the admin account.
(No, it's not connected to my network TimeMachine, because it's my work laptop and I want to keep that stuff separate from my personal stuff on my home Macs. All the data is backed up to my company's cloud servers, but that doesn't store any macOS config stuff.)
So in the end, I just had to recreate my browser profiles, reimport my bookmarks and stuff, recreate all my email accounts in Thunderbird – because Mozilla still hasn't got Mozilla Sync for T'bird, dammit – and it was an inconvenience. No actual data lost.
But it has left me strongly conflicted on the subject of case-insensitive tab-completion.
edit: Now I see it's a 20-year project.
That to say the least, the current mess is being forced down or throat by steam, unless your distros don't play video games.
And among the population of gamers, I am pretty sure a large majority have a dedicated gaming rig.
This seems, at face value without a deep understanding, to be the simplest way to do it. Again the caveat is my lack of knowledge.
Flatpak and NixOS are more complex because it's worth it. For example, they don't duplicate exact versions of dependencies on disk.
Doesn't feel like GoboLinux would either, does it?
FreeBSD does a good job with this: applications are installed into a standard Unix filesystem with conventional packages and the ports collection. Isolation is then implemented via jails.
The Linux equivalent of using standalone isolation layers, like firejail, on top of standard distro packaging, is far superior to Flatpak.
All of these are all still behind how Android stores apps. On Android each application can be distributed using a single file that is easy to distribute. Each application is properly sandboxed. Each application gets its own directory. And something all of the other things mentioned here are missing, each application gets its own subdirectories in the app's directory for storing its state (there are different ones for each user).
I ran GoboLinux 012-015 for a few years on a server that I used for hosting version control software and for the most part it kicked ass.
What was a bit of a stumbling point is that if you needed a package that didn't readily exist, you'd have to create the recipe. The language for creating GoboLinux recipes is perfectly understandable, the issue was often one package would depend on a dozen or a few dozen libraries and you'd spend a lot of time chasing that down, getting the versioning for those libraries right, THEN finding a URL for those libraries/packages, and THEN creating the recipe.
I eventually moved over to Debian and I still cringe and config files in "/etc" maybe the binary was put in "/usr/bin" or "/usr/local/bin".
I'm in the camp that finds systemd annoying and kind of like an octopus (you'll often resort to using a find command to locate the associated .service file, you can't rely on them being in once place, the CLI isn't really intuitive) in contrast Gobo had a very simple set of scripts to manage services and it was very easy to work with.
But, the convinience of just being able to 'apt get' what you need or 'dpkg -i <blah.deb>' outweighs the much more sane and intelligence behind GoboLinux. These days the number of Linux distributions people support has dropped from the myraid of options it used to be to now almost always including Debian (or Ubuntu) by default so you it's unlikely you can't get a package or some program installed, even if it outside the repositories.
macOS definitely does something similar to GoboLinux and it makes working with macOS on the CLI (at least prior to the current versions which are fairly user-hostile) pretty easy -- your pen drive will be located in /Volumes, configuration files for a program under ~/Library, etc.
FWIW, if the service is loaded you can just `systemctl status foo` and it'll tell you starting on the second line of output exactly what file(s) are in play, ex.
# systemctl status getty@tty1.service
● getty@tty1.service - Getty on tty1
Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled)
It's frankly kind of inspiring that they've stuck with it.
https://www.gnu.org/software/stow/manual/stow.html
This was very useful in early 2000s running shared linux machines with a diverse set of software for scientific applications.
(He was a local GoboLinux fan, but went off the map. Hope he's fine.)
This is way more meaningful than the /bin & /usr/bin split that distros are increasingly moving away from because multiple versions of the same software or forks can coexist on the same system. This model also makes /usr/local unnecessary.
So, a dependency map that contains "Foo = 1.0" would cause Foo/1.0/bin/uninstall.sh to be the one mapped to /System/Index/bin.
You also said it here: https://news.ycombinator.com/item?id=39533554
I honestly don't see the connection.
The idea of Gobo was to replace the cryptic Unix filesystem hierarchy with something clearer and more human-readable, and in so doing, replace a whole bunch of things that package managers do, making them almost unnecessary.
Your point doesn't address this at all. You're talking about building from source instead of using a package manager, as far as I can see?
But compiling from source still puts the resultant binaries somewhere in the existing Unix filesystem layout. It doesn't matter where the binaries come from. This isn't about where they come from -- it's about where they go.
It’s a shame that it didn’t get more traction. We probably wouldn’t have needed Docker or any of the gazillion package managers that are proliferating today if it had.
100% feel this way too. So much of the reason why we use containers is just not spreading crap all over the filesystem. It's why single binary distributables made popular by Golang are such a winner, ex: Caddy.
> the filesystem is the database
is such an epiphany for GoboLinux, truly atomic.
Of course nix also has one quite big issue, and that it is input addressed rather than content addressed, but its moving towards content addressed model which will reduce rebuilds and resource use https://nixos.wiki/wiki/Ca-derivations
Edit, additionally, yes. Such distributions are suitable for essentially any task for which any other distribution is suitable. The primary caution that I would offer anyone when venturing away from RHEL/Debian is how much you trust whatever organization to still be around in five years. If you're comfortable managing everything yourself, pick whatever; otherwise, it's "safest" to choose something that either contractually will still be around (RHEL), or is governed in a way that ensures some continuity (Debian).
It came along 22 years after Unix itself.
It's never too late.
Remember that Windows itself was a flop until version 3, and that -- Windows 3.0, in 1990 -- was the little snowball rolling down a mountain that brought multitasking multimedia networked GUI computers to the mainstream.
And thereby created the mainstream marketplace of x86-32 computers: the substrate that allowed Linux to grow.
(DOS made so little use of the 80386 that an 80286 PC was adequate, and after 5 years the 386 made little inroads into the mass market -- they were too expensive, even after the 1989 budget-model 80386, the 386SX. But Windows 3 ran much better on a 386 than a 286, and soon after Windows came along, the 286 was dead.)
Yes, they cite that among other UNIX like OSes while completely ignoring the most successful implementation of their idea, (by several orders of magnitude) Windows. I don't find that cute, I find it ignorant.
Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr/local/bin and /etc and the sbin directories. A lot of it has to do with permissions. If you've ever been a member of a multi-user server you might understand.
I will grant you tho; a lot of people never bother learning and just shove binaries where ever they can get it to work first.
In case anyone wants to know. Here is a good explanation:
Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup.
I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr.
I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some.
edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found.
(I don't remember in which distro it's in PATH and in which it isn't.)
I've administered multi-user servers and I can only guess at what you mean. Like... I've seen distros that default non-admin users to not having sbin directories in their PATH, but even then it's not like that's a security thing, it just makes your path a little cleaner. What security benefit do you see to the different directories?
(In fairness, I can see non-security reasons to split things up - the traditional reason is that /bin is local, /usr is on NFS and shared between every machine in the lab, and /usr/local is non-packaged software built from source. But none of that is a security argument.)
[1] https://gobolinux.org/doc/articles/clueless.html "I am not clueless"