Forking / Reviving Desktop Environment to fix the issue

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #15 – 30 September 2025, 23:20:38

Was thinking about putting it on the AUR, just didn't because yet because of missing session manager. I'll get to that later this weekend. I don't have expectations. I already know the standard response is going to be like above. Mostly troll or garbage.

Thanks for at least being constructive.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #16 – 01 October 2025, 04:40:20

Well, now that I know what this post was all about, I have to agree with the detractors that it was needlessly long and it invited off-topic discussion. Just saying "I patched this unmaintained window manager and added XYZ functionality/refactored the code/fixed compiler warnings", "I wrote this minimal floating window manager, it only depends on Xlib, no GTK or Qt" or "I'd like help writing panels/widgets for a new DE" would be clearer and have a far more positive reception than this topic.

If by session manager you mean something to put in the Exec= line of the /usr/share/xsessions file, missing one is not really a barrier to putting your DE/WM on the AUR; people (especially the kind who early-adopt window managers) can write an .xinitrc file, and you can pool ideas and get feedback before writing a definitive one.

I was skeptical at first because this is competing with plenty of other community-driven minimalist environments with vibrant communities (so acting like this is urgently needed is weird — not that more options aren't welcome), and doesn't really address some important ways "GNOME creep" can still affect these ecosystems (that's why I mentioned GTK and D-Bus in my second reply).

Well, mom said it's my turn to be rant-y.
Spoiler (click to show/hide)

Quote from: Hitman – on 29 September 2025, 10:59:05

I get what these unit things are, if it weren't for the dubious attitude that the rest of systemd has i would've said these are at least in part a useful set of tooling which software can use with reason. I don't see that if you have your own take at this you can't then cleanroom emulate systemd behavior from it quite easily. It's just encapsulated sockets.

It's not just encapsulated processes/sockets/mounts/whatever; it's the network of events, interactions and dependencies systemd creates among them too. The article I took the quote in my first post from has quite a few examples of non-intuitive behaviors of each unit type, and unusual consequences of specifying a dependency, some of which programs and tutorials in the wild rely on.

Even seemingly simple unit types aren't that easy to implement. Taking your example, encapsulating a socket for a "socket activated" service — which is just one of the unit types, and just one kind of unit type interaction (socket + service) — implies a means of holding that socket (so it's not lost if the process stops), and some glue between that and the process supervisor. AFAIK only s6 provides a general purpose file descriptor (not just socket) holder among non-systemd init systems. Dinit's socket-listen: could be extended for that purpose, but currently only works for a very restricted subset of what people can do by matching socket and service units. There can also be interactions between sockets and other unit types, emulating which will require glue between the socket holder and the other arms of this hypothetical ~~Frankenstein monster~~ systemd shim.

Even if some of these interactions are rarely used in practice (the fact that we have so many programs available on Artix with little to no patching is proof of that), and could be feasibly left out of the shim without breaking most programs, systemd's interfaces assume the program listening can and will make them happen, so it'll take an intelligent analysis, or compiling and running, to be sure if a program will be broken, which is not ideal.

I do agree systemd has some valuable UX lessons, as well as features worth emulating, but keeping the same interface for programmers and writing shims is not a good idea, especially long-term.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #17 – 01 October 2025, 11:23:38

Quote from: capezotte – on 01 October 2025, 04:40:20

have to agree with the detractors that it was needlessly long and it invited off-topic discussion.

Point taken about the length. I mentioned issues with KDE, Gnome, systemd and wayland.. That's enough to start a fight anywhere if the comments are negative. Those are ignored or read with a mountain of salt.

Sure, I could put it out bare, but none of the windows saved when logging out, etc. 0 reliance on GTK or QT.

I brought up the shim for systemd support, only for appimage. I wrote a bash script to map the command line params for systemd to call out dinitctl instead. It's not a serious thing but the point was, it's possible, and it works for appimage. I'm just at least willing to do the work.. linux is starting to be trapped into whatever gnome, kde, redhat / ibm want it to be instead of what it should be, which is why I'm here.

I just see it as an encroaching plague. The desktop environment isn't a hard thing to do anyway.. The UI is harder than the actual desktop environment is..