Live data from Hacker News

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

lists.busybox.net

21–30 of 131 posts

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

#21
post #20
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…

"Note that Arch follows the systemd FHS convention of symlinking" The Systemd convention? What the fuck? Does Systemd have to touch everything??

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.

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

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

Arch still occasionally has some packages installed to /opt. Annoying as hell, but they expect to be there for some reason. Android-studio was the latest unexpected surprise for me.

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

#24
post #23
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…

Arch still occasionally has some packages installed to /opt. Annoying as hell, but they expect to be there for some reason. Android-studio was the latest unexpected surprise for me.

Once upon a time, I read the LSB[1] filesystem hierarchy, of which the only thing I consider useful was that non-distro-provided third party software (i.e. anything you'd buy on a disk and install) should live in opt. It didn't make a huge deal of sense then and it still doesn't now, but it sorta provides a way to know which directories can safely be rm -rf'd.

[1]https://en.wikipedia.org/wiki/Linux_Standard_Base

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

#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 sandbox as it is run.

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

#27
post #16

I want to react to the signature FUD: GPLv3 is clearly a superior copyleft license to GPLv2 despite Linus' latently permissive opinion on the anti-TiVoization clause.

It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.

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 mean install and build scripts), you must also provide the signing keys for the hardware.

This also does not mean that GPLv3 makes software signing impossible and that you must forbid users from rejecting unsigned software if they so wish. It doesn't mean that you have to distribute every secret key that you use for signing software. It merely means that you have to give your users a way to install software on the User Product as they see fit, if they see fit. It's up to the user to decide to override any signing feature or not. It's very much in spirit with GPLv2 that required installation scripts. As far as GPLv3, hardware signing keys are just another part of installation scripts (the actual term used in GPLv3 is "Installation Information").

http://radar.oreilly.com/2007/03/gplv3-user-products-clause....

https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...

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

#28

I like that FreeBSD dedicates a man page, HIER(7), on this topic - https://www.freebsd.org/cgi/man.cgi?query=hier - "layout of file systems"

The other major BSDs:

http://man.openbsd.org/OpenBSD-current/man7/hier.7

http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current

https://www.dragonflybsd.org/cgi/web-man?command=hier&sectio...

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

#30
post #27
post #16

Earlier quoted context omitted.

It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.

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 on their work computer because if a single piece of GPLv3-licensed code makes it into iOS, even completely accidentally, the license demands that Apple release their root signing keys to the world, completely destroying the security of hundreds of millions of devices.

Also don't forget the patent stuff in GPLv3. That's not quite as scary as the anti-TiVoization stuff, but it's still pretty significant for large companies.

Post reply on HN