Hacker News Reader

Comment by cletus | Hacker News Reader

This is a detailed, depressing and really damning view of the current state of the world. Some general thoughts:

1. Some things are clearly not Linux's fault, like proper support from NVidia;

2. The decision to make device drivers part of the kernel (as modules or otherwise) is really showing itself to be a problem. Interestingly, this was one of the drivers behind Fuchsia since device drivers are a huge pain point.

3. Some of these were news to me just because I hadn't attempted to use them (eg the 10 bit color depth issues). That one's kinda sad because it doesn't seem to even require such hardware to expose those issues. Just set your color depth in xorg.conf and watch the world burn (apparently).

4. Further to (3) it seems like a lot of issues remain unresolved just because they don't affect or aren't prioritized by the devs. Possibly they might require large architectural changes. Whatever the case, this is the negative of not having central product direction. Of course there are benefits to that too but this is a list of issues;

5. The Wayland list is damning as it reads like serious architectural errors were made for something that was meant to learn from X; and

6. PulseAudio continues to be the answer to the question nobody asked.

This should be sobering to anyone this with even a modicum of objectivity because it reads like a list that will never be solved.

View on HN

> 6. PulseAudio continues to be the answer to the question nobody asked.

  1. How do I change the output destination for audio from typical desktop/consumer apps without building it into ever such app?

  2. How do I deliver audio across a network?

  3. How do I use bluetooth audio devices that (were) not yet supported by the ALSA stack?

  4. How do I allow multiple applications to use the same audio hardware without either (a) requiring (like JACK) that they all use the same sample rate and buffer size or (b) using the rather unreliable dmix ALSA library layer?

  5. How do I provide a common volume control panel that allows to me control the relative gain of different applications all in one place ?

I could go on.

What about PipeWire?

PipeWire is an intentional swamp draining effort that takes a lot of these ideas/solutions, and applies them more broadly. In the audio domain it does so by scaling to the requirements of competing APIs like JACK and implementing them as well. But it also expands them to the video domain (think arbitrating access to camera devices, or processing chains spanning multiple processes), which has a lot of the same challenges. And underneath it's built on Linux kernel infrastructure (e.g. dmabuf) that wasn't as present during the early PulseAudio days.

A decent one sentence-summary for PipeWire is shell pipes for A/V between processes, with pluggable policy (hello mixer) and plugins to inject sources into the graph.

When Pulse audio came around, pipewire didn't exist. In fact, the infra required to build it didn't either.

Like I get that PulseAudio was unreliable for many years that fostered hate for it but it's absolutely crazy that people say that it's useless. You need something to collect sound streams from applications and mics, mix them, transform them, and output them to a bunch of different kinds of hardware with different requirements. Like Pipewire is fantastic but it's just a more reliable PA.

Yes, it was a necessary endeavor, but the implementation never lived up to the task. I'm glad Pipewire is now getting traction, as I fear PulseAudio will never be able to be the stable and robust solution we need for audio on Linux.

Particularly, it handles badly sleep modes, hot plugging sources, and BT, which in 2021 is not acceptable. I regularly have to set things up manually using pavucontrol.

But yes, we needed it, and I thank the people that tried.

> Like I get that PulseAudio was unreliable for many years that fostered hate

Unreliable, and a shocking resource hog. Did that part ever get better, or did we just stop caring because memory sizes and core counts kept going op?

I stopped caring because PipeWire works well and ships as a drop-in replacement for PulseAudio and Jack by default.

It's not quite a drop-in replacement for JACK yet, but I have very little doubt that it will get there.

neither, when pulseaudio was built there where problems all up and down the stack. from the kernel, alsa, and userspace.

the effort around pulseaudio stabilized and resolved most of the problems in the kernel and alsa. leaving most of the problems in the implementation of pulseaudio.

pipewire is now building off that giant amount of work pulseaudio effort resulted in and is able to reuse pulseaudio's IPC framework to seamlessly replace pulseaudio itself.

An answer to most of these might be to fix and extend ALSA rather than wallpapering over it and treating it like abandonware.

ALSA was written to allow psuedo-devices to be implemented in user-space, which is how PulseAudio (and now Pipewire) does what it does.

Nobody is abandoning ALSA, it continues to be both the device driver layer and the lowest layer of the audio stack in user-space.

[ EDIT: you could make an argument that after many years of experience, it's time to put the lessons learned from JACK and PulseAudio into ALSA itself, and have ALSA provide the sorts of audio capabilities that the two of them, combined, enabled. I don't have much of a position on this compared with the Pipewire approach, which is to do the same thing, but outside of ALSA. There are good arguments for both, but Pipewire is what we have, and it remains as dependent on ALSA as JACK and PulseAudio and just about all other Linux audio has been since 2000 ]

which is funny because that's exactly how ALSA was started: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...

I've been developing audio & MIDI software for Linux since about 1997. Maybe that makes me a special case, but none of the experience described by the post is familiar to me. I even used to use xmms with ALSA.

There's some acorns of truth in that account, but it's been turned into a paragraph of hand-waving half-truth.

That's hilarious. And sad.

https://www.jwz.org/doc/cadt.html

Copy paste the link. Or:

> I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.

> It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?

> But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.

The 3rd quoted point.... if applying it the Linux audio stack then ... this is so absolutely fucking disrespectful to people like Takashi Iwai, who has spent 20 years fixing bugs and doing so much "un-fun" work on ALSA.

Y'all can vent on Lennart as much as you want, but every time you do you forget the heroes who have worked out of the spotlight, doing the boring grunt work that has kept ALSA working for two decades as audio hardware has changed dramatically.

How would my quote apply to people who do that kind of work?

The whole article is about people that <<don't>> do that.

It's pretty rude to insult someone by calling them an "attention deficit teenager" regardless of what they're working on. I would recommend against quoting that article.

I see you chose to ignore what prompted the rant. Is it deliberate?

I generally try to avoid responding to rants because every time I do that, the author gets angry and starts complaining at me. In my experience, people who rant are just frustrated and blowing off steam, and are not trying to be taken seriously or start a constructive dialogue. If a person actually has some leadership/direction and a solid grasp on the full picture then there is no need to rant.

But you may want to read my comment here: https://news.ycombinator.com/item?id=28856907

Where we put our attention says a lot.

People like Takashi get almost zero attention, because so many people spend their time blabbering about people doing "sexy" stuff. JWZ does this too. I believe we'd be much better off if we tried to do more ignoring of the flashy stuff we don't like and instead support and laud the unflashy stuff and the people who do it.

I'd say what's interesting is that the people who don't do that are probably overrepresented within the Linux community. The average tenure of devs there is in excess of the average tenture of most tech employees of today. It might be more meaningful to measure continuity as provided by organizations (i.e. communities vs. corporations, for example) as they address turnover, but I'm not so sure. Frankly tech churn seems to be about equal on both sides. Other systems have revamped their audio stacks on occasion as well. It's the economics/business models that favor certain kinds of finish, especially backwards compatibility.

