19 ms·

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,

by cletus 5y ago

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.

baybal2 5y ago
> 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.
- md8z 5y ago
  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.
PaulDavisThe1st 5y ago
> 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.
- melony 5y ago
  What about PipeWire?
  - sho_hn 5y ago
    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.
  - BiteCode_dev 5y ago
    When Pulse audio came around, pipewire didn't exist. In fact, the infra required to build it didn't either.
- Spivak 5y ago
  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.
sho_hn 5y ago
> 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.
- md8z 5y ago
  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.
- itvision 5y ago
  > 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 https://gitlab.freedesktop.org/wayland/wayland/-/issues/233
  - sho_hn 5y ago
    I posted more technical comments elsewhere in the thread.
yewenjie 5y ago
> 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?
- md8z 5y ago
  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.
  - itvision 5y ago
    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.
    - md8z 5y ago
      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.
CountSessine 5y ago
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.
- mijoharas 5y ago
  > 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".
- sprash 5y ago
  > 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.
joe_the_user 5y ago
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).
- heavyset_go 5y ago
  > 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 https://wiki.archlinux.org/title/Hardware_video_acceleration

by cletus 5y ago

baybal2 5y ago

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

md8z 5y ago
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.

PaulDavisThe1st 5y ago

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

melony 5y ago
What about PipeWire?
- sho_hn 5y ago
  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.
- BiteCode_dev 5y ago
  When Pulse audio came around, pipewire didn't exist. In fact, the infra required to build it didn't either.
Spivak 5y ago
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.

sho_hn 5y ago

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

md8z 5y ago
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.
itvision 5y ago
> 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 https://gitlab.freedesktop.org/wayland/wayland/-/issues/233
- sho_hn 5y ago
  I posted more technical comments elsewhere in the thread.

yewenjie 5y ago

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

md8z 5y ago
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.
- itvision 5y ago
  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.
  - md8z 5y ago
    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.

CountSessine 5y ago

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.

mijoharas 5y ago
> 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".
sprash 5y ago
> 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.

joe_the_user 5y ago

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

heavyset_go 5y ago
> 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 https://wiki.archlinux.org/title/Hardware_video_acceleration