Mastodawn

Daniel V.Jun 21, 2025

@strlcat @davidgerard not to be pedantic but is it really monopolization when the main developers of X11 have since move on to another project deliberately to replace the old?

Like to my understanding, it isn’t about “competition” in this case, but about moving standards from one system to another and making that work happen. Ie. we use computers in 2025, not 1985, and the way graphics for computers work has changed significantly from then til now, and part of the reason Wayland exists is to be able to modernize graphics on anything that uses it. So it’s a shift in standards vs Competition. Especially when it’s all X11 devs who moved on to Wayland and have generally stopped putting much work into X11 as is.

(And that isn’t even touching on most of the code added to base X11 from the founder of XLibre being reverted out due to breaking changes and weird modifications of licenses retroactively as people started looking over the commits and noticing some issues..)

Idk, I think a lot of the arguing around this issue is stemming from a handful of malignant actors that are deliberately throwing chaff into the wind and getting into everyone’s hair about it while fundamentally misunderstanding what is going on and why we have Wayland to begin with. Arguably deliberately misunderstanding for the sake of arguing and causing drama.

Are there technical issues with Wayland? Yeah! But there’s also a fuckload of technical issues with X11 as well, and the decision was made to focus on Wayland and modernizing graphics on Linux rather than maintaining something who’s primary promise of network transparency stopped being true decades ago.

David Chisnall (*Now with 50% more sarcasm!*)Jun 21, 2025

@dvandal @strlcat @davidgerard

Wayland and systemd are both symptoms of the same behaviour, as was PulseAudio:

Observe that an existing system has flaws.
Don't engage with users to identify use cases.
Throw up some half-finished code (with incomplete or nonexistent backwards compatibility) that solves some of the problems of the old system but doesn't address all of its use cases and introduces more problems for other people.
Declare that the old thing is deprecated and everyone needs to move to the new thing.
Create a load of work in the rest of the ecosystem that other people have to do.
Silence all criticism by pointing out that the old thing was imperfect.

And that's the kind of thing that you can only get away with if you're able to act as a monopoly, by employing maintainers at key points across the ecosystem.

The biggest problem with Microsoft was not that their monopoly allowed them to be evil, it was that it allowed them to be stupid. A lot of things in the MS ecosystem are actually bad for Microsoft, but they're pushed out because no one inside MS cares enough to do the right thing and no one outside is able to fix the problems. I, personally, don't want the F/OSS OS ecosystem to end up like that.

Daniel V.Jun 21, 2025

@david_chisnall @strlcat @davidgerard

If all the maintainers for Old Thing have moved over to working on New Thing, wouldn't it be incredibly irresponsible of them to not declare Old Thing as deprecated? Is that not the literal definition of Deprecation?

X11 as a fallback option has been supported for well over a decade at this point. The goal being: Push people to the new standard so the new *standard* can be developed more fully and flushed out and fix the majority of the gaps.

*Standards take time to change, with all the presumed growing pains in between*. It's not easy to shift standards, but when the devs have flat out *moved on*, it's not about a competition between the standards. It's that people are moving on to a new Standard to work on.

We did have competing modern display protocols there for a bit. Do you remember Mir? Didn't Mir just flat out lose out in terms of gaining market share and so forth to Wayland?

Suffice to say, framing a standard shift as Monopolization is *really really weird* and fundamentally is at odds at the reality of what the ongoing process actually is. The developers *moved on.* Nobody stood up to take their place and continue developing X11 until recently, and even then the first thing that project did was break from the Standard (lol)

I understand the annoyances and the pain of this process: I've been daily driving Fedora Desktop since Fedora 11. But I also understood, especially in the early days, that Wayland was *heavily* under development and to expect bugs, and I went into it knowing full well that I could revert to X11 Fallback as necessary (which I used a ton in the early days!). We're well into a decade past that at this point and I literally have more issues in X11 than I do with Wayland. It's been like that for about 3 years now, personally.

But again: Calling it a Monopoly when the core maintainers just Moved On is, frankly, weird.

Boyd Stephen Smith Jr.

@dvandal @david_chisnall @strlcat @[email protected] Yeah, I agree no maintainer should be forced to work on xorg, alsa, or sysvinit, no matter how many users it has. And, yes, when the amount of maintenance effort drops it is good to let users and downstream know -- based on some threshold relative of historical effort available or new work needed coming in.

I say this as someone that still uses Xorg.

I do think monopoly / monsopony can definitely be issues, but the solution to that is having enough producers / consumers so that coopetition is the default, not shaming maintainers.

I think this means improving the experience of being a maintainer, and while compensation is part of that, being given a bit more grace by the community when you choose not to do something (like maintain sysvinit support) is important, too.

mirabilos Jun 21, 2025

@strlcat @david_chisnall @BoydStephenSmithJr @dvandal the problem with that is not that the maintainers don’t want to be forced to support sysvinit. The problem is that they actively work against those people who do, even when presented with working patches and an offer of supporting the sysvinit-using users of their package… from a fellow team member, even.

Basically telling users to use the new systemd/fdo/gnome/wayland/pa/pw/whatever thing or get lost and actively working against the mere possibility of supporting it.

Boyd Stephen Smith Jr.Jun 21, 2025

@mirabilos @strlcat @david_chisnall @dvandal While I've heard of that happening, I don't see why a "soft" fork is not a suitable solution. Just publish a branch with the "sysvinit support" patches, and kick off the release tarball/build process whenever.

Debian maintains patches on top of upstream sometimes for many, many years. I maintained my own small patches against the kernel to enable a feature that "wasn't ready" but I needed for my hardware for nearly 2 years.

