I'm mad about linux distros again today and I think I am realizing why this is so hard for me to write about systemically: I have a software engineer brain and so I try to model the various problems as technical problems.
-
@miss_rodent but nothing is hostile to corporate interest here; the corporate interest can quite happily co-opt all the labor in any case; SteamOS has already proved that concept. You can either accept the corporate takeover *by* corporate leadership, or you can consolidate into an organization that protects user agency.
The logic here is "we shouldn't have a union, because that's just the same as a corporation". I specifically called out "volunteer-driven" distros (Debian, Fedora(ish), Arch)
You call out to the distributions to abolish themselves?
To bring up the topic: Systemd is exactly what @glyph is looking for „Unifying pointless differences between distributions“ https://unixdigest.com/includes/files/gnomeasia2014.pdf , brought to you by the systemd-critic article https://unixdigest.com/articles/the-real-motivation-behind-systemd.html but I verified the source on the conference homepage.
It seems to help PostmarketOS which is a systemd-only distribution which supports lots of exotic devices.
Unification seems to be the actual point which commercial cooperations like, for which reason the systemd lead developer was paid by Microsoft for 2022 to 2026.
„Never specific, always generic“ isnt necessarily environment-friendly, though.
I for my part prefer systemd free operating systems which differ on a wide variety of concepts.
-
@matt @cthos @miss_rodent I think *most* telling though, the thing that is downstream from all the various subtle upstream problems with flatpak, is why does the platform still have “native” apps and “flatpak” apps as separate categories? is there an OS yet which is ONLY a runtime for flatpaks and doesn’t have a privileged class of “good” apps which don’t have to live in flatpak jail?
@glyph @cthos @miss_rodent You might be interested in this blog post from a Fedora developer which, among other things, argues that Fedora should move away from packaging apps as RPMs: https://blogs.gnome.org/mcatanzaro/2025/07/21/fedora-must-carefully-embrace-flathub/
-
@glyph @cthos @miss_rodent You might be interested in this blog post from a Fedora developer which, among other things, argues that Fedora should move away from packaging apps as RPMs: https://blogs.gnome.org/mcatanzaro/2025/07/21/fedora-must-carefully-embrace-flathub/
@matt @cthos @miss_rodent thanks, this is great!
-
In short, all the volunteer-based distributions need to have a gigantic conference where they all come together and *agree to stop working on about 99% of them*, to pool efforts to make a real Linux platform. A lot of people will need to put their egos aside and decide to acquiesce to solutions they believe to be technically inferior, in order to be able to address the diffusion of labor into pointlessly recreating basically the same toolchain a thousand times.
@glyph@mastodon.social Linux International?
But judging by the the propensity of FOSS developers to disagree, I can imagine an schism forming just like the Marx/Bakunin schism of the First International. -
In short, all the volunteer-based distributions need to have a gigantic conference where they all come together and *agree to stop working on about 99% of them*, to pool efforts to make a real Linux platform. A lot of people will need to put their egos aside and decide to acquiesce to solutions they believe to be technically inferior, in order to be able to address the diffusion of labor into pointlessly recreating basically the same toolchain a thousand times.
@glyph I have already facilitated something like this for a single very small scoped Python/cross-distro problem and it still took us 2 fucking years to fix, at the scope of an entire distro I think it's simply not possible
-
@glyph I have already facilitated something like this for a single very small scoped Python/cross-distro problem and it still took us 2 fucking years to fix, at the scope of an entire distro I think it's simply not possible
@ehashman that's backwards from the usual logic of the industry. you took 2 years to fix it, so the next one will only take 6 months to fix, and within 5 years we'll be fixing 6-7 issues every microsecond. easy!
(I am constantly hearing in my head ThoughtSlime's iconic line, "And if that trend continues indefinitely, as indeed all trends do" <https://youtu.be/Ttb2BdExy38?si=omSvDlTgH0y6UeJY&t=62> )
-
Fixing the problem involves driving a truck through that load-bearing "to some extent". Doing a big ugly multi-party negotiation to figure out how we can EOL Qt, to replace it with Gtk everywhere, and get all the Gtk devs on board with being *extremely* nice to the Qt people as we sunset their work. (Did you feel a little thrill because I picked Gtk instead of Qt? Well, I flipped a coin. Imagine I said Qt wins instead of Gtk. You're gonna be that mad about *big* parts of this, no matter what.)
@glyph I mean, yes, but should I write my Windows app to use GDI, GDI+, WinForms, WPF, UWP, or whatever they're doing nowadays?
That only works on the corporate side because they throw oodles of money at propping up that hodgepodge of manager-getting-promotion frameworks, but yeah... that doesn't work so well when volunteer labor is fungible. Imitating corporate dysfunction without corporate resources is... suboptimal.
-
@ehashman that's backwards from the usual logic of the industry. you took 2 years to fix it, so the next one will only take 6 months to fix, and within 5 years we'll be fixing 6-7 issues every microsecond. easy!
(I am constantly hearing in my head ThoughtSlime's iconic line, "And if that trend continues indefinitely, as indeed all trends do" <https://youtu.be/Ttb2BdExy38?si=omSvDlTgH0y6UeJY&t=62> )
@glyph it doesn't follow that work with a dozen people took X time so work with 6000 people won't necessarily take 500X time, but my estimate is approximately no amount of time or funding would fix this (remember LSB?)
-
@glyph I mean, yes, but should I write my Windows app to use GDI, GDI+, WinForms, WPF, UWP, or whatever they're doing nowadays?
That only works on the corporate side because they throw oodles of money at propping up that hodgepodge of manager-getting-promotion frameworks, but yeah... that doesn't work so well when volunteer labor is fungible. Imitating corporate dysfunction without corporate resources is... suboptimal.
@xgranade on Linux this stuff matters because the user might be making choices about which ones are available. your package might arrive on a system without GTK, or without configuration for GTK. arguably on Windows making this choice is still a drain on your time and resources, but whichever choice you make the app still *works* and Microsoft has cleverly conditioned their user base to not care at all about how anything looks by using 15 different toolkits internally
-
@glyph it doesn't follow that work with a dozen people took X time so work with 6000 people won't necessarily take 500X time, but my estimate is approximately no amount of time or funding would fix this (remember LSB?)
@glyph if someone wants to pull together the funding and a proposal though, hit me up lol
-
@xgranade on Linux this stuff matters because the user might be making choices about which ones are available. your package might arrive on a system without GTK, or without configuration for GTK. arguably on Windows making this choice is still a drain on your time and resources, but whichever choice you make the app still *works* and Microsoft has cleverly conditioned their user base to not care at all about how anything looks by using 15 different toolkits internally
@glyph I mean, yes, right up until an application doesn't work, and then "computers are just like that."
The number of times .NET Framework is the wrong version, or that .NET is missing entirely (Windows ships with .NET Framework, not with .NET, same problem as Windows PowerShell vs PowerShell and for the same reasons), or it's the wrong version of the C++ runtime, or or or.
-
@xgranade on Linux this stuff matters because the user might be making choices about which ones are available. your package might arrive on a system without GTK, or without configuration for GTK. arguably on Windows making this choice is still a drain on your time and resources, but whichever choice you make the app still *works* and Microsoft has cleverly conditioned their user base to not care at all about how anything looks by using 15 different toolkits internally
@xgranade but, less tongue-in-cheek; it is *about* as miserable to develop for Windows as it is to develop for Linux, the difference is that developing for Windows gets you 7000% as many users so the time investment seems bad. it's a lot more pleasant to develop for macOS (only *3* first-party frameworks now, Cocoa, Catalyst, or SwiftUI! Way less than Linux or Windows, that's apparently the metric!
) and it's still 1200% more users, so you keep a similar ratio -
@glyph I mean, yes, right up until an application doesn't work, and then "computers are just like that."
The number of times .NET Framework is the wrong version, or that .NET is missing entirely (Windows ships with .NET Framework, not with .NET, same problem as Windows PowerShell vs PowerShell and for the same reasons), or it's the wrong version of the C++ runtime, or or or.
@glyph I've literally run into cases where a user-facing application fails entirely if Visual Studio is installed on the same computer.
UCRT helps somewhat, but not nearly enough. There's a reason why I not infrequently find that running Windows apps on Linux in separate Wine prefixes is more stable than running them on Windows.
-
@glyph I mean, yes, right up until an application doesn't work, and then "computers are just like that."
The number of times .NET Framework is the wrong version, or that .NET is missing entirely (Windows ships with .NET Framework, not with .NET, same problem as Windows PowerShell vs PowerShell and for the same reasons), or it's the wrong version of the C++ runtime, or or or.
@xgranade yeah windows is weird because you're really supposed to ship Windows to your Windows users as well, right? what if static linking, but in hell
-
@xgranade but, less tongue-in-cheek; it is *about* as miserable to develop for Windows as it is to develop for Linux, the difference is that developing for Windows gets you 7000% as many users so the time investment seems bad. it's a lot more pleasant to develop for macOS (only *3* first-party frameworks now, Cocoa, Catalyst, or SwiftUI! Way less than Linux or Windows, that's apparently the metric!
) and it's still 1200% more users, so you keep a similar ratio@xgranade although wow hats off to "Unknown", the real breakout star of the war for desktop OS marketshare https://gs.statcounter.com/os-market-share/desktop/worldwide/
are a lot of people running the QNX desktop now, or
-
@xgranade yeah windows is weird because you're really supposed to ship Windows to your Windows users as well, right? what if static linking, but in hell
@glyph .NET (not .NET Framework, because branding) is basically nodejs in terms of the static linking approach to packaging, yeah. You have to bring all your dependencies with you. This is a good idea, actually, for anyone used to Windows development back when you had to rely on a single fucking thing in C:\windows\system32. I have spent more hours in Dependency Walker than I ever care to admit.
-
@glyph .NET (not .NET Framework, because branding) is basically nodejs in terms of the static linking approach to packaging, yeah. You have to bring all your dependencies with you. This is a good idea, actually, for anyone used to Windows development back when you had to rely on a single fucking thing in C:\windows\system32. I have spent more hours in Dependency Walker than I ever care to admit.
@xgranade yeah like, real talk, windows is coasting along around 10% by their extremely hardcore compatibility for a VERY small core, which makes it possible for highly conscientious developers to get software to be extremely reliable *IF* they care (and to rack up lots of billable support hours _eventually_ fixing the problems, if they don't) and 90% by their anticompetitive effort to be installed everywhere
-
@xgranade yeah like, real talk, windows is coasting along around 10% by their extremely hardcore compatibility for a VERY small core, which makes it possible for highly conscientious developers to get software to be extremely reliable *IF* they care (and to rack up lots of billable support hours _eventually_ fixing the problems, if they don't) and 90% by their anticompetitive effort to be installed everywhere
@xgranade and even then, desktop Windows software got absolutely bodied by web apps specifically because of this misery. there's a reason that "desktop apps" more or less means either "games" or "legacy regulatory requirement" in that world
-
@glyph .NET (not .NET Framework, because branding) is basically nodejs in terms of the static linking approach to packaging, yeah. You have to bring all your dependencies with you. This is a good idea, actually, for anyone used to Windows development back when you had to rely on a single fucking thing in C:\windows\system32. I have spent more hours in Dependency Walker than I ever care to admit.
@glyph I can't address macOS since I'm again entirely outside of that world, but IME, no matter how painful Linux dev is, it pales in comparison to Windows dev as soon as one single line of native code enters the chat.
Like, .NET applications that rely exclusively on .NET packages and so forth work *fine*. It's really once you try to interact with native code, appx publishing, or anything other than "run this NuGet command" that things break.
-
@xgranade and even then, desktop Windows software got absolutely bodied by web apps specifically because of this misery. there's a reason that "desktop apps" more or less means either "games" or "legacy regulatory requirement" in that world
@glyph Yeah, but you talk about shipping Windows with Windows, though....
