The very odd split-up of bin and sbin

Chat about Linux in general
Post Reply
User avatar
Level 4
Level 4
Posts: 334
Joined: Thu Jul 14, 2016 3:40 am

The very odd split-up of bin and sbin

Post by Faust » Mon Mar 20, 2017 8:35 am

There are some really odd bits of legacy code in Linux , and some has been inherited from Unix .

eg. The UNIX and GNU/Linux file-systems

I've often wondered ....
How did we get the very odd split-up of bin, sbin [ usr/bin , usr/sbin ] ?

It seems to be one of those peculiar things that just got carried on indefinitely . for no apparent reason ( or not ?? )

The story is that the original UNIX developers ran out of hard-disk space for their OS .
They had to buy an additional 1.5 MB hard-disk pack ( at huge expense at the time ) to add to their original two
.... it seems surreal now , when a few dollars buys 16GB or more on a USB flash drive.

Anyway , here's the full story , just in case anyone is still interested ..... or even still awake ! ... 74114.html

BTW - " GNU/Linux " .... yes , I take the Stallman view with these things :)

Edit : corrected the link -
@Flemur ... thank you !

Last edited by Faust on Mon Mar 20, 2017 11:31 am, edited 4 times in total.
" And so it goes " - Kurt Vonnegut
The modern reality and the satirical parody are rapidly converging .

User avatar
Level 15
Level 15
Posts: 5641
Joined: Mon Aug 20, 2012 9:41 pm
Location: Potemkin Village

Re: The very odd split-up of bin and sbin

Post by Flemur » Mon Mar 20, 2017 8:58 am

This link works: ... 74114.html

I think some of the worst stuff in Linux is generated by ; they're awful.

Tho pretty fancy for the time, "X windows" is another stupid holdover from Unix.

And - blasphemy ahead - I think MS does the kernel & driver model better. Dunno if the bright idea for putting hundreds of drivers in one "kernel" comes from Unix...quite possible, since there weren't all that many devices back then, but it's not a good bright idea.
Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up....right?
Mint 18.3 Xfce/fluxbox/pulse-less
Xubuntu 17.10/fluxbox/pulse-less

Level 7
Level 7
Posts: 1757
Joined: Sun Mar 27, 2016 6:58 pm

Re: The very odd split-up of bin and sbin

Post by rene » Mon Mar 20, 2017 9:42 am

Flemur wrote:Dunno if the bright idea for putting hundreds of drivers in one "kernel" comes from Unix...
Not really no. Linux is a modular kernel and the vast majority of drivers as well as other functionally discrete bits of code such as filesystem-types can and for distributions will be modules. There's little functional downside to having lots of modules installed on the system; ones for functionality and/or hardware you do not in fact have are not loaded, just sit around your disk taking up a tiny bit of space. You can also of course always compile and install your own kernel, leaving fully out all you don't need.

But the fact that these drivers are supplied with the kernel is an important characteristic of the open-source and specifically Linux development model. All Linux code is available to any interested programmer and closed drivers/modules are in this environment frowned upon: even one closed module means a system cannot ultimately be trusted since all kernel code, including modules, runs at the highest privilege and can do literally anything it wants. The FSF side of the Linux-scape would have this mean any such module would be banned outright; the engineering side is quite a bit less dogmatic but doesn't on the other hand compromise it's engineering principles to make allowances for closed code. Specifically, wants to be free to improve any part of the kernel at any time they see fit; will not provide for a stable binary interface for closed modules. With the level of churn in the Linux kernel this means that basically no non-trivial external module stands a chance of working unchanged with more than a few point-releases (and in reality it is worse; a single point-release with some specific set of options that also need to match between kernel and module is enforced.) With the (often) issues companies have with open code and (always) with frantically updating a driver to track today's kernel for years on end, the only workable model is having open drivers, integrated/maintained along with the kernel itself, where they will be changed right along-side the kernel-side interfaces they rely on, and by those changing those interfaces in the first place.

That is, more than "a bright idea" it's a near direct consequence of the open development model...

Post Reply

Return to “Chat about Linux”