Summary of all problems I have with the Linux Desktop - GitHub Gist

Programmer tools are even worse here. While on Windows most of your functionality will be accessible through GUI tools, on Linux often the best you have is some curses-based terminal tool. Bad tools are gonna be bad tools, but *good* GUI tools will destroy anything that is "good" by CLI standards. The general impression I get is that Linux users put up with subpar commandline development tools, while Windows devs get far-superior GUI tools. … Programmer tools: - Process Hacker: it's htop on steroids. - Debugging tools: the state of the art for Linux here is still GDB/LLDB or barely functional wrappers around it. WinDBG and many other tools like x64dbg are way ahead and have functional UIs. - Event Tracing for Windows (ETW) and accompanying tools like WPA - DependenciesGui/Process Hacker's peview.exe: I hate having to use a vague combination of `nm`, `ldd`, etc... with barely rememberable flags. These tools are much more well-organized and easier to use. … EGL is such a pile of garbage, I hate having to use it. Did they really need separate extensions for "the concept of GPUs exists", "you can enumerate GPUs", "you can get info about enumerated GPUs"? Complete nightmare to work with. And the extensions are inconsistently implemented and there's no writing on what is available where. DXGI just fucking works and does all of this in a clear API doc on docs.microsoft.com with a 100% guaranteed of what APIs will be available where. … It's a fractured nightmare of extensions and protocols. The whole standards process is slow as molasses and basic functionality gets bikeshedded about for years. Some of the hilarious^4^ bullshit that comes out of this. I'm sure there's going to be more: ... ## ELF Linking Troubles Linux uses ELF for binaries and dynamic linking. Unlike Windows' PE32, ELF does not keep track of which symbols are imported from which modules. That means that unlike on Windows, where `foo.dll` imports `memcpy` from `VCRUNTIME140.dll` or what have you, on Linux `libfoo.so` depends on `libc.so` and needs `memcpy` from anywhere. Symbols on Linux are process-global because of how the linkage model works, and this is a *massive* nightmare for forwards compatibility if you are shipping applications. Example down below. … Combining these into one library is massively problematic, because you cannot load multiple `libc`s into a process (due to the aforementioned ELF-sucks linking problems), but you *need* to be able to do that for forward and backwards compatibility, versioning, and encapsulation of dependencies (since `libc` is an implementation detail of your C compiler, NOT a system API). … ### Glibc 2.35 glibc 2.35 (feb 2022) shipped a new dependency sorter or whatever. It is (at the time of writing) extremely buggy causing anything from angry valgrind, assert aborts, erroneous failing library loading behavior, to straight segfaults. All in `ld.so`. I had to spend a whole weekend debugging this, and as far as I could tell I was the first to find this. Then after another week of Linux users crashing in various new scenarios I said "fuck it" and passed a workaround env var from the launcher. Look, bugs happen, but this is literally the lowest and most fundamental component in the system above the kernel. This leaves an *extremely* sour taste in my mouth, you know? … **Somebody at Canonical thought twice about dropping OpenSSL 1.1, and decided that yes, Ubuntu 22.04 should just shit all over backwards compatibility to save some megabytes.** When one of the biggest Linux distros, often considered a "baseline" for various things, just completely disregards basic principles like "a program compiled a year ago should keep working" **I *genuinely* do not know what to tell you except that there is no fucking hope for this platform in its current governance.^5^** ## Targeting Linux As A Developer "Linux is better for developers" is a common mantra. What is commonly left out is that it's better for developers to *work on*. Not for developers to **target**. I can say with massive certainty that Linux is far more effort to target, all while being a SIGNIFICANTLY lower market share. The reasons why are basically explained at length in points above, but seriously. Linux breaks more and has higher maintenance effort, while also having significantly worse tech. **If I only targeted a single OS, a Linux-exclusive version would *still* be much more effort to develop and maintain than a Windows-exclusive version.** Now consider that Linux is a tiny marketshare compared to Windows and run the numbers on that. This is **not for lack of familiarity**, but simply due to **worse underlying technology**.