|
|
Subscribe / Log in / New account

Benefits

Benefits

Posted Jun 2, 2023 22:29 UTC (Fri) by ballombe (subscriber, #9523)
In reply to: Benefits by corbet
Parent article: Seeking the endgame for Debian's /usr merge

So Sam lists only two benefits, the first being cosmetic and the second entirely speculative, using as examples OS that did not do the merge. This is far from compelling.


to post comments

Benefits

Posted Jun 2, 2023 23:20 UTC (Fri) by pebolle (guest, #35204) [Link] (6 responses)

You're beating a dead horse.

All distributions decided that "/usr merge" should be done, even Debian. What this article is about is that Debian is being Debian so it discusses how that should be done for about a decade.

(It sometimes feels there's a tendency among the LWN readers to think they're more rational than people not into software. "MBAs", lawyers, "beancounters", politicians, whatever. They're too dumb to understand software. Ha, ha!

Guess what. The fact that LWN is still reporting on this /usr nonsense indicates that people writing software are prone to make the same mistakes that those that do not write software make. We're all the same! Or worse, perhaps the hubris of software developers makes them more likely to make mistakes.)

Benefits

Posted Jun 5, 2023 22:10 UTC (Mon) by jccleaver (guest, #127418) [Link] (5 responses)

>All distributions decided that "/usr merge" should be done, even Debian. What this article is about is that Debian is being Debian so it discusses how that should be done for about a decade.

Few if any distributions decided that "'/usr merge' should be done;" they decided to stop fighting Lennart and the systemd "cabal" and relented. Big difference.

Benefits

Posted Jun 11, 2023 11:07 UTC (Sun) by anselm (subscriber, #2796) [Link] (4 responses)

The main observation here is that once you've done the /usr merge, there are various advantages that result from this, but the main argument against it seems to be “it's not what we're used to, and we don't like it”. (Now where have we heard that before?) It's also not really a systemd thing; systemd doesn't care whether a system has been /usr-merged or not.

Why should the structure of today's systems be beholden to the fact that 50 years ago some guys couldn't fit all of their software on one hard disk?

Benefits

Posted Jun 18, 2023 18:55 UTC (Sun) by birdie (guest, #114905) [Link] (3 responses)

> Why should the structure of today's systems be beholden to the fact that 50 years ago some guys couldn't fit all of their software on one hard disk?

Exactly.

I wonder what benefits the original divided system had. I cannot think of any. Yeah, 30 year ago or so /usr was too big and /bin /lib /sbin were necessary to boot the system. We've long migrated to initrd which made this division redundant. Modern disk are crazy spacious, so again this division is redundant.

Benefits

Posted Jun 19, 2023 9:25 UTC (Mon) by geert (subscriber, #98403) [Link] (1 responses)

- You can mount /usr read-only most of the time, which means
- less chance of it becoming corrupted, either due to manual errors or due to bugs,
- no need to wait for fsck to finish checking your huge /usr file system on every boot.
- You can share/clone /usr among multiple machines (compared to /var, which is machine-specific).

Benefits

Posted Jun 19, 2023 12:57 UTC (Mon) by anselm (subscriber, #2796) [Link]

Yes, but all of these also apply to a post-/usr-merge system.

The root/usr split is an accident of history that is now finally getting fixed for good (in Debian GNU/Linux, anyway – as with. e.g., the init system, most other Unix-like systems including many other Linux distributions have addressed this ages ago). There's really no more to be said other than let's get it over with already.

Benefits

Posted Jun 19, 2023 13:45 UTC (Mon) by farnz (subscriber, #17727) [Link]

Having the root directory be completely ephemeral (could be a tmpfs set up by the initramfs) is useful, because it makes it trivial to do quite major surgery on your installation.

If you have the virtual filesystems (/proc, /dev, /sys etc), a /tmp for "temporary files, may be deleted any time", a /system (could be named /usr) for the installed system, and a /user-data (could be named /home) for user data, you now have some nice properties. First, you can unmount the user data at any time, in order to protect it somewhat from mistakes. Second, you can do things like take a snapshot of the current system area, do major surgery (e.g. try to convert in place from x86-32 to x86-64), and just roll back cleanly if your major surgery goes wrong. Thirdly, you now don't treat any partition specially in a rescue situation - because / is an ephemeral tmpfs, you just create one, mount in all the FSes, and now you have your rescue layout to examine.

With 20/20 hindsight, putting things directly on the root FS was a bad decision. But it's often better to make a bad decision and get something working than to never get anything to run at all for fear of making a mistake.

Benefits

Posted Jun 3, 2023 5:53 UTC (Sat) by vasvir (subscriber, #92389) [Link]

I think the benefits listed in the message are substantial even though the poster thinks that while cool may be the cost is not justifiable.

Path portability is not a cosmetic change and I have been bitten many time by it.

The second one to have the system under or directory /usr is tidier than the alternative. Everything can be done both ways albeit with minor difficulties. The question is if we never clean our home at which point it becomes intolerable? Maybe we get used to its quirks and its little foot guns here and there and even somebody depends on it xkcd style. But is this reason to never clean up? What are newcomers supposed to feel when everything feels so crufty and overloaded with history?

I understand that I am not the one that does the cleaning and tide up so my opinion doesn't carry any value here.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds