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

1–10 of 131 posts

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

#3

Post by nickpsecurity »

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 themselves.

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

#4

Post by orik »

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…

I was about to ask if any BSD's handle this better, great to see that NixOS does.

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

#5

Post by aidenn0 »

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…

It's a lot more work to retroactively impose a new FS layout on an existing distribution than to come up with a new distribution.

If e.g. Ubuntu did this then

1) They'd have to fix all of the packages in the main repository, and then PPAs?

2) Lots of third party software targeted on Ubuntu would break; this would cause a lot of users to want to stay on pre-change versions of Ubuntu, which probably means it would get forked.

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

#6

Post by ploxiln »

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 distro to use whatever layout you want, while some pieces do require patching and fixing ... but you do have the source :)

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

#7

Post by nickpsecurity »

aidenn0 wrote: post #5
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…

It's a lot more work to retroactively impose a new FS layout on an existing distribution than to come up with a new distribution. If e.g. Ubuntu did this then 1) They'd have to fix all of the packages in the main repository, and then PPAs? 2) Lots of third party software targeted on Ubuntu would break; this would cause a lot of users to want to stay on pre-change versions of Ubuntu, which probably means it would get…

"They'd have to fix all of the packages in the main repository, and then PPAs?"

The NixOS site made it look like they didn't have to do that with their solution: just give a meta-view on what's already there for the users.

"Lots of third party software targeted on Ubuntu would break; this would cause a lot of users to want to stay on pre-change versions of Ubuntu, which probably means it would get forked."

This could happen with any number of changes. Might still be worth it for at least major changes like making broken packages recoverable. I can't imagine myself getting off Ubuntu just because package failures can't brick my system anymore. Some developers might gripe about having to make changes but that makes them look like assholes, not Ubuntu.

I mean, VMS had this feature in the 80's with their versioned filesystem and transactions at app level. It's about time at least the package managers of Linux can do same reliably for apps. At least one of them did to their credit.

Post reply on HN