I fully understand a maintainer choosing to reject a patch *for any reason* and I support their rights to do so. If that becomes "censorship", then treat it as "damage and route around" the maintainer. (This does not require attacks, personal or otherwise against said maintainer.)

There are issues around namespace claims, but any resolutions to those issues will be specific to how the namespace is organized (hopefully [but rarely] democratically).

mirabilos Jun 21, 2025

@BoydStephenSmithJr @dvandal @strlcat @david_chisnall I was speaking of Debian packages.

Incidentally I did soft-fork the tomcat9 package, as ${dayjob[-1]} had need, and it ended up being a hard fork. Still available in my own APT repo, still downloaded by several users even… some even contacted me to say thanks.

Only sad I couldn’t bring the improvement into Debian proper as the primary maintainer veto’d it… for use of adduser of all things… back when sysvinit support was still mandatory (and the package therefore rc-buggy).

Boyd Stephen Smith Jr.Jun 21, 2025

@mirabilos @dvandal @strlcat @david_chisnall Never had the pleasure of being a Debian Maintainer myself, but I thought the technical committee was there to "encourage" maintainers to follow approved policy and accept patches for such rc-buggy things.

I do know such things rarely work out as well as they are designed to or even appear to from the outside.

I do know Debian is in a bit of a pickle these days because there are several upstreams that have significantly more "person-hours" available and are very difficult to patch. So, in order to make those package available at all ... "compromises" are made. :(

Thank you for maintaining an APT repo with your patched version! Even if I don't use it, it serve to illustrate the power of "bazaar"-style development.

mirabilos Jun 21, 2025

@BoydStephenSmithJr @strlcat @david_chisnall @dvandal I thought so, too, but evidently nobody in power had any tuits left to care about nōn-systemd at that point after years of debate.

Meanwhile the "modernists" took that power vacuum and started removing cronjobs from core packages such as mdadm in favour of systemd timers (even many systemd people use cron instead). The GR only gave the mandate for init scripts, not cronjobs, but nobody cared. And maintainers who unilaterally remove init scripts don’t even coordinate with the orphan-sysvinit-scripts package maintainers to have a handover that doesn’t break existing users.

(Meanwhile o-s-s shipped a buggy tomcat9 init script that could never have worked because all versions of tomcat9 actually in Debian for which the package could have come into effect were uninstallable due to a hard Depends on systemd for its adduser thing, so all it ever did was to break mine, and it took months to get it removed.)

Communication. So important.

wyatt Jun 21, 2025

@mirabilos @BoydStephenSmithJr @strlcat @david_chisnall @dvandal i myself have many, many debian packages that i `apt-get source` (or use their git repo) and then edit the debian rules/control files and `dpkg-buildpackage -uc -us -b` every time i update to dodge systemd

Boyd Stephen Smith Jr.Jun 21, 2025

@wyatt @david_chisnall @dvandal @strlcat @mirabilos Wasn't there there a Devuan (or smth) that was supposed to be Debian minus systemd? Did it die?

(Personally, I prefer systemd over sysvinit, so I didn't try it.)

mirabilos Jun 21, 2025

@david_chisnall @dvandal @BoydStephenSmithJr @strlcat @wyatt it attracted the same sort of people X"Libre" did, so it’s not an option.

I also doubt their technical and manpower to keep anything working that is actively desupported in Debian.

I’d rather go with the security-supported option.

fraggle Jun 22, 2025

@BoydStephenSmithJr @wyatt @david_chisnall @dvandal @strlcat @mirabilos scroll up. all the way up to the top of the thread

mirabilos Jun 22, 2025

@wyatt @BoydStephenSmithJr @david_chisnall @dvandal @strlcat weird, I have very few… mostly a package that just Provides: logind aptly called logind-considered-harmful (after having a look at elogind, which changes the system state in unpredictable ways, like lid closing crashes the system as it tries to suspend) and don’t use GNOME, so…

… ah, yes, and prevent-systemd-{installed,running,completely} install apt pinning to enforce it stays off.

All available from the wtf extrepo thanks to @wouter

JdeBP Jun 22, 2025

@BoydStephenSmithJr @dvandal @david_chisnall @strlcat

This reasoning is based upon a fallacious dichotomy. In the real history, Upstart existed and had a strong competing maintainership, to the level that the #Debian TC itself was nearly split down the middle on #RedHat/#Canonical lines, and the choice was *never* between van Smoorenburg init+rc and systemd.

It was between #Upstart and #systemd, the latter indeed being a reaction to the former, with #OpenRC as a late entrant.

David Gerard Jun 22, 2025

@BoydStephenSmithJr @dvandal @david_chisnall @strlcat yeah, the actual answer to continued X11 development is for someone to pay for X11 developers

if nobody is doing that, then that's your problem

if all you have is obnoxious nazis who can't code, your project is somewhere past dead

David Chisnall (*Now with 50% more sarcasm!*)Jun 22, 2025

@davidgerard @BoydStephenSmithJr @dvandal @strlcat

You’re buying into the false dichotomy that the people pushing these things love. The solution space is not old thing with problems vs new thing with overlapping set of problems. Things like Arcan exist and actually solve the problems with X11. It even had a Wayland bridge that let you run Wayland things (though Wayland is such a mess of incompatible extensions because the core protocol didn’t solve most of the problems end users actually have that they gave up trying to support it) which even handles graceful reconnect if the display server dies, and has an X11 compatibility interface (still maintained) that even lets unmodified X11 WMs manage windows with a security model on top. Pretending that the choice is X11 or Wayland is exactly how people push Wayland. Something must be done, this is something, we must do it.