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

261–270 of 310 posts

Re: Debian still having trouble with merged /usr

#261

Post by felixgallo »

PaulDavisThe1st wrote: post #243
felixgallo wrote: post #221

Earlier quoted context omitted.

Peace to Rob, but disagree with his recollection and the motivation. This was a very active topic in the early commercial Unix days as POSIX etc. were being formulated. It was very common to keep a tar backup of / and to separate out your /usr mount not because you didn't have space on /, but because you wanted to be able to lose/upgrade/etc. / without impacting /usr, and perhaps to move/copy /usr to another machine.…

I started using Unix (as a sysadmin and systems programmer) in about 1986, and my recollection is closer to Rob's. 1. Never used tar(1) for backups till much later, always dump(1), 2. Never wanted to separate backups or upgrades of / and /usr, but always wanted and needed to do that for /usr/local and wherever we put home dirs in those days (which I don't recall right now). 3. The / and /usr thing was definitely expl…

It's entirely possible that there were multiple rationales/retcons at various stages, maybe in serial or parallel; we could all be right. My 'been there' is also from ~1986 (AT&T 3b2, 300 baud acoustically coupled to an AAA-30). That said, the idea of / immutability and /usr variability was highly valued for its systems encapsulation properties for many decades, regardless of how we got there. As others in this thread have indicated, it's still considered valuable for that reason in space-constrained and security-critical domains (e.g. IOT).

Re: Debian still having trouble with merged /usr

#262

Post by __david__ »

rollcat wrote: post #178
codedokode wrote: post #104

Earlier quoted context omitted.

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

I wish two things happened... All OS's around the world implementing "#!python3" (or similar) as a shorthand to "#!/usr/bin/env python3", and in the meantime using #!/usr/bin/env to transition.

The reason that hasn't happened is because `#!` is a kernel level thing, but the `PATH` env is a userspace thing. I suspect even adding env parsing to the kernel would not be viewed as a favorable change…

Re: Debian still having trouble with merged /usr

#263

Post by roelschroeven »

codedokode wrote: post #104
Tor3 wrote: post #9

