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

Debian still having trouble with merged /usr

lwn.net

Post reply on HN
Print view View original

51–60 of 310 posts

Re: Debian still having trouble with merged /usr

#51

Post by iso1210 »

hyperman1 wrote: post #35
Cloudef wrote: post #11

Haven't used debian or debian based systems for many years. They do too much "automagic" things behind your back and thus tend to brick themselves, especially during major updates. Not really sure how they got so popular. The packaging ecosystem is also kinda mess.

From this comment, I assume you ran testing or unstable. Stable is great for letting up a server and let it run on its own for years without any maintenance (HN warning: No maintenance is of course never a good idea, but at least Debian made it possible) Testing ran in update conflicts at least once a month, but it was generally easy to resolve without bricking. Unstable, well, the name says it all.

Haven't run debian en-mass for a long time, for stable servers I stick the latest ubuntu 2004 and have unattended upgrades on, I haven't had any issues yet

Re: Debian still having trouble with merged /usr

#53

Post by pabs3 »

zozbot234 wrote: post #44
hashhar wrote: post #31

Earlier quoted context omitted.

Not everything is a binary. Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks. No more wondering where the various tools live since everything lives in /usr/bin and more.

The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted. Keep in mind that the approach of booting from initrd is quite non-idiomatic and used only for convenience wrt. a generic distro install; you're generally meant to recompile your kernel so that it can mount / directl…

You still need an initramfs in the case your bootloader/kernel doesn't support your filesystem; for eg GRUB didn't support LUKS2 and the Linux kernel can't boot LUKS directly without userspace tools to input the passphrase etc.

Re: Debian still having trouble with merged /usr

#54

Post by dataflow »

ssl232 wrote: post #39
sph wrote: post #4

Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

I mean, C++ is designed by committee, and it's hard to deny that it's been pretty successful too, regardless of what people's opinions on the language are. Both styles have flaws, but both can be adequate if you put in the right incentives and the right people.

Re: Debian still having trouble with merged /usr

#55

Post by sph »

derefr wrote: post #13
sph wrote: post #7

Earlier quoted context omitted.

I'm quoting the article: "Debian took a more incremental approach, in part because it strives not to make wholesale changes to users' systems like those required by a flag-day upgrade to a merged /usr. In 2016, the ability to voluntarily switch to that scheme was added, then some attempts were made for newer versions of the distribution to be installed with a merged /usr by default. [...] The location of some files w…

> The fact that the committee took a decision that the core package manager can't support is baffling to me. Why? Presumably the committee would be thereby deciding to drive development of the package manager toward whatever is required to support the high-level goal.

Well, this hasn't happened, and now we have the situation mentioned in this article.

Re: Debian still having trouble with merged /usr

#56

Post by pabs3 »

ssl232 wrote: post #39
sph wrote: post #4

Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

The Debian Project Leader election voting is going on right now, but the powers they have under the constitution mean the position is mostly a figurehead/administrator. Governance is more distributed in Debian; there is the technical committee to resolve technical disputes, the release team, the archive admin team and other teams.

https://www.debian.org/devel/leader https://www.debian.org/vote/2022/vote_002 https://www.debian.org/devel/constitution#item-5 https://wiki.debian.org/Teams/DPL

Re: Debian still having trouble with merged /usr

#57

Post by erik_seaberg »

enriquto wrote: post #17

I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round? Let's keep our binaries out of /usr! (as a first step to remove /usr altogether, since it has a confusing name). I long for a day where PATH=/bin is all we need.

Keeping /usr/bin is a smaller change, because that’s where most binaries were before the merge. Only a few essential repair tools traditionally lived in /bin because that made each host store its own copy (rather than maybe depend on NFS).

There will always be sets of tools managed by the distro or my org or my team or me, and it’s pretty important to segregate them to avoid and resolve conflicts, so I expect at least four entries in $PATH for the foreseeable future. Plus whatever messes vendors care to dump somewhere in /opt.

Re: Debian still having trouble with merged /usr

#58

Post by masklinn »

zozbot234 wrote: post #44
hashhar wrote: post #31

Earlier quoted context omitted.

Not everything is a binary. Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks. No more wondering where the various tools live since everything lives in /usr/bin and more.

The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted. Keep in mind that the approach of booting from initrd is quite non-idiomatic and used only for convenience wrt. a generic distro install; you're generally meant to recompile your kernel so that it can mount / directl…

> The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted.

The original point of a non-merged /bin was that /usr/bin was a spillover from when they ran out of space on the primary drive back in the 70s, so there was a slapdash split where the stuff necessary for bringup was kept in /bin and the rest would be kicked down to /usr/bin, in a very inconsistent manner depending on the system’s evolution.

In fact that’s also why users were moved from /usr (the original location, hence the name) to /home: /usr ran out of space, so they added a third disk and moved the user directories over there.

> Keep in mind that the approach of booting from initrd is quite non-idiomatic

How can you claim that it’s non-idiomatic when it’s the standard approach?

Re: Debian still having trouble with merged /usr

#59

Post by zozbot234 »

pabs3 wrote: post #53
zozbot234 wrote: post #44

Earlier quoted context omitted.

The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted. Keep in mind that the approach of booting from initrd is quite non-idiomatic and used only for convenience wrt. a generic distro install; you're generally meant to recompile your kernel so that it can mount / directl…

You still need an initramfs in the case your bootloader/kernel doesn't support your filesystem; for eg GRUB didn't support LUKS2 and the Linux kernel can't boot LUKS directly without userspace tools to input the passphrase etc.

Your distribution needs an initramfs for that reason; you as a user can just recompile the kernel so that the modules it needs are built-in rather than needing to be loaded separately from a ram-disk. If you need an early-boot file system at all (as with an encrypted /), it can be provided in /boot/ and then "swap root" to / at boot like initrd does.
Post reply on HN