hope not tied to SystemD
hope not tied to SystemD
Posted Aug 17, 2025 12:17 UTC (Sun) by kreijack (guest, #43513)In reply to: hope not tied to SystemD by pizza
Parent article: Finding a successor to the FHS
> [...]
> 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.
Posted Aug 17, 2025 14:27 UTC (Sun)
by pizza (subscriber, #46)
[Link] (6 responses)
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/
Posted Aug 18, 2025 4:34 UTC (Mon)
by alx.manpages (subscriber, #145117)
[Link] (3 responses)
> 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).
Posted Aug 18, 2025 13:06 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
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.
Posted Aug 18, 2025 18:02 UTC (Mon)
by alx.manpages (subscriber, #145117)
[Link] (1 responses)
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.
Posted Aug 18, 2025 20:20 UTC (Mon)
by pizza (subscriber, #46)
[Link]
"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".
Posted Aug 18, 2025 14:12 UTC (Mon)
by kreijack (guest, #43513)
[Link] (1 responses)
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:
Both approaches are acceptables.
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.
Posted Aug 18, 2025 17:58 UTC (Mon)
by zuki (subscriber, #41808)
[Link]
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
[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
hope not tied to SystemD
[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
hope not tied to SystemD
> Open source project maintainers in general.
hope not tied to SystemD
1) explicitly state that it is out of scope,
or 2) point ti another specification
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.
hope not tied to SystemD