hope not tied to SystemD [LWN.net]

hope not tied to SystemD

Posted Aug 15, 2025 22:14 UTC (Fri) by Wol (subscriber, #4433) [Link]

Given the mess that was SysVInit, almost anything would be an improvement ...

How many different places did you have to visit to change the hostname, for example ...

Cheers,
Wol

hope not tied to SystemD

Posted Aug 15, 2025 23:10 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (52 responses)

Reading through the standard[1], it mentions systemd in a few places. Some of these are fairly harmless (e.g. the vast majority of "reasonable" application packages will not need to care about exactly how /dev is managed, so the fact that the standard says it's done with systemd-udevd(8) is unlikely to cause compatibility issues, unless you do something silly like trying to install two different udev-like things at the same time). However, the document recommends the use of systemd-path(1) and other systemd facilities in several places, and I think that is more likely to be a sticking point.

I can see a few different options here:

* Rephrase all mentions of systemd as non-normative descriptions of how that particular implementation does it, rather than normative specifications of how it must be done, similar to the Boot Loader spec[2]. I see this as a dispreferred option because it would leave a few subdirectories with no portable means of discovery, most significantly /usr/lib/arch-id and its cousins.
* The man page for systemd-path says that it parses environment variables rather than talking to systemd. So it should be possible to replace all mentions of this binary with references to the corresponding environment variables. It might still be a good idea to say that systemd-path exists and can be used when systemd is installed, for the convenience of systemd users. But that will depend on whether non-systemd distros routinely set all of the relevant environment variables, with the same names and values. It may be the case that some things just can't be done portably.
* Remove all mentions of systemd entirely. This is strictly worse than rephrasing, because now *nobody* can find /usr/lib/arch-id, not even the systemd users.

[1]: https://uapi-group.org/specifications/specs/linux_file_system_hierarchy/
[2]: https://uapi-group.org/specifications/specs/boot_loader_specification/

hope not tied to SystemD

Posted Aug 16, 2025 7:48 UTC (Sat) by zuki (subscriber, #41808) [Link] (19 responses)

systemd-path provides a scriptable API for the paths listed in the spec. It has systemd in the name because it is part of the systemd project and we try to avoid namespace pollution.

udevd/systemd-udev is mentioned because it is *the* way that /dev is populated. Not mentioning it by name would be a poinless exercise in obfuscation.

Overall, I find it hard to see what to improve based on your comment. If you have something, please suggest a specific change. Or even better, just make a pull request.

hope not tied to SystemD

Posted Aug 16, 2025 9:25 UTC (Sat) by Wol (subscriber, #4433) [Link] (15 responses)

> udevd/systemd-udev is mentioned because it is *the* way that /dev is populated. Not mentioning it by name would be a poinless exercise in obfuscation.

Actually, mentioning systemd-udev is the pointless exercise. If I don't know (what is) systemd-udev, then that phrase is totally meaningless to me. You're promoting mechanism over policy, and in what is meant to be a specification that any system can implement that is BAD.

Remember back to the document format "wars". The official interoperable document definition is full of stuff like "Do it like Office 95 does it". Do we really want to be guilty of the same crap we were blaming Microsoft for? Or is the real reason likely the same reason we have all that Office 95 crap in the document spec - nobody actually knows how systemd-udev does it :rofl:

At the end of the day, saying "populate it with systed-udev" is dictating mechanism, where the spec should actually be stating policy.

Cheers,
Wol

hope not tied to SystemD

Posted Aug 16, 2025 11:53 UTC (Sat) by pizza (subscriber, #46) [Link] (14 responses)

> Actually, mentioning systemd-udev is the pointless exercise. If I don't know (what is) systemd-udev, then that phrase is totally meaningless to me.

As the saying goes, "you must be at least <this> tall to get on this ride"

If you don't know what systemd-udev is, you probably shouldn't be putting together something that requires either setting things up in /dev or even referencing things in /dev. Or heck, most of what the FHS covers... and, going back to TFA, doesn't cover but is still necessary to know if you want your stuff to work on a general purpose linux system.

hope not tied to SystemD

Posted Aug 16, 2025 13:21 UTC (Sat) by Wol (subscriber, #4433) [Link] (4 responses)

And if your system runs OpenRC? Okay, mine should by default (I've changed it to systemd), but there are other init systems out there, and it's quite possible to have a linux system without systemd-udev. Expecting someone (even with a lot of admin experience) running one of those to have a detailed knowledge of systemd-udev is unreasonable.

At the end of the day, you shouldn't be saying "do it like systemd-udev". You should be saying "this is what systemd-udev does". Same end result, but policy not mechanism.

Cheers,
Wol

hope not tied to SystemD

Posted Aug 16, 2025 14:28 UTC (Sat) by pizza (subscriber, #46) [Link] (2 responses)

> At the end of the day, you shouldn't be saying "do it like systemd-udev". You should be saying "this is what systemd-udev does".

The thing is, systemd-udev is literally the canonical udev implementation. Every other has to behave the same way or $badness happens.

So sure, I guess they could cut-and-paste the systemd-udevd documentation and do a global search-and-replace of the name with "the implementation". Or maybe just incorporate it via reference.

hope not tied to SystemD

Posted Aug 17, 2025 1:07 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

I would do neither of those things.

Currently, this section of the standard reads as follows:

> /dev/
>
> The root directory for device nodes. Usually, this directory is mounted as a devtmpfs instance, but might be of a different type in sandboxed/containerized setups. This directory is managed jointly by the kernel and systemd-udevd(8), and should not be written to by other components. A number of special purpose virtual file systems might be mounted below this directory.

Frankly, this is basically fine. As I said, the mention of systemd is incidental and not really relevant to application developers anyway.

But if "basically fine" is not good enough, and if we insist on making it perfect, you could argue for changing it to the following:

> /dev/
>
> The root directory for device nodes. Usually, this directory is mounted as a devtmpfs instance, but might be of a different type in sandboxed/containerized setups. This directory is managed jointly by the kernel and a userspace component such as systemd-udevd(8), and should not be written to by other components. A number of special purpose virtual file systems might be mounted below this directory.

Maybe also add a paragraph like this:

> The userspace component responsible for managing this directory is considered an implementation detail. Portable applications should not make assumptions about the nature or behavior of said component, unless the application takes a dependency on systemd or some other specific implementation.

But there is absolutely no need to go into exhaustive detail of exactly how systemd happens to do this. What matters is that:

1. Device files live in /dev/.
2. The host environment or "operating system," broadly construed, is responsible for managing those device files.
3. If you're an application developer, this is not your problem to deal with. Don't try to do anything clever, just open the device file you want to use.
4. ...unless you're willing to take a systemd dependency, then of course you can assume systemd-specific behaviors.

hope not tied to SystemD

Posted Aug 25, 2025 16:32 UTC (Mon) by pj (subscriber, #4506) [Link]

I want to +1 this so hard. Yes. Policy over mechanism, but policy can _refer_ to existing mechanisms.

hope not tied to SystemD

Posted Aug 16, 2025 18:33 UTC (Sat) by bluca (subscriber, #118303) [Link]

It doesn't say anything like that, maybe give it a read first?

hope not tied to SystemD

Posted Aug 16, 2025 14:30 UTC (Sat) by Wol (subscriber, #4433) [Link]

> If you don't know what systemd-udev is,

Actually, do even you know what systemd-udev is, eg what version, what tag in git, yada yada it is that they're referring to?

Simply saying "do it like systend-udev", or "with systemd-udev", is handing the ability to change the formal specification to any old tom dick or harry who happens to submit an update, bug fix or whatever, quite possibly without any idea whatsoever that he's actually modifying a formal spec! At least the Office spec says "like Office 95", even if nobody has a clue what Office 95 actually does :-)

That's why the UEFI specification is careful to lock down the exact version of the FAT-32 or FAT-16 specification it's referring to, so any updates to FAT can't unintentionally update UEFI at the same time ...

Cheers,
Wol

hope not tied to SystemD

Posted Aug 17, 2025 12:17 UTC (Sun) by kreijack (guest, #43513) [Link] (7 responses)

> > Actually, mentioning systemd-udev is the pointless exercise. If I don't know (what is) systemd-udev, then that phrase is totally meaningless to me.
> [...]
> If you don't know what systemd-udev is, you probably shouldn't be putting together something that requires either setting things up in /dev or even referencing things in /dev.

Being a specification, it is the opposite: *udev should refer to this specification for its behavior. And the same of course should do the developer of an application.

The point is important, because a developer want to know what can assume and what can't. E.g. it is important to know if a developer can assume that /dev/disk/by-label/... exists in any environment or he can assume that only /dev/sd* (and all its variant like /dev/mmcblk* /dev/hd*) exist. May be some environments (e.g. embedded) prefer a static /dev instead a dynamic one populated by udev.

It is fine even saying something like: "
- /dev/ is populated by the devices seen by the kernel; depending by the environment it can be a static directory or a dynamic one populated by *udev.
- /dev/disks is populated by the devices seen by the kernel; it is managed by udev; in environment where udev is not used it doesn't exist"

The point is to highlight what can be assumed, and what may be assumed. It is even reasonable to say: "this specification doesn't cover /dev". But saying "see *udev for /dev" doesn't clarify what a developer can assume or not. Which for a specification is a failure.

hope not tied to SystemD

Posted Aug 17, 2025 14:27 UTC (Sun) by pizza (subscriber, #46) [Link] (6 responses)

> The point is important, because a developer want to know what can assume and what can't.

Please read what I wrote, and to what I was responding.

If you don't know what systemd-udev is, and you are putting together something that needs to interact with /dev in some way, then that is a sign that you are missing on some foundational knowledge about how Linux systems have been put together for the past *two decades* and need remedial education before you should proceed.

Yes, two decades is longer than systemd itself has existed -- systemd-udevd is, for all intents and purposes, the continuation of the original udev, the latter having been subsumed into the systemd repository over 13 years ago [1].

Like it or not, systemd underpins the _overwhelming majority_ of non-android/non-embedded [2] Linux [3] installations today, and probably >99% of commercially-relevant installations. For all intents and purposes, it can be generally assumed to exist if you are writing something intended to be deployed on Linux. Frankly, leaving systemd's basic services out of a new baseline "this is what application writers can rely upon" spec is completely nonsensical, and is tantamount to ignoring the past 15 years of platform development.

[1] https://lwn.net/Articles/499480/
[2] Ie where Linux is not considered a hidden implementation detail
[3] Non-linux systems diverge wildly once you venture beyond what POSIX requires. Where hardware interaction is concerned, ie where interaction with /dev comes into play, every major OS family (even in the UNIXish world) does things its own way.

hope not tied to SystemD

Posted Aug 18, 2025 4:34 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (3 responses)

> systemd underpins the _overwhelming majority_ of non-android/non-embedded [2] Linux [3] installations today

> and probably >99% of commercially-relevant installations.

I'd like to remind that many Linux users are hobbyists and we should not stop supporting them. And that distros that avoid systemd also exist (I use one of them).

hope not tied to SystemD

Posted Aug 18, 2025 13:06 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> I'd like to remind that many Linux users are hobbyists and we should not stop supporting them. And that distros that avoid systemd also exist (I use one of them).

Who is that "we" you refer to, and why are you volunteering them for additional work?

Do you think that "we" should still be actively supporting retrocomputing folks that intentionally run hardware that was discontinued at least two decades ago? What about Debain/KFreeBSD or Hurd? All of those users are hobbyists too!

Supporting a bajillion snowflake environments is why applications using autotools (not to mention autotools itself) are baroque messes. That complexity mattered at one point ("it's where most of the users are"), but is it really worth spending time to ensure folks running ancient proprietary UNIXes [1] can use the latest software? (Mainline Linux just dropped support for anything older than 2nd-gen Pentium processors for similar reasons!)

Given that you only have limited resources (time/effort/money) at your disposal, you can't support everyone, so you draw the line to get the best return on what you can do. Given that systemd has been the default (or only) option for anything resembling mainstream released [2] or still supported [3] in the past decade, maybe that is where your attention should be focused instead of (more than) doubling your effort to support the remaining few percent.

...To throw out another analogy -- Do you really expect a typical automobile mechanic today to be able to readily diagnose the kinds of malaises common with complex smog-era carburettors, given that the the final vehicle sold with one was in 1994 [4]? Or would you go to a specialist (or become the specialist yourself) as that is the price you're (literally) having to pay for your hobby?

[1] Keep in mind that these systems can be _emulated_ faster (and with vastly more memory and other resources) than the real hardware could ever achieve.
[2] Debian was the final holdout, and even then its non-systemd paths have been slowly bitrotting because the folks complaining are rarely the ones *doing*.
[3] As of today, the only commercial non-systemd options are supported only via very pricey "extended support" offerings. Nobody is going to be setting up _new_ systems with (or writing/porting new software to) RHEL6 without a pretty substantial budget or the understanding they are completely on their own.
[4] Most of the industry had completely switched to fuel injection by the late 80s, though a few stragglers held on into the early 1990s. The final carburettor-equipped vehicle sold in the US was the 1994 Isuzu "Faster" pickup truck.

hope not tied to SystemD

Posted Aug 18, 2025 18:02 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (1 responses)

> Who is that "we" you refer to, and why are you volunteering them for additional work?

Open source project maintainers in general.

And in particular, anyone attempting to replace the FHS 3.0, which I still try to follow as much as I can (with sane deviations, of course). Is it so much work to support those in a file-system hierarchy standard? I bet the differences are rather small.

> Do you think that "we" should still be actively supporting retrocomputing folks that intentionally run hardware that was discontinued at least two decades ago? What about Debain/KFreeBSD?

No. Hardware/software that was discontinued long ago is dead to me.

In general, maintaining support for those systems is a lot of work, and results in less safe code (for example, 32-bit code is prone to bugs). That's something I don't mess with.

> or Hurd? All of those users are hobbyists too!

I receive patches from GNU/Hurd maintainers when software that I co-maintain doesn't work in Hurd. I appreciate their effort in making it work, and accept those patches. After all, it's not too much; often, it's just a macro that in Hurd is not defined, so we define a fallback ourselves. Hurd is not discontinued, and not unsafe, so I help them.

> Given that systemd has been the default (or only) option for anything resembling mainstream released [2] or still supported [3] in the past decade, maybe that is where your attention should be focused instead of (more than) doubling your effort to support the remaining few percent.

Someone in this thread reminded that Gentoo doesn't use systemd by default. That's a system I would consider mainstream.

I personally use Devuan, and I'm happy with it. It works.

hope not tied to SystemD

Posted Aug 18, 2025 20:20 UTC (Mon) by pizza (subscriber, #46) [Link]

> > Who is that "we" you refer to, and why are you volunteering them for additional work?
> Open source project maintainers in general.

"Open source project maintainers in general" don't owe you (or anyone else) anything.

You don't get to tell them, collectively or individually, what they should or should not be spending their time doing.

(Unless you're paying them)

> Someone in this thread reminded that Gentoo doesn't use systemd by default. That's a system I would consider mainstream.

Don't equate "familiarity" with "mainstream" -- Gentoo explicitly targets folks that already know enough to be able to make (and deal with the consequences of) the multitude of choices that it enables/provides. Whereas the "mainstream" just wants "something that works".

hope not tied to SystemD

Posted Aug 18, 2025 14:12 UTC (Mon) by kreijack (guest, #43513) [Link] (1 responses)

> If you don't know what systemd-udev is, and you are putting together something that needs to interact with /dev in some way, then that is a sign that you are missing on some foundational knowledge about how Linux systems have been put together for the past *two decades* and need remedial education before you should proceed.

I am perfectly fine with udev. This is not the point of discussion. The point of discussion is *IF* a specification should leverage or not on udev when we are talking about /dev

FHS should define what users and/or developers should expect from the filesystem. If it is not possible, the specification should either:
1) explicitly state that it is out of scope,
or 2) point ti another specification

Both approaches are acceptables.
It has to be point out that udev is an *implementation*, not a *specification*, and leveraging to udev is an mistake because understanding what udev does is possible only reading the source/man page/configuration files which is an activity long and errors prone.

Therefore, the most appropriate course of action would be to leave /dev device management out of scope for this specification, rather than deferring to an implementation like udev.

hope not tied to SystemD

Posted Aug 18, 2025 17:58 UTC (Mon) by zuki (subscriber, #41808) [Link]

FWIW, "systemd-udev" is a hyperlink in the text, so people who do not know are not sure can always follow the link and read…

The text in question just says that /dev is managed in cooperation by kernel and systemd-udevd, without saying anything about how this is done and how udev should behave. So the whole discussion seems a bit pointless. We certainly don't want to describe the details of udev in the page about file hierachy.

Anyway, https://github.com/uapi-group/specifications/pull/157 is now up with some rewordings based on the discussion and suggestions here.

hope not tied to SystemD

Posted Aug 16, 2025 15:21 UTC (Sat) by mgb (guest, #3226) [Link] (1 responses)

> udevd/systemd-udev is mentioned because it is *the* way that /dev is populated.

So the "standard" changes every time udev changes and *the* one true standard way that /dev is populated is in fact determined by a thousand lines of rules in half a hundred rules files in /etc and /usr/lib ?

Do I need to switch from stable to unstable so that I can update my udev package roughly 40 times in the last 12 months to maintain compliance with this standard?

hope not tied to SystemD

Posted Aug 16, 2025 18:35 UTC (Sat) by bluca (subscriber, #118303) [Link]

You should read something before you criticize it going off solely by some off-hand comment. If you do that, you'll see that nothing you said has any relations with it.

hope not tied to SystemD

Posted Aug 17, 2025 0:46 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

Either replace the following with something that does not depend on systemd, or add a vendor-neutral alternative:

> To query $libdir for the primary architecture of the system, invoke:
>
> systemd-path system-library-arch

Currently, no alternative is provided, and systems that lack systemd altogether cannot support this interface.

hope not tied to SystemD

Posted Aug 16, 2025 9:56 UTC (Sat) by bluca (subscriber, #118303) [Link] (30 responses)

> However, the document recommends the use of systemd-path(1) and other systemd facilities in several places, and I think that is more likely to be a sticking point.

It shouldn't be for any reasonable reader, and unreasonable ones will never be happy anyway.

Mentioning real-world tools like systemd-path as examples of things that can be used, rather than as normative things to follow, is useful and informative, as it suggests an immediate and practical way to interact with the specification.

This spec is very much intended to be user-facing as well, so that if one wonders what is what on their system, it can be used to find out.

hope not tied to SystemD

Posted Aug 17, 2025 0:44 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (29 responses)

> Mentioning real-world tools like systemd-path as examples of things that can be used, rather than as normative things to follow, is useful and informative

Agreed. Unfortunately, that is not what the standard says. For example:

> To query $libdir for the primary architecture of the system, invoke:
>
> systemd-path system-library-arch

No alternative mechanism is provided. If you can't invoke systemd-path (because it is not installed), then per the standard, you just can't find that directory at all.

hope not tied to SystemD

Posted Aug 17, 2025 10:11 UTC (Sun) by bluca (subscriber, #118303) [Link] (28 responses)

Of course you can, you just have to use a different mean to derive it. If your vendor doesn't want to ship that tool to you, they can make available another mechanism.

hope not tied to SystemD

Posted Aug 17, 2025 14:36 UTC (Sun) by Wol (subscriber, #4433) [Link] (27 responses)

But the point is, the standard is specifying mechanism. It shouldn't - it should be specifying policy.

If I read THE STANDARD, and my system does not provide systemd and its assorted bits and pieces, then I'm up a gum tree. Isn't the point of standards to avoid such gum tree messes? Yes yes real world cough cough it doesn't always work ... but that is a pretty blatant failure of the standards process!

Cheers,
Wol

hope not tied to SystemD

Posted Aug 17, 2025 14:55 UTC (Sun) by bluca (subscriber, #118303) [Link] (10 responses)

> But the point is, the standard is specifying mechanism. It shouldn't - it should be specifying policy.

No, it mentions whatever we find useful to mention and is in scope. And for normal users this is useful information.

If it offends the feelings of a couple of antis, well, they'd be offended anyway, so why bother and make things worse for nearly everyone in a futile attempt to satisfy a handful of loudmouths who will never be satisfied anyway? Makes zero logical sense

hope not tied to SystemD

Posted Aug 17, 2025 18:18 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (9 responses)

Please stop putting words in my mouth. I never said there was anything wrong with mentioning systemd. I'm simply of the opinion that systemd should not be described as the one and only way of obtaining a specific piece of information, as it makes all non-systemd distros inherently non-compliant with the spec. That would be fine if this was a systemd spec, but it is a UAPI spec.

hope not tied to SystemD

Posted Aug 17, 2025 20:25 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

What's the organisation that refused to standardise anything unless there were TWO independent implementations?

As I said before, we screamed blue murder about the amount of Office XML stuff that was defined as "what Office 95 does". Why are we now doing exactly the same thing and defining something as "what systemd does".

And again as I said, do we want to give any Tom Dick or Harry the power to change the defined standard - quite possibly without realising that's what they're doing - just by submitting a bugfix or enhancement to the definition?

It's shades of the C specification saying "we defer to the platform standard", when the Posix platform standard says "we defer to the official C specification". The end result is a definition that cannot be trusted to (a) be easily understood, and (b) to be trusted to remain (mostly) immutable.

Cheers,
Wol

hope not tied to SystemD

Posted Aug 17, 2025 21:34 UTC (Sun) by pizza (subscriber, #46) [Link]

> As I said before, we screamed blue murder about the amount of Office XML stuff that was defined as "what Office 95 does". Why are we now doing exactly the same thing and defining something as "what systemd does".

Putting aside the minor detail that "the amount" referenced above was actually just _once_ [1], there is a _major_ difference between saying "do what <proprietary undocumented thing> does" and "do what <a heavily-documented component of a Free Software tool that ~98.76% of the intended audience has been using for over a decade> does"

[1] 2.15.3.26 footnoteLayoutLikeWW8

hope not tied to SystemD

Posted Aug 17, 2025 22:15 UTC (Sun) by bluca (subscriber, #118303) [Link] (6 responses)

> as it makes all non-systemd distros inherently non-compliant with the spec

No? The spec is about directories. Tools are not part of it, they are useful ancillary information. The spec is called "Linux Filesystem Hierarchy" not "tools to print directories"

hope not tied to SystemD

Posted Aug 18, 2025 3:39 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (5 responses)

The spec says that the only way to discover the location of /usr/lib/arch-id is to run a systemd command, as I said upthread[1]. No alternative is provided, so on systems that lack systemd, there is simply no specification of where this directory is located or how to find it. The same also goes for the .../lib/arch-id subdirectories in other parts of the filesystem.

[1]: https://lwn.net/Articles/1034093/

hope not tied to SystemD

Posted Aug 18, 2025 8:02 UTC (Mon) by gdiscry (subscriber, #91125) [Link]

The spec says that arch-id in $libdir is an architecture tuple:

The architecture identifier to use is defined on Multiarch Architecture Specifiers (Tuples) list.

The issue is that some distributions do not use that path:

Legacy locations of $libdir are /usr/lib/, /usr/lib64/.

Therefore, systemd-path is currently one way to query the path of $libdir at runtime across distributions that use systemd.

You could also use the first existing directory:

/usr/lib/arch-id/
/usr/lib64/ (if your architecture is x86_64)
/usr/lib/

hope not tied to SystemD

Posted Aug 18, 2025 8:49 UTC (Mon) by bluca (subscriber, #118303) [Link] (3 responses)

> The spec says that the only way to discover the location of /usr/lib/arch-id is to run a systemd command

No, it doesn't say it's the only way. It provides that as a way to do that, which works in 99.999% of the cases.

hope not tied to SystemD

Posted Aug 18, 2025 17:30 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

> No, it doesn't say it's the only way.

Can we please drop the silly word pedantry? If the spec describes one and only one way to do something, and gives not the slightest hint that that way will not work in all circumstances, then supporting that method is a requirement of the spec. I'm baffled that you are continuing to argue this point.

hope not tied to SystemD

Posted Aug 18, 2025 17:43 UTC (Mon) by bluca (subscriber, #118303) [Link] (1 responses)

Once again, there is no requirement for any particular tool, it's just a description of a hierarchy of directories, and that's the end of it. Any requirement for any particular tool is a misreading, intentional or not.

hope not tied to SystemD

Posted Aug 18, 2025 17:46 UTC (Mon) by daroc (editor, #160859) [Link]

I think neither of you are likely to change each other's minds at this point. Let's leave the discussion here, please.

hope not tied to SystemD

Posted Aug 17, 2025 14:56 UTC (Sun) by pizza (subscriber, #46) [Link] (15 responses)

> I read THE STANDARD, and my system does not provide systemd and its assorted bits and pieces, then I'm up a gum tree. Isn't the point of standards to avoid such gum tree messes?

Uh, the entire point of a specification is to define minimum requirements, and by definition, if you don't meet those, you're SoL.

hope not tied to SystemD

Posted Aug 17, 2025 20:35 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (14 responses)

If systemd is required to comply with the standard, then they probably should not have given it to the UAPI folks in the first place.

(I say this as someone who likes and uses systemd. My position is not that systemd should be removed from the standard, merely that systemd should not be part of the minimum requirements for a standard that wishes to be universal.)

hope not tied to SystemD

Posted Aug 17, 2025 21:16 UTC (Sun) by pizza (subscriber, #46) [Link] (4 responses)

> My position is not that systemd should be removed from the standard, merely that systemd should not be part of the minimum requirements for a standard that wishes to be universal.

"Universality" only extends out to the scope of what you're trying to achieve.

A truly "universal standard" would necessarily need to include the likes of Windows, MacOS/iOS, zOS, and so forth... good luck finding common ground there. Just like it is reasonable to reduce the scope of said "universality" to exclude non-UNIXes, it's reasonable to exclude non-Linuxes. But even sticking to "Linux", it's reasonable to exclude Android and purpose-built embedded systems... and oh look, we're already quibbling over where the outer bounds are drawn.

In this specific instance, excluding systemd-udev by name makes little sense given that it is the canonical implementation of /dev management under Linux, and independent re-implentations [1] have to behave in the same manner or fail the basic fitness-for-purpose test.

[1] all one of them (ie busybox) -- There's also eudev, but it was forked from pre-residing-in-systemd's-git-repo udev for entirely political [2] reasons.
[2] "We don't want to have any source code from systemd present even if the udev binary produced has zero runtime dependencies on systemd"

hope not tied to SystemD

Posted Aug 17, 2025 22:26 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

> it's reasonable to exclude non-Linuxes. But even sticking to "Linux", it's reasonable to exclude Android and purpose-built embedded systems... and oh look, we're already quibbling over where the outer bounds are drawn.

Well, I run a mainstream (at least, last I knew it was used by kernel devs like Greg KH) distro, and I had to change the init system away from the default, and to systemd. (And yes, I do describe gentoo as somewhat systemd-hostile, but the distro devs prefer OpenRC which I believe predates systemd, so it's not a case of "we refuse to have systemd", just "we don't see the benefit in changing". I don't agree, but I'm not a distro dev, and I've taken advantage of the ability to change the default.)

Any spec that is intended to be a reference for ALL "typical" linux distros should not defer to what just SOME of those distros do. A proper superset should not be defined in terms of a subset - it's just the wrong thing to do.

To put it in your terms, if the spec writers intend it to apply to "all linux distros", or even "all linux distros with typical user spaces like Gnome or KDE/Plasma, then they have extended the boundaries of the spec beyond systemd-distros, so they cannot assume the presence of systemd on the system.

Cheers,
Wol

hope not tied to SystemD

Posted Aug 17, 2025 22:33 UTC (Sun) by bluca (subscriber, #118303) [Link] (2 responses)

> they cannot assume the presence of systemd on the system

quote the parts where that is the case

hope not tied to SystemD

Posted Aug 18, 2025 7:07 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

So you clearly didn't read the comment you were replying to.

My distro, by default, does NOT install systemd, therefore you cannot assume its presence on my system (yes it does happen to be there, I over-rode the default, but the choice is either/or, not both/and).

Cheers,
Wol

hope not tied to SystemD

Posted Aug 18, 2025 8:51 UTC (Mon) by bluca (subscriber, #118303) [Link]

...and? What has that to do with anythng written there?

hope not tied to SystemD

Posted Aug 17, 2025 22:13 UTC (Sun) by bluca (subscriber, #118303) [Link] (8 responses)

> If systemd is required to comply with the standard

Can you quote the parts that where that is the case?

hope not tied to SystemD

Posted Aug 18, 2025 3:41 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (7 responses)

As I explained to you in another subthread, I already quoted that part of the spec upthread: https://lwn.net/Articles/1034093/

To be clear, this is not "optional" or ancillary information. It is the only way to discover the path to one of the specified directories.

hope not tied to SystemD

Posted Aug 18, 2025 8:50 UTC (Mon) by bluca (subscriber, #118303) [Link] (6 responses)

You are mistaken, this is most definitely optional and ancillary information.

hope not tied to SystemD

Posted Aug 18, 2025 9:26 UTC (Mon) by rschroev (subscriber, #4164) [Link]

If it is meant as optional and ancillary information, might I suggest rewriting it?

"Instead of constructing the arch-id and $libdir manually, you can query $libdir for the primary architecture of the system by invoking systemd-path system-library-arch on systems that support it". Or something similar.

The way it is written now, very much gives the impression that invoking systemd-path system-library-arch is the one and only way.

hope not tied to SystemD

Posted Aug 18, 2025 17:27 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (4 responses)

In a spec that describes the layout of the filesystem, the path to one of the specified directories is not "ancillary" information. It is a core part of the spec.

hope not tied to SystemD

Posted Aug 18, 2025 17:41 UTC (Mon) by bluca (subscriber, #118303) [Link] (3 responses)

The path is not related in any way, shape or form to any tool. It's distribution and architecture dependent, and that's why there's a convenience utility available.

I assure you that out of ~60000 packages building right now in Debian, and however many are in Ubuntu, exactly _zero_ use systemd-path to query the library directory at build time. A significant fraction of those _will_ need to explicitly know what the exact path is, and they won't use that tool for it.

It's just a utility provided for convenience, it is not part of any specification.

hope not tied to SystemD

Posted Aug 21, 2025 7:06 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

> it is not part of any specification.

Good, then you should have no objection to rewording that sentence in a way that clarifies it is non-normative.

I'm glad we're in agreement on that much, at least.

hope not tied to SystemD

Posted Aug 21, 2025 10:15 UTC (Thu) by bluca (subscriber, #118303) [Link]

Feel free to send a PR to adjust any wording of any sentence of any paragraph, and it will be discussed in its own merit

hope not tied to SystemD

Posted Aug 21, 2025 10:14 UTC (Thu) by bluca (subscriber, #118303) [Link]

> I assure you that out of ~60000 packages building right now in Debian, and however many are in Ubuntu, exactly _zero_ use systemd-path to query the library directory at build time. A significant fraction of those _will_ need to explicitly know what the exact path is, and they won't use that tool for it.

This is not a hyperbole btw, I really mean it.

Number of packages calling systemd-path in debian/rules to find per-arch libdir: zero out of 30000

https://codesearch.debian.net/search?q=path%3Adebian%2Fru...

Number of packages using at least one other mean (a specific makefile include file that defines a specific makefile var, none of which are related to systemd): ~5000 out of ~30000

https://codesearch.debian.net/search?q=path%3Adebian%2Fru...

hope not tied to systemd

Posted Aug 16, 2025 13:09 UTC (Sat) by rhbvkleef (subscriber, #154505) [Link]

I think this is unfortunate. Standards like this should consider systemd as it is (I am guessing) the most used init system currently, though other init systems like Busybox init, and OpenRC /are/ used, so should be considered too. Thus, mentioning systemd like the standard currently does is not the best, and I especially like the first solution you proposed:

> Rephrase all mentions of systemd as non-normative descriptions of how that particular implementation does it, rather than normative specifications of how it must be done, similar to the Boot Loader spec[2]. I see this as a dispreferred option because it would leave a few subdirectories with no portable means of discovery, most significantly /usr/lib/arch-id and its cousins.

hope not tied to SystemD

Posted Aug 16, 2025 12:04 UTC (Sat) by pizza (subscriber, #46) [Link]

> Sorry I meant the standard shall not be tied to particular init system, which shall not control the file system layout in any way.

The *only* defined job for init (ie pid 0) is to reap children processes. (And to not die itself...)

Meanwhile, in the real world, folks run non-spherical-cow inits [1] that do a heck of a lot more than that, because it turns out that operating system creators and application writers need more functionality to create a usable system with components whose presence can be relied upon. The FHS (and its successors) are attempts to do just that.

[1] eg sysvinit, which does neither one thing, nor well.