3 ms·

I'm not familiar with Linux that much so I'm curious, do you have a couple examples of errors in the piece?

sho_hn 5y ago
In general, the article has an odd mix of "this sucks about computers in general right now" and "this sucks about Linux specifically and with better alternatives available" points, and I think is worse for not picking a consistent direction. It feels a bit like a collection of claims found on forum threads over the years, by authors with differing levels of expertise and at different points in the timeline. For example this point: > Traditional Linux/Unix (ext4/ reiser/ xfs/ jfs/ btrfs/etc.) filesystems can be problematic when being used on mass media storage. - This is not equally true for all of the file systems named and for all of mass storage media. For quite a few of these combinations, Linux actually has the best solution available. Some of these file systems are also very niche and a general user will never even encounter them. Standard systems default to the most generally useful ones. - I can take a guess that this is probably thinking of things like inadequate TRIM support and then may be outdated, and also no different from highly complex, often device vendor-specific scenario trees on the competing systems. - In the combinations where it is true, it is generally also true for broadly used competing filesystems like NTFS - and for the same reasons (lack of wear leveling, etc.). In general, the points that focus on general user experience more broadly and are not Linux-specific tend toward being the better ones in the piece. The more technical and Linux-specific it gets, the worse: > Wayland doesn't provide multiple APIs for various crucial desktop features (global keyboard shortcuts, drag-n-drop, systray, screenshotting, screencasting, UI rendering acceleration, and others) 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. It's a conceptual mistake to assume that Wayland (an IPC tech stack and protocol to regulate exchange of pixel buffers between processes and arbitrate shared access to i/o hardware w/ event routing, with facilities to add further protocols) should be responsible to provide all of the listed features. The equivalent features in other systems are usually provided by seperate APIs as well. It's also mistaken to assume that just because Wayland does not provide a feature, a standard does not exist that fills the role, making it a non-problem. In Linux desktop architecture Wayland intentionally specializes in the functions listed above, while many other IPC problems are addressed through D-Bus and standardized D-Bus protocols. An example of this from the list would be the systray. Some other entries in the list are just outdated and have been addressed by later work in the Wayland protocol family. > Wayland doesn't provide a universal basic window compositor thus each desktop environment has to reinvent the wheel In practice the Wayland implementation landscape has greatly consolidated. There are projects providing Wayland implementations as middleware used by many of the smaller HMIs, e.g. wlroots. Having a standard protocol spec independent from implementation does not mean implementations can't be reused, that's just orthogonal. > 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. Nothing in Wayland requires specific hardware. > 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. This is correct as far as the first claim goes, but then goes off the rails when describing the competing systems and in painting it as a problem. First of, font rasterization and text shaping in Linux has long since standardized, with all major app stacks consolidating on the freetype and harfbuzz libraries. Those two are used in the same roles on Android. On Windows and MacOS, modern APIs for this are likewise no longer part of the display server/windowing system, and often there are actually multiple APIs for the job supporting different features. Windows, say, added Direct2D in addition to the existing GDI at some point. Plenty of Windows apps also render through freetype/harfbuzz these days, bundled by the cross-platform UI libs they use in lieu of Microsoft APIs. I.e. the technical mistake here is assuming Wayland is somehow unique here and not just reflecting broad tech trends. In some cases the reality on Linux is actually more consolidated than elsewhere, and this is one: There is no meaningful competition to the freetype+harfbuzz stack. This inaccuracy is where it gets really complicated: If you know to recognize it as such, this talking point originates in internal debates in the Linux community about the X to Wayland transition, the logic of the change-averse going "X had standard fonts and Wayland does not, so it's bad!" - even though that's already wrong, because while X had standard fonts at inception, they stopped being used by apps decades ago. And then it's backed up by an incorrect comparison to the other systems, because the original author of the claim, a Linux user, didn't know better. This sort of thing makes this list hard to evaluate by users of other systems - the content is often sifted from a strange place. A lot of this reads like excerpts from a flame war on fictional Star Trek technology. Phasers are bad because tachyon couplings suck vs. Klingon disruptor grids! > Wayland does not provide a basic universal unified graphical toolkit/API (and Wayland developers will not implement it) 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. The API scope of Win32 falls far short of what a modern UI lib provides, and Microsoft has many different generations and flavors of UI libs on top of Win32 (MFC, WinForms ... Maui is the latest one I think?). Many Windows apps are in fact written using non-native toolkits such as Qt and Electron as well these days. This is a variation/continuation of the earlier sort of inaccuracy. Broadly speaking, windowing systems never particularly favored server-side rendering or server-side toolkits, with Wayland's predecessor, the X Windowing System, just a short-lived odd one out - but even in X-based desktops, apps converted to client-side rasterization using UI toolkit stacks long, long before Wayland came about. Disagreeing with these directions is fine, but it's disagreement with much of an entire industry and spanning many systems. The rest of the Wayland section is largely the same - a weird mix of incorrect, misattributed and outdated.
- itvision 5y ago
  > This is not equally true for all of the file systems named and for all of mass storage media. For quite a few of these combinations, Linux actually has the best solution available. Some of these file systems are also very niche and a general user will never even encounter them. Standard systems default to the most generally useful ones. I've stopped reading here - you did *not* follow the corresponding bug report and you are trying to refute something which you took 0 seconds to understand and as a result your comments to this issue are 100% worthless and equally irrelevant. Good luck and have fun. Maybe next time you could be a little bit more attentive and inquiring.

