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

211–220 of 310 posts

Re: Debian still having trouble with merged /usr

#211

Post by yjftsjthsd-h »

egberts1 wrote: post #127

We can now kiss-gone the security for embedded world and its IoT-related security brethren. It is often the directory separation of /bin and /usr/bin that is used to denote the extent of firmware’s scope between these binaries that are require for a boot up and what are they require to support their applications. (Thanks, PDP-11). Such wonderful boundaries of IoT upgrade scope can and is often denoted as two-stage up…

> We can now kiss-gone the security for embedded world and its IoT-related security brethren.

Is anyone using Debian for that kind of thing? When I hear embedded, I expect buildroot or at least Alpine Linux.

Re: Debian still having trouble with merged /usr

#212

Post by Karellen »

sph wrote: post #48
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 am of the opinion that BDFL style governance is best in software. In the real world the problem is a bit more hairy, but if you have an issue with a tyrant in open source, you can just fork the project. A BDFL solves the bureaucracy problem (they mandate, everybody implements) and the big ego problem (the biggest ego is at the top by definition). Also BDFL can have vision, something a committee will never have. In…

The trick with BDFL is, of course, lucking into a suitably B BD, and hanging onto them for as much L as possible.

And benevolence is not an attribute that can be passed to one's successor.

Torvalds and Jobs have done well, but are examples of survivorship bias. What about all the software projects helmed by autocratic douchebag dictators which never went anywhere because they were unable to attract enough contributors to feed the dictator's ego to the point where the community became self-sustaining?

Debian's been going longer than a lot of other software projects, and kept going after the initial founder(s) left the project. The process is messy, sure, but it sure seems sustainable so far.

Re: Debian still having trouble with merged /usr

#213

Post by FooBarBizBazz »

scandox wrote: post #74
mwcampbell wrote: post #45

Earlier quoted context omitted.

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

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…

> the human race will breed itself into some mad corner

Bit of a tangent, but I think sexual reproduction helps to avoid this. Picture a set of points (people) in Euclidean space. Pick any two, "a" and "b", at random. Add a new point "c" at the midpoint. Unless the overall shape of this swarm is highly nonconvex, then this point "c" is going to be more in the "interior". If we formalized things a little more, we could prove that this operation is a contraction. The Fixed Point Theorem would apply, &etc.

So, once your set has reached some convex shape, then there's a balance between these two forces: The contracting force of sexual reproduction, and the expanding force of random mutation.

There's also selection of course. I tacitly assume there isn't much more of that happening right now? I could be wrong though; there may be some (strong?) selection against education...

Interestingly, it's these educated who I assume would "benefit" from a eugenics regime. But, one bad meme, and the whole thing goes bad...

Re: Debian still having trouble with merged /usr

#214

Post by kibwen »

Karellen wrote: post #212
sph wrote: post #48

Earlier quoted context omitted.

I am of the opinion that BDFL style governance is best in software. In the real world the problem is a bit more hairy, but if you have an issue with a tyrant in open source, you can just fork the project. A BDFL solves the bureaucracy problem (they mandate, everybody implements) and the big ego problem (the biggest ego is at the top by definition). Also BDFL can have vision, something a committee will never have. In…

The trick with BDFL is, of course, lucking into a suitably B BD, and hanging onto them for as much L as possible. And benevolence is not an attribute that can be passed to one's successor. Torvalds and Jobs have done well, but are examples of survivorship bias. What about all the software projects helmed by autocratic douchebag dictators which never went anywhere because they were unable to attract enough contributor…

Precisely. Everyone adores a caring and benevolent dictator. The problem is that the sort of personality traits that inspire someone to pursue a position of power make it overwhelmingly likely that your dictator will be malevolent rather than benevolent. There's a reason that examples of effective BDFLs arise from cases where the dictator was in place before the project became popular.

The other problem is the continuity of leadership. Despite its flaws, one of the strengths of democracy is that the code paths for the transition of power are explicit and regularly exercised. The only reason that anybody has any faith in any potential replacement for Torvalds is that, presumably, Torvalds will hand-pick his inevitable successor. But the successor's inevitable successor will have none of the same legitimacy, and by that time (be it decades from now) I expect the project to transition away from a BDFL model out of necessity.

Re: Debian still having trouble with merged /usr

#215

Post by hyperdimension »

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…

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?

Re: Debian still having trouble with merged /usr

#216

Post by mmh0000 »

The Filesystem Hierarchy Standard[0][1] is used by most Linux distributions as the authoritative source and description of the various system directories. As other commentators have already noted, the hierarchy on UNIX system has always been a bit of a mess, the FHS is an attempt to clean up while maintaining backwards compatibility.

[0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#...

Re: Debian still having trouble with merged /usr

#217

Post by throw0101a »

Beltalowda wrote: post #195
WhyNotHugo wrote: post #148

Earlier quoted context omitted.

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.

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…

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

Re: Debian still having trouble with merged /usr

#218

Post by tych0 »

WhyNotHugo wrote: post #122
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 should also be noted that, while this change is Linux-specific, it does not directly break software which also targets BSD or nix-like OSs. Files that were previously in /usr/bin or in /bin can now be found in EITHER of these locations, since one symlinks the other. So no previous expectation was really broken. Only software built on merged systems fails to run on unðmerged systems. This should not really happen,…

> Files that were previously in /usr/bin or in /bin can now be found in EITHER of these locations, since one symlinks the other. So no previous expectation was really broken.

I don't know, I just hit breakage the other day. I have /usr/bin before /usr in my path (which is the default on Ubuntu at least); I have muscle memory to use dpkg -S `which $foo` to figure out which package a binary is, but that doesn't work if dpkg thinks the binary is in /bin (e.g. ping), since it'll ask dpkg who installed /usr/bin/ping, which is nobody.

It is small fiddly things like this all over people's packaging and personal scripts that break.

Re: Debian still having trouble with merged /usr

#219

Post by nyuszika7h »

drexlspivey wrote: post #150
jeffparsons wrote: post #120

Earlier quoted context omitted.

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…

Can you link to a few maintained packages that only support Python 2?

This one is relatively maintained, for example: https://github.com/pyroscope/pyrocore

Re: Debian still having trouble with merged /usr

#220

Post by comprev »

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 understood it to be 'secure binaries', locked away from regular users through security policies.
Post reply on HN