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

171–180 of 310 posts

Re: Debian still having trouble with merged /usr

#171

Post by necovek »

mwcampbell wrote: post #72
scandox wrote: post #70

Earlier quoted context omitted.

I think parent poster is actually only partially blind

Correct. Legally blind, meaning, for example, that I can't drive, but with enough sight to read text up close if it's large enough. Edit to add: I do increasingly depend on a screen reader, though not yet for my actual programming work. ETA 2: Sorry for the confusion in the original comment. I've become wary of terms like "visually impaired", because they wreak of over-sensitivity and political correctness. But there…

Nah, you were precise enough, I just misread the "like me" part — my apologies.

Re: Debian still having trouble with merged /usr

#172

Post by faho »

upofadown wrote: post #131

>Improved compatibility with other Unixes/Linuxes... A quick check reveals that OpenBSD presently has separate /bin and /sbin. FreeBSD also has a separate /lib. Exactly what were the other Unixes/Linuxes that this was supposed to improve compatibility with? I hope was not just Solaris...

The idea is, if something hardcodes e.g. /bin/grep because it was written on a system where that's where grep is, it will suddenly start working because now grep is also accessible via /bin/grep.

So it's compatibility in the sense of making things work (instead of failing over pointless differences), not in the sense of being the same.

Re: Debian still having trouble with merged /usr

#173

Post by jeroenhd »

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…

All file system hierarchies contain complicated rules and systems that have been built in by the people who designed them decades ago.

I still don't know what I'm supposed to do with /usr/local, what the difference is between /usr/share and /usr/local/share, what the point of /opt is if programs install their files and dependencies in /usr(/local?)/lib anyway and why I have /usr/lib, /usr/lib32 and /usr/lib64 when only two directories and the right environment variables should suffice.

There are subfolders in /dev that feel like they don't need to be subfolders. There's /tmp and three other places that contain temporary files that should get cleaned on boot. PID files appear strwen across /var/run and /tmp/.

/var can contain just about everything. Most of /var feels like it should actually be inside /var/spool but you're not going to see much in there except for a mail queue to nowhere on desktop Linux machines.

Then we come to the XDG standard everybody just blatantly ignores that tries to bring order to the chaos that is program-generated files in the home directory.

And then there's also snap. Snap looks at any directory convention, laughs, spits in your face for good measure, and creates a folder called "snap" wherever the fuck it wants to. I'd purge it from my system if the snap people hadn't convinced some tools I use to support it as the main distribution method.

I'm sure there are guides out there that explain every directory and their purpose. I've read one of those guides, noticed that at least a third of the common programs I use clearly haven't read it, and forgotten the details already. The file hierarchy of a fully-fledged desktop Linux is kind of a mess, and that's just what you get when your core system is formed by combining the work of hundreds or thousands of volunteer projects.

Re: Debian still having trouble with merged /usr

#174

Post by anotherhue »

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…

FreeBSD's hier (7) has some good background info on older Unixisms https://www.freebsd.org/cgi/man.cgi?hier(7)

Of note, though not called out in that link, FBSD uses /usr/home/foo as the home directory of foo, not /home/foo (though they are often symlinked)

Re: Debian still having trouble with merged /usr

#175

Post by BuildTheRobots »

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…

The obvious followup question that jumped to mind is "what's the difference between /bin and /sbin?".

Both contained files required to boot in single user mode, however /sbin contains executables not usually executed by normal users. sbin short for "System Binaries" maybe?

Re: Debian still having trouble with merged /usr

#176

Post by rollcat »

torstenvl wrote: post #166
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 we're linking hundreds of individual files on a single large partition, why not make them hard links and avoid the clutter?

Dealing with hard links in the real world is a bit tricky. For example, "mv a b" is very different from "cat a > b". You have to do the equivalent of the latter in order to update a file in-place without updating every single hard link, which is problematic since writing to a file is not atomic the way an unlink+rename is. It's a bit of extra logic for the package manager to deal with, while a symlink is just a symlink.

Re: Debian still having trouble with merged /usr

#177

Post by egberts1 »

andrepd wrote: post #98
mwcampbell wrote: post #72

Earlier quoted context omitted.

Correct. Legally blind, meaning, for example, that I can't drive, but with enough sight to read text up close if it's large enough. Edit to add: I do increasingly depend on a screen reader, though not yet for my actual programming work. ETA 2: Sorry for the confusion in the original comment. I've become wary of terms like "visually impaired", because they wreak of over-sensitivity and political correctness. But there…

"Visually impaired" is a WHO technical term that encompasses visual acuity worse than 6/18.

WHO depends on labeling people as “crippled” despite their inability to define normal.

Re: Debian still having trouble with merged /usr

#178

Post by rollcat »

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

Re: Debian still having trouble with merged /usr

#180

Post by voidfunc »

BuildTheRobots wrote: post #175
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…

The obvious followup question that jumped to mind is "what's the difference between /bin and /sbin?". Both contained files required to boot in single user mode, however /sbin contains executables not usually executed by normal users. sbin short for "System Binaries" maybe?

I always understood it as statically linked binaries that could be used regardless of the state of the rest of the system.
Post reply on HN