I'd further submit the Linux story there has improved over time. For example PulseAudio didn't attempt to provide much of an upgrade path to apps using aRts and ESD (its predecessors), but PipeWire provides continuity for apps written against ALSA, PulseAudio and JACK. And as PulseAudio and JACK were difficult to run side-by-side at times, it actually reduces fragmentation as well. By aligning audio and video device access within one system it also generalizes system behavior.

That comment is somewhat problematic and I went into detail about it last week: https://news.ycombinator.com/item?id=28856907

Great comment. Sorry that I missed this at the time.

ALSA is already overcomplicated. What I expect from ALSA is being able to enumerate audio devices and being able to send audio to hardware without any transformations. The rest is the work for the userspace daemon.

That's what ALSA does. You don't have to use any other features of it. However, the task is a bit more than you're describing, because in 2021, users expect things like:

  * hot-pluggable devices (so you need a device notification protocol)

  * ability to lock the device to prevent settings modifications (very important to pro-audio/music creation settings). macOS calls this "hog mode".

Also, you're eliding the distinction between the capabilities of an API and where it gets implemented. Contemporary audio has all sorts of requirements that could be/should be/are implemented in user space, but it's unclear if they should be a part of the ALSA API or some layer(s) above that.

I guess? If I have a video player or a game/emulator in the foreground then I think it deserves direct access to the audio device and I just don't like the idea of a userspace sound server in the middle. For a music player or whatever other random stuff, sure, mix it however, send it over Bluetooth, who cares. I've given up fighting PulseAudio, though, and with one audio device I can't have it both ways.

PulseAudio obeys a (dbus) protocol that Lennart and I worked out that allows JACK (or Ardour) to show up and say "hey, I want the device". Any other application could implement it. Pipewire has (AFAIK) implemented the same protocol.

That is super cool, thanks for the information!

> 5. The Wayland list is damning as it reads like serious architectural errors were made for something that was meant to learn from X; and

The Wayland section is also perhaps the most technically inaccurate of the post, for example in its comparisons to how competing systems are put together - more than once it lays the blame for not providing a certain kind of API at the feet of Wayland, when in the other systems named, the equivalent API is also not provided by the windowing/compositing system but at an orthogonal library level. In other cases the criticism reflects broad technological trends that are equally true for other systems from the same era (e.g. client-side rasterization), and for the same motivating reasons.

I noticed that as well. The entire Wayland section is completely confusing and incomprehensible to me, and also filled with numerous false statements. It's just very poorly researched.

> The Wayland section is also perhaps the most technically inaccurate of the post

The author is open to valid criticism and updates the article whenever someone points inaccuracies or falsehoods.

You and the guy replying to you, both say nothing technical or factual aside from "it is all wrong or/and inaccurate". That's very hard to act upon.

> In other cases the criticism reflects broad technological trends that are equally true for other systems from the same era (e.g. client-side rasterization), and for the same motivating reasons.

Yet other systems provide a level of integration and ease of use (APIs) which are leaps and bounds above what the Wayland protocol offers. That's the main gripe.

Check this for more info: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

I posted more technical comments elsewhere in the thread.

5. The Wayland list is damning as it reads like serious architectural errors were made for something that was meant to learn from X; and

Not really - remember that Wayland is mostly just doing things the way every other OS (ios, mac, android, windows) does them - passing around raster buffers to user-processes.

Most of the complaints have to do with the politics behind Gnome+GTK, KDE+Qt, and FreeDesktop. It was always ridiculous to have all of these settings stored in and managed by X11 - no other OS manages user shortcut and keyboard settings this way. When you take away X11, presumably you'd want to take away the bad separation-of-concerns as well, right? So it doesn't make sense for Wayland to be managing these things, right?

But then someone else needs to pick up the ball. The fact that everyone is writing their own compositor is just another symptom of the ridiculous project-fragmentation that has always afflicted desktop linux. They could have cooperated and made a common compositor, but everyone had to build their own.

> Not really

Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic scrolling and all kinds of application behavior is now potentially completely different for different applications. It's a mess, we need standardized solutions and such a solution already exists: X11.

> The fact that everyone is writing their own compositor is just another symptom of the ridiculous project-fragmentation that has always afflicted desktop linux. They could have cooperated and made a common compositor, but everyone had to build their own.

The Linux community already has huge problems to agree on any standard at all and X11 is such a standard with a huge amount of support functionality. This is rare and should not be squandered. X11 is not pretty but the insistence on backwards compatibility led to a growth of a huge ecosystem (just count the numbers of Window managers). If anything I consider Wayland (and GNOME) a deliberate act of sabotage.

> Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic scrolling and all kinds of application behavior is now potentially completely different for different applications. It's a mess, we need standardized solutions and such a solution already exists: X11.

A lot of this commentary just doesn't quite reflect reality, even if it's meant well. There's a lot of misunderstanding on what really is different now, or how things are different from other systems.

- Font rasterization and text shaping in all major applications has normed on freetype and harfbuzz.

- Kinetic scrolling/input event handling has (or is in the process of) normed on libinput.

- This is true for X11-based systems as well! The X protocol historically does contain commands for server-side text rendering, but those haven't been used in decades - applications started moving to client-side rasterization ages ago, and the X server moved to using libinput (where its code originated, before then being intentionally moved out).

- In competing systems such as Windows/MacOS, the situation is often the same or reflects the same tech trends. Often there are legacy server-side APIs to do things, but apps have long-sinced moved to newer library APIs. Often there's more than one way to do things (say, text rendering on Windows: Pick GDI or Direct2D) and the perceptual same-ness has just been achieved through effort of alignment. In fact it can actually be worse on other systems nowadays - native app development on Windows has really deteriorated and you can find many apps that just ship freetype/hardbuzz there (bundled with the cross-platform UI lib they picked) and don't match Windows font rendering.

- The separation of duties between the windowing/compositing system and orthogonal library APIs is often the same. For example, in both iOS and Android the display server is not responsible for text rendering in any way. On Android the latter is done through freetype/harzbuzz as well.

- Wayland compositors already share a lot of code in much the same way that X-based desktops did, e.g. by graphics drivers having moved out of the X server into the kernel and Mesa, and input having been moved to libinput.

X11 is not really a viable solution anymore. The API has some pretty major flaws that there are no plans to fix. Or rather, the plan to fix them has been to ship Wayland as the new API. It should continue to be backwards compatible because of XWayland. Also I don't believe X11 has any API for kinetic scrolling, that typically is implemented by the desktop environment so I'm confused as to what you mean.

