Hacker News Reader

Comment by wing-_-nuts | Hacker News Reader

I was initially excited for wayland, and was an early adopter.

I soon soured on the entire thing. It's very clear to me that wayland was an 'ivory tower' display server that had little respect for users or wm devs. You can't just go and break tons of things for security's sake when the harm is clearly higher than the benefits. Disabling screen and input capture should have been an 'opt in' feature for the truly paranoid. They should have also shipped a fully working bare bones desktop wm instead of a 'toy' implementation meant to run on a car entertainment center.

Frankly I can't believe it got as much traction as it has, but we're all stuck with it now as it's clearly 'the future'. This and systemd really showed me that the linux ecosystem is far more vulnerable to the interests of a few corporate sponsored devs than the general community.

View on HN

To be fair they just make applications go through an API now, known as a desktop portal. This is done to allow the user to control which applications can capture or control their screen or input, like Windows and MacOS.

https://wiki.archlinux.org/title/XDG_Desktop_Portal

Allowing any application to do that without the user knowing, the X11 model, is a recipe for disaster. With the right exploit chain you could theoretically deploy a keylogger from a website.

Now sure, Wayland didn't have all of this from the start, but it wasn't the default for most distros until all of these things were in place. You opted to use Wayland before it was ready for general consumption.

>Allowing any application to do that without the user knowing, the X11 model, is a recipe for disaster.

I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.

If they wanted to not break existing apps, simply intercept attempts to share screens or inputs, and pop up a dialog box asking the user for consent? That would have been fine. That should have been a part of their default implementation. What they actually wound up doing was infinitely more user hostile.

I tried using it summer of '22. The wayland hype train was well underway and major linux distributions were already pushing it. I'd be much more forgiving if the wayland devs said 'hey guys, we're working on a new display server but it's very experimental and no one should use it unless they want to help us work out the kinks'. Instead, it was 'this is the future, x11 is abandonware'

> I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.

Yes, well, the ground is being prepared to turn desktop Linux into a Android/Windows like app system (/ wasteland) where users mostly download third party proprietary apps and devs push updates directly to users with minimal oversight.

In this brave new world, you will definitely appreciate app isolation.

