Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

lists.busybox.net

Post reply on HN
Print view View original

51–60 of 131 posts

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#51

Post by spc476 »

JdeBP wrote: post #47
Jasper_ wrote: post #35

Earlier quoted context omitted.

The systemd maintainers were one of the first ones to put together a technical proposal and do a lot of the implementation work for the UsrMerge, in a way that was reusable across distros. systemd itself does not depend on being on a UsrMerge'd system, and otherwise, the proposal does not have anything to do with systemd. From https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... "Note that this page discus…

You are quoting 2013 doco. systemd has (again) changed since then. As of 2016, the position is that whilst there is still code in some of the program to handle a split /usr, a significant part of the system (in particular Plug and Play device management) now references /usr and depends from it, to the extent that it is already a requirement that /usr be always present: i.e. that it either be on the root volume or be…

So, as Linus controls the kernel, Lennart wants to control userspace?

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#52

Post by psydk »

m45t3r wrote: post #15

For all people that think this is still a issue: it is not: * Arch Linux: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc... * Fedora: https://fedoraproject.org/wiki/Features/UsrMove * Debian: https://wiki.debian.org/UsrMerge * Ubuntu: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMer... And this is true for quite a long time. I think the last distro that did /usr merge is Debian and this is a…

The Ubuntu document is from 2012 and the merge is not done on 16.04. How can we know if the change is still planned, and when? Is there a roadmap somewhere?

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#53

Post by JdeBP »

ChuckMcM wrote: post #44