"I consider Wayland (and GNOME) a deliberate act of sabotage."

KDE is actually fully behind Wayland as well. It's not something that GNOME is doing just to inconvenience you. https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayl...

> X11 is not really a viable solution anymore.

These are very unsubstantiated claims. X11 works perfectly. Wayland on the other hand is not a viable solution at all at this point. You can't even take screenshots.

> The API has some pretty major flaws that there are no plans to fix.

Except for the 15bit coordinate limitation it has no major flaws and can be extended if needed. If anything has major flaws it is Wayland. As an exercise I recommend implementing a native screenshot application on Wayland and compare that experience with the X11 equivalent. The Wayland API is pure garbage.

> KDE is actually fully behind Wayland as well.

Maybe in words only. The Actual Wayland version of KDE has major bugs and people doing serious work always switch back to the X11 session where it works flawlessly. Besides that I don't think KDE is any good either.

I'm using GNOME on Wayland and pressing the "Print Screen" key takes a screenshot so I'm not really sure what you're talking about, it would help if you could clarify.

My experience developing screenshot/screencast/webcam applications on Wayland has been significantly better than it has been on X11. Using X11 APIs for those things is somewhat of a misuse and breaks in corner cases, as those APIs are only really safe to use by the window manager. Extending X11 is also a bad idea because that's just more things that have to get plumbed through Wayland/the X server/toolkits/libraries. Pipewire really makes it easy to use and convenient, you just use that and then you don't have to worry about messing with the lower levels of the stack.

If you don't think KDE or GNOME are good then we have not much to talk about, there are no other viable open source desktop platforms on Linux. I certainly don't think they're free of flaws, but they are the best we've got.

> My experience developing screenshot/screencast/webcam applications on Wayland has been significantly better than it has been on X11

I use Firefox on X11 and screen sharing in Google meet just works.

A colleague uses Firefox on Wayland and screen sharing in Google meet does not work.

Maybe his setup is just incorrect, but it does not sound like things have become significantly better.

It works for me with GNOME and Firefox 93, your colleague may have to update. Not Google Meet but I did it successfully with Jitsi.

But I am referring specifically to the developer experience I had with the API, not the progress of any given application in implementing this API.

Everything works on my wayland. Btw I use swaywm and have perfect support for any of the flaws mentioned. The quality of screen sharing is better than other OS even under low bandwidth.

> These are very unsubstantiated claims. X11 works perfectly. Wayland on the other hand is not a viable solution at all at this point. You can't even take screenshots.

You either haven't used Wayland, or haven't used it lately. You can take screenshots just fine. I used to do it regularly with KDE's Spectacle, and now I use Flameshot.

Screen sharing also works.

> Maybe in words only. The Actual Wayland version of KDE has major bugs and people doing serious work always switch back to the X11 session where it works flawlessly. Besides that I don't think KDE is any good either.

I use Plasma with Wayland to do my work and it's been a breeze, no pun intended.

> They could have cooperated and made a common compositor, but everyone had to build their own.

I don't think it's bad to have different projects with different goals.

One thing that's also with pointing out is wlroots which is a library that can be used by lots of different compositors to help share code, which kind of is "everyone coming together to make a common compositor".

Scanning the OP list.

It seems to involve X hardware isn't supported and "You can divide up Y output - can't have two graphics drivers or two audio systems, have to reboot when things crash or etc". I hope these get fixed but I can't see how they're either "major" or damning. I mean, Linux is intended to be utterly reliable as a server OS but the ability to reboot when X crashes is otherwise a function of how likely it is for X to crash. If it's unusual and rebooting is reasonably easy, what is that problem. Windows itself got by with rebooting as the solution back when problems were far more common than they seem to me to be (once every 1-4 weeks my mouse driver dies and I need to reboot - and that problem IS supposed to be fixable without a reboot but isn't but who cares).

I mean, I have had "fuck around 'till it works" problems on Windows when I used it ten years ago and I have had them on my various Linux laptops since then.

* As I understand it, the major/damning problem on Linux is that a lot of gaming generally isn't support. That's different from all these problems which are "serious annoyance you can often work around".

Like you're #3 is "awful, damning, I never noticed and still haven't tested..."

Let's keep this in perspective.

Edit: a problem mentioned, that I would consider damning/major is using the CPU for video. That is a serious headache for video conferencing. A list that doesn't pile up all the snafus but instead prioritizes them would be good (I think there's actually far more headache-type issues even this list but I still can use my cheap Ubuntu/Mate laptop for nearly everything and enjoy it).

> a problem mentioned, that I would consider damning/major is using the CPU for video. That is a serious headache for video conferencing

If you have a hardware codec, graphics card, or codec support built into your chipset like many AMD and Intel chipsets have, then you can accelerate video encoding/decoding via VA-API, VDPAU or whatever Nvidia's solution is. Check out this page[1].

[1] https://wiki.archlinux.org/title/Hardware_video_acceleration

> 5. The Wayland list is damning as it reads like serious architectural errors were made for something that was meant to learn from X; and

Exactly my thought as well. However I am pretty happy with Wayland as my daily driver though (except some weird issues on Firefox). Anybody with more knowledge about Wayland's development cares to comment?

I have done some hacking on Wayland and most of the comments there about Wayland are misleading or wrong. I could go through that list but I don't know if I'm really interested to do that unless the author reads the feedback and could be convinced to change their article. It is really exhausting to deal with online misinformation unless it's stopped at the source.

You could email him or leave comments under the article. All valid criticism has been addressed and the article keeps being updated. It's its 500th revision or something like that.

