upofadown
a day ago
This part seems fairly editorial:
>Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade.
What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place.
>The specification was not so much finished as abandoned after FHS 3.0 was released...
OK.
>...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results.
So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard.
>Meanwhile, in the absence of a current standard, systemd has spun off its file-hierarchy documentation to the Linux Userspace API (UAPI) Group as a specification. LWN covered that development in August, related to Fedora's search for an FHS successor.
Ah. Systemd/Fedora want a standard that they can directly control without interference from others.
jzb
19 hours ago
Author here: It was abandoned. I linked to one of the former maintainers who said as much. The current effort is by a few people who asked the LF to take out over, and have (so far) done little after an initial flurry of activity. That, too, is covered in the other article I wrote about the FHS recently.
Prior to the group who started an update effort, it had not been touched in about a decade. That’s not slow-moving: that’s abandoned.
upofadown
18 hours ago
The FHS ultimately belongs to the users collectively, not those maintaining it. I am old enough to remember the horror that existed before the influence of the FHS. It exists in the fact that it is to some extent respected, not because there is a file somewhere that says it is the FHS standard. If you want changes, then sure, do the politics required to develop support for those changes. You can't just declare a new standard and then do whatever you want.
Developers have this thing where they will think of a standard as a specification. Instead it is a statement of political will. Saying that a standard is "abandoned" due to lack of "maintenance" seems like an example of thinking of a standard as the instantation of a specification; an actual program.
dijit
16 hours ago
I know it's not the same, but imagine thinking a law is not longer meant to be followed because it hasn't been updated in 10 years.
Arubis
16 hours ago
I agree--given your contraints of law and 10 years. But what about a law that hasn't been updated for 150 years? There's plenty of those that we regularly ignore.
What's the timeline for software?
bawolff
9 hours ago
> what about a law that hasn't been updated for 150 years? There's plenty of those that we regularly ignore.
There might be minor alterations to details, but the core laws are mostly older than that. Murder, theft, etc don't change that much.
Even the silly confusing ones have a long life. E.g. "Rule against perpetuities"
divegeek
16 hours ago
Much of the US/UK legal system is based on common-law rules that are several hundred years old. In some cases those old laws have been codified, in some cases not, but either way there's no need to drop them just because they're old. On the contrary, laws that have stood that long without needing to be changed have demonstrated that they are extraordinarily good ideas.
avianlyric
10 hours ago
I’m not sure point to the UK is a good example. There are plenty of weird and obscure laws that simply aren’t enforced or followed anymore. Everything from laws about handling salmon suspiciously, through to various right around who can drive sheep across Tower Bridge.
Those laws survive not because anyone considers them a good idea, but simply because the issues caused by ignoring them are substantially smaller than the effort involved in removing them.
We also have a bunch of laws that are still followed, but only in the most technical sense. Every “Parliament route” train schedule falls into that category. Train services that must be provided at least once a day, sometimes only once a week, which nobody actually uses, and in some cases only travel to stations with no practical public entrances. Those laws don’t survive because anyone things they’re a good idea, it’s just easier to run the train, than it is to get parliament time to abolish the law.
dijit
16 hours ago
There is no automatic, fixed timeframe after which a law simply stops being followed because it hasn't been updated or looked at; and remember, we're still applying the FHS, it's in active use even if it's not updated.
Laws remain in force until they are formally:
* Repealed (abolished) by the relevant legislative body (Parliament, Congress, etc.).
* Struck down by a court as unconstitutional or otherwise invalid.
A 150 year "delete" timer would genuinely undermine the foundation of the legal system. Lawyers, judges, and businesses rely on the continuity of core laws (e.g., contract, property, and tax law). If a 150-year-old property law suddenly lapsed, it could instantly void millions of land titles and commercial contracts...
crote
10 hours ago
> Laws remain in force until they are formally: * Struck down by a court as unconstitutional or otherwise invalid.
False. They are still in force - they have just become unenforceable. There's a crucial difference, as the US is currently finding out: as long as they are in the books, a Supreme Court decision can instantly render them enforceable again - even against the wishes of the population.
The proper thing to do would be to "garbage collect" unenforceable laws, but politicians are (understandably) hesitant to spend political capital on it when it doesn't provide any tangible return.
MrJohz
12 hours ago
There are other reasons as well. The body responsible for enforcing a particular law can choose not to enforce it, thereby rendering the law useless. Or a law can become obsolete by changes in technology or society - the original law legislates something that just doesn't happen any more, say. Laws can also be written to handle a specific event that only occurs once. Once that event has passed, the law might as well not exist. It doesn't need to be repealed because it just doesn't apply any more.
In addition, laws are typically regularly amended to handle new societal developments, to clarify wording, or to fit better with other laws or changes in attitudes. A law that has gone 150 years without being amended at all is probably a law that falls into the categories above and is obsolete.
Of course, all this is getting somewhat off-topic, but the point is that laws absolutely can become outdated and unmaintained, either deliberately or by happenstance. And the inverse is also true: most laws that people deal with regularly are kept up-to-date to ensure that they still reflect the needs and wills of the society they're being used in.
lenerdenator
15 hours ago
There are plenty of 150-year-old laws that we don't ignore, too.
ikiris
15 hours ago
How often does "thou shall not kill" need an update?
knowitnone3
14 hours ago
Not even in defense of your own life, family, others? You have a lot of people on HN that celebrate killing of then innocent.
wakawaka28
14 hours ago
Obviously the intent was "Thou shall not murder anyone"... Interpreting it otherwise doesn't make sense, and is inconsistent with the rest of the Bible.
crote
10 hours ago
The definition of "murder" is "unlawful killing", so you've reduced it to "unlawful killing is against the law" - which is meaningless.
wakawaka28
10 hours ago
That's the wrong way to look at it. The Bible does not refer to other laws as a source of authority. Saying murder is "just" illegal killing is the real meaningless statement. Clearly people in the Bible are allowed to fight and defend themselves. Murder is typically intentional and unnecessary killing of someone else for malicious reasons (or no reason at all). Malicious reasons would typically be spite, greed, or convenience.
crote
9 hours ago
> The Bible does not refer to other laws as a source of authority
The Bible is the source of law here. My point was that interpreting it solely in the way you deem "obvious" does not work: you cannot have "thou shalt not murder" on its own without additional rules clarifying what counts as "murder" and what counts as "lawful killing" - and the Bible contains plenty of those.
> Murder is typically intentional and unnecessary killing of someone else for malicious reasons (or no reason at all). Malicious reasons would typically be spite, greed, or convenience.
That's how you interpret it. Modern law allows for killing out of greed - if the soldier firing the bullet is different from the politician wanting to capture some resources. We allow countries to kill out of spite with retaliatory strikes. We allow cops to kill in self-defense - even when other methods to subdue are theoretically available, but inconvenient. On the other hand, we no longer allow stoning to death people violating the Sabbath.
Clearly, there is a nontrivial list of criteria separating murder from lawful killing, and this list is mutable. In practice this list is codified in the law, which means murder becomes "killing which is not otherwise allowed in the law", which is the point I was trying to make.
Looping back to the original discussion: contrary to what ikiris was originally claiming it is not "thou shalt not kill" but "thou shalt not murder", and we've been updating the definition of "murder" (and by extent the meaning of "thou shalt not murder") quite a lot over the last few thousand years, so it is false to claim that " 'thou shalt not kill' never needs an update ".
wakawaka28
6 hours ago
>The Bible is the source of law here. My point was that interpreting it solely in the way you deem "obvious" does not work: you cannot have "thou shalt not murder" on its own without additional rules clarifying what counts as "murder" and what counts as "lawful killing" - and the Bible contains plenty of those.
It is obvious to people who know the Bible lol. It may have lots of contradictions but this isn't one of them. Murder was understood in a particular way to these ancient people, that still applies to us today.
>That's how you interpret it. Modern law allows for killing out of greed - if the soldier firing the bullet is different from the politician wanting to capture some resources.
As I said, I am not referring to laws of any country. The laws of modern countries are irrelevant to interpretation of the Bible. The dictionary does not count either.
>Looping back to the original discussion: contrary to what ikiris was originally claiming it is not "thou shalt not kill" but "thou shalt not murder", and we've been updating the definition of "murder" (and by extent the meaning of "thou shalt not murder") quite a lot over the last few thousand years, so it is false to claim that " 'thou shalt not kill' never needs an update ".
The only thing that needs an update is the translation. The meaning is very clear and universal. Don't kill people except in self-defense. It is just as antisocial today as it was thousands of years ago.
hobs
9 hours ago
Or when God tells you to.
"Now go, attack the Amalekites and totally destroy[a] all that belongs to them. Do not spare them; put to death men and women, children and infants, cattle and sheep, camels and donkeys.’”
"and when the Lord your God has delivered them over to you and you have defeated them, then you must destroy them totally.[a] Make no treaty with them, and show them no mercy."
etc
wakawaka28
6 hours ago
Lol yes... I've heard some alternative explanations of this. The Ten Commandments are not recognized outside of Christianity. They are just some important general sounding rules in a book that is full of rules for Jews, who get into battles with other people at times. Many of those rules in the same book have prescribed punishments of stoning to death, as well. So clearly, killing is at least allowed for purposes of punishment and warfare. Common sense also tells us that no religion can realistically prohibit self-defense.
sterlind
6 hours ago
jesus. what did the Amalekites do?
michaelmrose
5 hours ago
Without looking it up classic reasons are almost always thin veils over they have things that could enrich us.
wakawaka28
4 hours ago
Not really: 1 Samuel 15 starts like this:
"Samuel said to Saul, “I am the one the Lord sent to anoint you king over his people Israel; so listen now to the message from the Lord. 2 This is what the Lord Almighty says: ‘I will punish the Amalekites for what they did to Israel when they waylaid them as they came up from Egypt. 3 Now go, attack the Amalekites and totally destroy[a] all that belongs to them. Do not spare them; put to death men and women, children and infants, cattle and sheep, camels and donkeys.’”"
Later on it says that he was not happy with the outcome because they didn't kill all the livestock and people... Of course this is a work of mythology, but the message clearly isn't that the Israelites should go and loot from these people.
immibis
13 hours ago
"Obviously the intent was" probably not the same as it obviously was 150 years ago!
wakawaka28
12 hours ago
It's still obvious, but in context. It isn't a recipe or street sign lol...
Retric
15 hours ago
The US constitution is still in force after 236 years, and even older laws are still enforced. US courts will sometimes look at precedent from England before the colonies existed.
Meanwhile some laws that are months old are ignored by law enforcement because nothing forces them to read it. It’s that effect which is why so many old laws are ignored rather than formally repealed. When nobody is ridding a horse nobody cares how you need to tie one up when visiting a store etc.
jkaplowitz
15 hours ago
> The US constitution is still in force after 236 years
True, but it's been updated a lot more recently than that.
The last update was still much longer ago than 10 years, of course. The most recently ratified amendment to the Constitution - the Twenty-Seventh Amendment, ratified 1992 - was, incredibly enough, proposed in 1789 along with the ten we know as the Bill of Rights and another one which was never ratified. And of the twenty-seven amendments ratified so far, the one most recently proposed by Congress, the Twenty-Sixth Amendment, was both proposed and ratified in 1971.
Retric
14 hours ago
Are you suggesting that appending the constitution in 1992 with: No law, varying the compensation for the services of the Senators and Representatives, shall take effect, until an election of Representatives shall have intervened.
Somehow has an impact on anything else? Because by that standard every change to any law updates all existing laws that were not changed. Or I’m just completely misunderstanding your point here.
jkaplowitz
8 hours ago
My point is that merely referencing the centuries-old original age of a document is misleading when it’s been updated dozens of times ending just a few decades ago. (And many of the updates, including the one in 1971, have been far more impactful than the Twenty-Seventh Amendment which you quoted.)
It’s certainly true that the constitution is old and crusty overall and desperately needs an overhaul, but the discussion was about when old laws which haven’t been updated in a while are ignored or enforced.
The constitution is indeed one law, not several different laws, and it’s been updated far more recently than its original year of promulgation or ratification. And it’s still mostly enforced (with increasing exceptions but that’s another discussion entirely).
Retric
6 hours ago
> been updated dozens of times
18 times. 27 total amendments with 1-10 all passing on December 15, 1791.
> a few decades ago
There hasn’t been a meaningful change in over 54 years.
> The constitution is indeed one law, not several different laws
Those recent amendments are a minimum different laws. If you want to call it one law then there’s either 2 federal laws in the US. One needs to be ratified by the states and the others don’t.
jkaplowitz
5 hours ago
> No 18 times. 27 total amendments with 1-10 all passing on December 15, 1791.
Fair correction.
> Those recent amendments are a minimum different laws.
Only in the sense that any new enactment is a new law, but in that sense no law can be updated in a way that preserves its identity as the same law. Which is not useful for the discussion of whether an old law has or hasn’t been updated, since by that definition updates to any law are impossible.
Lawyers and judges don’t exclusively use that sense any more than programmers view a software patch as changing the basic identity (beyond something like a version number) of the patched software program.
They do use that sense when they are referring to individual enactments by Congress, just like programmers refer to patches and patch releases as well as to the things which exist across many patch( release)s over time. Which sense is useful depends on context, and which sense is meant depends on a mixture of context and exact phrasing.
> If you want to call it one law then there’s either 2 federal laws in the US.
There are far more than 2 federal laws in the US, but far fewer than one per enactment except when using the sense of “a federal law” that specifically refers to each enactment.
For example, most federal tax legislation explicitly amends the Internal Revenue Code of 1986, which is still the official name of our federal tax code. Similarly, most immigration legislation amends the Immigration and Nationality Act of 1954 (I could have the year wrong), even more than 70 years later. The many “patch” laws enacted in the meantime all have their own identities via Public Law numbers and often a name, but they do update a specific identifiable underlying law without replacing it.
Other federal laws, like most annual appropriation and authorization bills, stand alone and are not routinely updated but have a finite duration of relevance. Common provisions are often carried forward from one iteration to the next, but they are re-enacted as part of each separate iteration.
And then there are the many parts of the federal legal landscape where the US Code is the official authoritative version instead of a mere convenience version as it is for things like the tax code and immigration law. Amendments to the directly authoritative parts of the US Code explicitly amend the US Code instead of a separately named law, so those directly authoritative parts of the US Code are themselves (whether each or collectively) a single federal law in the sense I’m discussing.
Yes, this stuff is complicated and messy in both the law and the software worlds.
> One needs to be ratified by the states and the others don’t.
Yes, constitutional amendments are laws (in one sense) that amend a law (in the other sense) and which states need to ratify, and regular Acts of Congress are laws (in the first sense) that may or may not amend one or more pre-existing laws (in the second sense) and which states do not need to ratify.
Retric
4 hours ago
> Yes, constitutional amendments are laws (in one sense) that amend a law (in the other sense) and which states need to ratify, and regular Acts of Congress are laws (in the first sense) that may or may not amend one or more pre-existing laws (in the second sense) and which states do not need to ratify.
Yea, obviously we agree with what’s going on this is just a question of arbitrary definitions that don’t impact anything.
> Which is not useful for the discussion of whether an old law has or hasn’t been updated, since by that definition updates to any law are impossible.
It’s definitely easier work with the law based on the provided organizational structures with tax code being separate from family law etc. Yay, congress is doing something reasonably efficiently.
However, timing matters as making something illegal ex post facto is explicitly banned by the constitution etc. Further, in case of conflict newer laws win even without explicitly declaring the old laws invalid. So each bill is a meaningfully different law, and there’s in effect one law at any given moment after resolving those conflicts.
Net result three mutually contradictory but still useful definitions. But IMO organizational structure is by far the least meaningful one from a legal standpoint while being the most useful one from a practical standpoint.
znpy
12 hours ago
yup, but no standard is a law.
law on its own can mandate the use of a specific standard, but a standard on its own is no law.
so much so that often doing non-standard stuff is the most successful route. dumb example: Apple and all of it proprietary, non standard stuff.
crote
10 hours ago
> The FHS ultimately belongs to the users collectively, not those maintaining it.
I completely agree that regular updates are not a requirement for standards to remain relevant, but it does require the ecosystem to still adhere to them - and the problem is that Linux users are increasingly deviating from the FHS.
The FHS does not accurately describe the situation on-the-ground, there are no plans to update the FHS to accurately describe the situation on-the-ground, and there are no plans to update the ecosystem to accurately implement the FHS.
Like it or not: the FHS is dead, and nobody seems interested in reviving it.
bigstrat2003
9 hours ago
I still don't think you adequately explained why that would matter. To reiterate the question OP asked: what updates does it need that it hasn't been getting? It isn't as if one would expect a "put X stuff in y location" document to need maintenance.
jzb
6 hours ago
The FHS 3.0 doesn’t reflect current practices, such as the /usr merge, nor the /sys directory. There’s other ways it’s either no longer followed or missing developments from the last 10 years.
Hendrikto
a day ago
Counterpoint: Modern distro’s needs have evolved past the FHS in some cases, and everybody deviates from it slightly but incompatibly.
A standard does no good if it does not reflect reality. I think it is a worthwhile effort to try to bring it back in line with actual real world usage.
cwillu
10 hours ago
An interesting take in the context of systemd's deviation from it being the source of bugs because of real world usage that conflicts with systemd's changes.
sterlind
6 hours ago
laughs in NixOS
it's remarkable to me that NixOS manages to run so well despite breaking the FHS so thoroughly. and not just in superficial ways like not calling it /bin, I mean forsaking dynamic linking (hence /var/lib and /usr/lib), keeping man pages, resources and config bundled into the same derivation as the binary sometimes, and occasionally hacking up binary blobs to rewrite rpaths.
on the other hand, there's a place for legacy distros too.
palmotea
18 hours ago
>> Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade.
> What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place.
It's 2025, anything that wants to be considered modern (and everything should want that), needs to be undergoing constant change and delivering regular "improvements."
>>...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results.
> So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard.
The FHS people to get off their butts. There's no excuse for that pace now that we have such well-developed AI assistants. They should be pushing quarterly updates at a minimum, and a breaking change at least every year or two. It's been obvious for decades that "etc" is in urgent need of renaming to "config", "home" to "user", and "usr" to "Program Files" to keep up with modern UX trends.
cweagans
17 hours ago
I genuinely can't tell if this is satire.
palmotea
17 hours ago
I thought it would have been obvious by the "Program Files" at the end :).
Anyway, Linux community as a whole has an antiquated development process, and needs to modernize and follow the best practices of an industry-leading trend-setter, like MS Teams.
microtherion
3 hours ago
Surely Linux should be developed Google style, with a Web Scale perspective. uucp, tar, yacc, roff removed (with a 30 day notice, of course!), all the uses of "creat" amended to add the final "e", etc.
And systemd already follows Microsoft best practices, such as "Fire and Motion" https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
hulitu
16 hours ago
The X11 people are trying this hard. I'm really curious how Wayland will evolve but, the history of GTK and QT does not give me much hope.
scrps
12 hours ago
Wait you were kidding? I've already spun up a kubes cluster so we can feed FHS in a globally load-balanced CI/CD pipeline, I have an agentic LLM doing constant improvements so we can sprint to you never knowing where your files are!
It's like ASLR for files but no maps because maps aren't for trailblazers, they make the maps! It's very cutting edge and a value-add!
(Obligatory /s)
prerok
15 hours ago
Ok, so it's only half satire, or is this reply also a satire? I mean, MS Teams, really?
pinkmuffinere
3 hours ago
(Yes, the reply was also satire)
rascul
21 hours ago
The /usr merge is an example of something that a modern FHS might reflect.
curt15
21 hours ago
OS X doesn't have a merged /usr. On my Mac I see /bin as a separate directory, not a symlink into `/usr`. Does Linux have a compelling reason that OS X lacks?
mariusor
20 hours ago
The reason for having a separate /usr has long slid into obsolescence. Our storage is no longer constrained to require us to mount a remote partition which holds most of the binaries and other sundry required to boot a distribution.
syncsynchalt
11 hours ago
I'm assuming you're referring to partitioning of boot-critical binaries into `/bin`, but "the reason for having a separate /usr" is even older and worse than that. In original Unix `/usr` was for home dirs[1], and was colonized by the operating system in 1971 when it no longer fit on a single 1.5MB RK05 disk. Nobody ever untangled that change and we've been living with the hack ever since.
[1] https://lists.busybox.net/pipermail/busybox/2010-December/07...
tremon
20 hours ago
In other words, the strongest argument for usrmerge is that there is no compelling argument against it?
mariusor
19 hours ago
I think the current strongest argument against it is that systemd complains when /usr is on a separate partition[1], and what its devs have weighed in on the matter[2].
[1] https://freedesktop.org/wiki/Software/systemd/separate-usr-i...
[2] https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
amiga386
18 hours ago
sysvinit had no problem being told to mount /usr as soon as network was available, and if you set up an init script to run before /usr was available, but the script needed /usr, that was your own fault.
systemd relies on things in /usr being available, including to decide which scripts to run, and mounting /usr would be one of those scripts, so it has a chicken-and-egg problem.
But ah, it doesn't! Instead the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug.
Personally, I don't mind /usr/bin merging with /bin, the benefit I can see is no more squabbling over whether something should be in /bin or not (i.e. is this tool needed to boot the system, or not?)
mariusor
18 hours ago
> sysvinit had no problem being told to mount /usr [..] if you set up an init script to run before /usr was available,
> the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug.
Unironically in the same post despite being, to my untrained eye, the same thing.
amiga386
17 hours ago
The difference being that the authors of sysvinit didn't advertise obnoxious messages at boot time (https://systemd.io/SEPARATE_USR_IS_BROKEN/) and try to get the filesystem standards changed.
One is like "I'll run some scripts in order, everything else is on you", the other is like "I'll take care of everything, I'll do that, WHAT YOU DIDN'T MOUNT /USR ? SHAME ON YOU I DON'T WANT TO DEAL WITH THAT CORNER-CASE"
ElectricalUnion
10 hours ago
I read that message as "Whoever is the poor soul attempting to fix this system that doesn't boot, (because who otherwise inspects early boot messages?) whoever installed this system is running a known-fragile configuration."
And that's what I expect of systemd? That it should complain loudly whenever me, the daemons I'm attempting to run, or the overall system is doing things in a weird, known-bad, known-fragile way and warn me about it before it breaks if possible.
Brian_K_White
12 hours ago
systemd is my hammer having it's own opinions about what nails I hit & where & into what & why.
I want a nail only driven half in and at some crooked angle, that's my business.
It's not my hammers job to agree or disagree that it's a bad nail hammering job as far as it knows. I don't wantto have to convince it of the validity of a use-case it didn't think of before, or thought of and decided it doesn't agree to support.
I just want that crude coat hanger and I don't care who else likes it or doesn't like it or who else thinks I should buy an actual coat hanger and attach it in some way that someone else approves of.
ElectricalUnion
10 hours ago
> systemd is my hammer having it's own opinions about what nails I hit & where & into what & why.
I feel like the exact opposite. systemd has way too many layers of customization. Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes.
Now, if you are in a system that doesn't use systemd, if you mess with the "sacred and sanctioned" system service summoning scrolls, now you're on your own to diff whoever stuff the maintainer did, every time the summoning scroll changes, and to make sure that probably Turing-complete mess still summons a valid, working and safe system component instead of rampaging thru your system.
bitwize
5 hours ago
Systemd is what happens when a software engineer says "What you have here is not a hammer but a Wood Fastening Device Driver..."
We used to throw such people into moats.
wredcoll
10 hours ago
I don't want my hammer to have a razorblade embedded in the handle so if I grab it "wrong" my hand gets sliced up.
Look analogies work both ways!
josefx
6 hours ago
Poettering would assert that the razorblade is a part of their vision and systemd only supports modern, razorblade resistant hands anyways.
immibis
13 hours ago
In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc).
From the creators of systemd we also have GNOME, PulseAudio, and Wayland. They have some design philosophy in common.
BTW most sysvinit distros barely even use sysvinit. sysvinit is a service monitor, similar to systemd but more primitive, but typically most of what it's configured to do is to launch some shell scripts on startup. We really have "systemd distros" and "ad-hoc script distros", not sysvinit distros ("ad-hoc" is not a pejorative). I don't know why they don't make init a shell script directly - you can do that, and it's typically done that way in initramfs.
dathinab
15 hours ago
no, it is that it adds complexity which is no longer needed
especially for image based stuff it's a pain
which includes OCI images for things like docker
but also image based distros like e.g. ostree (as used through rpm-ostree by Atomic Fedora desktops like Fedora Silverblue, but also in similar but different forms something Ubuntu has been experimenting with)
1oooqooq
an hour ago
if you're building containers with full systemd instead of the pid0 shim you're doing systemd wrong
dathinab
15 hours ago
it makes things more complicated without any benefits (at least not anymore)
this doesn't matter for OS X which main changes mostly tend to be diverging away from it's roots into a fully proprietary direction
but it does matter if you build image based Linux distros which might be the future of Linux
jcgl
16 hours ago
Merged /usr is one (increasingly accepted?) means of implementing image-based distros. New OS version, new /usr parition.
comex
14 hours ago
macOS didn't merge /usr, but it did do something sorta related.
One of the purposes of usrmerge is to cleanly separate the read-only and read-write parts of the system. This helps with image-based distros, where /usr can be on its own read-only filesystem, and related use cases such as [1]. Usrmerge is not required for image-based distros to work [2], but it makes things cleaner.
macOS, starting in 2019, is also an 'image-based distro', in that it has a read-only filesystem for system files and a separate read-write filesystem for user data. However, the read-only filesystem is mounted at / instead of /usr. Several different paths under the root need to be writable [3], which is implemented by having a single read-write filesystem (/System/Volumes/Data) plus a number of "firmlinks" from paths in the read-only filesystem to corresponding paths in the read-write filesystem. Firmlinks are a bespoke kernel feature invented for this purpose.
Both approaches have their advantages and disadvantages. The macOS approach is nice in that the system filesystem contains _all_ read-only files/directories, whereas under "distro in /usr" scheme, you need a separate tmpfs at / to contain the mount points and the symlinks into /usr. But "distro in /usr" has the advantage of making the separation between read-only and read-write files simpler and more visible to the user. Relatedly, macOS's scheme has the disadvantage that every writable file has two separate paths, one with /System/Volumes/Data and one without. But "distro in /usr" has the opposite disadvantage, in that a lot of read-only files have two separate paths, one with /usr and one without. Finally, macOS's scheme has the disadvantage that it required inventing and using firmlinks. Linux can already achieve similar effects using bind mounts or overlayfs, but those have minor disadvantages (bind mounts are more annoying to set up and tear down; overlayfs has a bit of performance overhead). Actual firmlinks are not necessarily any better, though, since they don't have a clear story for being shared between containers (which macOS does not support). It is nice that "distro in /usr" doesn't require any such complexity.
Ultimately, the constraints and motivations on both sides are quite different. macOS couldn't have gotten everything read-only under one directory as easily because it has /System in addition to /usr. macOS doesn't have containers. macOS doesn't have different distros with different filesystem layouts and deployment mechanisms. And philosophically, for all that people accuse systemd of departing from Unix design principles, systemd seems to see itself as evolving the Unix design, whereas macOS tends to treat Unix like some legacy thing. It's no surprise that systemd would try to improve on Unix with things like "/bin points to /usr/bin" while macOS would leave the Unix bits as-is.
[1] https://lwn.net/Articles/890463/ [2] https://blog.verbum.org/2024/10/22/why-bootc-doesnt-require-... [3] https://eclecticlight.co/2023/07/22/how-macos-depends-on-fir...
blueflow
21 hours ago
I'm very happy that the "independent standard" facade of the UAPI group fell, and its actions are now directly attributed to systemd's interests.
dathinab
15 hours ago
> What ongoing maintenance would a file system standard require?
adaption to _a lot_ of subtle changes to requirements
- very different security related requirements today
- very different performance related requirements/characteristics
- very different need for various edge cases
and lastly adapt based on what turned out to work well and what didn't
so some examples not already mentioned in the article
- /boot -- dead or at least differently used if you use efistub booting
- /etc/X11 -- half dead on wayland
- /etc/xml, /etc/sgml -- dead, should IMHO never have existed
- also why was /etc/{X11,xml,sgml} every explicit part of the standard when the spec for `/etc` already implies them as long as e.g X11 is used ??
- `/media` -- dead/half dead depending on distro, replaced by `/run/media/{username}/{mount}`
- `/sbin` -- "controversial"; frequent reoccurring discussions that it isn't needed anymore, didn't work out as intended etc. It was useful for very old style thin clients as `/sbin` was in storage but `/bin` was mounted. And there are still some edge cases where it can makes sense today but most fall under "workaround for a different kind of problem which is better fixed properly".
- `/tmp` -- "controversial", long history of security issues, `/tmp` dir per program fixes the security issues (e.g. systemd service PrivateTmp option) but requires having a concept of "programs" instead of just "running processes" (e.g. by systemd services or flatpack programs). Also `tmpfiles.d` can help here.
- `/usr/libexec` -- dead, nice idea but introduces unneeded complexity and can be very misleading in combination swith suid and similar
- `/usr/sbin` see `/sbin`
- `/usr/share/{color,dict,man,misc,ppd,sgml,xml}` -- should never have been in the standard they are implied by the definition of `/usr/share`; at least sqml,xml are dead. dict was for spell check/auto completion, except that neither works anymore like dict expects
- `/var/account` -- to specific to some subset of partially dead programs, shouldn't be in the standard
- `/var/crash` -- distro specific mess
- `/var/games` -- basically dead/security mess, I mean 99% of games today are user per-user installed (e.g. Steam) and even for such which are packed any variable download data is per user, making it shared creates a permission/security mess
- `/var/lock` -- as mentioned there are better technical solutions by now, e.g. using `flock` instead of "presence of file" and some other techniques. Tend to also avoid issues of crashed programs not cleaning up "lock files" leading to dead locks and needing manual intervention.
- `/var/mail` assumes a quite outdated form of managing mail which is quite specific to the mailing program, as it's very program specific it IMHO shouldn't be in the standard
- various legacy program specific, non "generic" file system requirements e.g. that `/usr/lib/sendmail` must exist and be a link to a sendmail compatible program and similar.
also missing parts:
- `/run/user/{uid}`
- `/var/run/user/{uid}`
- `/proc`
- `/sys`
- user side versions (e.g. from the XDG spec which is also somewhat in a zombie state from my personal experience with it , e.g. .config, .local/{bin,share})
- references to light weight sandboxing, e.g. per-program /temp etc.
- factory reset stuff (`/usr/share/factory`) needed for having a uniform way for devices sold with Linux and device specific distro customization(e.g. steam deck)
so yes, it's quite outdated
Starlevel004
14 hours ago
> `/usr/libexec` -- dead,
Definitely not dead, the XDG portals and Polkit agents live here.
meltyness
a day ago
Well, it probably depends on which software's concern will be implementing a policy to prevent users from having permission to fill critical directories and prevent the system from operating normally, which is discussed in the article. Which is also a coordination problem because the most common user of disk is software itself, I think.
FHS seems to specifically imbue the user with the responsibility and consequences of filling up the disk.
paulddraper
17 hours ago
A more neutral phrasing would be.
> Debian Policy still cites the FHS, and FHS has remained static for over a decade.