Notices by Adrian Vovk (adrianvovk@fosstodon.org)

Another day in Linux: everyone's too busy squabbling over init systems to organize against the real enemy: Microsoft, Apple, and Google

Look I don't expect everyone to be strategic with their use of their own time. Do whatever you want. But to hurl vitriol at the people who are focused on making Linux win rather than on your chosen issue is not appropriate

If you're out here calling people bad faith corpo shills you should take a good hard look in the mirror and realize who your behavior helps

@forteller Some of these mice are also keyboards, from a USB perspective. Stuff like this ensues

@forteller Looks cool! I think the scaling factor is a bit low though, no? I think it would make sense to turn on 2x scaling for the screenshot, so that it's more visible

It may look weirdly large on your display, but in other contexts the screenshot from your display is a little too high res and everything looks tiny

@navi @lanodan @thesamesam I'm not a glib maintainer so it might be better to ask in a space with them, but sure I'm always open to someone asking me questions. No promises I'll have useful answers though 🙃

@navi @lanodan @thesamesam I think this would be quite reasonable to have in GLib. Like yes the protocol is pretty trivial but it would also be unnecessarily duplicated code to have in many projects. Especially if more stuff starts integrating with the service manager and starts sending NOTIFY_SOCKET messages

(Plus, if it's in GLib, we could integrate the watchdog into GMainLoop and turn it on automatically when the service manager asks for it)

Feels like the right solution

👀 (still very unfinished though!) #gnome

@karolherbst @BrodieOnLinux @drakulix Yeah I'll echo this (and myself, since I've already given this feedback a month ago, when I had to issue a correction to the "GDM dropping X11" video)

Please, just ask us!

Somehow paradoxically, in open source - the one place where development happens in the public and developers are directly accessible, the default is to read comments on the issue tracker: literally the least up-to-date and productive form of communication we have at our disposal. Why?

@dalias @tknarr For two, this fallback code is a second codepath that will never be tested and will work completely differently from the first one. Thus, it will be broken and unmaintainable. I'm not signing myself up to deal with that, sorry. Really, userdb isn't that hard to implement. You just need to know the specifics of your distro (which may be using a weird non-shadow auth system, or a different C library, or a different init system, or all of the above) that GNOME can't know

@dalias @tknarr For one, /etc/passwd doesn't have any form of rich information about the user. No profile pictures, no ability to export any kind of user settings to the login screen, etc. It barely has the ability to store a display name (which is actually "GECOS" instead, which is... complicated for historical reasons). userdb is json, so we can add new stuff to it whenever we want instead of going in and implementing weird side databases (which is how shadow and accountsservice happened, btw)

@dalias @tknarr Yeah it's expected to break at some point in the future, because userdb will be required by accountsservice/its replacement

userdb isn't incompatible with /etc/passwd or shadow in any way (in fact, to implement it right you're supposed to integrate it with shadow if you have it). It should be possible to implement on any Unix system, I don't think there's anything Linux specific about it (but I'm no expert in non-Linux Unixes)

@dalias @tknarr Indeed. That is the workaround I implemented for non-systemd distros, as explained in the blog post. And, again as I explained in the post, the workaround will remain until another unrelated component (accountsservice) is replaced with userdb for unrelated reasons (because it provides us with rich user records, unlike /etc/passwd)

@dalias @navi @sertonix They don't share a home directory... they're different users.

As for the rest... sure. If you believe that so few scenarios require remote login then I can understand why you think this is an overcomplicated solution to a nonexistent problem. That belief is incorrect, but I really do not wish to argue about it so I'll leave it there.

@tknarr @dalias the sessions are not running under different UIDs. Once you log in you're logged in as yourself. Only the login screen runs as different UIDs

@navi @dalias @sertonix I mean it used to do that. That's literally what this announcement is about: instead of rendering multiple login screens under one user, we use discrete ephemeral users.

I'll give the simplest reason to do this (there are others): remote login is the same as multiseat, and you _really_ don't want multiple different remote login screens running as one user. Otherwise pwning one pwns the rest. On X11 this is extra catastrophic because then you can keylog the other (1/2)

I wrote a thing: "Introducing stronger dependencies on systemd"

https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/

@BrodieOnLinux @gboncoffee @mks_h Even assuming this project will be able to produce good work (which I find... unlikely) it'll never be adopted by anyone with any amount of sense because of that README. The relevant distros are going to stay the hell away from this project to protect their communities. The rest is a fraction of a fraction of people

@BrodieOnLinux Hello. You didn't go into much detail, and I see your audience commenting about it, so:

I think it's pretty thoroughly decided that GDM will retain the ability to launch non-GNOME X11 desktops. Luckily this functionality is isolated from the rest of GDM, as noted in the issue

What will be going away is: "legacy X11" (where one X server running as root is shared by the whole system), XDMCP (ancient remote login for "X terminals"), and GDM's ability to run its own UI under X11

@BrodieOnLinux @zstg I mean it's a soft fork of libadwaita. And libadwaita is GTK4. Idk where the idea that this is GTK 3 came from...

https://github.com/xapp-project/libadapta/blob/master/src%2Fmeson.build#L285

@CleoMenezesJr Are you aware of https://gitlab.gnome.org/bertob/app-ideas?

@LaF0rge Companies pay their employees to contribute to FOSS if and only if it benefits the companies in some way. Russian defense contractors don't contribute to Linux out of the goodness of their hearts. Letting them keep contributing means they keep benefiting

The people that work for these companies but contribute in their free time don't have my sympathy too. Their day job is still building the tools to kill innocent people, and if all that costs them is their hobby then they got off easy