Maybe I'll go through it if I have time but there are several other things that are really wrong or misleading in the article, it's a research project in itself to correct all the misinformation there. (A lot of the article is mostly correct though so it's probably an even worse situation for a reader)

Also a huge part of it is that the author is asking for things that don't really make sense e.g.

"Wayland does not provide a basic universal unified graphical toolkit/API (and Wayland developers will not implement it) akin to Win32"

Wayland sits at a level below the toolkit, it is an implementation detail in the toolkit. You're supposed to build toolkits on top of it. It wouldn't be feasible (or even wanted) to move the toolkit inside Wayland. A lot of these other criticisms are along these lines, i.e. a misunderstanding of what Wayland actually is. That bug report that was filed is not even actionable because of this.

Also edit: Sorry, I just noticed you're the author, you could mention that :) I'm not trying to give you a hard time here, but that whole part needs to be rewritten I think, because basically everything in it stems from a major misconception and is not constructive feedback because of that. I am actually in agreement with your thesis though, the "Linux desktop" (whatever collection of random 1000 git repositories that refers to this week) is pretty flawed. And Wayland definitely is flawed too, just not in any of the ways that were mentioned.

> there are several other things that are really wrong or misleading in the article

When I see generalization about a ton of stuff I instantly get suspicious about such claims. The article cannot be as wrong as you're trying hard to portray it.

> it's a research project in itself to correct all the misinformation there

You're really a fan of "misinformation". Sorry, the guy who wrote it, has been using Linux for more than two decades and is trying to be as unbiased and factual as possible. Looks like you're just too invested in Linux and you've been personally shaken that such an article even exists in the first place.

> Wayland sits at a level below the toolkit, it is an implementation detail in the toolkit. You're supposed to build toolkits on top of it. It wouldn't be feasible (or even wanted) to move the toolkit inside Wayland.

What's wrong with this claim exactly? You're not disproving it in the slightest, you are _explaining_ why it has been done the way it's been done. Most people don't give a damn about it.

Most 32bit Windows applications continue to run in Windows 11 26 years later. Linux, be it X11, Wayland or Mir, has no alternative to that. Yes, the author wants some LTS API for graphics, do you have anything to add to that? How does having Qt/Gnome/EFL/etc even address the issues shown in the article like inability to configure all the toolkits font rendering and other features simultaneously?

Had we had a low lever API akin to Win32 which toolkits like e.g. Gnome/Qt could be built upon, that would have never been an issue, meanwhile Linux developers continue to reinvent the wheel and _not_ provide universal solutions which allow to build software on top of it which will work for decades without recompilation.

You really don't see where the author comes from, yeah, Windows, where software can be developed and work for decades.

Just don't start BS'ing me with "everything could be recompiled for $next versions of Gnome/Qt" - this has _not_ been the case, we've lost hundreds of GTK 1/2, Qt 1/2/3/4 applications which no one wants to port to newer toolkits.

Actually please don't bother with your "refutations". I see where you're coming from and I'm sure you'll continue in the same vein which is "Linux is built differently, get used to it".

I can, I have but ISVs and game developers will _not_. If you're OK with no commercial software and AAA games for Linux, absolute most average people are _not_. They want to play native games and run native Adobe/Autodesk/etc. software under Linux.

I can imagine you could be content with having always incomplete layers of emulation and VMs which further prove that other OSes like Windows are built and designed better, since Win32 APIs are so easy to emulate.

Had you started differently I'd have been glad to continue arguing with you but you've used the meanest and dirtiest words to describe the work put into the article which is an instant turn off and a clear indication that you might have a superiority complex.

The article actually is that wrong because it stems from one faulty piece of information, I tried to mention that. Wayland is not meant to sit at the layer of the stack you're thinking it is. You could be asking for all those features in something else, but that's a different project you'd be talking about and a different project you'd need to be criticizing, not Wayland.

"You're really a fan of 'misinformation'. Sorry, the guy who wrote it, has been using Linux for more than two decades and is trying to be as unbiased and factual as possible. Looks like you're just too invested in Linux and you've been personally shaken that such an article even exists in the first place."

This is wrong, please avoid making these accusations of bad faith, and please do not spread this misinformation about me. That really hurts me when you do that because you are lying to my face about the thing I know most: myself. Sadly this kind of unprofessional behavior is so common in the Linux world that I think some of us have gotten used to it. But it needs to stop. I also have been using Linux for more than two decades. Linux on the desktop sucks. It's bad. I'm in total agreement with you there. It's deeply flawed in a lot of ways.

"You're not disproving it in the slightest, you are _explaining_ why it has been done the way it's been done. "

There's nothing to disprove here though, that's what I'm saying. I'm saying the claim doesn't make any sense, it's like saying "the Linux kernel is bad because it doesn't have a feature to do my taxes". Well yes, Linux is just a kernel. It's not tax software. If you want to use tax software you'll have to find something built for that purpose, and then if you find the tax software makes an error you could report it to the authors of it. If you tried to report it to the kernel developers they'd say sorry there's nothing we can do about that. See what I mean? Trying to make all these complaints about Wayland doesn't make sense. What you're asking for is something different entirely.

"Linux, be it X11, Wayland or Mir, has no alternative to that. Yes, the author wants some LTS API for graphics, do you have anything to add to that?"

Actually XWayland serves this purpose to keep old legacy apps running. Win32 API is not a good example since most modern Win32 applications are not built using the Win32 API either. But old software X11 should work just fine, if not then you should mention the particular bug you're having so that could get fixed. I'm not sure what you mean "LTS API" though, you could just ship any old version of an API you want.

"You really don't see where the author comes from, yeah, Windows, where software can be developed and work for decades."

No need to get defensive. I'm curious what's your experience with Docker? That's been good for me to keep old software running.

"Had we had a low lever API akin to Win32 which toolkits like e.g. Gnome/Qt could be built upon"

Well we did have that, it was called Xt, and those toolkits moved away from it because it was very ugly :) I get what you're saying but it sounds like you're asking for them to have developed the perfect API 20 years ago which I hope you understand is not realistic. We know all the things we know now because of the benefit of hindsight.

"Just don't start BS'ing me with "everything could be recompiled for $next versions of Gnome/Qt" - this has _not_ been the case, we've lost hundreds of GTK 1/2, Qt 1/2/3/4 applications which no one wants to port to newer toolkits."

You don't need to port those to newer toolkits though, you can just ship the old version.

"Actually please don't bother with your 'refutations'. I see where you're coming from and I'm sure you'll continue in the same vein which is 'Linux is built differently, get used to it'."

I assure you, you're wrong about me. I'm not trying to refute you, I'm trying to explain that some of these problems actually do have solutions, so that you can use it to help yourself. And the thing about misinformation is that it spreads to other people and gives them the wrong ideas too, so if we want to have any chance to stop it then we need to take responsibility ourselves.

"I can, I have but ISVs and game developers will _not_. If you're OK with no commercial software and AAA games for Linux, absolute most average people are _not_. They want to play native games and run native Adobe/Autodesk/etc. software under Linux. I can imagine you could be content with having always incomplete layers of emulation and VMs which further prove that other OSes like Windows are built and designed better, since Win32 APIs are so easy to emulate."

I'm in total agreement about this. The Linux APIs are a total mess and unappealing to developers. Windows has Linux beat in an extreme way. But that's not an excuse to make false or misleading statements, we still need to get our criticisms correct if we want to have a chance to fix things. Edit: In my opinion the issue with gaming is totally separate from X11/Wayland and everything else. Linux just does not have any real gaming APIs. There's Vulkan and there's SDL and then that's it. That also is something that probably needs to happen at a layer above Wayland.

"Had you started differently I'd have been glad to continue arguing with you but you've used the meanest and dirtiest words to describe the work put into the article which is an instant turn off and a clear indication that you might have a superiority complex. "