Do you think the same would have applied to Android, had it used X11 instead of SurfaceFlinger (which in turn isn't very different from Wayland)?

Even if no virus cares about the Linux desktop, that doesn't mean that security issues should be ignored.

> If it was a threat vector, it clearly wasn't a very big issue.

By the same token, patching the apps to use the new API is not a very big issue either. Or is it? Why?

If you have the sources, neither is a problem. If you do not have sources, both are problem. A matter of fact is, that users are going to use apps that they do not have sources for, and can neither audit, nor update the apps.

> If they wanted to not break existing apps, simply intercept attempts to share screens or inputs, and pop up a dialog box asking the user for consent?

Because there was no API before; there were hacks. Some of them worked only due to circumstances of how the given functionality was implemented, but spec-wise, it wasn't guaranteed at all.

Now there are APIs. Just like there is a virtual memory or filesystem permissions. These weren't given years ago either. They also "broke" apps.

> major linux distributions were already pushing it.

RHEL8 is Wayland-default on non-Nvidia GPUs. Old relase of a freaking RHEL, which itself moves as molases.

> I'd be much more forgiving if the wayland devs said 'hey guys, we're working on a new display server but it's very experimental and no one should use it unless they want to help us work out the kinks'.

You missed that phase by some 10 years or so.

> Instead, it was 'this is the future, x11 is abandonware'

That's how it is. If linux wants to stay relevant and not became another Amiga, that's how it is going to be.

>I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.

So: no true Linux user succumbs to malware and no true Scotsman puts sugar on his porridge.

Putting that aside, it doesn't take much effort to find an example of X11 keylogger that requires zero superuser privilege and zero explicit permission granting by the user. Here, the first result from DDGing "x11 keylogger": https://github.com/anko/xkbcat

It is hard to believe this has not occurred in the wild. If such attack really hasn't occurred before in the Linux world, I would rather use the unpopularity of Linux desktop as my justification.

xdg-desktop-portal is a workaround for the chaos Wayland caused. It puts the implementation burden on all of the individual "compositors" (read desktop environments) individually, resulting in many times the work, many incomplete and many incompatible implementations.

The Wayland devs hyped their project up like it's going to be the thing to replace X11, but ended up delivering barely 10% of what X11 is.

One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts. Now, a DE needs to implement all of X11 and then some to be feature-complete.

And no, I'm not accidentally mixing up DEs and compositors - the reality is that we don't have a good "base compositor" that DEs could build on top of. The big players built their own compositors and the small players either died or used wlroots, which again doesn't implement most of the essential things (and the ones it does are incompatible with KDE and GNOME).

>One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts.

Why do people like to emphasize this point so much? You still get shared infrastructure in the Wayland ecosystem by utilizing libraries such as wlroots or Smithay.

In fact, GNOME and KDE are practically the _outliers_ of the ecosystem as they do their own thing, but other compositors such as Hyprland or Sway do share the same core.

If you want even higher level of abstraction so that you can make your own window manager in one hundred lines of code, you can opt to write a Wayfire plugin. It's as close to having a "base compositor" as possible.

GNOME and KDE definitely are the outliers, but they are the biggest players and they didn't do this out of sheer evil or whatever. They did this because when everyone was pushing for Wayland adoption, wlroots didn't exist or wasn't usable. And when it came out, everyone called it a "reference implementation" and it was expected of DEs to implement their own compositors.

And the main problem wasn't even that DEs didn't have a shared codebase for compositors, it was that there weren't any standards for critical features of any modern system. It was all "up to the compositors", meaning it wasn't just a matter of implementing some APIs, they had to be designed first. We now have different protocol extensions for KDE and wlroots alongside external DBus-based APIs for GNOME that have now also been partially implemented by KDE, yet there are still basic X11 features that can't be done on all of these compositors.

> And when it came out, everyone called it a "reference implementation" and it was expected of DEs to implement their own compositors.

Small correction, it is Weston that was a reference implementation. Weston was developed alongside the standard, so it's always been around. Whereas wlroots is very much supposed to be a practical implementation, but only came later.

The general Linux community is just fine with systemd. It works, and works well. It is only a minority (albeit vocal) of users who are actually upset about systemd.

> It works, and works well.

Bold statement to make.

To say it works well is an overstatement. "It works", yes, it does but I still beg to differ.

I've always encountered issues with it. Services failing to shutdown, throwing me timeouts of x/y requiring of attempting z tries.

Which as experienced within an install of Ubuntu Server a few days ago; nor have I seen systemd-resolved work either.

I've used both systemv and systemd professionally. They both have flaws. I have had fewer issues with systemd(albeit I have a system that rarely doesn't start up its target program after a restart, but it's managed so it's not a problem and just gets a manual start). Individual experiences may vary obviously but overall your comment supports the GP assertion of a vocal minority.

> but overall your comment supports the GP assertion of a vocal minority.

So nobody can express their frustrations with it without being written off as just a "vocal minority"? That's pretty sad, in my opinion.

Others may not vocalise the issues, to which I believe happens to more people than those who do vocalise the matter, doesn't mean it's works well. It works at best.

> […] but overall your comment supports the GP assertion of a vocal minority.

Is it possible to tell the difference between a demographic minority of people who are (all/largely) vocal, and a demographic majority of which only a small number are vocal?

Generally people like to complain; if everyone says something is bad, usually it is, and if most people aren't complaining, but consistent voices do, then it's an indicator of individual rather than widespread issues.

OK.

Nevertheless, the point of software freedom is freedom. I'm not upset about systemd as long as I have other choices.

It's the tendency of systemd users to say "shut up, you don't count, you're just a minority and you don't have anything real to complain about" and otherwise forcefully evangelize for their favorite paperclip maximizer that irks me.

Software freedom is the freedom to inspect and modify the source code, not have others develop that code to your personal preference.

You are free to fork whatever part of the Linux stack you want and modify it to your liking.

I don't need to fork it, we've got lots of nice alternatives, most of which are older and better debugged.

As someone who used to maintain an init script, ROFL.

As someone who writes init scripts and daemontools controllers all the time, I recommend daemontools and similar.

