Debian still having trouble with merged /usr
lwn.net
lwn.net
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 because /usr/bin and /usr/sbin might not be mounted yet.
This no longer makes sense in the days of large disks which fit /usr just fine and initrds which can mount all the disks before kicking off the things which might need those binaries. In fact I think the initrd has taken the place of /bin and /sbin on a modern system containing copies of all the binaries needed to mount the disks (like mount and fsck).
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 would hold /bin, and with 'reinstalling' not remotely as easy an option as it would be these days, storing an extra 'bin' etc. directory in the 'larger partition for user directories' became commonplace.
Sun had a few interesting early views on networking.
You could ask Ken Thompson (/usr/ken) himself to verify. ;-)
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, since the usr merge was a one way trip, not a flag that you're supposed to turn on and off. You'd also never build dynamically linked binaries for BSD on Linux, so that should not be an issue.
But, for some reason, Debian chose to make this merge something that individual systems could turn on and off, which is a terrible idea for part of the base system. It's like letting users pick if they way `/bin` or `/binaries`. Having such heterogenous setups in regards to something so basic and foundational is asking for breakage.
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.
Who installed '/foo/bar/baz' when '/foo' is a symlink to '/usr/bin'?
I'm 100% in favor of the DPKG maintainer's perspective of "do ugly symlink farms" and then "reap what you sow" (ie: if you don't like there being a symlink there, then fix the offending package).
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)
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?
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).
Thus why the (per-machine, read-write) /var became standardized. Earlier /usr contained a mix of writable things (like /usr/log). Now it was important to make /usr something that could be NFS mounted read-only by a bunch of NFS clients.
There were also UNIXes that ran on multiple architectures, like SunOS on 68k and SPARC. In theory, you could have them both use the same read-only /usr/share mount and save some resources on the server.
I say "in theory" because I don't know how many sites ever implemented this in practice. There were definitely places that supported mixed-architecture diskless fleets, but I'm unsure how many of them were committed to keeping the OS version pinned between them... or how many then went through the extra work to make /usr/share a separate mountpoint. I'm sure some people did it, but it's not something I remember seeing personally.
Still, I feel it's somewhat useful to help humans understand what parts of a package are CPU-specific and which aren't. Probably good that it's lived on.
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.
Separate /bin and /sbin were so that Unix systems could start with a small, minimal, clean root disk that could be read only or effectively read only. The /usr partition was sometimes mounted separately, but this was more for proper organizational/systems design division than it was for disk space reasons.
This is still a useful division in many Unix systems today (e.g. IOT) where starting from a known-good minimal image and then layering filesystems on top can help reduce complexity and prune the debugging tree.
It's not surprising that the ibm/redhat/systemd/freedesktop crowd doesn't care about this stuff, but it's unfortunate.
http://lists.busybox.net/pipermail/busybox/2010-December/074...
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 explained to me in terms of disk space, more by comparison with the VMS system I was also managing which had 1MB drives. But I was too late to have "been there".
/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.
This does not align with my memory at all. /home came much later. Both AIX and SunOS/Solaris had it early, but not anywhere near as early as the / and /usr split.
But then the question becomes, why not get rid of /usr?
Also, you could mount / as read-only, and mount the writable parts at different points, or using a UnionFS mount of / .
Not technically, but I've built a number of "appliance" linux systems for clients, and to improve reliability I just make the entire disk read-only with the exception of /home and /var.
The few locations outside of /var that sometimes need to be writable (in particular, /media, /mnt, and sometimes /root) can simply be symlinked into /var.
To avoid breaking backward compatibility.
GP's idea, as I am now thinking about it it, is that you could basically move everything out of /usr into /, effectively getting rid of /usr.
Symlinking /usr to / seems like a dubious idea (since we'd get weird things like /usr/etc/passwd) but turning all of its top-level directories into symlinks seems like a possibly OK idea.
Looking at my ubuntu installation, /{bin,sbin, lib,lib32,libx32,lib64) are all links to /usr/{...}, which seems backwards to me. I think they should have hoisted everything into / and made /usr/* symlinks for backward compatibility.
macOS still has a traditional BSD style /bin (37 utilities) and /usr/bin (1000+).
(But why is /bin/sleep a 150K executable? maybe it's a fat binary in more ways than one?)
I just don't understand, if people want to merge /usr and /, why they insist on keeping the gratuitous /usr prefix. It can all just be rolled up into / : /bin, /sbin, /share, /lib, /include, /share, /src and so on.
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 support both, guess what, supporting both means having two problems now.
That is specifically not what happened, and the article is quite clear about it.
The Technical Committee voted unanimously for merged usr: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#178
The problem is that dpkg, an essential component of Debian, has specific issues with symlinks: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_...
So the issue is how merged usr is accomplished, not whether it is at all.
Please don't spread this kind of misinformation.
"Debian took a more incremental approach, in part because it strives not to make wholesale changes to users' systems like those required by a flag-day upgrade to a merged /usr. In 2016, the ability to voluntarily switch to that scheme was added, then some attempts were made for newer versions of the distribution to be installed with a merged /usr by default. [...] The location of some files was being resolved at build time to point into /usr/bin (for example), but those files only existed in /bin on the non-merged systems."
The fact that the committee took a decision that the core package manager can't support is baffling to me.
Why? Presumably the committee would be thereby deciding to drive development of the package manager toward whatever is required to support the high-level goal.
> deciding to drive development of the package manager
Which is the hilarious part: No one seems to be working on it. The package maintainer for dpkg isn't required to it as long as he accepts reasonable patches, but only half finished patches (that identify themselves as such) are coming in when the reported issues are not outright ignored. Seems liked Debian suffers from the same issue every open source projects suffers from: A bunch of lazy and entitled as fuck users insisting on features without putting any effort in themselves.
If I've learned one thing, it's that there's very little that software can't be made to do. Whether it should is an entirely valid question, and hopefully figured out before assessing the "could" aspect.
Who owns a file in a path that includes a 'well known symlink dir'?
So maintain a list of well known symlink dirs. When checking a file path against the database, the normalization step should check if the known symlink dir is any point of the path; if it is the redirect should be resolved to the well known target instead.
E.G. owns('/bin/bash') ... the path mutates to '/usr/bin/bash' because the location '/bin/' is already known to really be '/usr/bin/'.
I've been upgrading my Fedora systems between major versions with yum/dnf for as long as I can remember. It just works.
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 "tyranny of the minority" - I hope to never see that phrase again. Protections for minorities in democracies exist for a very good reason. In the case of projects such as Debian to reduce the chance of solo maintainers quitting over frustration about being overruled, in democracies to prevent atrocities and hold up human rights for vulnerable people (e.g. disabled).
There is plenty of evidence for the theory proposed by Taleb[0] on this one, he wrote:
"It suffices for an intransigent minority – a certain type of intransigent minorities – to reach a minutely small level, say three or four percent of the total population, for the entire population to have to submit to their preferences."
[0] The Most Intolerant Wins: The Dictatorship of the Small Minority https://medium.com/incerto/the-most-intolerant-wins-the-dict...
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.
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.
This is why attempts to impose democracy from outside tend to fail. Giving people the vote doesn't automatically lead to respect for their fellow citizens' civil liberties, which is much more fundamental.
I am pretty sure the use in the phrase you object to is of the latter form.
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 central problem is: how shall the "right way" in "both in the right way" even be defined?
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 most effective interface for most people. That assumption is so thoroughly baked into everything that I sometimes think it might have been better if, through some kind of eugenics, I and people like me (blind from birth) had never been born at all, so the world could go on with that assumption (as it mostly does anyway) without leaving us out. I know eugenics is a taboo idea though, and it has its own problems.
That means that without going the only-the-perfect-survive route, there are always going to be issues with how the world operates. For any given human problem, it's probably rare that it's optimized for even half the population.
Doesn't help you, being on the extreme of the eyesight problem, but the fact that we need to accommodate blind people also helps a bunch for people with vision issues and (commonly imperfect) correction.
So while you can consider yourself to be in the small percentage of completely blind people, you can also consider yourself to be in the majority of people with vision issues. Should we have avoided all of them in this world?
And that's wherein lies the issue with eugenics or any sort of artifical selection of our descendants: where is that line?
And just judging by this single comment, you are at least capable of eloquent, reasonable discussion, which is probably untrue for at least half the population.
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's also something to be said for accurately and clearly communicating the actual condition.
Second of all the human race does not have some over-arching goals we need to meet like a business. It is or should be like a club run for the benefit of the members: let's create good conditions for people. We can tolerate a bit of complexity and diversity.
Individuals and groups (including businesses) do have goals though, and it seems natural that some of them feel that they're being thwarted in their pursuit of those goals by expectations that they accommodate every little minority (including the one to which I belong). The backlash against legislation requiring accessibility, for example, is real, as seen in this thread: https://news.ycombinator.com/item?id=30726471
If we're no longer taking even the slightest bit of care towards looking after our fellow Man then it's not a world worth living to me.
EDIT: It's also not just a "tiny minority", about 13% of the world's population have serious vision impairment. Making streets, businesses, services, products accessible is the very least we can do. It's scary that someone who suffers from this himself would chalk it off as inefficiency and waste.
It's somehow similar to the way so many of us expect actually evil people to somehow come with horns or other evil-indicating visual accessories. The reality is that evil people wear suits, and jeans, and shorts and hats and look just like the non-evil people.
So it is with "reasonable". The fact that someone can phrase their objections to accessibility that doesn't make them immediately sound like a prejudiced ignorant lunatic doesn't actually mean that they are not a prejudiced ignorant lunatic (it doesn't mean that they are either, but you should remain suspicious).
For myself, I had a revelation about such matters when my daughter had major hip surgery (twice). While normally a fully mobile and athletic person, she had to spend several weeks (twice) with a wheelchair. Suddenly it became clear that the accomodations we have made in this direction are not just for people born with disabilities that prevent them from walking: any one of us could find ourselves, either temporarily or permanently, benefitting from ramps and door openers and curb cuts etc.
I am absolutely certain that the same is also true of accomodations made in the direction of visual impairment, hearing impairment and just about any other condition that deviates from some (often hypothetical) state of "full functionality".
Please, protect yourself from the backlash from these "seemingly reasonable" people. They are ignorant, selfish and of limited scope in their thinking. You deserve better.
Between spending several months on crutches ten-ish years ago and helping care for several elderly relatives, I'm a believer.
Then we should start with the assumption that they're not, right? I'm guessing that starting out by assuming the worst in others is one thing that contributes to the current polarization in US politics.
> Please, protect yourself from the backlash from these "seemingly reasonable" people.
What specifically do you advise that I do here? I don't want to just ignore challenges to the idea that accessibility should be a requirement. If I pay attention to these people and put in the effort to understand why they think as they do, then I can become a more effective advocate, or possibly even revise my position. Yes, the latter may lead me to question whether I should even exist, but it seems to me that a healthy mind should be able to dispassionately contemplate hypotheticals that even threaten oneself.
However, while we definitely need more empathy, the world is also full of stupidity, and there's a point in everything where you need to be able to stop putting your energy into fighting the stupid. There's a point where you have to say "no, wait, these people are not actually arguing in good faith, i've explained to them over and over again why they are wrong, why the evidence of the last N years shows them to be wrong, and they have no answer to this, and just keep repeating the same falsehoods. I'm done".
Now, if you're not at that point with the people you engage with about this, great, keep aiming for empathy and understanding. But if you are, move on.
There's a company I collaborated with once who had an epiphany when they realized they had been putting way too much energy into trying to prevent people ripping off their software. They changed direction and focused on ignoring the people who did that, and instead tried to provide the best possible customer service and support they could to people who had paid them. Things got better for everyone. I think there's a general lesson here about where best to direct one's energies.
Eugenics does not automatically mean we all customize our embryos to be 2m tall geniuses with patterned body hair.
More of an aside, but I’ve always wondered where humans would end up if we did do unbridled genetic engineering. Is 2m the ideal height? 1.80m? 2.40m? What would we discover is the optimal IQ? Etc.
Your parents might have conceived again, and had another child who did pass, to whom they gave the same name. But that child wouldn't be you.
I think Brave New World treats this question pretty well. We'd probably discover that there is no 'optimal' height or IQ and we'd still need the whole span of "Big Dumb Brutes" to hyper-geniuses. The secret is convince everybody the IQ/physique they've been assigned is the 'actual' optimal and they're the lucky ones that everybody else should envy.
I'm just under 2m and I can assure you: it is not.
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...
You need to realize we are currently implementing eugenics, we just don't know what our goals are.
There's two types of eugenics, positive and negative, based on the root of postulate. A positive eugenics program selects *for* specific qualities like hair color. Negative eugenics selects *against* deleterious phenotypes.
You still need to exercise caution. For example, selecting against depression may be long term bad because the real thing we need to do is reform society to reduce depression. But there are some things, like being born with a disability, that have obvious impact outside of a functioning society that it seems reasonable to select against them.
W.r.t. the parent comment to yours, I'm conflicted; I've spoken to people and seen how many issues they have getting accomodation. If people were forced to care, making interfaces for blind people would be pretty easy. But many people refuse to care.
The idea of genetic drift due to lack of selective pressure has been studied (recently, and in a way not connected to racism) and was pretty grim. Unfortunately due to the connotations eugenics typically carries it has remained poorly investigated.
I am blessed that I have all my senses and so do my children, but I absolutely believe that the 9999 other traits that you have to share should not be lost just because of a single non-optimal trait.
To be clear, that's a fictional character in a fictional future that may or may not ever come. Sure, we can use assistive technology, e.g. screen readers, to enable us to work. But with our current technology, that requires cooperation from developers of platforms, applications, websites, etc., and as I said in another comment, advocating for that sometimes seems futile. We do sometimes make progress though.
> I absolutely believe that the 9999 other traits that you have to share should not be lost just because of a single non-optimal trait.
Of course you're right; thanks for that reminder.
> I figure the future will be primarily whatever the wealthy minority wants.
It seems very odd to propose that the solution to a problem is to liquidate all people who suffer from that problem.
Are there any operating systems written from or computers built from a blind perspective, or are the blind just using the accessibility features of sighted operating systems?
Yes, but they struggle to keep up with the mainstream, especially considering the runaway complexity of the web. The one notable open-source example is Emacspeak [1]. The rest, as far as I know, have been proprietary and often overpriced products.
Just want to encourage you to keep pointing to accessibility problems loud and clear. While CSS complexity was mostly driven by ads, ecommerce, and porn, there are people who tried hard to do the right thing on the web (Paciello Group, W3C's WCAG, etc.), thereby also contributing to unwarranted complexity, who could benefit from feedback. And I don't have to tell you, but if you think you're not affected because you're young, sight/focussing problems kick in at about the age of 50.
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 my humble opinion, people like Torvalds and Jobs are the secret to wildly successful software.
"Deadwood and apathy in the 20-member core team lead to creating bylaws that set up a 9-member elected core team First elected core team in 2000 with few carryovers from old core team" [1]
It should also be an odd number if they vote, so that there won't be a tie in votes. The same approach is used in kendo and other Japanese martial arts examinations, the number of examinators is always an odd number.
This also solves the "what if the BDFL is hit by a bus" problem: another member is appointed.
1. https://papers.freebsd.org/2018/bsdcan/mckusick-The_Evolutio...
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.
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.
https://www.debian.org/devel/leader https://www.debian.org/vote/2022/vote_002 https://www.debian.org/devel/constitution#item-5 https://wiki.debian.org/Teams/DPL
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've had a lot less trouble with merged /usr. I guess it's not a fair comparison, but it does suggest to me that there are more important factors at play.
It sounds like the package authors sticking with Python 2 that you're dealing with are just stubborn beyond belief. The rest of the world has moved on whether they agreed with the changes in Python 3 or not. Hopefully if the packages are useful enough to others and the licence allows it, people will fork them and make them work with 3.
I believe grand majority of packages already dropped 2.7 from latest releases, given that it's officially dead for over two years.
Monarchies seem to work well in cases where "the top" has interests that align with the interests of the subjects, and is well-informed. Jordan seems to be a great example. Yet history is full of examples of long-standing monarchy-type organizations where after only a short time of disconnect between the governing and the governed, the entire system fails. A Frenchman could probably provide good examples.
Did you invent this? Because it's freaking brilliant!
I'd argue you are overstretching one example of one broken system to a whole class of systems. We can reframe these big egos as people who do not believe in democracy, but great believers in feudalism. (Though I do not know all the details what is going on in Debian, may be I misunderstand the affair, and I don't want to mark some specific people as anti-democrats, but I don't know how to aviod it, sorry).
We see how individual developers say "get off my lawn". The social dynamics of a collective decision making doesn't mean for them a thing. Any democracy needs a legitimate way to reach consensus. And everyone needs to conform to a consensus. Legitimacy of procedures must be enough for everyone to believe in the consensus or at least to believe in their obligation to conform. And the more power someone have, the more his obligations to conform are.
I mean, if I'm a regular voter without any special powers to resist consensus, then I cannot brake the consensus, I cannot stop system from working without resorting to really destructive and antisocial behavior. But if I was a president, I would have power, I could resist. But if I did then it would be not a democracy but an autocracy. If I was something in between a voter and a president, then the situation would be something in between, though probably the president may interfere with my plans, use their powers to stop me ruining the system.
In Debian it seems every developer maintaining something important enough have powers to resist any consensus reached. And moreover there are some who actually use their power to resist. And the system as a whole doesn't treat such behavior as them undermining the system and may be undermining the very idea of democracy. I'd say that Debian is playing democracy but didn't invested enough into building a mythology of a democracy, into making people believe in a divine right of democratic procedures to rule them all.
Though from other hand, it may be not a bug, but a feature of a system, because it pays to people by handling them some power, I believe it helps them to not burn out too fast. It charges the community with struggles and a constant fight, it provokes people-centered procedures, not rule-centered.
just because people care about the technology...
and upgrading is important for small business with less money. and this shows how hard it is to achive an good upgrade path.
$ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?<=(?=x^|(?&b))[\s\S])))\/bin\/(?!(sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat))" /usr/bin
(I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier)
[1] http://www.drregex.com/2019/02/variable-length-lookbehinds-a...
Alternatively, a simple
grep --binary-files=text -rP '(?<!/usr)/bin/(?!sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat)' /usr/bin
Also, I don't see how a folder filled with symlinks would prevent the problem that are you talking.
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
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
As far as I can see, both methods allow insufficiently careful developers to hardcode the wrong paths. What am I missing?
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.
I long for a day where PATH=/bin is all we need.
Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks.
No more wondering where the various tools live since everything lives in /usr/bin and more.
The original point of a non-merged /bin was that /usr/bin was a spillover from when they ran out of space on the primary drive back in the 70s, so there was a slapdash split where the stuff necessary for bringup was kept in /bin and the rest would be kicked down to /usr/bin, in a very inconsistent manner depending on the system’s evolution.
In fact that’s also why users were moved from /usr (the original location, hence the name) to /home: /usr ran out of space, so they added a third disk and moved the user directories over there.
> Keep in mind that the approach of booting from initrd is quite non-idiomatic
How can you claim that it’s non-idiomatic when it’s the standard approach?
https://lwn.net/Articles/890306/
> First, technical challenges: HURD tried to move from /usr to / and had quite a bit more trouble with it, and that trouble warned against trying it on a larger scale. It's much easier to move from / to /usr than from /usr to / ; fewer things break.
> Second, consolidation: moving into /usr gives us a single directory containing all files managed by the distro / package manager. This has quite a few advantages. It makes sharing /usr among several chroots or containers feasible (one /usr, different /etc and /var). It makes versioning and A/B upgrades (upgrade to new image, fall back to old image if new image doesn't boot) simpler and easier. It makes it easy to lock down /usr with something like fs-verity.
Some folks also do something similar using LVM, BTRFS or ZFS snapshots on various distros.
Many users prefer the flexibility of package managers to appliance installs though, so having both types of installs is still a good idea.
That is explained in the “Case for the usr merge” essay: having all the readonly system stuff under a single root directory makes the system much easier to manage, and simplifies useful scenarios like having the system on a network share, or sharing the host’s read-only across guests: with a merged usr, you just have to manage a single mount point or directory rather than half a dozen which must be kept in sync.
Also /usr is not just /usr/bin. Sbin, and lib (and lib64, and lib32) are also part of the usr merge.
There will always be sets of tools managed by the distro or my org or my team or me, and it’s pretty important to segregate them to avoid and resolve conflicts, so I expect at least four entries in $PATH for the foreseeable future. Plus whatever messes vendors care to dump somewhere in /opt.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
> On Fedora the root directory contains ~450MB already. This hasn't been minimal since a long time[…]
> There is no way to reliably bring up a modern system with an empty /usr.
These seem like workarounds for self-inflicted Fedora problems. Having a known-good /bin from boot time seems strictly better than an extra copy of some of /bin in a ramdisk that almost nobody works with because it’s quickly thrown away.
I always thought the reason was to categorize binaries which seemed like a valid reason
> the dpkg maintainer it's being a jerk.
He is required to accept working patches, priority by the committee seems to be the removal of warnings about the broken support instead of actually fixing it.
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 an unreasonable concern, and no one likes to work on patches that will never get merged.
I don't know what the path forward for Debian would be here. Things seem ... difficult. Getting some of the social tension solved and having people "kiss and make up" would probably be a good start, but that can only work if people are willing.
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 perceive as "moving goalposts" and "excuses".
Bocassi is also the guy who claimed the first incomplete patch was rejected without further comment, which going by the article wasn't the case. So his opinion of the maintainer is at best misinformed, at worst intentionally deceptive.
Also going by the article a merge can be forced by the committee. So this seems to be a non issue.
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.
I feel like most of the objections & problems relate to the transitory phase, to having to support both, to trying to install old packages. I was thinking Bookworm was committed to a merged usr, but sounds like the next release after, Trixie, will be the first pure usr-merged, when everyone should be on the new thing.
For all the dpkg maintainer's griping, it sure doesnt seem like there are viable alternative implementations available to aliased directories.
Well that's a recipe for a long drawnout battle
I've always struggled with figuring out where stuff lives on the file system in different linux and unix derivatives. It's never where you expect/want it to be. I've used solaris, hp ux, mac os, and linux over the years. They all have similarly named directories, mostly for weird historic reasons. Is it /var/usr/god/knows/what or in /opt/foo/bar or in /usr/var/lib or /usr/share/lib. What about /etc, /usr/etc, /usr/local/etc?
You can take almost any 1,2,3, and 4 symbol permutations of share, lib, var, bin, opt, and sbin and probably find something that expects files to exist under that path. Reducing the number of permutations would probably be helpful.
People seem to just roll the dice and create some place where shit lives based on mostly just vague intentions, rules, heuristics, and interpretations of those associated with long dead unix variants from the nineteen eighties, weird naming conventions, and what not.
So, what's the rule here? Some 'special' packages should install to /bin and some other not 'special' packages should install to /usr/bin? Why? Is there any agreement about what constitutes a 'special' package? Is there a good functional reason for having both directories? And then the whole bin/sbin distinction is kind of arbitrary as well. Some binaries are statically linked, others are not and require libraries to exist in yet more shared directories on a library path. It all boils down to users requiring a PATH variables (and, inevitably, a lot of other/similarly named variables). And of course the order of paths is also super relevant and kind of the point. So you look in /usr/bin before or after you look in /sbin? It's all a house of cards. Brittle by design and convention.
The notion of taking a package and then fragmenting it over a multitude of shared directories is the problem that needs fixing. The role of a package maintainer is bridging those different notions of where stuff should live between different distributions with some convoluted scripts. It's a job that should not need doing and code that should not need to be written.
The main differences between linux distributions boil down how none of them actually having solved this problem that ended up doing only loosely similar but clearly different things for mostly obscure reasons. They don't agree on where stuff should live, how it should be moved/copied/linked there, where and how things are configured, etc. Most of these differences are kind of arbitrary and petty. /sbin, /usr/bin, /usr/sbin, /bin, /usr/local/bin, etc. who cares? I pretty much need all of these in my path for things to work as intended. I don't see a good reason for more than 1 of these to exist.
Apple kind of got this half right with the notion of mounting a package rather than installing it. Most applications install/uninstall via drag & drop. I always thought that was a neat idea. Of course, they then made it complicated by having /User/<uid>/Library/* and /Library/* directories anyway. So, most applications leave a lot of clutter there after you drag them to the trash-can. And they also have the usual contingent of unixy directories. And package managers like brew, macports, fink, and whatnot that sort of carved out different places in the filesystem where their stuff lives. So, I wouldn't go as far as saying that Apple solved the problem. But it does look like progress to me.
Mounting stuff rather than fragmenting it all over the place is progress. Docker does this. And so do Flatpak and Snap. Flatpak and Snap are kind of tedious in their own way (e.g. opencl support is a PITA with Darktable and other packages that need that). But at least I have some stuff that I installed with those that actually works without having to be customized for every linux distribution.
I didn't read the rest of your long comment because this is incorrect.
/bin is a symlink to /usr/bin on arch. There are no files in a folder /bin. Any package that tries to install a file in /bin will throw an error that it conflicts with the filesystem package.
Arch goes one step further, there is no /sbin or /usr/sbin either. Both are also symlinks to /usr/bin
This was completed about a decade ago.
https://lists.archlinux.org/pipermail/arch-dev-public/2012-M...
https://archlinux.org/news/binaries-move-to-usrbin-requiring...
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.
That's really unfortunate naming then. Any systemd-foo that "works on it's own" is (rightly) assumed to be tightly coupled to the rest of the systemd ecosystem.
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". Well, maybe, but you broke my system and before it was perfectly fine, and that's kind of an issue for me. Especially with something as critical as booting my system, I want to be able to just rely on it without breakage "because I was using it wrong". Linus' "we don't break userland"-policy was a great piece of insight. I wish systemd had a similar attitude.
Some of the systemd criticism has gone off the rails (...and then some...), but there's a number of things one could reasonably criticize about the project and development style, IMHO.
The tight coupling of systemD is a popular criticism of it.
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 outputs, others. But these cross cutting concerns mostly get compiled in. The actual interdependencies between subsystems are few & far between. Feels like the critics dont really understand what they are trying to criticize.
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 config.
Systemd-boot (nee gummiboot).is such a huge breath of fresh air. Simple senisible plaintext entries that one cam modify in any old text editor, which have immediate effect. It's so pleasant & simple.
Alas debian doesnt seem to ship any hooks for updating systemd-boot with kernel updates. There's a shell-script to write/remove the entries but one has to go write their own hook & figure out the variables to marshal into the script's arguments. Please Debian!
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!
I had not heard of systemd-boot, I will check it out…
By creating a fork and proving that it works, the discussion becomes about whether to merge patches or adopt the fork rather than sterile "what if"s.
Edit: added last paragraph
Other than that:
* /Users == /home
* /Data == /var
* /Mount == /mnt (?)
so what do we get by breaking the world?
In the the gobo documentation^1 section called "But what about Unix compatibility?"
> The GoboLinux system layout seems to be a major departure from the Unix tradition. Does this mean all programs need to adjusted so that they work with the new layout? Fortunately, the answer is no. Through a mapping of traditional paths into their GoboLinux counterparts, we transparently retain compatibility with the Unix legacy.
~] ls -l /dev/null | cut -b 45- /dev/null
~] ls -l /bin/sh | cut -b 45- sh -> /Programs/Bash/4.4/bin/bash
~] ls -l /usr/include/stdio.h | cut -b 45- stdio.h -> /Programs/Glibc/2.24/include/stdio.h
> There is no rocket science to this: /bin is a link to /System/Index/bin. And as a matter of fact, so is /usr/bin. And /usr/sbin... all "binaries" directories map to the same place. Amusingly, this makes us even more compatible than some more standard-looking distributions. In GoboLinux, all standard paths work for all files, while other distros may struggle with incompatibilites such as scripts breaking when they refer to /usr/bin/foo when the file is actually in /usr/local/bin/foo.
> You may have noticed that the Unix paths did not show up in the system root listing in the very first example. They are actually there, but they are concealed from view using the GoboHide kernel extension. This is for aesthetic purposes only and purely optional, though: GoboLinux does not require modifications in the kernel or any other system components. But our users seem to like it a lot. :-)
So it doesn't break the world. The faq^2 also indicates this wasn't a change to make Linux more newbie friendly, but in my own words I think it does.
> The primary commercial Unix implementation is nowadays Oracle Solaris. [...] By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris.
I wonder what he means by "primary"? I'm reasonably sure than in 2012 OS X was used on more machines than Oracle Solaris.
They are primarily not concerned with your workstation.
I liked init systems of yore. I don't ask to toss out systems because its very useful in some settings, however, I prefer the init systems we had, when it comes to my personal workstation preferences.
Sadly that ship has sailed, but it's finally 10-12 years later that there are some niceties to systemd that make it worth it to me (systemd-resolved in particular).
So when I tell you the Debian community mainly cares about servers, I'm not bullshitting you and I know who the fuck Lennart is.
Solaris 10 did have some neat features not found in Linux then, not just ZFS, but containers etc.
By 2012 as the concept of things like AWS was gaining traction, I'm surprised that legacy systems like solaris was even a consideration, I'd be very surprised if solaris was chosen in any greenfield installation (rather than extensions to existing companies with a lot of solaris/oracle) in the last 15 years.
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...
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.
FreeBSD used to do this too, but got rid of it in FreeBSD 6 (I think? Maybe 7? About ten years ago).
Both systems install packages to /usr/local.
That's because "packages" in the BSD world (at least openbsd) are considered third-party options, the base system is considered static. Linux distributions don't really have the notion of a static base system with "package" addons, the distribution packages are the system.
As for merged /usr, recently using Arch Linux for desktop use. Which accomplishes this by symlinking, which is ugly. Arch certainly is not perfect. Not sure if this is the way.
What I don't get... yes, it may be possible to get a dpkg database into an inconsistent state. But why is everyone hoping on a patch that may or may not appear to prevent these bugs, instead of deriving a way to fix a system with an inconsistent dpkg database?
As for merged /usr, recently using Arch Linux for desktop use. Works decent enough to getting things done.
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 in it, the whole c:\windows\syswow64 b.s., c:\Program Files (x86) and c:\Program Files, the hierarchy in the Windows registry which has "Windows", "Windows NT", "Microsoft Windows" (probably), etc.
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/<magic directory name>.
/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.
/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.
Directories like var, opt, usr need some rethinking. Hence the UsrMerge I presume?
This is what the current filesystem looks like: """ lrwxrwxrwx 1 root root 7 Apr 6 15:21 bin -> usr/bin drwxr-xr-x 3 root root 4096 Apr 6 15:30 boot drwxr-xr-x 17 root root 3400 Apr 6 15:31 dev drwxr-xr-x 67 root root 4096 Apr 6 15:32 etc drwxr-xr-x 3 root root 4096 Apr 6 15:30 home lrwxrwxrwx 1 root root 31 Apr 6 15:24 initrd.img -> boot/initrd.img-5.10.0-13-amd64 lrwxrwxrwx 1 root root 31 Apr 6 15:24 initrd.img.old -> boot/initrd.img-5.10.0-13-amd64 lrwxrwxrwx 1 root root 7 Apr 6 15:21 lib -> usr/lib lrwxrwxrwx 1 root root 9 Apr 6 15:21 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 Apr 6 15:21 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 10 Apr 6 15:21 libx32 -> usr/libx32 drwx------ 2 root root 16384 Apr 6 15:20 lost+found drwxr-xr-x 3 root root 4096 Apr 6 15:21 media drwxr-xr-x 2 root root 4096 Apr 6 15:21 mnt drwxr-xr-x 2 root root 4096 Apr 6 15:21 opt dr-xr-xr-x 173 root root 0 Apr 6 15:31 proc drwx------ 2 root root 4096 Apr 6 15:32 root drwxr-xr-x 17 root root 520 Apr 6 15:34 run lrwxrwxrwx 1 root root 8 Apr 6 15:21 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Apr 6 15:21 srv dr-xr-xr-x 13 root root 0 Apr 6 15:31 sys drwxrwxrwt 9 root root 4096 Apr 6 15:32 tmp drwxr-xr-x 14 root root 4096 Apr 6 15:21 usr drwxr-xr-x 11 root root 4096 Apr 6 15:21 var lrwxrwxrwx 1 root root 28 Apr 6 15:24 vmlinuz -> boot/vmlinuz-5.10.0-13-amd64 lrwxrwxrwx 1 root root 28 Apr 6 15:24 vmlinuz.old -> boot/vmlinuz-5.10.0-13-amd64 """
What goes where. I have been a sysop for a long time. Came from a time that computers where simple by comparison to now. Limited in functionality, but just worked. Seen many changes. I the past there were less directories. Though time we added a couple. E.g. opt, srv, media. Or the dev, proc and sys. What happens when something new popup? Create a new directory? Possible. Maybe now is the time to consolidate and rethink certain directories? Better names? E.g. system instead of usr. Location where put libraries, maybe consolidate into one? Location for data (stores)? Etc.
Off cause current hierarchy isn't complicated. But it's not intuitive and can be confusing. Even the windows directories are better readable? I think naming must be more intuitive. Especially with regards to new or inexperienced user. Just an idea. Make unix accessible to everyone is a good goal.
Starts with readability in my opinion.
Oh, didn't mention software development. Which is an entire different ballgame with respect to device files, magic files etc. Ugly to boot. The mantra everything is a file is also not true.
It's just my opinion.
[0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#...
Looking forward ro some blog posts discussing how to support this use case; it's a good one. I think usr-merge is so much more managable though that it's totally worth doing.
You could even ship the initramfs and kernel using tftp.
Then the diskless systems just need enough storage for a bootloader like uboot or tianocore.
It's essentially like Macos's /Applications directory, except where Macos supports the traditional POSIX fhs via a hidden /private root directory, Gobolinux hides these directories with a filesystem kludge.
For backward compatibility there are symlinks (that takes no disk space) to the standard directories, but these are hidden by the kernel so they don't show up and clutter your file manager.
[1]: https://gobolinux.org/at_a_glance.html [2]: https://gobolinux.org/doc/articles/gobohide.html
> /bin is a link to /System/Index/bin. And as a matter of fact, so is /usr/bin. And /usr/sbin
So, they're doing exactly the same thing as Debian is doing on the default merged configuration ?
Issues seen on Debian are not the system using symlinks or not, but packages failing when exchanged between system that still had both /bin/ and /usr/bin as separate directories, as it was historically, and the new merged systems. Gobolinux being a from scratch built distro with no transition history, I am not sure how it can be seen as a better example here.
No.
* https://gobolinux.org/doc/articles/clueless.html
* https://gobolinux.org/at_a_glance.html
I'll just copy & paste from earlier posts I made on a gobolinux-related thread some time ago (can't be bothered to rewrite the same arguments in different words)
"Anyone who wants to try out gobolinux for real would at least do some basic reading first. Its that distinct a distro that you kind of have to, and no problems with that. Not everything innovative can be expected to be digested without a modicum of work up front.
...
Sometimes the simplest alternative implementations require the most up-front understanding, because their simplicity challenges long-held preconceptions about how things should be.
Thats Gobo in a nutshell.
At its heart, its actually a very simple distro. Which uses simple tools, and the filesystem, to lay everything bare in front of the user.
Funnily enough, Gobo is one of the few distros where you can refer to /bin/<any-linux-executable>, and as long as actually have that pkg installed (yes, under /Programs), then /bin/xyz WILL be found. Guaranteed.
Thats by design."
And:
"The kernel module that hides the standard dirs under / is entirely optional, and is only there for aesthetic purposes. If you don't want it, don't load it. Absolutely nothing in gobolinux requires that kernel module to be running. Again, its just purely for aesthetic purposes."
https://wiki.debian.org/DebianTesting#Best_practices_for_Tes...
A package manager should in my opinion leave daemon stopping/starting to the administrator, as they know their configuration better than any package manager ever can.
Also that behavior isn't unique to Debian at all.
These days we mostly deploy our stuff using containers anyway, and for my own personal machines I've just switched to Arch Linux since.
Stable is great for letting up a server and let it run on its own for years without any maintenance (HN warning: No maintenance is of course never a good idea, but at least Debian made it possible)
Testing ran in update conflicts at least once a month, but it was generally easy to resolve without bricking.
Unstable, well, the name says it all.
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 upgrade with /bin as read-only; now, not so much.
This is yet another case of IoT system engineering design getting steamrolled by the diminutive desktop-mindsets despite progress by its systemd author.
Try yanking that Ethernet cable from its physical socket and watch if your long-running deeply-stateful process can survive. (It won’t, unless you retrain it against KISS principle to ignore such netdev disappearance.)
For device-local binaries (e.g.: not part of firmware), /usr/local/bin sounds like the right choice (also, somewhat in line what some BSDs do).
Perhaps, it might be ideal and suitable to Windows-ize for your case; the security modeling of many designs, not so much.
I don't see how Window is relevant; it doesn't have /usr nor /usr/bin.
From the reliability perspective (protecting against accidental damage), the /usr merge makes it easier to set up A/B booting and protect the entire system, rather than blessing a small subset of the system and preventing anyone from upgrading those components at all in the future.
Is anyone using Debian for that kind of thing? When I hear embedded, I expect buildroot or at least Alpine Linux.