I don't think I'm superior to you and I'm not criticizing you as a person. You're great. However some of the things you've said aren't correct, and I do think that you, as an intelligent being, deserve to know that so you can improve your article. There's no nicer way for me to put it, nobody likes to hear that they fucked up, but sometimes we need to hear it. Please do not write these articles if you're going to get defensive and don't want to field any criticism, that is not the way to have a discourse with the community. Edit: Also you've referred to this as an argument which it isn't. I'm not interested in arguing with you, I'm interested in correcting these issues. If you knew me you would probably find that I agree with you in most areas.

> This is wrong, please avoid making these accusations of bad faith, and please do not spread this misinformation about me.

If you could stop being so rude and insulting I could discuss this further with you. _It was you_ who started with "misinformation" even though it was _never_ the author's intent.

> Wayland is not meant to sit at the layer of the stack you're thinking it is. You could be asking for all those features in something else, but that's a different project you'd be talking about and a different project you'd need to be criticizing, not Wayland.

ISVs and game developers need stable APIs to base their applications on and no Linux library or middleware or whatever you want to call it provides it currently, Wayland or not. You seem to be nit-picky as hell without trying to remotely understand what the author wants and has in mind, and that is "write once and be able to run for decades".

Here's the item you're opposed to and calling "misinformation":

> Applications (or GUI toolkits) must implement their own font antialiasing - there's no API for setting system-wide font rendering. Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X. In Wayland all clients (read applications) are totally independent.

Where the hell is misinformation exactly? Do graphical libraries for Wayland use common _shared_ APIs, interfaces and configuration to render fonts? Are those even standardized? Can I be sure that an application which doesn't use GTK/Qt/EFL will use my ~/.config/fontconfig ? No. That's the answer.

OK, they currently all maybe use FreeType/Pango/Cairo/Skia/whatever, but will these libraries be there in 10 years time? Just 15 years ago _nothing_ in Linux used Pango. It was XFT. No bloody standards, no APIs to guarantee anything in the long term. Well, under Windows all Win32 applications render fonts exactly the same (let's not talk about UWP and other fancy crap) using your font antialiasing settings.

BTW, right bloody now, in Fedora 35, GTK, Qt applications and web browsers all render fonts differently. I can upload screenshots for you to see. So much for "misinformation". Oh, God.

OK, let let's call this article which, every time it shows up, gathers hundreds of comments "a load of absolute bullcrap/misinformation" (which you're so fond of) and Linux is perfect.

If you really want to be technical and factual, approach what article says from the same PoV, not "I will _interpret_ this and that this way based on the _status quo_ and call it misinformation".

