probably not a huge deal, but bigger implications [LWN.net]

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 15:56 UTC (Mon) by wtarreau (subscriber, #51152)
In reply to: probably not a huge deal, but bigger implications by calvin
Parent article: GNOME deepens systemd dependencies

> the system layer is pretty important (see Benno Rice's talk); perhaps there should be an effort to make that kind of functionality available across OSes, and have an API for it. The POSIX of service management, if you will.

But IMHO there's already such an API, it's based on config files, /dev entries and reasonably portable commands like mount, ps, etc. It has worked for a very long time. Even 25 years ago, the CDE environment was very well integrated with multiple proprietary operating systems without having to require deep OS-level changes. You could perfectly well click on a CD icon to mount a CD for example, listen to wav files, or see notifications when you had mails.

I'm not really sure what is being attempted these days by making all this stuff so much complicated, brittle and resource hog, but it must be profitable to someone (maybe users?) or maybe it's self-feeding.

to post comments

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 16:44 UTC (Mon) by Wol (subscriber, #4433) [Link]

> I'm not really sure what is being attempted these days by making all this stuff so much complicated, brittle and resource hog, but it must be profitable to someone (maybe users?) or maybe it's self-feeding.

Ooh - new! shiny!

Unfortunately grey beards are not normally shiny.

As Ecclesiastes said, there's nothing new under the sun. Unfortunately the young turks keep re-inventing the wheel - isn't that part of what being a young turk is?

Cheers,
Wol

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 17:39 UTC (Mon) by calvin (subscriber, #168398) [Link]

Can you point me to a standard Unix API for managing processes? Even before systemd, System V and BSDs had their own things, and they lacked a general API for building supervision trees, especially at a per user or session level.

Your memories of CDE aren't also quite accurate - there was a ton of vendor customization of CDE. Solaris, for instance, had its own automounter that they had CDE integrate into. The other vendors had their own and they were all proprietary and different in their own ways. The current state of affairs with fd.o presenting a single interface for i.e. UDisks or whatever is much better than what we had in the 90s. A lot more complicated than mount(8)...

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 17:48 UTC (Mon) by jafd (subscriber, #129642) [Link]

My memory is that the "API" we had so far, based on "config files, /dev entries and reasonably portable commands like mount, ps, etc." has been, as you put it, "so much complicated, brittle and resource hog".

There are reasons every desktop environment in existence comes with its own "session manager" (one is that before systemd, there was nothing portable or uniform to manage the user session at all, and no, a 4,000-line bashrc ain't it). In my older days, playing audio used to be related to a wonderfully refreshing experience of using lsof to find who was holding up the sound hardware this time. Using removable media was invariably connected with a cornucopia of permission errors, then begrudgingly dropping to a root shell.

Sure, you could count on the commands to be "reasonably portable", for some values of "reasonable", but there are all sorts of hooks and crooks when it comes to actually using them all together and making assumptions about things. Look at the old sysvinit scripts for popular services — you can see how they grew in response to edge cases being discovered. They are very far from being simple. Knowing and understanding them could sure bring joy to someone fond of collecting arcane bits of knowledge.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:25 UTC (Mon) by ballombe (subscriber, #9523) [Link] (15 responses)

Use xfce, xfce is what CDE tried to be but never achieved.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:52 UTC (Mon) by joib (subscriber, #8541) [Link] (14 responses)

I recall xfce 2.x and 3.x having some resemblance to CDE, but the current XFCE 4.x, not so much.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:56 UTC (Mon) by jzb (editor, #7867) [Link] (13 responses)

Users can still theme Xfce to look like CDE if that happens to be their preference.

Funny enough, I used to think CDE was hideous—but I have to admit, it's grown on me over the years. Probably just nostalgia...

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 21:30 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

> I used to think CDE was hideous

I always found it hideous as well :-) And super slow. But it did work on a 64 MB machine at 300 MHz. Standards have changed!

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 6:39 UTC (Tue) by joib (subscriber, #8541) [Link] (1 responses)

CDE was(is?) hideous, but I used xfce 2.x for some years due to being used to the UI from using a precursor to CDE at a summer job (HP VUE).

Not sure whether I should be happy or horrified that it's possible to recreate that look with modern xfce. ;-)

CDE as XFCE gateway

Posted Jun 24, 2025 12:26 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Yes! I had a job on Solaris running CDE, and I discovered XFCE which at the time was very CDE-like.

I'm still happily using XFCE4 even though it's no longer particularly CDE-like. The XFCE developers are very conservative about changes to look and feel, and my muscle memory appreciates that.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 9:46 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

CDE looked clunky and ugly, when you were used to OpenLook!

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 11:34 UTC (Tue) by joib (subscriber, #8541) [Link] (7 responses)

It was even possible to run openlook on Linux. Alas, IIRC it was never open source so you had to download and compile it and whatever applications needed the libs yourself instead of using something packaged by the distro of your choice. I think I tried it out sometime, as I had sometime visited my fathers workplace where they had these Sun workstations with for the time humongous 21" screens. Albeit grayscale, but still glorious.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 12:40 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

Yes, there was 'olwm' - OpenLook Window Manager. Unfortunately the OpenLook toolkit was never released with source, AFAIK. A lower level XView toolkit was, but I don't think much used it (?). The ability to pin windows - literally with a little virtual pin - was nice in OpenLook.

The Silicon Graphics "Indigo Magic Desktop" was also nice, with some nice widgets. Like a little thumbwheel for zooming in and out of views, and sliders that looked like sliders. Very nice. Motif based, so the later CDE didn't look /too/ different from it (indeed, CDE surely took a lot of cues from IMD).

University I went to had a lab full of SparcStation 1's and 1+'s with OpenLook, and another lab full of Silicon Graphics Indy's with IMD. Such amazing machines at the time (the Indy's particularly). Unix OSes and their desktops were just light years ahead of Win3.11 and Win95 PCs, and their underlying MSDOS.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:25 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

I wish WindowMaker were still actively developed. That was my preferred WM for many a year. Unfortunately, it isn't really useable on laptops - can't cope with switching/extending displays.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:53 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (1 responses)

> I wish WindowMaker were still actively developed. That was my preferred WM for many a year. Unfortunately, it isn't really useable on laptops - can't cope with switching/extending displays.

Not really sure what you mean, I *am* using it on a laptop and have dealt with screen size changes every time I connect it to an external projector. When the external size is larger than yours, the only thing is that if you stored your icons on the right, they stay at their absolute position (which can become 2/3 of the screen), but everything works fine for me.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 16:35 UTC (Tue) by paulj (subscriber, #341) [Link]

Huh, you don't need to restart WindowMaker when you change res or monitor? Did the new maintainer update WM and make it cope dynamically with resolutions at last? :)

probably not a huge deal, but bigger implications

Posted Jun 26, 2025 19:04 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (2 responses)

Check out WaylandMaker

https://github.com/phkaeser/wlmaker

probably not a huge deal, but bigger implications

Posted Jun 27, 2025 10:58 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

If that works well enough, that may overturn my inner kurmudgeon's "Sigh, am I really going to have to change my whole desktop?" feeling towards Wayland. ;)

Thanks!

probably not a huge deal, but bigger implications

Posted Jun 27, 2025 12:42 UTC (Fri) by smurf (subscriber, #17840) [Link]

Heh. I feel with you. A few months ago I switched my desktop from Gnome to Sway because I couldn't stand the bloat any more.

Not looking back.

Not looking forward to converting my laptop either, but that's a different topic.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 13:49 UTC (Tue) by clump (subscriber, #27801) [Link]

That is an impressive screen shot. The colors, fonts, and lines gave me a rush of nostalgia.

I can imagine the mouse pointer changing window colors when hovering, and the right click menu disappearing when you release the button.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:53 UTC (Mon) by parametricpoly (subscriber, #143903) [Link] (13 responses)

> It has worked for a very long time

Yes, if you measure system's functionality by the fact that things somehow seem to work, mostly, and some graphics appears on the screen (if not, just reboot), then yes... quite ridiculous that many x11 based greeters still run as root (e.g. https://github.com/canonical/lightdm/issues/18), no proper isolation. Since Covid, many have had a flexible office. GECOS is such a stinking pile of garbage, no wonder most users doesn't use it at all.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 21:35 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (12 responses)

> GECOS is such a stinking pile of garbage, no wonder most users doesn't use it at all.

And what's the next step ? Drop support for /etc/passwd and /etc/shadow and force users to use yet another GNOME mega-application to edit an entry from the local console ? Have them run an imitation of regedit to change their UID ? We're progressively but surely going away from the KISS principle that has made UNIX-based systems last 5 decades, and slowly turning them into a single megalith that nobody understands and that newcomers will denounce as the pest to combat like windows was pointed the finger at 25 years ago. We might reach a point where the stuff will have become so complex and boring that nobody will want to hack on it anymore and it will die by itself in boredom.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 23:39 UTC (Mon) by parametricpoly (subscriber, #143903) [Link]

The article clearly stated the problem. There's a need to convey extra metadata related to the user. That field is a time capsule to 1960s. What would be your solution?

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 0:32 UTC (Tue) by pizza (subscriber, #46) [Link]

> Drop support for /etc/passwd and /etc/shadow

You say that as if it's a bad thing.

In the real world, requiring all processes performing authentication to (1) run as root and (2) work with plaintext credentials is both (i) a major security weakness (that has been exploited countless times) and (ii) severely limits the sorts of authentication mechanisms one can use.

> We're progressively but surely going away from the KISS principle that has made UNIX-based systems last 5 decades, and slowly turning them into a single megalith that nobody understands and that newcomers will denounce as the pest to combat like windows was pointed the finger at 25 years ago.

User info and authentication hasn't been obtained directly from /etc/passwd(etc) since Unix System V Release 4 in *1988*, instead proxying through the libc's NSS to allow for NIS and other directory services to be transparently used. This was later augmented by PAM (1996) and SSSD (mid-late 2000s), which in turn could be plugged into countless other user authentiction/directory services.

"KISS" ended nearly 40 years ago, out of the necessity of working in the real world.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 2:10 UTC (Tue) by smurf (subscriber, #17840) [Link]

> And what's the next step ? Drop support for /etc/passwd and /etc/shadow

Lots of places already did. Did you ever try to edit /etc/passwd when the name displayed by your company's Active Directory server was wrong?

systemd's user info server isn't yet another huge thing you need tooling for. It's mainly an aggregator. You can plug a parser for /etc/passwd+shadow into it, or AD, or whichever other service you want. It's a protocol, not an API or (worse) a file format from the 70s/90s that can't evolve and can't be extended. There's strict separation of concerns (in contrast to libpam and related ugliness).

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 3:03 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (5 responses)

If your expectation is that you can look up a user in /etc/passwd then that hasn't been true for decades - even if we choose to ignore NIS as a Sun special, Project Athena had come up with Hesiod in the 80s, and modern enterprise environments are almost certainly using some form of LDAP (either natively or via Active Directory). At some point it becomes necessary to consider whether continuing to apply bodges on top of the existing infrastructure ("Your password is here, unless it isn't, in which case you need to know which backend to query to find it") is genuinely simpler than replacing it with unified tooling that caters to the modern world rather than one which envisaged managing hostnames by just having people mail out updates to /etc/hosts

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 6:35 UTC (Tue) by joib (subscriber, #8541) [Link] (4 responses)

There was also some effort by the sssd people some years ago to provide a dbus service to query also local users in some unified way and provide more info than possible with NSS&PAM, but seems it never went anywhere and support was eventually ripped out from the codebase.

So now systemd is trying the same. Will it allow some unification and simplification, or the opposite if applications will need to support that in addition to classical NSS&PAM along with some ad-hoc kludge to provide more info if necessary, and the sssd thing if that was ever supported? I guess one can only try and hope it gains more or less universal adoption, but there's a risk this will just increase complexity rather than reduce it.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 7:43 UTC (Tue) by smurf (subscriber, #17840) [Link]

> provide a dbus service

The problem with dbus is (a) its access rights model, which is surprisingly complex and a source of subtle security errors, (b) libdbus isn't exactly easy to integrate, (c) hey now your passwords pass through yet another daemon what could possibly go wrong.

systemd has a plugin for PAM, so your the legacy(-ish) tooling will continue to work. The other way 'round, there's the io.systemd.Machine provider.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:20 UTC (Tue) by rjones (guest, #159862) [Link] (2 responses)

I've always just used 'getent' to look up users and groups.

This leverages nss and thus works regardless of what service is sourcing the id numbers for these things. This includes the systemd dynamic uids, which is also exposed via nss with the nss-systemd module.

Cat your /etc/nsswitch.conf to confirm. You should see 'systemd' listed there after files, etc

I don't think there is anything special that applications need to do to support anything at this point. Even if /etc/passwd was to magically disappear.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:53 UTC (Tue) by joib (subscriber, #8541) [Link] (1 responses)

NSS, despite its architectural shortcomings, roughly does what it was designed for, and support for it is indeed near universal, from things like getent to the various user/group querying APIs in libc that applications use to look up info.

Problem here seems to be a desire to associate additional info to a user, not possible in the NSS data model. Like a picture of the user, email address, fully qualified username (name@DOMAIN), etc. Sssd having a go at this failed, remains to be seen whether the systemd approach will turn out to be more successful.

probably not a huge deal, but bigger implications

Posted Jun 25, 2025 11:07 UTC (Wed) by rjones (guest, #159862) [Link]

Oh, well that make sense.

Took a quick look at JSON Group Record and JSON User record from Systemd's documentation it all seems very reasonable and not any different then what people have already been doing for decades with LDAP.

It would be nice to have a nice way for users to set their picture, email address, timezone, default language, security keys, etc. in a saner manner. None of that seems crazy or undesirable.

And since systemd-userdb provides support for multiple backends then it can provide a unified interface for retrieving and interacting with LDAP and other sources of user information people already use and rely on while systemd-homed provides feature parity for people not using any of those services.

If it all works out then it should represent a nice improvement and simplification of the OS over the status quo.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 7:16 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (2 responses)

I vaguely remember some distributions dropping /etc/passwd. The replacement was a directory tree somewhere in /etc, each user-representing directory owned by that user. Inside were files for metadata like real name, a symlink to the shell etc.

I can't find it now, but Openwall's TCB (https://www.openwall.com/tcb/) looks similar. Or maybe that was something from GoboLinux? Or maybe T2 SDE? Nevertheless, life without /etc/{passwd,shadow} is possible and even quite pleasant.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 10:01 UTC (Tue) by dottedmag (subscriber, #18590) [Link]

It was ALT Linux probably, it uses TCB.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 18:15 UTC (Tue) by adobriyan (guest, #30858) [Link]

This is likely to make updates non-atomic.