zlacker

Not really, back then disks were very expensive and you had no choice but to split. And disk sizes were very small.

But, I in a way int kind of makes sense.

/bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime.

's' for items regular users do not need to run, remember, UN*X is a multi-user system, not a one person system like macs, windows and in most cases Linux.

>>jmclnx+(OP)
> /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime.

Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.

>>jmclnx+(OP)
How does splitting help save space?

>>eviks+22
I think it's less about saving space and more that / and /usr can be two separate disks

>>kokada+V
> initramfs, that is a compressed image that includes everything the system needs to boot

Not always (raise your hand if you've had an unbootable system due to a broken or insufficient initrd).

In retrospect, the whole concept of the initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.

>>schmuc+pa
Yes of course it can break. The point is that the stuff needs to be in initramfs. "includes everything" has an implicit "when working".

What seems bad about it to you? Initrd means you only need /boot (or equivalent) to be working at boot time, which seems nice to me. And looking at mine, the image is smaller than the kernel, so it's not wasting a ton of space.

>>schmuc+pa
I rather like it for embedded systems because I can pop a simple installer into it and bundle that with the kernel.

>>schmuc+pa
> initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.

Eh, kinda. That's where "essential" .ko modules are packed into - those that system would fail to boot without.

Alternative is to compile them into kernel as built-ins, but from distro maintainers' perspective, that means including way too many modules, most of which will remain unused.

If you're compiling your own kernel, that's a different story, often you can do without initrd just fine.

>>Dylan1+Cc
More than once I've run into weird issues with missing filesystem drivers and other important things that caused me major grief during an emergency.

Sure it could be blamed on shitty distro maintenance and development but a better architecture would be putting essential things like filesystem drivers in /boot without this extra kludge of rebuilding an initrd (that you hopefully didn't forget to do before typing reboot) which depends on a pile of config files set just right (and oh by the way different in literally every distro).

>>schmuc+2i
A folder in boot could still be missing drivers, though.

Rebuilding an image isn't a big factor there, it's a tradeoff between making setup a bit more annoying versus making it a bit easier to manage your boot files.

>>jmclnx+(OP)
I really should write that "Yes, Virginia; executables once went in /etc." Frequently Given Answer.

Because it was /etc (and of course the root directory) where the files for system boot and system administration went in some of the Unices of yesteryear. In AT&T Unix System 5 Release 3, for example, /etc was the location of /etc/init, /etc/telinit, and /etc/login .

sbin is actually quite complex, historically, because there were a whole lot of other directories as well.

* https://jdebp.uk/FGA/unix-path-and-personalities.html