What's so hard about init scripts ? Since few years peoples are literally demonizing them, ROFL.

"Maintaining" that few lines of shell code that start/stop/check some program is incomparable to mainatining source code so can't be serious reason for demanding of removing them from existence.

And from that little scripts you literally know everything about starting/stopping managed program. Compare this to systemd undocumented, buggy and not working as expected "configs" :>>

Of course it's possible to make mess with scripts. But you can't manage to mess script so badly it becomes so monstrous as systemd :)

And you realy can't include so many CVEs as systemd introduced - that brain-dead not-a-init moved init process to ranks of sendmail and bind... Well done ? Works for me ? Minorities only problem ?

> What's so hard about init scripts ?

Unixes have this nasty property that forking new processes tends to inherit all the attributes of the parent process, and shell scripts are really good at making sure all the attributes are passed by default unless you bitch and complain and try really hard to not do so. Things like signal masks or environment variables, etc.

If you wanted a system where a service you're setting up runs differently because it was invoked by init on startup versus invoked by someone over an ssh session versus invoked by a different user over an ssh session versus someone running in a terminal in an X session, well, init scripts are a great way to do that. If you think such a system is horrific for debugging purposes and should be avoided at all costs, you're going to start by avoiding shell like the plague. (Also, shell is just an atrocious language for most tasks.)

But you can do all that above. You can split onto separate parts when needed. You can start small and grow your scripts. You can comfortably replace them. You can do everything you have rights to.

Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :)

So what deserve bigger "avoiding like the plague" ? Possibility or not possibility ?

You actually can't.

The first problem is you can only write a shell script to be defensive about the things you know about. Do you personally know which environment variables need to be reset to their default value for your service to work correctly?

The next problem is that there's actually some inheritable process state you can't manage with shell builtins. Combine that with the above, and it really makes sense for you to have a utility that knows how to spawn a service in a pristine, controlled environment.

While we're working on that pristine, controlled environment tool, we should also reflect on the fact that process management in Linux is a real complicated bitch. Simple is invariably neither robust nor correct. If we've already got a utility to help us write a services, we might as well extend it to be able to help with detecting stuff like "is this service still actually running or did it somehow fart itself and die?"

Of course, once you have this tool, you look back at your new init script and realize that all of the work you have to do is now in this tool, so why should you have to bother with boilerplate in a defective-by-default language [1]?

> Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :)

I've had more issues debugging init scripts than I have with systemd stuff. I actually find debugging easier with systemd... it actually tells me when things go haywire!

[1] Try having directories with spaces in their name with shell and see how often you get tripped up by it!

> You actually can't.

Maybe, maybe it can be done in some way, whatever 'it' is.

> you can only write a shell script to be defensive about the things you know about

And that is a problem strictly unique to shell scripting ? :) With systemd you know ? Or pick one arbitrary thing and just deny other possibilities ? Of course you deny (you as in the systemd implementer / beliver / user), as has been seen many many times. Suddenly usecase has been changed ! And maybe now you can do that with scripts even better then with systemd ? :)

> inheritable process state you can't manage with shell builtins

Is "builtins" a key world here ? Becouse shell scripts are quite literaly about using not build in pieces :)

> spawn a service in a pristine, controlled environment.

See ? Use case changed. It is no longer "user" or "other user", nor ssh or console or interactive, nor txt or X or W... Use case refactoring :) You can rething how to script it to not loss functionality.

Oh, wait... It's systemd ! Functionality loss is a motto there :) But scripts need to handle orginal usecase, for PR reasons :)

> process management in Linux is a real complicated bitch

nixes are complex. Lastly Linux have even more namespaces, contexts, etc. And you know what ? Systemd do not helped to make it simpler. Just wrapped some of them, badly (context v1 for years!) into internals and hijacked development of sane and modern system utilities.

> Simple is invariably neither robust nor correct.

Luckily we talking shell scripting here :) Becouse any system utility can be used. And they can be combined even ! Shocking ! ;)

> If we've already got a utility to help us write a services, we might as well extend it to be able to help with detecting stuff

Valid use case. Had been done ages ago. In modular fassion. With possibility of replacing monitoring part into other implementation. Can be even started from init.d script :)

