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

181–190 of 310 posts

Re: Debian still having trouble with merged /usr

#181

Post by KptMarchewa »

jeffparsons wrote: post #120
ssl232 wrote: post #39

Earlier quoted context omitted.

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 can't deny Python's success, but I wouldn't hold it up paragon of change management, either. 13+ years after the release of Python 3 and 2+ years after 2.7's EOL, I'm still dealing with Python dependencies that don't work on Python 3 because maintainers preferred to pretend that Python 3 wasn't happening and that Python 2.7 would be around forever. It's confusing as heck trying to figure out what I should even expe…

>It's confusing as heck trying to figure out what I should even expect to work, because some authors treat it as obvious that their code will work on both Python 2 and Python 3, while other authors treat it as obvious that they still only support Python 2.

I believe grand majority of packages already dropped 2.7 from latest releases, given that it's officially dead for over two years.

Re: Debian still having trouble with merged /usr

#183

Post by ink_13 »

ntauthority wrote: post #108
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…

Adding to this historical reasoning, it is to be noted that in traditional Unix, /usr was pretty much the equivalent of /home in Linux systems: the parent directory for user home directories, i.e. 'usr'. The existence of /usr/bin can probably be explained by the reasoning that, just like nowadays Linux systems often have a really big /home partition, early Unix systems eventually ran out of space for whatever volume…

Careful, you'll attract computing historians who will want to tell you that "usr" actually stands for "UNIX system resources"

Re: Debian still having trouble with merged /usr

#184

Post by athrun »

ngc248 wrote: post #49
mschuster91 wrote: post #8

Earlier quoted context omitted.

> 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. The problem is not in democracy itself as a concept. In both the open-source world and in society itself, the problems arise only when the demos (the population) either grow disinterested in democracy or is small in numbers. As for "tyr…

>> As for "tyranny of the minority" - I hope to never see that phrase again. Protections for minorities in democracies exist for a very good reason. I digress, but how are these protections an inherent feature of democracies. Even in a democracy (most democracies are representation democracies) people can vote for policies which may discriminate against people. This would be again democracy in action.

they are a feature of _liberal_ democracies.

In a liberal democracy, it is understood that the will of the majority is not the only thing that matters. For example, having the majority vote to strip a minority from their religious freedoms is not OK.

Re: Debian still having trouble with merged /usr

#186

Post by egberts1 »

WhyNotHugo wrote: post #157
egberts1 wrote: post #154

Earlier quoted context omitted.

This is just another direction to desktop-hive mentality with a focus toward minimizing security. Perhaps, it might be ideal and suitable to Windows-ize for your case; the security modeling of many designs, not so much.

How does this minimise security? I don't see how Window is relevant; it doesn't have /usr nor /usr/bin.

Precisely, Windows have centralized directories for system executables.

Re: Debian still having trouble with merged /usr

#187

Post by wil421 »

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…

Isn't that design by committee? A democracy would mean all the users would be able to vote on everything.

Re: Debian still having trouble with merged /usr

#188

Post by Beltalowda »

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. And it's "stuck" since then. This is why /usr has such a weird name, because it was intended for user files (/system, /software, /additional or something would make more sense, abbreviated to /sys, /sw, or /add of course). Initially Unix was a quickly developing system for internal use, but it was actually used and there was often some tension between "do the right thing" vs. "don't break too much". Some of the weird things in C are due to that as well (e.g. &'s precedence being a good example).

I guess some other systems that ran Unix ran in to similar problems, but by the time unix started to gain some adoption in the mid to late 70s disks were larger too, so I don't know if it was ever really needed beyond that initial research unix system used only internally at Bell Labs. I believe they updated the disks on the original Unix system not too long after this making this hack superfluous, but they kept it for compatibility (and because it might be useful again in the future).

Re: Debian still having trouble with merged /usr

#189

Post by Cockbrand »

ink_13 wrote: post #183
ntauthority wrote: post #108

Earlier quoted context omitted.

Adding to this historical reasoning, it is to be noted that in traditional Unix, /usr was pretty much the equivalent of /home in Linux systems: the parent directory for user home directories, i.e. 'usr'. The existence of /usr/bin can probably be explained by the reasoning that, just like nowadays Linux systems often have a really big /home partition, early Unix systems eventually ran out of space for whatever volume…

Careful, you'll attract computing historians who will want to tell you that "usr" actually stands for "UNIX system resources"

That's how I've learned it around 1995, and that the division between /[s]bin and /usr/[s]bin has the reason that the former are required for system boot, while the latter are mounted via NFS from a central server - why waste local disk space when these would be identical for every system anyway (in a homogenous environment, at least). While that made a lot of sense to me back then, I've become aware that it might not be absolutely accurate, though.

Re: Debian still having trouble with merged /usr

#190

Post by VancouverMan »

WhyNotHugo wrote: post #148
iso1210 wrote: post #52

> The /usr merge idea was first raised in "The Case for the /usr Merge" by Lennart Poettering in 2012. It came out of the systemd community Well that's a recipe for a long drawnout battle

Yeah, ideas and projects are often dismissed due to coming from the systemd group. For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.

Considering the massive amount of unnecessary and unjustifiable trouble that so many people have experienced over the years with systemd and PulseAudio, it's no wonder people would distrust everything coming from the developers and proponents responsible for such software.
Post reply on HN