Wayland just isn't up to snuff as of yet and I seriously doubt it ever will be. Seems more interested in killing the past to continue a more complex / resource hog of a future. I've done plenty of X in the past, it has it's warts, but it can actually be fixed. I don't understand why they took the path they did with Wayland or why it took so long with funding to get where it is now.
Before this is all said and done, people need to start realizing all the cursing and fighting over nonsense will not help the fact that the companies / groups, are driving things in linux down a path and dragging everyone with it kicking and screaming. Unless projects that can provide alternative can actually find enough funding. Then it's always going to be stuck on back burners for devs that can.
I do appreciate what XLibre is doing but I'm not sure it's not too little too late. I say this typing from it - checking it out, with 0 issues. And sometimes truly, a compositor isn't required or desired. All again depending on what your doing with it.
It's possible to revive an unbloated desktop environment and bring it current, within a day or two, but to continue development the project would need support. Though this would also mean people would finally have a say in the desktop and what it can do as long as it's within reason. i.e. don't build a 3d pipeline into it as that's out of scope.
I've watched gnome creep projects all over the place, and others as well for far too long and projects like these will tear out non systemd and non wayland components at a moments notice or until they can put their attention to it. If interested feel free to message or reply. Otherwise I assume this will see near 0 input.
Artix + DInit work well.. adding a small systemd shim for certain functionality, and extra appimages that require systemd actually run fine but outside of that supported Desktops are going to shrink. It's high time to get ahead of it and fix the issue.
Anyone care to tell me whether or not their would be enough interested parties willing to support the endeavor? I'm not a marketer nor care to be one, so keep that in mind.. Someone would have to take that over outside of posting progress and updates, etc.
I don't see that happening but thought I'd ask and see here first since Artix is my choice.
The issue you're referring to is (quoted from one of the best-written critiques of systemd (https://archive.is/FMfu4)):
I'd expect forks born out of this project to be dismissed as needless duplication of the originals and/or smeared as the death throes of reactionary forces. Plus, in order to effectively halt "gnome creep" (sic), transitive dependencies in common packages (like web browsers -> GTK) also need to be addressed, and that would make this project's scope huge.
Finally, the situation in the desktop front isn't that bad. A lot of standalone window managers and smaller DEs (and even Wayland compositors!) do care about other Unix-like OSes (and I'm aware of a few written by people unconvinced by, or outright hostile to, systemd itself). Polishing them up, either upstream, or with helper utilities designed for them, or with better packaging, would be far more fruitful.
Tangent on the systemd shim thing:
The "small systemd shim" idea was attempted multiple times. uselessd, an attempt to make systemd more focused and portable, was given up on. Upstart's was continued by MX Linux, but died recently to kernel changes. Elogind is pretty much systemd with huge chunks of the code stripped out. The root cause, as Laurent Bercot (s6 author) has a bunch of posts on, is implementing systemd APIs correctly pretty much require your project to work exactly like systemd. Dinit is the best match for a systemd shim precisely because it's the most systemd-like in underlying implementation (and, unsurprisingly, where it isn't, providing similar functionality without patching/rewriting programs at an unsustainable scale is hard - take a look at the kind of issues Chimera Linux's developers deal with).
Artix adopted and ported a fork several years ago of a lightweight, fast, complete and versatile X11 DE, called Moksha.
Details can be found here:
https://wiki.artixlinux.org/Site/MokshaDesktopForArtix
artist
Yes, I tried that one before.. didn't like it.. Looks like it's based on enlightenment, and that's a no go by default. It's good for people who want to customize just about every aspect of the ui - and that's fine, but for normal users, it's too much.
And for capezotte -
Systemd is such a small part of what I'm talking about - it's not the major issue I'm referring to. I'm talking about mostly the DE and not just systemd. systemd is meh, I can live without it - and prefer to. Yes, I am openly hostile to systemd. I admit that but right now - I'm not that worried about it.
Not even sure why you'd jump to such a conclusion. I'm not talking about forking gnome or kde. I already have a local fork of a DE that I was finishing adding session support on.
You should be more specific, then. What components are part of "the DE"? Why "the", instead of "a"? What spots in the ecosystem need a new project (instead of adopting an existing one with aligned goals, like logind → seatd)?
Regardless, the situation described in the quote is also true if you s/systemd/Wayland/g; you're also fighting influential upstreams who want deep integration with that at the expense of everything else, especially "legacy" software.
I'm not just talking about forking Gnome or KDE either. I'm also talking about e.g. forking/patching GTK4/5 to keep X11 support in, or dbus-daemon so it integrates with service managers other than systemd.
I'm pretty sure that conclusion is because s6 is really server focused so that guy won't be that much interested to look at something such as: take the basically pre existing components, login(seatd)/sockets(dbus)/user session mgmt(e.g. for when local user services will actually manage all the session from compositor and desktop utils. onward, they also must really be managed by the init in some form or another and dinit and openrc provide this, system instance can control the user one), and have them each implementing it's own part of systemd api's as a general compatibility mode, not a simple "shim".
What will then remain is for some remaining apis to have to be hooked in from their respective systemd functions at compile time e.g. https://deepwiki.com/chimera-linux/turnstile/6.1-api-reference but it can be made to be universal.
You can then make a bigger "shim" but cleanly+easily and build a worthy systemd contender from there.
I get that desktop is nice but i never got along with it, and if we're trying to talk about standards compliance which x11libre is hopefully not trying to break ICCCM as it's fixing x11, then the best DE will start from IceWM.
Also hope the stupidities in wayland get fixed especially the inter program viewing block BS, clipboard becoming forgotten if an app is closed which started with late x11 versions, make some kind of plugin support etc.
Remember, when talking about APIs, we mean programs should not need to be rewritten.
Not really. He doesn't say user services, seat management or IPC are impossible without becoming systemd 2, he just thinks these should be provided by gluing multiple projects together, preferably in a way that makes each piece easy to swap out or remove.
Dinit is actually an example of this since the user service support it has is very basic (pretty much just changing default paths) and the most important part (reacting to login/logout and managing the instances) is actually provided by Turnstile — and it can hook just as well with e.g. runit, as is done on Void. OpenRC does react to login/logout on its own, however (though I wouldn't be surprised if hacking a Turnstile configuration that calls
openrc --user works).
What he does say is that the mechanisms systemd provides to use its features can't be easily exposed by solutions that work even slightly different from it, or that target different usecases. Communicating with systemd at the lowest level requires D-Bus (so you need a D-Bus interface, like systemd), and the functions it exposes work with its specific concepts/objects like units — and to implement "units" correctly, your init system needs to care about sockets, mounts etc. in addition to processes (like systemd), and down the rabbit hole we could go...
It's not a shim, it's an alternative. Projects have to be rewritten to use either that (when it matures) or libseat.
Excuse my ambiguity but i have envisioned it as a set of patches as universal as a -libsystemd=none switch and only for remaining api's that can't be implemented nicely from the "outside", so not completely implementing libturnstile/libseat but merely to make abstraction of some of those dependant systemd functions that distros such as here don't already modify at compile time.
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.
How much this remains to be patched in the resulting programs is to be seen but this is not rewriting anything above 1% of related codebase. Yes this is optimistic but some more let's say ideas from systemd will have to be borrowed, for instance we haven't talked about auditing yet and just s6 partially implements that. More detailed statistics other than logtype=buffer in dinit. Stuff like that. It's a bit all over the place right now. Systemd unfortunately does them with a structure (albeit a perverted one).
DE = Desktop Environment. I wouldn't and have 0 plans to fork gnome or KDE. That's most of what I was on about and it's all I'm worried about at the moment. Just something to replace them because with the QT re-licensing and the further forced adoption of even more systemd - It's dumb, but yeah anyone against systemd knew that's exactly what was going to happen.
Either way - the conversation has definitely twisted from the original intention, so I'll get done what I get done and if nobody uses it that's fine too.
lol,
Apparently, there is a secret school somewhere in the world (which no one has told me about yet) where you learn how to write epically long, pointless posts to annoy potential readers. I can't think of any other explanation for this thread.
What's with the hostility? What secret school did you learn that from? What point does you're post serve other than to troll?
Linux, in general has this issue. It's needless.
Requesting the thread to be closed.
I have noticed you seem to be referring to some specific DE which you call "Desktop Environment" but you have never made clear what that is, as no known DE is called that:
https://wiki.archlinux.org/title/Desktop_environment
Therefore everyone else in this thread has no idea what you are on about, or assumes you mean you are forking Gnome due to the recent news about it depending on Systemd in future.
If you could provide some link to the DE you have forked you might get some more helpful replies. Do you mean Common Desktop Environment, which was the original basis and inspiration for Gnome?
??? I didn't name it Desktop Environment.. it IS a Desktop Environment. Gnome, KDE, XFCE, LXDE, LXQt, are all Desktop Environments, hence DEs. I can't help people who skim, refuse to read/comprehend, or make assumptions. Not saying that's what you're doing. Many tend to be in straight up troll mode up front, instead of asking a question to clarify.
I've already stated: "It's possible to revive an unbloated desktop environment and bring it current".
I don't consider Gnome or KDE are not unbloated environments. Esp since I stopped using gnome after they went to 3.x - not my bag.
I have 2. The one I already fixed is QVWM, the other is my old one, which was never released to the public. They're both small.
Please shut up then.
No one but the equally insane can comprehend complete gobbledygook. From the thread title and hitherto.
If you have something working you could post it on GitHub or somewhere similar, and also make an AUR package to bring it to a wider audience, and you might find others who were interested in your project like that. But people online are often remarkably unadventurous and stay with the known and mainstream, so don't expect to be overwhelmed by the response - but that also means you might as well make it available as keep it private, and not worry too much about it. :D
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.
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.
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.
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..