> "is this service still actually running or did it somehow fart itself and die?"

And this is working on systemd ? :) Working better then in other service managers ? How systemd detect such conditions that other managers can't do that ? :) And why systemd display that not-funny messages of waiting for service to do something ? And permamently halting system halt ? And making my screen / tmux not working ? :)

> > Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :)

> I've had more issues debugging init scripts than I have with systemd stuff.

I have more problems with systemd configs then I had with using init.d scripts - they are just like command line(s), sequencial execution, easy to debug by just looking on them and checking system / app state. And usually it's not script problem but something with app. How systemd can improve on that ? By blackboxing managing service ? :)

> I actually find debugging easier with systemd...

Maybe. But just wait systemd will make debugging effort poinless by changing systemd behavior :)

But you missed something: with pure scripts or simpler managers you know everything* about system you are running. With systemd you don't - you introduce additional complication. And constant CVEs stream. How that is easier to debug ?

> defective-by-default language / directories with spaces in their name

On contrary, *nix shell scripts are perfect for work they are doing - batching commands you type into pack for re-execution. Tested commands that work as expected. And "spaces" problem is solved. Do tar or cpio in script have problem with directories with spaces ? Do ls, find and others have options for better separating things ? Do shell allow '""' usage ?

Thing about scripts is that you are supouse to stop using them when usecase is more complicated. This is counted as +1 for scripts and +1 for init.d usage (and -1 for systemd monitic monster). Scripts work is just to be agregators for fast and clear development eg. for start / stop / check helpers that you copy / paste almoust literally. Just like configs in systemd :)

Edit:

Btw. Hey, I don't specially like init.d - it works, is simple, extendable, replacable in few hours, etc, etc. Just systemd is such monstrous insanity...

> And that is a problem strictly unique to shell scripting ? :) With systemd you know ? Or pick one arbitrary thing and just deny other possibilities ?

If I run /etc/init.d/foo start to start a service, the service is forked from my current shell and therefore inherits everything from the shell. If I instead run service foo start, the tool instead sends a message to PID 1 process to fork the service, inheriting everything from PID 1. At that point, anything that can be changed could only have been changed by systemd itself, so if systemd doesn't know about something, then it can only be in the default state.

> And "spaces" problem is solved.

No, it's not. Write a shell script that reads a shell command (that contains quoted arguments with spaces in them!) from a file, appends some extra arguments to that command, and runs that command. The only way I could get that working was to go through Python instead.

> If I run /etc/init.d/foo start [...] inherits everything from the shell

'su' and 'env' helped a lot all that decades. Until everyone started using sodo passwordless :)

> If I instead run service foo start, the tool instead sends a message to PID 1 process to fork the service, inheriting everything from PID 1

Wait, you just want clean service ? I thinked usecase need to recognize how it is started and react to that ! But ok, send a signal 9 and inittabzerod will fork it with inheriting everything from pid 1 :)

> > And "spaces" problem is solved

> No, it's not

Ok, it isn't :) They even rewrote git in C to use file descriptors instead of text paths. But moustly it is becouse it is a very known problem with decades of solutions already implemented in common tools.

> Write a shell script that reads a shell command (that contains quoted arguments with spaces in them!) from a file, appends some extra arguments to that command, and runs that command

So: do shell meta programming in shell ?? :) That's clear abuse becouse shell is not general purpose programming language.

And how you do just that with systemd ? :)

But if you want some editable template file then oneliner in sed or awk or perl or ... with some structure will do. No need for introducing CVEs with new and soon to be rewriten or removed or abandoned parser somewhere in milions of lines.

So if you've got it, what are you complaining about?

Indeed, and many of us who have spent extensive time writing data center automation prefer it to the way things used to be.

* Config files and startup behavior are all in the same format; outputters for name daemons, cron jobs, networking, name resolution, NTP, coredumps, mountpoints, and more are all the same. Hand it a data structure with the proper keys and you know it's going to work.

* cgroup and namespace configuration are much more fine grained, flexible, and straightforward than docker. Have a weird vendor service that you'd like to restrict or isolate? you can do that.

