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

61–70 of 131 posts

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

#61

Post by digi_owl »

eridius wrote: post #16
paxcoder wrote: post #10

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.

Frankly v3 just clarifies ambiguities in v2 that corporations where driving truckloads through.

It solidifies the freedoms the FSF champions.

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

#62

Post by CMCDragonkai »

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.

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

#63

Post by malka »

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…

Each user would get its own private key that could only be used on its own device. It could not be used to sign software for someone else device

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

#64

Post by yrro »

Pxtl wrote: post #19
arthur2e5 wrote: post #18

Earlier quoted context omitted.

> Establish a new, consistent filesystem hierarchy. systemd is kind of enforcing this already, preferring /usr (where most of the packages go) over naked paths. This is the trend on relatively modern desktop systems, which thankfully preserves standard fs hierarchy while mostly keeping everything in one place. (Unfortunately there are bunches of non-desktop uses for Linux out there.) See also https://freedesktop.org/…

Still, clutters and confuses new users. In wonder if some of the fs apis could hide the silly/redundant directories?

I much prefer compatibility symlinks actually existing in the file system over some complex, hidden pathname resolution override riles lurking in the kernel. That way, Windows lies.

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

#65

Post by mariuolo »

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…

> And this is true for quite a long time. I think the last distro that did /usr merge is Debian and this is already 3 years ago. So I find surprising that people still thinks that this is a issue.

It hasn't happened on openSUSE yet:/

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

#66

Post by rekado »

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…

Much like Gobolinux, Guix also has a completely different filesystem layout. Packages are installed into their own namespace under /gnu/store but then linked to expected locations under a profile root (such as ~/.guix-profile).

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

#67

Post by justincormack »

fit2rule wrote: post #46
takeda wrote: post #22

MacPorts use /opt/local :)

And, interestingly, HomeBrew uses /usr/local "because Apple left it for us when they abandoned this whole mess" ..

/use/local/bin has the big advantage that it is in the default PATH.

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

#68

Post by digi_owl »

Esau wrote: post #20
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…

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

Systemd has basically become the enforcement arm of Freedesktop, that in turn is a cover for RH/Fedora running the Linux user space show.

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

#69

Post by digi_owl »

Jasper_ wrote: post #35
Esau wrote: post #20

Earlier quoted context omitted.

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

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…

That one curious definiton of "reusable"...

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

#70

Post by teamhappy »

/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.)

/usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less).

/usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake).

Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but don't want to install system-wide (single-file C utils that come without man pages, stuff like that).

I'm not sure where the confusion comes from and I don't really see any advantage in merging / and /usr. On the flip side, I do think there's value in keeping /{bin,sbin} as small as possible (because that stuff has to work).

Post reply on HN