I understand the problem dpkg is facing (can't know the canonical pathname for an object is, in some cases), but I have huge problems understanding why a symlink farm is preferable. The last thing I want to see on my Debian system is directories with hundreds or maybe thousands of symlink entries. There must be a way to let dpkg do its job if the directory-symlink approach is used instead, surely? (/bin -> /usr/bin)

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

I must be missing something, because I don't see how a link farm doesn't have the exact same problem.

In the case of symlinked directories we have:

  - the binary lives in /usr/bin/python3
  - /bin is a symlink to /usr/bin
  - /bin/python3 therefore refers to /usr/bin/python3
We can use either /usr/bin/python3 or /bin/python3.

In the case of a link farm we have:

  - the binary lives in /usr/bin/python3
  - /bin/python3 is a symlink to /usr/bin/python3
Again we can use either /usr/bin/python3 or /bin/python3.

As far as I can see, both methods allow insufficiently careful developers to hardcode the wrong paths. What am I missing?

Re: Debian still having trouble with merged /usr

#264

Post by throwaway48375 »

tenebrisalietum wrote: post #164
BlinkenBlinken wrote: post #158

Current state of the UNIX file hierarchy is a mess. Many incarnations of GNU/Linux systems didn't contribute to a more elegant yet simplified directory structure. Just pick the one you like the most and serves the purpose of your desires. As for merged /usr, recently using Arch Linux for desktop use. Works decent enough to getting things done.

Elaborate. I don't find the UNIX file hierarchy complicated, but there are some historical quirks and artifacts (like `/var/lib`). The difference between `/usr/X` and `/X` is about the worst of it IMHO. Everything important is usually at most 3 levels deep and the short names are very convenient (versus "C:\Users\xxx\Documents and Settings"). Compare to things like Windows: c:\windows\system32 that has 64 bit stuff i…

One of my personal favorites is C:\Windows\System32\Drivers\etc\hosts.

Re: Debian still having trouble with merged /usr

#265

Post by __david__ »

rektide wrote: post #222
Beltalowda wrote: post #195

Earlier quoted context omitted.

I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". We…

Systemd-boot is a dream. Why anyone would tolerate or think grub2 is an acceptable piece of software is beyond my understanding. grub.cfg used to be human editable, but has evolved & morphed into some massive gnarly twisted mess of inscrutible noise that only multiple layers of shell scripts can output. It's become a write-once-read-never disaster. And if i recall it's not even live. You still have to install that co…

I loved grub (1)--being able to fix a boot configuration issue during boot time was such a amazing upgrade over lilo. When I first saw grub2 and learned how it worked it struck me as the platonic ideal of the second system syndrome[1]. Everything about it was more complicated, expansive, configurable. The fact that they need `grub-mkconfig` is a sign that it went horribly wrong.

I had not heard of systemd-boot, I will check it out…

[1] https://en.wikipedia.org/wiki/Second-system_effect

Re: Debian still having trouble with merged /usr

#266

Post by LeoPanthera »

mcguire wrote: post #250
nickcw wrote: post #89

Just in case anyone is wondering why we had (or used to have) /bin and /sbin directories as well as /usr/bin /usr/sbin here is my understanding of it. It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. Therefore /usr was a separate disk which might not be available during boot. This meant that you needed to put all the binaries you needed for boot in /bin and /sbin…

Old Unix guy here: That is my understanding as well. But then the question becomes, why not get rid of /usr?

Having the "immutable" parts of UNIX reside in a single directory is often useful. It can be mounted read-only, for example.

Re: Debian still having trouble with merged /usr

#267

Post by dagw »

tzs wrote: post #23
busterarm wrote: post #16

Earlier quoted context omitted.

They're talking about things that distro maintainers care about, namely servers. They are primarily not concerned with your workstation.

Was Solaris more used than HP-UX or AIX in 2012?

Can't speak about AIX, but it was massively more used than HP-UX. Solaris was still under pretty active development and adding new and cool features in 2012, while HP-UX seemed pretty much abandoned by HP. Itanium on HP-UX was HPs last big push on HP-UX, but after that failed to catch on they seemed to give up on the OS.

Re: Debian still having trouble with merged /usr

#268

Post by jeltz »

xyzzy_plugh wrote: post #236

As a Debian user in a previous life, and a current NixOS user, this whole debacle amuses me greatly, as I no longer give a shit about paths like /usr/bin or /bin, beyond a handful of binaries needed to bootstrap my environment. I've even moved those paths into a read-only filesystem on some systems!

This could happen in any distribution which does not have a powerful dictator at the top. Almost nothing about this issue has to do with paths. It is one maintainer of a core package who obstructs the Debian project which is enabled by Debian's distributed nature with no powerful dictator at the top.

Re: Debian still having trouble with merged /usr

#269

Post by caylus »

roelschroeven wrote: post #263
codedokode wrote: post #104

Earlier quoted context omitted.

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

I must be missing something, because I don't see how a link farm doesn't have the exact same problem. In the case of symlinked directories we have: - the binary lives in /usr/bin/python3 - /bin is a symlink to /usr/bin - /bin/python3 therefore refers to /usr/bin/python3 We can use either /usr/bin/python3 or /bin/python3. In the case of a link farm we have: - the binary lives in /usr/bin/python3 - /bin/python3 is a sy…

> - /bin/python3 is a symlink to /usr/bin/python3

You don't symlink everything in /usr/bin to /bin, just "all regular files that have traditionally been in /bin" (per the article).

python3 has not traditionally been in /bin, so /bin/python3 would not be linked.

Re: Debian still having trouble with merged /usr

#270

Post by scns »

mwcampbell wrote: post #45
agumonkey wrote: post #14

Earlier quoted context omitted.

> tyranny of the minority this is a trendy thing too, very often minorities who felt ignored, are now pushing to get more because of the tiranny of the majority had flaws (but to me is mostly unavoidable due to the natural economies of scale it grants). I don't know how one can design a social system where you balance both in the right way.

> the tiranny of the majority had flaws (but to me is mostly unavoidable due to the natural economies of scale it grants). In a different context, this is a source of frustration for me as a (partially) blind person advocating accessibility for blind people. The world is designed around the assumption, correct for most people, that people have the high-bandwidth, low-latency sense of sight. And that does lead to the…

The nazis tried it...

https://en.wikipedia.org/wiki/Lebensborn?wprov=sfla1

Post reply on HN