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.
-
@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....
-
@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 my experience of windows may not be representative, everything I actually _shipped_ there had a hand-written InstallShield wizard or NSIS installer and like 5,000,000 lines of in-house C++ so "package management" of "upstream dependencies" was not really a thing
-
@xgranade my experience of windows may not be representative, everything I actually _shipped_ there had a hand-written InstallShield wizard or NSIS installer and like 5,000,000 lines of in-house C++ so "package management" of "upstream dependencies" was not really a thing
@glyph Yeah, makes sense. With enough violence, you can make Windows work just fine. It just takes a startling amount to get there...
-
@glyph Yeah, makes sense. With enough violence, you can make Windows work just fine. It just takes a startling amount to get there...
@xgranade I guess another way of putting it is that getting something to work in the first place on Windows is a shocking amount of misery; there's a strong cultural assumption that you're building the universe from scratch and if you're not you're kind of on your own. whereas on Linux it is *deceptively* easy to get something kinda working on your own computer which will never work on a second one
-
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 This is partly why I often joke, there are a lot more ‘religious’ arguments than ‘technical’ arguments in tech (yes, I know there *can* be objective, technical arguments, but often feels people argue their religion as ‘objective’ XD)
-
@cthos @miss_rodent I think I do have some nuanced structural critique of flatpak that I sadly don’t have time to get into right now, but if I am being honest most of my systems have a weird quirk where user data lives outside home directories on external media and this causes flatpak’s weird slightly-wrong but makes-things-mostly-work heuristics absolutely violently explode in ways which cause huge issues that contributes to an overall *immediate* negative impression
@glyph @cthos @miss_rodent i think flatpak (and AppImage, not snap) are the closest thing to standardization you are going to be able to convince linux devs to make. The desktop linux platform already has a lot which is close across distros, all the large ones use systemd and pipewire, mostly use Wayland graphics and KDE or GNOME, or a skin on top of those. GNOME especially expects a system to be set up in a more standard fashion, so distros have less flexability to pointlessly diverge in ways that break apps. Most gui apps are possible to flatpak, and run on almost any distro that is near standard (sorry for your systems which youve made difficult to support by accidently working at cross purposes to flatpak assumptions, but its hard to maintain compatibility when every computer-toucher wants to be their own ISV). Unfortunately its going to take a long time to convince Shuttleworth and Canonical that they are wasting everyones time with snaps, but Ubuntu isnt as popular as it once was. Its also going to take a long time to convince Debian, Fedora or Arch packagers that they should stop and target flatpak on the Freedesktop runtimes instead. There are a lot of devs who are personally offended by inefficiencies in the design of flatpak that leads to vendoring of libraries and duplication between runtimes, but i dont see any other way, the distro approach of deduplicating libraries creates bugs of its own and is unsustainable labor, the improvements to software build and integration that distro feedback brings to gui devs is probably not worth the effort it takes.
I dont think you are going to have much luck convincing volunteers to not work on what makes them happy, or for any existing distro to jump off a cliff for the good of the community, but you can make them irrelevant by inventing something better that the original gui dev community likes and can make work themselves. You can ask them to join your project if it looks successful and fun
-
@matt @cthos @miss_rodent flatpak does not address the deficiencies or the expense of interacting with a zillion different compositors, or for that matter different audio systems or GPS daemons. the kinds of apps that need to interact with the platform need an API shaped in terms of d-bus endpoints, and the problem that flatpak addresses is one of .so files. flatpak also requires manual management of filesystem permissions, which means apps are just slightly dysfunctional
@glyph i could see an effort around freedesktop and flatpak to define what dbus apis are expected to be provided by the distro/desktop to have full compatibility, and what might be outside those expectations. I dont think it makes sense to have flatpaks that only work on some distros/desktops because they depend on unique components, the baseline for running flatpak needs to declare what is required and provide reasonable errors if am amateur ISV tries to run it somehere impoverished
-
@cthos @matt @miss_rodent sorry I do not mean to be mean about this. but it seems like they’ve done some really good work here and are trying to snatch defeat from the jaws of victory. I have *heard* about bazzite and bluefin. at some length. i knew they were immutable distros. I had considered installing them. I did not even realize they were largely compatible let alone more or less the same thing
@glyph i think this is irreconcilable though because the software and out of the box config of an immutable distro is fixed, so you need to have different complete builds if you want different stuff in the base system. The compatability for apps is high though because the OS maker is pulling all the components out of the same pool. Like i dont think you want your general purpose desktop to boot into Steam, like Bazzite handheld builds do, but any of the flatpak apps will run just the same on all of the family, like the choice of specific flavor is driven by the hardware and purpose of the computer, but they can all run the same stuff outside the base os
