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

81–90 of 131 posts

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

#81

Post by perfunctory »

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…

Excuse me my naivety but I don't really understand what you mean by "This is not an issue and hasn't been for quite a long time". When I do ls / on any of my machines I still see /bin /usr/bin and all the rest.

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

#82

Post by majewsky »

dredmorbius wrote: post #39

Reasons why you still might want to keep / and /usr isolated: 1. NFS mounts. Your local or initial BOOTP image has a minimal root, your (non-root-writeable, BTW) NFS /usr has Other Stuff. 2. Mount options. Root is often (and perhaps still must be -- /etc/mtab for example -- I've stopped closely tracking discussion to make root fully read-only) writeable. It may also require other mount permissions, including device f…

mtab is not a problem anymore. On Arch, /etc/mtab is just a symlink to /proc/self/mounts.

As for the recovery partition, you don't need the split for that, either. Just have a live system on the recovery partition that mounts the normal root FS. Then you can chroot into there for recovery tasks.

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

#83

Post by majewsky »

Annatar wrote: post #48

The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, "for third party and unbundled applications". Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can nev…

> Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems

What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.

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

#84

Post by gqg »

perfunctory wrote: post #81
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…

Excuse me my naivety but I don't really understand what you mean by "This is not an issue and hasn't been for quite a long time". When I do ls / on any of my machines I still see /bin /usr/bin and all the rest.

They are all symlinked - just different names for exactly the same directory in the file system. If you compare the contents, you will find they are identical.

Edit: Nevermind, I am wrong :)

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

#85

Post by kps »

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…

  > And /home never existed before Linux
SunOS used /home before Linux existed.

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

#86

Post by tremon »

gqg wrote: post #84
perfunctory wrote: post #81

Earlier quoted context omitted.

Excuse me my naivety but I don't really understand what you mean by "This is not an issue and hasn't been for quite a long time". When I do ls / on any of my machines I still see /bin /usr/bin and all the rest.

They are all symlinked - just different names for exactly the same directory in the file system. If you compare the contents, you will find they are identical. Edit: Nevermind, I am wrong :)

  $ ls -1 /bin | wc -l
  127
  $ ls -1 /usr/bin | wc -l
  2271

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

#87

Post by tremon »

shirro wrote: post #26

The /bin vs /usr/bin split makes perfect sense but I always thought /sbin was superflous to happy to see it being deprecated by many distros. I expect with the increasing moves towards app stores and sandboxing on all platforms that the days of installing packages contents all over the filesystem are limited and things like xdg-app are probably going to take over with an app being mounted into the filesystem in a san…

Funny. I always thought the /bin vs /sbin split made more sense than / vs /usr. I very much prefer that my shell's autocomplete does not stop on binaries that I have no business running as a normal user, so I like that root-only tools are in /sbin.

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

#88

Post by tremon »

eridius wrote: post #30
jordigh wrote: post #27

Earlier quoted context omitted.

I wonder if people even know what those restrictions are and how exactly the anti-tivoisation clause works. It does not forbid anyone from running software on tivoised devices, which is what some people seem to think it does. All that it requires is that if you distribute the software primarily to be used on a User Product (as GPLv3 calls it), then as part of the installation information (which in GPLv2 used to just…

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

Oh please. It really doesn't, it merely mandates that the user is able to override a manufacturer's lockdown. Not that any nitwit should be able to override a user's lockdown.

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

#89

Post by dTal »

eridius wrote: post #57
gherkin0 wrote: post #38

Earlier quoted context omitted.

> 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…

>GPLv3 is fundamentally incompatible with having a secure hardware platform

That's funny because Chromebooks ship with GPLv3 code.

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

#90

Post by nickpsecurity »

CMCDragonkai wrote: post #62
nickpsecurity wrote: post #3

NixOS is one of the few distros that recognizes and solves this problem: https://nixos.org/nixos/about.html A solution like theirs should become the default. Their transactional, package management too given the number of times my Linux packages got broken by some ridiculous crap. That even a smaller outfit could knock out two problems, one major, shows these bigger distros could be gradually knocking out such issues…

You don't lose anything too, you can still imperatively build packages if necessary.

What do you mean? That sentence can read a few ways.
Post reply on HN