Debian still having trouble with merged /usr • Hacker News Board

Re: Debian still having trouble with merged /usr

#251

Post by bigbillheck » Wed, Apr 06, 2022, 7:21 PM UTC

jorvi wrote: post #110

scandox wrote: post #74

Earlier quoted context omitted.

First of all I think Eugenics would/will quickly lead to something akin to runaway selection: people will make increasingly absurd decisions mainly driven by status markers / perceptual drift and the human race will breed itself into some mad corner. So I don't believe Eugenics is ever going to do what even its most ardent supporters imagine. Second of all the human race does not have some over-arching goals we need…

You could just have the government mandate a test, and any embryo that has markers (genetic or otherwise) of a chronic debilitating condition is not allowed to be brought to term. If parents do choose this, the kid will fall outside of the healthcare system for its condition and parents will have to foot the entire ongoing bill. Eugenics does not automatically mean we all customize our embryos to be 2m tall geniuses…

> Is 2m the ideal height

I'm just under 2m and I can assure you: it is not.

Re: Debian still having trouble with merged /usr

#252

Post by bigbillheck » Wed, Apr 06, 2022, 7:22 PM UTC

nix23 wrote: post #32

Eduard wrote: post #20

Earlier quoted context omitted.

Comments section is only two levels deep and we have already arrived at Godwin's law.

I don't compare you with a nazi, but you should understand that minority's can take over a country, that's what the nazis did but also the communists in romanov-russia...china is more complicated. It's something completely different, but maybe "nazi" is a red flag for you in comments...because not comfy. EDIT: And more actual, the Taliban's in Afghanistan, an absolute minority but the one with weapons, training, conn…

Billionaires in America.

Re: Debian still having trouble with merged /usr

#253

Post by Beltalowda » Wed, Apr 06, 2022, 7:29 PM UTC

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…

Oh yes, grub is a pain; no argument there. I didn't even like grub 1 and in grub 2 it got several orders of magnitude worse.

I did almost use systemd-boot a few weeks ago though; I moved my SSD to a different laptop and that somehow accidentally booted some remanent of the Windows boot manager, which automatically and helpfully hijacked the lot and now it didn't boot in either the new or old laptop. I ended up using Grub as my distro doesn't provide systemd-boot at all (let alone update hooks), and aside from the hiccup a few weeks ago I haven't had to look at it in over a decade; so for all its ugliness it does "just work" for me, and I figured looking at alternatives would be a bit of a waste of time.

I miss the times where I used FreeBSD and the MBR bootloader they had (have?) just automatically detected things and it would always work without any keffufing about. Just dd these 512K to the start of your disk and presto!

Re: Debian still having trouble with merged /usr

#254

Post by valleyer » Wed, Apr 06, 2022, 7:34 PM UTC

slim wrote: post #244

hyperdimension wrote: post #215

Earlier quoted context omitted.

Is that also where /usr/share got its name for application data? Data that's shared among the rest of the users, as opposed to in their respective homedirs?

I think /usr/share is linux specific. so much later

It exists on BSDs as well. (No idea who did it first.)

Re: Debian still having trouble with merged /usr

#255

Post by xenadu02 » Wed, Apr 06, 2022, 7:35 PM UTC

felixgallo wrote: post #221

PaulDavisThe1st wrote: post #203

Earlier quoted context omitted.

Rob Landley doesn't agree: http://lists.busybox.net/pipermail/busybox/2010-December/074...

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

Well you are wrong. All of that was a retcon after the fact. Ask the folks from Bell Labs because that's where the story comes from:

/usr meant Users. Duh.

They had one disk because disks were expensive. The disk got full, they got a second one, so they moved /usr to the second disk.

Then the root disk got even more full and they moved some binaries to /usr/bin purely for disk space reasons.

Then /usr got full but by this time it was too baked in to change so they invented /home and moved user home directories there on yet a third disk.

Union mounts and other such solutions hadn't been invented yet. It was entirely an ad hoc solution to an immediate problem. This is simply a historical fact. I don't know where the urge to retcon a bunch of justifications for it comes from.

Re: Debian still having trouble with merged /usr

#256

Post by CameronNemo » Wed, Apr 06, 2022, 7:37 PM UTC

_wldu wrote: post #29

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.

$HOME/bin is useful as well. I like that I can have my own software (that I wrote and compiled) in my home folder and don't need to ask a sys admin to install it for me.

I use ~/.local/bin, but yeah using your homedir for as much as possible makes system administration easier for everyone.

Re: Debian still having trouble with merged /usr

#257

Post by Beltalowda » Wed, Apr 06, 2022, 7:38 PM UTC

josefx wrote: post #232

Beltalowda wrote: post #191

Earlier quoted context omitted.

