GlyphI'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. And there are numerous technical problems to think about (platform interfaces, ABI boundaries, release management, etc) but the core problem is a social one, which requires a social solution.
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.
This is a big problem because labor is not fungible and the reason that a lot of these people got involved in distro development *in the first place* is that those sorts of problems and systems are interesting and engaging for them to work on. They all want to have control over a packaging tool, or a build farm, or whatever. The redundancy is a huge problem and a huge waste but it's also the engine that powers the whole thing, to some extent.
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.)
mcSlibinas@glyph so, to invent linux need to invent society first?
Cassandra is only carbon now@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 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.
Matt Campbell@xgranade @glyph On the CRT (C/C++ runtime) issue, Microsoft's "Hybrid CRT" technique (https://github.com/microsoft/WindowsAppSDK/blob/main/docs/Coding-Guidelines/HybridCRT.md) needs to be better known, and supported by open-source tools (Python, Rust). Assuming you're not still targeting Windows 8.1 or below, it does just enough static linking, while taking advantage of the DLLs that are always available on Windows 10+.
@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.
@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 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
@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
@xgranade @glyph Forgive me if I come off as a Rust fanboy, but Rust is pretty good about making it easy to ship a self-contained native executable on Windows. They just need to make the hybrid CRT (see my other post) the default. I guess I should open an issue and then a PR.
That also means it's easy to use Rust to build a native module in a larger Python or Node.js app. (Not sure about .NET; last time I tried, you were on your own for implementing and consuming a C API via P/Invoke.)
@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
Stephen Rosen@glyph there are problems, but I don't see the redundant efforts of various duplicated components as a core issue.
A lot of Linux is about avoiding monoculture. vim *and* emacs. Snap *and* flatpack.
It's something that emerges naturally from people trying to create a hackable platform.
I think we'd be better off if people shared ideas and infrastructure without denigrating one another's work. We should have both Qt and Gtk so that they can cross pollinate.
@glyph To be clear, I agree with your complaint, as I read it. It's the twofold
- you aren't providing something non-developers can use
- you aren't providing something developers can easily target
Canonical is trying to make Ubuntu the desktop distro. And tons of software ships as .debs, whether or not that's really the best choice.
The wild English garden of Linux can continue to exist, alongside a TiVo-ized, consumer oriented Ubuntu. But if you lose the anarchy, it's not Linux.
Irenes (many)@glyph yes, this all sounds true. it's gonna be difficult, but we've got to.
Ivan Sagalaev 
@glyph mmm, not just because of "interesting and engaging problems", but many people came into it specifically because of their egos: *my* distro will be better (and I will be famous). Basically, you're advocating for abandoning the core motivation (or one of the main ones anyway) for tinkering around the free code.
@glyph my thinking was always that it's fine to have a gazillion distributions, but I'd prefer one of them to clearly win. And for that they need to care about the whole stack: from hardware to apps (like Apple). Canonical was in this position, but Mark Shuttleworth very clearly said they were not interested in hardware. @elementary does seem to care about the whole stack, but they lack resources. System76 does hardware + desktop, but not the apps…
@isagalaev @elementary I mean *ideally* we'd have a healthy fringe of biodiversity around the edges where users could move to a new platform provider with relatively low friction to pick a new "winner" if the biggest one started to enshittify the ecosystem, so a bunch of different free operating systems that are friendly to ISVs and low-effort to port to, but that does not seem to be what's happening
elementary@glyph this is one of the problems solved by flatpak. We now have both multiple flatpak platforms and multiple flatpak-based app stores that developers can target while the apps themselves can be used on any Linux desktop. Portals provide a predictable and cross desktop set of APIs and are defined collaboratively in freedesktop.org
Niels Abildgaard@glyph Why is the redundancy a huge problem? I think I have basically the opposite take, but would like to understand your reasoning!
Cassandrich@glyph Completely disagree. The fact that we don't have a "real Linux platform" is our strength. It's non-monoculture. It's why software has to be written to follow specifications rather than treating an implementation as the specification. It's why the BSDs etc. are still viable too - software that's portable to different Linuxes is usually also portable to them. It's why we're not stuck listening to the worst people forcing their ideas on us, but can make something different that still runs basically all the same software when you want it to.
RE: https://hachyderm.io/@dalias/116189951658156876
@glyph And I know you're well-meaning, but this kind of wish to tear up the non-monoculture we've so painstakingly nourished over the decades, fighting to preserve consensus standards process and portability, is a big part of:
LisPi
Speaktrap@glyph And there are already plenty of people who feel that systemd was imposed against their will. No, I feel like this can't be the right answer. Especially when the problem, as I understand it, is that the Linux bazaar is uncomfortable to those of us who primarily ship applications for other, proprietary platforms. Why would they want to fundamentally change what they're doing to fit our conception, which they presumably view as flawed, of what a platform should be?
@matt they're free to read my analysis, think "nah", and forget about it. I'm not particularly influential here, it just bothers me.
but the reason it bothers me is that the cost here is permanent irrelevance. is the point of a free software desktop to have direct, monarchical control of the development process of your compositor or whatever, or is it to provide *users* with a more accessible and open computing experience where they can have agency and control over their applications?
@matt I would like to see the efforts of the movement directed to the kind of liberatory project that everyone involved in "Free Software" pretends to care about, for actual users, not just themselves. which means making it popular enough that it is the system that kids accidentally encounter at school and at home and at the library. which means making it the system that people get on their work computers.
Krzysztof Sakrejda@glyph @matt over time things have moved in the direction you're suggesting. I think systemd and sway are pretty good examples. Systemd in particular implemented a lot of core functionality and stayed committed to their bit long enough almost every distro has continued to shrink their init script footprint.
The gtk/qt thing would probably also be taken care of best by shrinking the space of responsibility those toolkits take up rather than choosing between them.
Simon Richter
Ewen McNeill@glyph so XKCD “15 standards”…. but somehow in reverse? 😂
(I do agree that it’s almost entirely a set of social problems though. It always has been. Indeed the whole “15 standards” problem is basically social problems translated into tech.)
@ewenmcneill yep that's the idea and that's also why it's intractable
Joe Brockmeier@glyph I don’t necessarily disagree (or 100% agree) but the odds of this seem… small.
Our problems really aren’t technical - they’re social and political. The same problems that keep us from solving other political and social problems: we just can’t seem to put things aside for the common good or organize for such things without personal interests, tribalism, and greed getting in the way.
skippy@jzb @glyph Social means community. Which community is most likely to achieve what you envision? We don’t need to consolidate all the efforts of all possible contributors. We just need enough effort from a large enough group rowing in the same direction. User friendliness has long been a Linux issue. Sign me up to help!
(hic/haec/hoc)@glyph but why? What's the problem if there's a long tail of distributions with few developers and users, in addition to the big ones? Some may have only minor differences, but many focus on a specific niche or are built around completely different technologies that solve different problems, and you never know which ones will become important in the future, either by themselves or by proving that something works well enough to be widely adopted
Ben Berry@glyph (fully recognizing how helpful the following take isnt)
Yes, but also extremely no.
Being able to put forward a coherent, open-source, not-megacorp-owned product that is approachable for everyday use probably only happens if we do something like this.
On the other hand, there is strength and value in decentralization, and also value in specialist and niche distributions (even if some of their value is simply the delight they gave their developers)
I would also bet that a at least half of the stubborn split efforts are not around technical merits or the way they tie into developers egos.
JayF@glyph this assumes I have interest in (volunteer) working on something watered down enough to work for 99% of people 😕
Phie Lux 
@glyph It’s not just about egos either. Different people have different incompatible ideologies. You have free (libre) software purists and open source purists and free (beer) purists and license hawks and IP anarchists and people who may not be able to say it out loud but are quite happy to serve the interests of capital and people who can’t even agree what serves the interests of capital. And many of these aren’t differences of opinion in means but differences of opinion in ends. You can’t get people to agree who don’t agree on goals. If you can get everybody to agree that the goal is to create the Linux, you have a shared goal and it is conceivably achievable. I can’t see that happening. Distributions, like all software, are always a means to an end.