Good luck and have fun calling everything you disagree with (even though it's not technically false) "misinformation". BTW, you've used "disagree" quite a lot but still call everything "misinformation. Make up your mind already. Either something is dead wrong or not. First you made it abundantly clear that it's _all wrong/false_ and now you're "disagreeing".

Lastly there are 12 items (!) under Wayland, one which you disagree with, yet the whole article is disinformation. OMFG. This certainly invalidates everything.

Sorry, you've rattled me too much to continue.

"_It was you_ who started with "misinformation" even though it was _never_ the author's intent."

I am not saying it is your intent, most people who get things wrong are not intending to do so. It still however can be misinformation. I think you are confusing terms, the word "disinformation" is what usually refers to intentional false information. I'm not saying you're spreading disinformation and I'm not criticizing you as a person. My issue is with the words that are written in the article. Please avoid taking criticism of your work personally, I'm sure you are a good and beautiful person.

"ISVs and game developers need stable APIs to base their applications on and no Linux library or middleware or whatever you want to call it provides it currently"

I agree, this is the real problem and you could just state that. It has nothing to do with X or Wayland or whatever.

"what the author wants and has in mind, and that is 'write once and be able to run for decades'"

Actually I do understand this, and I feel the article doesn't communicate it well, I wish you would be clearer about what problems you're having here with shipping apps like this. The criticism of all kind of unrelated things is distracting, just mention what you're trying to run that isn't working.

"Do graphical libraries for Wayland use common _shared_ APIs, interfaces and configuration to render fonts? Are those even standardized?"

The answer to all of those is yes, they use freetype.

"Can I be sure that an application which doesn't use GTK/Qt/EFL will use my ~/.config/fontconfig ? No."

I'm really not sure what you're asking for here, if the app opts out of the standard then of course it won't work. You can also implement your own font rendering on Windows/MacOS and opt out of the standard there too. There is absolutely nothing X or Wayland or Mac or Windows or anything can do if an app decides they are going to implement their own font rendering library. And I assume you're talking about games here, those are a great example of something that intentionally doesn't follow the system settings on any platform.

"OK, they currently all maybe use FreeType/Pango/Cairo/Skia/whatever, but will these libraries be there in 10 years time?"

Well yes, the code will probably still be around, I think github has archived all this stuff for 1000 years or something like that.

"Just 15 years ago _nothing_ in Linux used Pango. It was XFT. No bloody standards, no APIs to guarantee anything in the long term."

I have no idea what you mean, you can still use Xft. Pango has more features however so you'll have to upgrade if you want those. That's generally how it works, new APIs get new features, the old APIs stay the same and remain stable.

"Well, under Windows all Win32 applications render fonts exactly the same (let's not talk about UWP and other fancy crap) using your font antialiasing settings."

I don't understand why you are saying disregard UWP, that would be a demonstration of the same problem!

"gathers hundreds of comments 'a load of absolute bullcrap/misinformation' (which you're so fond of) and Linux is perfect."

Linux isn't perfect, I've said repeatedly that it's heavily flawed.

"Good luck and have fun calling everything you disagree with (even though it's not technically false) "misinformation". BTW, you've used 'disagree' quite a lot but still call everything "misinformation. Make up your mind already. Either something is dead wrong or not. First you made it abundantly clear that it's _all wrong/false_ and now you're 'disagreeing'. Sorry, you've rattled me too much to continue. "

Please avoid this kind of combative comment. I've said I agree with you in subjective matters in what constitutes being "good" or "bad" and what we think needs to happen. In matters of the facts of what the software actually is doing right now, that's where we need to worry about facts and misinformation. You owe it to your readers to be as accurate as possible if you want to have a positive effect. Also I apologize if you feel rattled, it's not my intent to upset you, my intent is to get the facts corrected.

Anyway I'll get into it. From my perspective from actually working on this, the problem with most of these statements is that none of these things can actually be fixed in Wayland. Wayland is just a really basic protocol for putting buffers on the screen, it doesn't do much else and it's intentionally not good at being a general purpose API for desktop-y things. Your article seems to assume that it is, which is a misconception, and only causes confusion. If you actually tried to fix these problems by making changes in Wayland then you would make the problem worse. Most of what is mentioned absolutely are problems, but they need to be fixed elsewhere, and the claim should probably be rephrased to reflect that if you want it to be accurate. To be clear, I am in no way trying to downplay any of these problems.

"Wayland doesn't provide multiple APIs for various crucial desktop features"

So some of these are in the portal API, not wayland. It doesn't really make sense to put them in Wayland, some implementations do provide them in Wayland but that's more of an implementation detail and applications wouldn't actually be expected to use that API. Some of them are still missing from the portal API however, which is a problem, so maybe this should be edited down to just those. I'll talk about each of them too.

- global keyboard shortcuts - It's not clear what this means. There were some proposals for this but none adequately explained the problem.

- drag-n-drop - Not sure what else you're looking for here, Wayland has this.

- systray - There are implementations of this, it doesn't belong in the wayland protocol. It would be for a panel to communicate with an app.

- screenshotting, screencasting - This is in the portal API.

- UI rendering acceleration - Not sure what this means, Wayland clients can just use OpenGL or Vulkan.

"which must be implemented by the window manager/compositor, which means multiple applications using the said features can only support their own Wayland compositor implementations"

I'm not sure what this means, applications can use an abstraction layer that deals with it for them. Most applications already are using such an abstraction layer like GTK/Qt/SDL/etc, they should not have to deal with the raw X11/Wayland API.

"Wayland doesn't provide a universal basic window compositor"

This is not the use case of Wayland and it would not be possible for Wayland to provide this. You could build such a compositor on top of Wayland.

"thus each desktop environment has to reinvent the wheel and some environments simply don't have enough manpower to write a compositor e.g. XFCE/IceWM. This also leads to a huge amount of duplication of work (and bugs as well) because various desktop environments need to reimplemen the same features and APIs over and over again."

Well no, if they're short on manpower they can just use an existing compositor such as Mir, wlroots, mutter, etc. The real problem here is that they are short on manpower, nothing can be done in Wayland or X11 or anything to really fix that.

"Wayland and its window managers/compositors have very high requirements in terms of support from both hardware and kernel drivers which prevents it from working on far too many configurations. X.org and Windows on the other hand can work on an actual rock using e.g. VESA."

So this is an actual problem but it's not really related to Wayland, e.g. if you want to run an X compositor on an old PC that will also have bad performance because it requires hardware acceleration. And if an app itself requires Vulkan or something then that definitely won't work. I'm not sure what can be done about this and this seems like complaining about an unsolveable problem, you will also have similar problems if you try to install Windows 11 or MacOS Monterey on an old PC and try to run modern apps on it.

"Applications (or GUI toolkits) must implement their own font antialiasing"

This is completely wrong, basically all applications and UI toolkits just use freetype.

"there's no API for setting system-wide font rendering"

This is also completely wrong, this is what fontconfig is for. It's not the best API though so this section could be rephrased as a review of freetype and fontconfig.

"Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X."

This is also completely wrong, I just checked Android and MacOS and there is no setting to change the font rendering. Not sure about Windows as I don't use it.

"Wayland does not provide a basic universal unified graphical toolkit/API (and Wayland developers will not implement it)"

See what I said above, Wayland cannot implement this. If you wanted this you would have to build it on top of Wayland. Wayland is a API to use when implementing a toolkit.

"akin to Win32 which means applications using different toolkits (e.g. Qt, GTK, Enlightenment) may look and behave differently and there's no way to configure all of them once and for all."

Toolkit fragmentation is a real thing which should be mentioned in this article, but see above again, this is not something that Wayland is ever going to be in any position to fix.

"Firstly, forget about performance/bandwidth efficient RDP protocol (it's already implemented but it works by sending the updates of large chunks of the screen, i.e. a lot like old highly inefficient VNC)"

Another thing that Wayland is not in the position to fix. This would be nice to have but would be up to the toolkits to implement.

"forget about OpenGL pass-through, forget about raw compressed video pass-through"

This has to be implemented in the VM host, there is nothing a Wayland implementation can really do about it. The Wayland protocol only receives the dmabufs and YUV buffers and passes them off, it doesn't say anything about what to do with them.

"In case you're interested all these features work in Microsoft's RDP."

Yeah so that would be a problem with the RDP implementation, FreeDRP or whatever.

"Secondly, forget about proper output rotation/scaling/ratio change."

That thread is really confusing and nonsensical to me. If you have non square pixels then you just make the application aware of the vertical/horizontal DPI in some way. Wayland doesn't even need to get involved, it will just display your buffer as you pass it. Wayland itself doesn't assign any unit to a pixel.

"Wayland doesn't allow XWayland applications to change display resolution which could make running games slower as the compositor needs to upscale each game frame."

This is more of a problem with X11 since there is no "safe" API to change the display resolution there. Maybe someone could fix it but those apps really need to be ported to a different API.

"Also software upscaling might not be the best option."

Well most compositors are using hardware upscaling.

"Wayland doesn't allow applications to exclusively grab mouse/keyboard which is required for games and applications like VMs."

This is wrong, that's what the pointer constraints protocol is for.

"Applies to the X server/protocol as well: neither X.org, nor Wayland window managers offer a way to extend/modify window's title bars and File Open/Save dialogs."

This again has nothing to do with X.org or Wayland. The title bars and file dialogs are handled by the toolkit.

"there's no unified toolkit and no unified window manager (or protocol)."

So I think you could just replace this entire section with this statement and then go from there.

"Wayland compositors don't have a universal method of storing and configuring screen/session/keyboard/mouse settings."

This one's potentially a real problem, but again, it's not clear what "screen/session/keyboard/mouse settings" are. That could be thousands of things. And this also has nothing to do with Wayland because it's not a protocol for configuring settings.

"Currently there's no standard way to remap keys under Wayland."

See above, this has nothing to do with Wayland.

"Wayland applications cannot run without a Wayland compositor and in case it crashes, all the running apps die."

This statement is badly worded, technically this isn't true and it just needs to be implemented. Which is the real problem and is currently underway, see here: https://lists.freedesktop.org/archives/wayland-devel/2021-Au...

"An assortment of various other general and KDE specific issues."

These are valid issues, please make these issues more prominent.

And just a few more things.

The sections on video drivers, printers, Xorg and Linux kernel I think are mostly correct but I would say you probably want to remove any paragraphs that have no sources, or ones that have low quality sources. Random Slashdot and Reddit posts are not a reliable source, and it makes your article look sloppy. It's not responsible to put that information out there with nonexistient/bad sources, so probably take those paragraphs out and put them back in once reliable sources are located. It would be best to have a tracking issue or official statement from the developers for each of those problems.

I think this article is good for maybe a first draft but it needs a lot more editing to really be a powerful piece. You are clearly a smart and capable person and you can do much better than this. You may even want to take it down completely until everything is fixed. I had some other issues but I can't remember what they were, and in any case I think you have enough to work with here. So I'm looking forward to getting these corrected and seeing future revisions of this article. Just let me know if you need more help, thanks.

> you probably want to remove any paragraphs that have no sources, or ones that have low quality sources. Random Slashdot and Reddit posts are not a reliable source, and it makes your article look sloppy.

Since there are no official/factual sources but the sentiment is shared by lots of people, what would you do about that? To think about that, _nothing_ in the article has rock-solid proofs or sources. If we continue along those lines, it should simply not exist as it's so effing "bad" yet it's common knowledge that 1) APIs in Linux are abandoned all the time 2) There's nothing similar to Win32 3) There are tons of regressions all the time 4) HW support is spotty at best despite to the proclamations of the opposite 5) Lots of bugs in core applications e.g. DEs 5) Older applications are abandoned with no official way to run them - and people debate even these things based on anecdata, "Linux works for me which means it's perfect".