* Process management is mostly a solved problem after years of being ignored by POSIX.

* Accounting metrics on memory, tasks, and I/O is for all your services is there

* Shipping to syslog is a breeze.

Yeah, it's got a learning curve but it's objectively better than a bunch of random init scripts. Which you can still use.

I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It doesn't integrate nicely into any of the tools I would normally use. tail in particular is pain in the ass because I have to wait for journalctl to convert the entire log back to text.

Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage.

I know it can forward to syslog, but at that point I'd rather just have syslog.

systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.

From the log producing side, journald is much better than log files. No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). With systemd you just log to stdout+stderr and are done.

> No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder).

I do.

I want my (e.g.) auth.log rotated regularly and kept forever. Many other things I only care about (say) 4-6 weeks of retention.

(This is in addition to off-host log shipping, which of course journald doesn't do itself so I have to run rsyslog regardlesss.)

I would totally agree with this.

I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald.

From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.

The logs are stored in a database. Having a database being purely clear text makes querying it slow.

this is nonsense

you can process millions of lines of plaintext in a tenth of a second using awk

Their current database is still dramatically slower than log files. Waiting for journalctl to produce logs is consistently the slowest part of me working with my logs.

It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.

> logging in binary was a mistake.

They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it.

> The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness.

* https://www.linkedin.com/pulse/20140924071300-170035-why-you...

Adding some more:

* You get real honest-to-god dependency solving, no more having to number scripts so they run in the right order or working with magic comments.

* .targets are the correct abstraction over runlevels that do what people actually need them to do.

* How journald manages disk finally fixes the stupidity of logrotate edgecases.

* sysusers/tmpfiles is by far by far the best way to manage non-human users and application specific directories.

* The entire system is programmable in real programming languages without having to shell out to system("systemctl start ..."). The whole thing is dbus-first and systemctl is just a client to it like any other.

* You can make your own unit types with systemd-generators if the built-in ones aren't enough for you.

* The system for overrides finally solves the package management bullshit where the init script and the package manager fight.

* Built-in userspace oom killer.

* Makes user sessions a real thing on Linux instead of an ad-hoc set of conventions.

* sd-notify for service readyness checks is fantastic

* Parameterized services!

No we're not, we just don't have the energy or clout to endlessly voice our valid objections

I hate systemd so much

For what?

> Disabling screen and input capture should have been an 'opt in' feature for the truly paranoid.

You can do screen captures on wayland. I've seen tools that were used to share a mouse and a keyboard to multiple computers kvm like that supported wayland so input capture seems to be possible to me.

My only gripe with wayland is that we seems to be lacking a common top level interface that is compatible with any compositor. Right now if some feature is not managed by the toolkit's wayland backend, devs need to have to implement compatibility with gnome's mutter, wlroots based compositor and kwin independently which doesn't seem to be a sane way of doing things. I wish all projects would converge into a common library like wlroots.

You can, now, but it's still not up to the level of polish that we had in x11, and nearly all of these are janky workarounds to a self inflicted problem

That will change, and you can expect support in Wayland to eventually surpass X11 because guess where all the developer effort is.

> That will change

Been hearing that from Wayland folks about very basic things for what, 15 years now?

Basic things have been sorted for a while already.

But not complicated things like, uh, dumping a representation of what's on screen to a file.

I've been using https://git.sr.ht/~emersion/grim for ~5 years now.

This has been possible for a long while already.

>I wish all projects would converge into a common library like wlroots.

They could also converge to a single display server implementation and the display server can interface with a separate window manager which could be swapped out.

I share your thoughts on Wayland.

Throwing systemd into the rant is unwarranted piggy-packing.

> but we're all stuck with it now as it's clearly 'the future'

Citation needed. X seems to be doing fine.

I sure hope so. Wayland still doesn't support an important use case for me so it would suck if I couldn't use X11.

What is the use case ? :-)

Not OP, but for me the use case is Xmonad (window manager).

Wmonad ;-)

There's a project called "wmonad" on GitHub, but it's actually another X11 window manager, no relation to Wayland.

There was the Waymonad project, but AFAIK it was never usable and is now abandoned (last commit 4 years ago).