Interesting. First there was /bin for the things that UNIX provided and /usr/bin for the things that users provided. Part of the system, it lived in /bin, optional? it lives in /usr/bin. In SunOS 4 (and BSD 4.2 as I recall) the introduction of shared libraries meant you needed a "core" set of binaries for bootstrap and recovery which were not dynamically linked, and so "static" bin or /sbin (and its user equivalent /…

> good enough for Windows right?

Only in the minds of people who don't know much about Windows.

The Windows model is, after all, for globally installed individual packages to be largely rooted at "/Program Files/%COMPANY_OR_PERSON%/%PACKAGE%/" with "%USERPROFILE%/AppData/Local/%COMPANY_OR_PERSON%/%PACKAGE%/" as a root for per-user data. The former dates all of the way back to Windows NT 3.5, the latter "merely" dating back to Windows NT 4 (where it was "Application Data" rather than "AppData").

* https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-sho...

Unix and Linux people will recognize this as akin to NeXTSTEP's ~/Apps, /LocalLibrary, /LocalApps, and so forth from the early 1990s; and to Daniel J. Bernstein's /package hierarchy (for package management without the need for conflict resolution) from the turn of the century.

* http://cr.yp.to/slashpackage.html

* http://cr.yp.to/slashcommand.html

And a few years after NeXTSTEP introduced its directory hierarchy, SunOS 5 (a.k.a. Solaris 2) introduced the System 5 Release 4 /usr merge.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#54

Post by digi_owl »

spc476 wrote: post #51
JdeBP wrote: post #47

Earlier quoted context omitted.

You are quoting 2013 doco. systemd has (again) changed since then. As of 2016, the position is that whilst there is still code in some of the program to handle a split /usr, a significant part of the system (in particular Plug and Play device management) now references /usr and depends from it, to the extent that it is already a requirement that /usr be always present: i.e. that it either be on the root volume or be…

So, as Linus controls the kernel, Lennart wants to control userspace?

I'm not sure Torvalds care about control either way, he just wants to build a kernel to be proud off.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#55

Post by digi_owl »

Hello71 wrote: post #32
dsfyu404ed wrote: post #21

Earlier quoted context omitted.

Systemd walks into a bar, shoots the owner, proclaims it is the new owner, turns the bar into a casino, adds a hotel, a grocery store and an init system.

systemd opens a new bar right next to the most popular bar in town, becomes far more popular (possibly due to better advertising), people complain that their beer tastes worse, and when other people tell them to just go to the original bar, they complain that all their friends are at the new bar.

Also closes the doors on the auto shop next door. Proclaiming you can either go through the bar to get to it, or climb over the barbed wire fence out back to get in.

Others instead use abandoned tools from said auto shop to set up a new one across the road, and get daily ridiculed by the systemd patrons for it.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#56

Post by digi_owl »

bbanyc wrote: post #12

Nitpicking: If you look at the very early versions of the Unix manuals, before even /lib was invented, there was a notion that /bin was the "system" (section 1) and /usr/bin was "user software" (section 6). This fell by the wayside when they ran out of disk space on / and started putting section 1 commands in /usr/bin. At some point the system/user distinction was abandoned and everything but the games got moved to s…

I can't help think that initramfs is a pox on Linux. It seems to lead to all kinds of "solutions" that are bothersome at best to maintain unless you have big dollars at your back.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#57

Post by eridius »

gherkin0 wrote: post #38
eridius wrote: post #30

Earlier quoted context omitted.

Or to put it another way, GPLv3 mandates that your hardware be insecure (because you cannot prevent a malicious actor from installing malicious software on someone's device, which would normally be done by requiring all updates to be codesigned by the manufacturer). And it's not just limited to software that would be installed on the hardware; companies like Apple won't even allow employees to install GPLv3 software…

> GPLv3 mandates that your hardware be insecure (because you cannot prevent a malicious actor from installing malicious software on someone's device, which would normally be done by requiring all updates to be codesigned by the manufacturer). I think that's wrong: http://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys : > I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3…

What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix anything because 99.99% of users will never do that, or even know it exists.

> If Apple is behaving that way, it's Apple's own fault, not the GPLv3's. They could have chosen to design their software in a way that would have given them better options if they are ever forced to comply with the GPLv3, but they chose not to.

That makes no sense. What you said is basically equivalent to "That's Apple's fault, they could have just designed their hardware platform to be completely insecure".

GPLv3 is fundamentally incompatible with having a secure hardware platform. This is absolutely GPLv3's fault.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#58

Post by digi_owl »

ploxiln wrote: post #6
IshKebab wrote: post #2

I wonder what is more likely in our lifetimes - a sane Linux filesystem layout, or viable fusion power. Honestly I'm not sure.

gobolinux - http://gobolinux.org/ - has had a completely different filesystem layout, for many years. It's languished in the past few. archlinux has for a couple of years symlinked /bin, /sbin, and /usr/sbin to /usr/bin, and /lib, /lib64 to /usr/lib https://wiki.archlinux.org/index.php/arch_filesystem_hierarc... If you make your own linux distro from scratch, you can get many of the open source pieces of a linux dist…

Gobolinux still house the old layout for compatibility.

Heck, i think it could adopt any any FS layout it wanted as long as some defined place to house the "Programs" tree was provided.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#60

Post by digi_owl »

ufo wrote: post #33
SquareWheel wrote: post #9

How badly would things break if we tried to "fix" this split today?

One workaround you can do is to add lots of symlinks to keep the old paths working. This is what they do in Gobolinux (a Linux distro that has a radically different filesystem organization)

One funny thing about Gobolinux is that you could still do the equivalent of a / /usr split.

You never really search /Programs for binaries, you aim that at /System/Index (housing the equivalent of the classic FHS for compatibility reasons). This means that things do not really need to live in /Programs to be useful.

And because of that you have two tools DetachProgram and AttachProgram that allow you to place a package (really just a tar-ball of the /programs branch) in an arbitrary location and have them be symlinked into place.

Thing about Gobolinux is that it do not depend on special Gobo only features. Everything is built around tools you will find in any *nix, and any action can be performed manually if need be.

Nor does it demand that something upstream do something special to placate them, as long as --prefix or similar actually works.

Post reply on HN