Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Forking / Reviving Desktop Environment to fix the issue (Read 11011 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Forking / Reviving Desktop Environment to fix the issue

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.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #1 –
Quote
It's high time to get ahead of it and fix the issue.

The issue you're referring to is (quoted from one of the best-written critiques of systemd):

Quote
[A successful attempt to replace systemd or make it obsolete] cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem.

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:
Spoiler (click to show/hide)

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #3 –
Quote from: Artist – on
Artix adopted and ported a fork several years ago of a lightweight, fast, complete and versatile X11 DE, called Moksha.

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 -
Quote
The issue you're referring to

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.

Quote
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.

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.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #4 –
Quote from: spliskin – on
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.

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.

Quote from: spliskin – on
Quote
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.
Not even sure why you'd jump to such a conclusion. I'm not talking about forking gnome or kde.

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.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #5 –
Quote from: capezotte – on
implementing systemd APIs correctly pretty much require your project to work exactly like 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.

Quote from: Artist – on
Artix adopted and ported a fork several years ago of a lightweight, fast, complete and versatile X11 DE, called Moksha.
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.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #6 –
Remember, when talking about APIs, we mean programs should not need to be rewritten.

Quote from: Hitman – on
I'm pretty sure that conclusion is because s6 is really server focused

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...

Quote from: Hitman – on
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.

It's not a shim, it's an alternative. Projects have to be rewritten to use either that (when it matures) or libseat.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #7 –
Quote from: capezotte – on
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.

Quote from: capezotte – on
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...
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).
 

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #8 –
Quote from: capezotte – on
Quote from: spliskin – on
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.

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.

Quote from: spliskin – on

Not even sure why you'd jump to such a conclusion. I'm not talking about forking gnome or kde.

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.

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.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #9 –
Quote from: spliskin – on
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.
Quote from: spliskin – on
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.
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons,fonts} -gnome3 -kde -plasma -wayland "

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #10 –
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.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #11 –
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?

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #12 –
 ??? 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.



Re: Forking / Reviving Desktop Environment to fix the issue

Reply #13 –
Quote from: spliskin – on
I can't help people who skim, refuse to read/comprehend, or make assumptions.
Please shut up then.
No one but the equally insane can comprehend complete gobbledygook. From the thread title and hitherto.

Re: Forking / Reviving Desktop Environment to fix the issue

Reply #14 –
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