In general, the article has an odd mix of "this sucks about computers in general right now" and "this sucks about Linux specifically and with better alternatives available" points, and I think is worse for not picking a consistent direction. It feels a bit like a collection of claims found on forum threads over the years, by authors with differing levels of expertise and at different points in the timeline. For example this point: > Traditional Linux/Unix (ext4/ reiser/ xfs/ jfs/ btrfs/etc.) filesystems can be problematic when being used on mass media storage. - This is not equally true for all of the file systems named and for all of mass storage media. For quite a few of these combinations, Linux actually has the best solution available. Some of these file systems are also very niche and a general user will never even encounter them. Standard systems default to the most generally useful ones. - I can take a guess that this is probably thinking of things like inadequate TRIM support and then may be outdated, and also no different from highly complex, often device vendor-specific scenario trees on the competing systems. - In the combinations where it is true, it is generally also true for broadly used competing filesystems like NTFS - and for the same reasons (lack of wear leveling, etc.). In general, the points that focus on general user experience more broadly and are not Linux-specific tend toward being the better ones in the piece. The more technical and Linux-specific it gets, the worse: > Wayland doesn't provide multiple APIs for various crucial desktop features (global keyboard shortcuts, drag-n-drop, systray, screenshotting, screencasting, UI rendering acceleration, and others) 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. It's a conceptual mistake to assume that Wayland (an IPC tech stack and protocol to regulate exchange of pixel buffers between processes and arbitrate shared access to i/o hardware w/ event routing, with facilities to add further protocols) should be responsible to provide all of the listed features. The equivalent features in other systems are usually provided by seperate APIs as well. It's also mistaken to assume that just because Wayland does not provide a feature, a standard does not exist that fills the role, making it a non-problem. In Linux desktop architecture Wayland intentionally specializes in the functions listed above, while many other IPC problems are addressed through D-Bus and standardized D-Bus protocols. An example of this from the list would be the systray. Some other entries in the list are just outdated and have been addressed by later work in the Wayland protocol family. > Wayland doesn't provide a universal basic window compositor thus each desktop environment has to reinvent the wheel In practice the Wayland implementation landscape has greatly consolidated. There are projects providing Wayland implementations as middleware used by many of the smaller HMIs, e.g. wlroots. Having a standard protocol spec independent from implementation does not mean implementations can't be reused, that's just orthogonal. > 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. Nothing in Wayland requires specific hardware. > 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. This is correct as far as the first claim goes, but then goes off the rails when describing the competing systems and in painting it as a problem. First of, font rasterization and text shaping in Linux has long since standardized, with all major app stacks consolidating on the freetype and harfbuzz libraries. Those two are used in the same roles on Android. On Windows and MacOS, modern APIs for this are likewise no longer part of the display server/windowing system, and often there are actually multiple APIs for the job supporting different features. Windows, say, added Direct2D in addition to the existing GDI at some point. Plenty of Windows apps also render through freetype/harfbuzz these days, bundled by the cross-platform UI libs they use in lieu of Microsoft APIs. I.e. the technical mistake here is assuming Wayland is somehow unique here and not just reflecting broad tech trends. In some cases the reality on Linux is actually more consolidated than elsewhere, and this is one: There is no meaningful competition to the freetype+harfbuzz stack. This inaccuracy is where it gets really complicated: If you know to recognize it as such, this talking point originates in internal debates in the Linux community about the X to Wayland transition, the logic of the change-averse going "X had standard fonts and Wayland does not, so it's bad!" - even though that's already wrong, because while X had standard fonts at inception, they stopped being used by apps decades ago. And then it's backed up by an incorrect comparison to the other systems, because the original author of the claim, a Linux user, didn't know better. This sort of thing makes this list hard to evaluate by users of other systems - the content is often sifted from a strange place. A lot of this reads like excerpts from a flame war on fictional Star Trek technology. Phasers are bad because tachyon couplings suck vs. Klingon disruptor grids! > Wayland does not provide a basic universal unified graphical toolkit/API (and Wayland developers will not implement it) 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. The API scope of Win32 falls far short of what a modern UI lib provides, and Microsoft has many different generations and flavors of UI libs on top of Win32 (MFC, WinForms ... Maui is the latest one I think?). Many Windows apps are in fact written using non-native toolkits such as Qt and Electron as well these days. This is a variation/continuation of the earlier sort of inaccuracy. Broadly speaking, windowing systems never particularly favored server-side rendering or server-side toolkits, with Wayland's predecessor, the X Windowing System, just a short-lived odd one out - but even in X-based desktops, apps converted to client-side rasterization using UI toolkit stacks long, long before Wayland came about. Disagreeing with these directions is fine, but it's disagreement with much of an entire industry and spanning many systems. The rest of the Wayland section is largely the same - a weird mix of incorrect, misattributed and outdated.

itvision 5y ago
> This is not equally true for all of the file systems named and for all of mass storage media. For quite a few of these combinations, Linux actually has the best solution available. Some of these file systems are also very niche and a general user will never even encounter them. Standard systems default to the most generally useful ones. I've stopped reading here - you did *not* follow the corresponding bug report and you are trying to refute something which you took 0 seconds to understand and as a result your comments to this issue are 100% worthless and equally irrelevant. Good luck and have fun. Maybe next time you could be a little bit more attentive and inquiring.