x11 has seen no development for 10 years. Staying on it for forever is not viable.

Maybe that's why X11 still works, while Wayland is still an absolute shitshow.

I've been using Wayland for years at this point, and it works fine, and has continued working fine. When I switched, which again was years ago, it handled several things I cared about much better than Xorg. Try using multiple monitors of different DPIs on Xorg, it sucks.

According to [0] there have been several releases in the last 10 years. Including one in 2021 that added variable refresh rate and touchpad gesture support.

[0]: https://en.wikipedia.org/wiki/X.Org_Server

Maintenance work has been done, yes. But not new feature development.

Aren't the two examples I mentioned new features?

Oh sorry. They weren't visible in the edit I replied to.

What new features are needed to display my windows on my screen?

At some point you will have to either start building it for yourself or get someone to build it for you (when distros drop it from their repos). And that will become harder and harder as time goes by. Just recently apps I was building using Tauri stopped working on Xband forced me to switch to the Wayland Gnome session (on Debian testing) permanently. This will become more and more common, until it becomes untenable.

I doubt it will be so hard to build. Folks build X servers for Linux, Mac and Windows right now. If anything, X will probably outlive Wayland.

Building X is probably going to be trivial going into the future, yeah. Building and running future apps written for the Wayland will be a different beast though.

Just like there is XWayland today to make it possible to use a Wayland system with X apps, there are already similar solutions to run Wayland apps on an X system.

If you run `cage`, it will run a Wayland application in its own sandboxed window while the rest of the system runs X.

Similarly; if you run `sway` under X for example, it will start the window manager in its own window, and you can run Wayland applications inside it.

On the output side: Mixed-DPI displays. HDR/wide color gamuts/LUTs/color management. Non-rectangle workspaces, or workspaces with no absolute coordinate systems (think headsets).

On the input side: touch gestures recognized as touch gestures, not as mouse emulation.

On both: hotplug of all input/output devices. Headless sessions and handover of sessions between console and headless, both directions. Reliable lock screen, even if popup menu is showing ;).

> Reliable lock screen, even if popup menu is showing ;)

Impossible. I'm told if you're not running xscreensaver it is safe to assume that your screen does not lock!

> Mixed-DPI displays. HDR/wide color gamuts/LUTs/color management. Non-rectangle workspaces, or workspaces with no absolute coordinate systems

Pop quiz, how many of those work on wayland?

I have multi DPI displays (laptop + 2 monitors) work fine on Wayland (fractional scaling).

Except the HDR/wide color/LUTs/color management, everything.

And the last missing thing is WIP.

I find that comforting. I know it works and isn't going to be affected by what's trendy.

Fortunately, the source is available and if there is a need to make changes, that is entirely possible.

If the X11-and-Wayland maintainers had put X11 up for adoption that might not have been the case.

That is, they might have said "We're looking for new maintainers for X11. They will be responsible for its future direction, representing X11's interests to the kernel and to distributions, and deciding when (and if) X11 is to be declared deprecated."

As far as I can make out, what they did instead was say "We're looking for people to fix bugs in X11, but they won't get to make any nontrivial decisions."

By fixing bugs in X11, you get to make nontrivial decisions; that's the point why nobody wants to touch it.

Anyone is welcome to contribute. You still can I you feel so inclined[1].

Contributions have never been discouraged, but no one wants to work on xserver. Remember, this is a 20 year old codebase. With all the cruft and dark corners you would expect and more.

[1] https://gitlab.freedesktop.org/xorg/xserver

"ls" has likely seen no development either, nor have "dd" or "cat" I bet

When will you youngsters learn that something can be complete, done, and in no need of pointless reshuffling.

> x11 has seen no development for 10 years. Staying on it for forever is not viable.

Erm, what ? Are you sure ? Why it is X starting without a mouse now ? It has not done it 10 years ago ? Why do i need a gazilion of font libraries now ? Why were the default fonts changed ? Why is Mesa a hard dependency now ?

Xorg is unmaintainable and this is acknowledged by the experienced maintainers that don't want to maintain it any longer.

You are correct in your observations except that traction was actually bought by Red Hat's money.

Reply on news.ycombinator.com