> He is required to accept working patches The thing is that no one wants to interact with a maintainer hostile to the very idea of your patch. Sure, they may be "required" to accept it, but it's not going to be a fun process for anyone involved. Part of Boccassi's concern with their patch is that it might not be merged at all due to what they perceive as "moving goalposts" and "excuses". I think that's not entirely…

> The thing is that no one wants to interact with a maintainer hostile to the very idea His hostility seems to be based on actual reasons if it is true that other systems that performed the unification basically throw out any guarantees made by dpkg. Providing a patch that fixes that would get rid of those reasons. > Part of Boccassi's concern with their patch is that it might not be merged at all due to what they pe…

There seem to me some conflicting accounts and perspectives. Boccassi took the "broken by design" snipe in reply to his patch as "this is going to get rejected", which I don't find completely unreasonable. There were also some other more technical comments from other people, which other people took as "this could get merged, if it gets addressed", which is not unreasonable either.

Yes, the CTTE can force a merge, but that's a pretty uncomfortable situation for everyone – at the very least it's going to be an uphill battle. I wouldn't just dismiss it as a "non-issue".

I spent a good time reading up on some of the mailing list threads this afternoon as I thought it's an interesting social problem, but with a long simmering conflict that's been going on for years it's hard to really get to the bottom of things. No one here seems especially constructive, but it's hard to really get to the bottom of the full context of all of this. I can definitely understand people's lack of motivation in writing fully polished patches if the dpkg maintainer is constantly railing that it's all "broken by design" though.

Re: Debian still having trouble with merged /usr

#258

Post by xenadu02 » Wed, Apr 06, 2022, 7:42 PM UTC

Beltalowda wrote: post #188

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…

> It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. It was really a single system in 1971 that kicked off this trend. Originally /usr was for user files, like /home is today (do you'd have /usr/dmr, /usr/ken, etc.) / and /usr were two physical disks, and at some point the / disk (a 1 or 2MB disk IIRC) was full to they put some things from /bin in /usr/bin as a hack…

I am so happy to see that this correct explanation has finally spread.

When I first started posting on HN the standard response you would get was the retcon explanation like the parent comment or even more nonsensical ones like "usr == UNIX system resources".

At the time cursory searching could not find any actual explanations for this. I started a deep dive into Usenet history and reaching out to folks who knew the history, looking for scraps of info in old Unix books, etc and found the correct explanation as you posted. It was entirely an ad hoc solution to running out of disk space. /usr got moved to the second disk. When root got full again they moved some large binaries to /usr/bin. When the /usr disk got full the user home directories were the easiest thing to move so they moved to /home on a third disk. Every other explanation is purely post-hoc rationalization.

Since then I've been pointing it out when the topic comes up and I am happy that general knowledge of the actual history has started to spread.

Note: I am not taking credit for this, many other people have been correcting the story both before and after me. I'm just glad the true story is seeping into the collective tech community. Sometimes misinformation or incorrect "facts" seem to linger no matter how many times and how many people correct them... but this makes me hopeful that misinformation can be corrected.

Re: Debian still having trouble with merged /usr

#259

Post by CameronNemo » Wed, Apr 06, 2022, 7:43 PM UTC

rektide wrote: post #223

throw0101a wrote: post #217

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. The tight coupling of systemD is a popular criticism of it.

And this is another fine case demonstrating how very very wrong that criticism is. All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it. It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outp…

You say this, but systemd-udevd at one point would sigkill every process on the system if it was not started under systemd (or otherwise in its own cgroup).

Re: Debian still having trouble with merged /usr

#260

Post by Arnavion » Wed, Apr 06, 2022, 7:47 PM UTC

jeroenhd wrote: post #173

tenebrisalietum wrote: post #164

Earlier quoted context omitted.

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 on…

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

/opt - You put everything related to program foo under /opt/foo . Binaries, libraries, configs, it doesn't matter; all go under /opt/foo. Everything specific to foo should be under /opt/foo, such that deleting /opt/foo also wipes all traces of foo from your system.

/usr/local - Equivalent to /opt/jeroenhd, with a substructure mirroring /usr, ie top-level bin, lib, share directories. If jeroenhd compiles multiple things foo and bar and they all end up under /usr/local, removing them after the fact is hard due to the difficulty of determining what files are foo's and what are bar's.

You say "if programs install their files and dependencies in /usr(/local?)/lib anyway" as if you don't have a choice, but that's up to the programs. Eg anything with a configure script should let you configure the prefix to /opt/foo so that it installs there instead of /usr/local

>[...] and why I have /usr/lib, /usr/lib32 and /usr/lib64 when only two directories and the right environment variables should suffice.

/usr/lib - Architecture-independent libraries

/usr/lib32 - 32-bit libraries

/usr/lib64 - 64-bit libraries

(For the Debian family the arch-specific libraries are mostly in subdirectories of /usr/lib named for the triple, eg /usr/lib/x86_64-linux-gnu)

Not sure which of these you'd excise to be left with only two, or what env vars would have to do with anything.