> It would be best to have a tracking issue or official statement from the developers for each of those problems.

No one cares. Most developers will oppose to this idea HARD. The list has existed since 2009. If anything has been solved on it it was due to developers being _personally_ annoyed by the said issues. Not because the Open Source community demanded it, or someone paid attention to bug reports, no, it was either developers addressing bugs which affected them or companies like Valve sponsoring the things they need (wine/Proton/DXVK).

> I think this article is good for maybe a first draft but it needs a lot more editing to really be a powerful piece.

Nah, just "misinformation". I will never forgive you for using this word, as I have a very strong attitude about people who use it willy-nilly to talk about anything they merely _disagree_ with.

While I'm totally OK with people having different opinions about something which has not been established or proven scientifically, there can be no opinions about something which has been conclusively proven, e.g. evolution, climate change, gravity, etc. etc. etc. You do not debate something which has long become the scientific fact. The author has a scientific background, opposes religions and loves science, so to think that he's willingly spreading misinformation is an insult of insane proportions.

> You may even want to take it down completely until everything is fixed.

Nah, your posts will be reviewed later, if there's truly valuable, meaning it's really good in terms of refuting the article head-on, it will be addressed just like it's been done before. If you find the article so repulsive, don't visit this abomination made of falsehoods. Sorry for kinda overreacting but you started off horribly.

Likely everything that goes under "I disagree because", "This happens because" followed by mostly inane "arguments" why Linux is "different" from well-established OS'es with good stable APIs and excellent documentation, will not be addressed because your opinion, while it's very deer to you, does _not_ solve or address the issues presented therein. Open Source fans have a long list of opinions about Open Source, almost none of which have helped address anything since 1991. Most open source fans love to think of themselves as selected few who are so great for choosing open source, yet absolute most of them haven't contributed in any way shape or form. The guy who wrote this ugly largly false article (according to you) has helped resolve hundreds of bugs including in the Linux kernel, GCC, Xorg and other core Linux projects. Applying the word "misinformation" to his work and efforts is terribly insincere, damning and extremely insulting.

> I had some other issues but I can't remember what they were, and in any case I think you have enough to work with here. So I'm looking forward to getting these corrected and seeing future revisions of this article. Just let me know if you need more help, thanks.

Slow and steady.

Wayland and Xorg sections have been reworked. Most of your Wayland concerns have been addressed (but not all).

If you still have other concerns and want to contribute, please do.

Only like I said before, let's talk about items which are _factually wrong right now_ as we speak.

> the portal API

I don't care about lightweight virtualization solutions, I care about native applications. If we start talking about virtualization, let's forget about Linux as a software platform altogether. Why would anyone want to run Linux if you can run Flatpaks under Windows, FreeBSD, etc. etc. etc. not to mention increased memory consumption, disk consumption, slower startup, and ... ISVs just don't like it. They like to compile native applications and be done with that like they do for Windows, MacOS, Android and iOS.

> - systray - There are implementations of this

Exactly, "implementations" - which means you cannot write an app which could run under all Wayland DEs and minimize to the systray. This is not an issue under Xorg Windows MacOS - only under Wayland.

> global keyboard shortcuts - It's not clear what this means. There were some proposals for this but none adequately explained the problem.

"proposals", exactly, no APIs, no standard way to make 'em work in all Wayland compositors.

> drag-n-drop

Removed.

> screenshotting, screencasting - This is in the portal API.

Again, Flatpak.

> UI rendering acceleration - Not sure what this means, Wayland clients can just use OpenGL or Vulkan.

It means under Windows you use Win32/D3D and as a programmer you don't have to think how to make your application run fast using system wide GPU hardware acceleration. Again, there's no common API underneath GTK, Qt, EFL which provides it which means a zoo of implementations, bugs and problems.

Still, you're right, it has nothing to do with Wayland, so moved to a new section and rephrased! Good point.

> I'm not sure what this means, applications can use an abstraction layer that deals with it for them.

Doesn't exist currently.

> Well no, if they're short on manpower they can just use an existing compositor such as Mir, wlroots, mutter, etc.

Their lead programmers think otherwise or they would have started using them a long time ago. Please argue with them. Is this an issue right now? YES!

> I'm not sure what can be done about this and this seems like complaining about an unsolveable problem, you will also have similar problems if you try to install Windows 11 or MacOS Monterey on an old PC and try to run modern apps on it.

Windows and X.org both can run on VESA compatible GPUs, that also means you have safe mode in case your graphical driver misbehaves. No such option with Wayland compositors. Is this an issue with Wayland itself? No. Is this a valid current issue? Yes.

> This is completely wrong, basically all applications and UI toolkits just use freetype.

Already mentioned that GTK Qt EFL based applications and Web browsers here on this PC render fonts differently despite all using FreeType. They don't just use FreeType, there's no such thing as "just using FreeType".

> This is also completely wrong, this is what fontconfig is for. It's not the best API though so this section could be rephrased as a review of freetype and fontconfig.

See the previous paragraph. I don't care why they look different and render fonts differently, but the issue remains.

> This is also completely wrong, I just checked Android and MacOS and there is no setting to change the font rendering. Not sure about Windows as I don't use it.

In Android all apps look exactly the same to me. In MacOS last time I used it all apps looked exactly the same. In Windows: classic Win32 applications all look the same: https://www.thewindowsclub.com/disable-font-smoothing-window...

> See what I said above, Wayland cannot implement this. If you wanted this you would have to build it on top of Wayland. Wayland is a API to use when implementing a toolkit.

> Toolkit fragmentation is a real thing which should be mentioned in this article, but see above again, this is not something that Wayland is ever going to be in any position to fix.

Addressed.

> Maybe someone could fix it but those apps really need to be ported to a different API.

Windows has moved from GDI to WDM 1/2/3 transparently and most old applications continue to work. Not a good argument, sorry.

> Well most compositors are using hardware upscaling.

Addressed/removed.

> This is wrong, that's what the pointer constraints protocol is for.

Can you provide more info please?

> This again has nothing to do with X.org or Wayland. The title bars and file dialogs are handled by the toolkit.

> So I think you could just replace this entire section with this statement and then go from there.

Moved/addressed.

> This one's potentially a real problem, but again, it's not clear what "screen/session/keyboard/mouse settings" are. That could be thousands of things. And this also has nothing to do with Wayland because it's not a protocol for configuring settings.

Does Wayland necessitate a compositor implementation for the user? Yes. Does the user want to configure each of dozen possible compositors? Very unlikely, they want to configure their graphics and related settings once and for all.

> See above, this has nothing to do with Wayland.

I've lost you here.

> This statement is badly worded, technically this isn't true and it just needs to be implemented.

Is this an issue RIGHT NOW? Yes.

> These are valid issues, please make these issues more prominent.

Copying and pasting is not my forte.

-------------------------------------------------------

P.S. I beg you - please stop talking about "this needs to be implemented", "this could work if", etc. - expressions like these unfortunately prove it right.

You started with "misinformation" yet the article describes the CURRENT ISSUES plaguing Linux on the desktop.

If you want to actually make a difference (about the article), start talking about _the status quo_.

Let's quickly disagree with you as well:

> It's deeply flawed in a lot of ways.

Again, a bloody insult. You carefully choose words to insult the author, are you like that IRL as well?

> I'm curious what's your experience with Docker?

It's basically a virtual machine, almost like WSL for Windows. I couldn't care less about it because it's useful for packaging server applications, not for end users or ISVs.

> Actually XWayland serves this purpose to keep old legacy apps running.

Tell me how I can run KDE2/KDE3 applications in my Fedora 35 or Ubuntu 20.10. Your "actually" is a MISINFORMATION when right now I cannot use most graphical applications just from 10 years ago.

> You don't need to port those to newer toolkits though, you can just ship the old version.

Will not work, Qt2/Qt3/GTK1 are not available under new Linux distros in any shape or form. "Too costly to maintain". GTK2 will be removed soon.

Linux proponents always like to talk about various "workarounds" which are just NOT THERE for the average user. Docker is one of them.

No one will ship anything because Linux distros don't have enough manpower to maintain currently available software.

> I'm trying to explain that some of these problems actually do have solutions

This is FALSE, period. Case in point: http://blogg.forteller.net/2016/humble-test/

Linux distros do not give a damn about any software which they don't include. They don't care about any forward or backward compatibility. Ubuntu just recently tried to remove all 32bit support only then they realized their Wine users would not appreciate it. Most don't care about any stability as they don't give you an option of using say e.g. the current stable kernel or LTS kernels. Period.

Again, the article is about _major current unresolved_ issues in Linux and it stands by it.

Your "solutions", "workarounds", etc. are worth nothing if the average user who's going to install Fedora 35 in two weeks will not be able to use any of them.

"Again, a bloody insult. You carefully choose words to insult the author, are you like that IRL as well?"

I'm not insulting the author, that is a statement about the article. If you are suggesting that everything you write has no flaws then I'm sure you understand how that's not a reasonable thing to say. I write plenty of stuff that has flaws. But I'm willing to field criticism and correct it if it's wrong, that's how we collaborate to make something that's twice as good because it combines both our knowledge. Please do not write these articles if you are not interested to field criticism, thanks. Also please avoid trying to second guess the technical direction of a project unless you are involved in its development in some way, otherwise more misinformation like this is very likely to occur.

"It's basically a virtual machine, almost like WSL for Windows. I couldn't care less about it because it's useful for packaging server applications, not for end users or ISVs."

I'm not sure I agree, I've seen many ISVs that ship docker containers, even for desktop apps. You may want to look more into this technology.

"Tell me how I can run KDE2/KDE3 applications in my Fedora 35 or Ubuntu 20.10. Your 'actually' is a MISINFORMATION when right now I cannot use most graphical applications just from 10 years ago."

Someone would have to package those applications for those systems. I could walk you through the process if you want help. It's not exactly an easy process and we will probably have to solve some issues but I think it's doable. The real problem here seems to be that those distros have stopped shipping those applications. Edit: Actually I think this would be perfect to do in a flatpak or snap, you really should consider asking someone to do that and making that more prominent in the article. I'd suggest that you avoid setting arbitrary time frames like "right now" or "in two weeks" or anything like that.

"Will not work, Qt2/Qt3/GTK1 are not available under new Linux distros in any shape or form. 'Too costly to maintain'. GTK2 will be removed soon. Linux proponents always like to talk about various 'workarounds' which are just NOT THERE for the average user. Docker is one of them."

So again that would be the real problem, those things are too costly to maintain and there is no manpower. All of that is true and you can just mention that in the article. Not sure what can be done about it, if you have some ideas I'd love to hear them.

"This is FALSE, period. Case in point: http://blogg.forteller.net/2016/humble-test/"

For whatever reason the spreadsheet doesn't load so I can't see what you're talking about or try to figure out what the problem is. But those are games so I doubt the problem has anything to do with X or Wayland or KDE or anything like that. It's possible it could be something simple, like a few missing libraries. But maybe not, I really don't know, and if you don't know either then I would suggest against saying that it's true or false. This is not something we can productively speculate about on a blog or social media, it needs to be investigated as an actual bug.

"Linux distros do not give a damn about any software which they don't include. They don't care about any forward or backward compatibility. Ubuntu just recently tried to remove all 32bit support only then they realized their Wine users would not appreciate it. Most don't care about any stability as they don't give you an option of using say e.g. the current stable kernel or LTS kernels. Period."

All of this is true but is again unrelated to the rest of the things you said. Please make the article more about this and what can be done about it, if you offer solutions on how to fix it that would be even better. Right now, the article offers very little in the way of constructive comments.

"Your 'solutions', 'workarounds', etc. are worth nothing if the average user who's going to install Fedora 35 in two weeks will not be able to use any of them. "

It would be nice if you could mention more examples of what this average user using Fedora is trying to do. It's not helpful to discuss theoretical users, a valid bug report needs concrete steps to determine what the problem actually is. I think that would also be a major problem with the article, most of the commentary is phrased as "X doesn't have Y" or "X doesn't let me do Y" when that's not really a meaningful thing to say in many cases. It's more helpful to phrase it as "I tried to do Y thing, the result was Z instead, here are the steps I took using software A B and C".

> 6. PulseAudio continues to be the answer to the question nobody asked.

Getting rid of PulseAudio though became a question to an answer nobody wanted.

Axing these *Kit MacOS wannabe software, and useless middleware is half the business these days if you want to make usable Linux desktop software.

This comment is really confusing to me. If you're trying to build a comprehensive desktop platform then you actually want more and more middleware. That's what entices app developers to the platform when they have a lot of structure they can work with, it's part of why Apple has been so successful at that.

Reply on news.ycombinator.com