Future of Windows in pro audio

[BertKoor]

it's the maintainers' problem

You missed his point: Tiles IS the maintainer.

[Tiles]

So here we go again. Everybody guilty but Linux

If the software is open source, then it's the maintainers' problem.

No, that’s not a rebuttal, that’s just a workaround dressed up as an argument.

You’re effectively solving the problem by redefining Linux into something it isn’t: one or two controlled distros, fixed stacks, standardized desktops, curated dependencies. At that point, yes, a lot of the issues disappear – but only because you’ve removed the actual properties of the system you were originally defending.

That’s the contradiction you’re not addressing.

You can’t argue “Linux is fine as a general desktop platform” and then in the next breath require strict curation, freezing, and standardization to make it work. That’s not “using Linux as it is,” that’s turning it into a managed appliance environment. Where is your proclamated freedom gone?

And this “just pick a distro / just use containers / just standardize it” pattern doesn’t scale to the real world of desktop software distribution. It only works if you assume away the exact fragmentation that defines the ecosystem.

So either Linux is a freely fragmented ecosystem, in which case the distribution problems are real, and they are, i have listed them based at my own experience. Or it is a controlled platform, in which case you’ve already conceded that fragmentation is a problem that must be artificially removed.

You can’t have both.

[ampetrosillo]

It's not about being guilty. Linux is... a kernel. The Linux ecosystem is wide. You get slow-moving, reliable commercial distros (RHEL, for instance), slow-moving, reliable community-led distros (Debian), a bit faster-moving, kinda reliable semi-commercial distros (Ubuntu), cutting-edge, less stable distros (on a continuum going from Fedora to Arch), a big bunch of minor players...

Now. The trait d'union across these distros is the underlying open source base. These distros take open source software, package it, curate it and take the trouble to get it to work reliably. With open source software (provided as is, with no guarantees attached), the onus is on the distros and not the original developers. The original developers are somewhat expected to interact with the distro maintainers, but, at the end of the day, it's the distros who should put in the effort to make the software work - or leave it out entirely. That is how Linux has grown into the number one OS for servers and embedded software (in this case, it's the OEMs who put in the effort). If it didn't really work, it wouldn't have had all this resounding success. If the top-down, stable, consistent nature of other OSs were so valuable, we would have seen maybe some BSD taking Linux's place - the argument that BSD was too risky because of those lawsuits doesn't hold.

What if you do not wish to release your software under an open source licence? Then you are literally "on your own" because you are voluntarily, deliberately moving away from that distributed effort-taking within the Linux ecosystem. You have to be the maintainer of your own software, and you have to make the choices to make your software work. And when you are the maintainer, you can do whatever you like. Even just assuming away the distributed nature of the Linux ecosystem and turning it into the controlled platform (by you) that you seek. That will mean a few things. First, your software will never be properly integrated within any system that is not your assumed target, but will have to be grafted on top of the underlying OS. Containers allow you to do this quite easily, although stuff like theming might be broken. You don't strictly need them, and again, Reaper just releases a .tar.gz with an install script within that simply throws everything into /opt/reaper (or keeps it within your /home, if you want). For the record, Reaper just works. On any distro I've tried. Others use stuff that makes it easy for things to just work (like Electron, which means that a simple text editor will weigh 3GB ). How is that being deprived of any freedom?

[Tiles]

It's not about being guilty. Linux is... a kernel.

We talk about the desktop here. So i saved me the term desktop.

Your reply shifts the argument away from the actual claim. And honestly, I don’t see much point in continuing this if the argument keeps drifting into strawmen instead of addressing the actual issue.

The original point is about technical release complexity on Linux: fragmentation, inconsistent dependencies, multiple distros and graphics stacks, and lack of a single stable platform ABI.

You instead frame it as a responsibility or ideology issue (“you chose proprietary so you are on your own”). That’s a strawman, because the difficulty exists regardless of licensing.

The “distros make it work” argument is only partially true: they curate their own ecosystems, but that still results in multiple incompatible targets, not one unified platform. Even point releases are incompatible with each other. I have once released a game that runs on Ubuntu 12.04. And nowhere else. The windows version still runs fine. I already told about another case where a point upgrade made one of my software quitting. Does this sound like it the distros works?

Server and embedded Linux success is not comparable, since those environments are controlled and homogeneous, unlike desktop Linux. You have a LAMP configuration. Maybe Nginx. Not comparable with the complexity of a destkop OS. Bringing them up here is just another distraction from the actual problem. And yet another strawman.

If you want a better comparison, look at Android. It is also based on Linux, but it presents a single, well-defined platform to developers. There aren’t hundreds of incompatible “Android distros” you have to target separately.

That is exactly the difference: Android succeeds as an application platform because it standardizes the stack and defines a clear target. Desktop Linux does not, and that is where a large part of the release complexity comes from.

Examples like Reaper or Electron don’t disprove the issue, they show it is often solved by bundling or bypassing system integration entirely. That doesn’t help if you’re targeting something like Ableton or Cubase, and it highlights how Linux often relies on special-case solutions rather than a consistent platform.

This all is not a new discussion. It has been going on for roughly 25 years, and despite all improvements (desktop) Linux (distributions) still has not become a mainstream desktop platform. That persistence itself points to structural causes rather than misunderstandings or lack of effort. And even Linus Torvalds knows them all. I save me the time to relink his video where he explains why Linux at the desktop sucks.

Bottom line: the claim was about fragmentation and deployment complexity, not about openness or developer responsibility.

And one last word to freedom. When you can't get your job done because the software for it is missing, then that's the exact opposite of freedom. The biggest freedom is at Windows. All proprietary software, most open source software.

What really frustrates me as a software developer is how often all open source software gets lumped in with Linux. I have nothing to do with Linux, except that i am a Linux user too. Linux happens to be open source, but open source is not the same thing as Linux. As an open source developer, I am not somehow “owned” or represented by that ecosystem.

[ampetrosillo]

It's not about being guilty. Linux is... a kernel.

We talk about the desktop here. So i saved me the term desktop.

Your reply shifts the argument away from the actual claim. And honestly, I don’t see much point in continuing this if the argument keeps drifting into strawmen instead of addressing the actual issue.

The original point is about technical release complexity on Linux: fragmentation, inconsistent dependencies, multiple distros and graphics stacks, and lack of a single stable platform ABI.

ABI is a problem only for binaries, it's not a problem for stuff that can be compiled by the distros (note that this could be made to work also with proprietary software). This is also a problem within the kernel, but only for out-of-tree modules. If it's within tree, then the kernel maintainers literally take care of everything. As for the rest, the problem exists but, again, it can be solved by building for a target. There is some degree of standardisation within the Linux ecosystem, so it's not as bad as you make it. The biggest problem now is Wayland. There are some distros that are now Wayland-only, and there have been a few issues with PipeWire (and earlier with systemd) but this applies to all architectural changes, also on Windows (as I said earlier).

You instead frame it as a responsibility or ideology issue (“you chose proprietary so you are on your own”). That’s a strawman, because the difficulty exists regardless of licensing.

The “distros make it work” argument is only partially true: they curate their own ecosystems, but that still results in multiple incompatible targets, not one unified platform. Even point releases are incompatible with each other. I have once released a game that runs on Ubuntu 12.04. And nowhere else. The windows version still runs fine. I already told about another case where a point upgrade made one of my software quitting. Does this sound like it the distros works?

When I said that you are on your own, it wasn't ideological or a responsibility issue, it was a matter of choice. If I release a piece of software and it's open source, the distros can take it and package it, literally without even asking. At that point it's their problem. If it doesn't work on their system, they are supposed to look into the problem and make it work. If they don't want to make it work, they simply do not include it within their repos (or maybe somebody in the community packages it into the community repos). If it's not open source, then it simply does not fit within this mechanism and it's a fact of life. No fingers pointed.

Server and embedded Linux success is not comparable, since those environments are controlled and homogeneous, unlike desktop Linux. Bringing them up here is just another distraction from the actual problem. And yet another strawman.

What? How homogenous and controlled are they really? Servers exist across several different architectures (x86, ARM, maybe MIPS, sometimes even mainframes, possibly RISCv5 in the future), distros... Each with their own hardware, virtualization software, etc.

If you want a better comparison, look at Android. It is also based on Linux, but it presents a single, well-defined platform to developers. There aren’t hundreds of incompatible “Android distros” you have to target separately.

That is exactly the difference: Android succeeds as an application platform because it standardizes the stack and defines a clear target. Desktop Linux does not, and that is where a large part of the release complexity comes from.

And that is done with a lot of strong-arming by Google, not to mention the fact that applications are basically all containerised there.

Examples like Reaper or Electron don’t disprove the issue, they show it is often solved by bundling or bypassing system integration entirely. That doesn’t help if you’re targeting something like Ableton or Cubase, and it highlights how Linux often relies on special-case solutions rather than a consistent platform.

What do you mean? Ableton and Cubase don't even exist on Linux. The Reaper or Electron model is not "ideal", but it works.

This all is not a new discussion. It has been going on for roughly 25 years, and despite all improvements Linux still has not become a mainstream desktop platform.

Because, to be honest, there is no clear need for another mainstream desktop platform. Most users do not care. As well as there being a chicken-and-egg problem, and networking effects, etc.

That persistence itself points to structural causes rather than misunderstandings or lack of effort. And even Linus Torvalds knows them all. I save me the time to relink his video where he explains why Linux at the desktop sucks.

Bottom line: the claim was about fragmentation and deployment complexity, not about openness or developer responsibility.

Linus Torvalds speaks as the head maintainer of the one kernel everybody ends up using. His view, of course, is slanted. The kernel never, ever, ever breaks user space. But all the stuff within the kernel can and does break, and is promptly fixed as long as the kernel devs can fix it. Anyway, I'm not saying that he's wrong, but it is a bit "easier" when you are the pivot. Enforcing this kind of discipline across an entire ecosystem is not exactly a walk in the park. Which is why, I suppose, distros count so much.

[ampetrosillo]

Also, a note on the fact that you are not really free if the software is missing. Not all software *has* to be on your platform. In the audio production world, you don't have Logic. You don't have ProTools. You don't have Ableton. But you have Reaper. You have Bitwig. You have Studio Pro (now). You have Mixbus. You have Ardour. Maybe that's not enough, so this means there is an opportunity. It's like complaining that you can't find your favourite brands in the country you moved to. As an Italian, I know that I won't be able to eat proper Italian food anywhere in the world except Italy (unless I pay through the nose for a merely decent pizza in London, for instance. In other places I don't even have this luxury choice). That's why you use the good stuff that is local instead of complaining about the lack of the good stuff you consumed in your home country.

[Tiles]

ABI is a problem only for binaries

Binaries. You mean… the thing users actually run? Ah, right, who needs software when he can have Linux.

When I said that you are on your own, it wasn't ideological or a responsibility issue, it was a matter of choice.

It is not a matter of choice since there is no choice. If you want to distribute software on Linux, you generally have to go through the same set of constraints and workarounds.

You don't have Ableton. But you have Reaper.

So the solution is basically “your tools don’t work here, use different ones”?
That’s a bold way to define a platform. Hope your doctor doesn’t apply the same philosophy.

If tools don’t matter, why not just say “use Windows instead”?

Oh right, because for you Linux obviously does matter.
So how do you get from “platform choice matters” for yourself to “it doesn’t matter” for everyone else?

The issue isn’t whether something can be replaced in principle.
It’s that tools like Ableton are not just applications, they are muscle memories, habits, ecosystems, personal connections and workflows built up over years.

Switching DAWs isn’t like switching text editors. It’s retraining, rebuilding workflows, losing integrations, plugins, habits, and production pipelines. And lifetime.

And that’s exactly where “just use Reaper” falls apart as an argument: it ignores that software choices have a reason, and are often not interchangeable without real cost.

If the answer to “this software isn’t available here” is always “use something else”, then the conclusion is not “problem solved”, it’s simply “this platform is incompatible with part of the software ecosystem people actually use”. You better use something else.

---

I think you may be misreading what I’m actually arguing against. And I am unfortunately pretty certain that you are doing this intentionally. You repeatedly try to distract from my points, and you haven't adressed them yet.

The original discussion is about release and compatibility complexity on Linux: fragmentation across distributions, inconsistent dependency ecosystems, multiple graphics and audio stacks, and the absence of a single stable platform ABI.

That’s a real structural property of the ecosystem, not something that disappears by saying “just rebuild it” or “just use a different tool”.

Where I disagree is how you frame the impact of that. I’m not approaching this from an ideological point of view, I’m questioning the conclusion you’re drawing from the technical constraints. Since you obviously miss the knowledge about this part.

Saying “ABI is only a problem for binaries” or “just compile it for the distro” doesn’t remove the complexity, it just shifts it:

from users to maintainers
from vendors to distributions
from runtime compatibility to build-time fragmentation
from Linux to everybody else being the guilty one !

I tell you that i as a developer have much more effort with the Linux binaries, and you tell me that's my fault. No it is not. In the real world it's only the Linux distributions that are responsible for the Linux distributions. Nobody else.

[imrae]

I think distribution maintainers generally prefer to be responsible for compiling binaries than to troubleshoot problems without access to the source.

[Tiles]

Mh,it’s not so much about “preferring to compile binaries”, but about distributions owning the build and integration process for quality and security reasons. That’s exactly what makes the model strong, but also what creates friction upstream.

The underlying issue is that software is tied to distro specific packaging instead of a single stable deployment target, and the ecosystem is fragmented across many package managers and hundreds of Linux distributions. Even point versions and dependency differences often need to be accounted for.

On Windows I ship a single executable and I’m done. That target stays stable for years.

[audiojunkie]

There are indeed many valid reasons to move away from Windows and Microsoft today. But there are even more reasons to stay with Windows. Installing Ubuntu, Mint, or Arch often leads to a moment of truth, when solving one set of problems usually brings a different set of trade offs and impossibilities.

Many workflows depend on native Windows applications, and a large amount of commonly used software is either missing or only works via Wine or Proton. Linux is not well suited for many everyday tasks that work out of the box on Windows. Usability is another hurdle. For many tasks that could be handled through a graphical interface, you are still forced to use the bash, and this pattern repeats in various ways.

These limitations are largely self-inflicted by the Linux ecosystem itself, rather than being the fault of users or third parties. They stem from fragmentation among distributions, the lack of commercial support, and fundamental design choices in how Linux is structured. Managing everything through a single central system, the package manager, works in theory but creates practical dependency challenges that contribute to these issues. This is a systemic problem that has persisted for more than twenty-five years and shows little sign of ever being resolved. As a developer, Linux often gives me much more work than Windows, which contributes to the situation where there is less software available.

For most users, the lack of native software remains a practical barrier rather than a philosophical one. It is not a question of will. Principles are nice, but they do not get the job done. That is also why Windows still holds a vast majority of the desktop market, while Linux distributions together represent only a small single digit percentage. No Linux distribution functions as a true general purpose platform like Windows, and macOS, the only real competitor, has its own limitations.

Linux works best as a complementary platform for tasks where it truly excels, such as servers, embedded systems, or certain development environments. Even in areas like gaming via Proton, it still covers far fewer users than Windows and has limitations for many mainstream applications.

TL;DR: If I can’t do my job, switching to Linux is simply not an option

Written from Ubuntu as my dual boot system

EDIT, maybe one last word about Onedrive and Bitlocker encryption. I think it is common sense simply not to use it, there are better alternatives. Same for the integrated AI solution. It was one of the first things that i turned off. I don't need a spy AI that makes snapshots from my desktop. These things are not part of the OS, even when Windows makes it look like, by shipping it together with the OS. It's part of the service with which Microsoft makes their money nowadays.

Apologies for basically necroing this quote, since I've only started reading this thread now, but the idea that developing for Linux is harder than on Windows is... imprecise.

It is if you expect to carry the "developing for Windows" philosophy over to Linux.

Linux is a system where everything is intended to be open source by default, and where certain design practices (eg. shared libraries, and secondly Unixisms) are expected to be adopted. It's like coming to Italy to buy a house and complain that you need to go through a notary. It's part of the system. (And this step is devised to do stuff that other countries simply do differently, for example through purchasing contract insurance instead of relying on an official to check whether everything is in order). Linux is community-led and community-oriented. To develop for Linux means to interact with such a community. Especially if you work at the kernel level (but it also applies to user space somewhat).

You have some really romantic ideas here

The short answer: nope, that’s not how it works in reality, sorry.

The long answer:

The issue here isn’t “philosophy” or someone trying to apply a Windows mindset to Linux. This isn’t about preferences, biases, or aversions. It’s much more concrete than that.

There are real, practical friction points when developing for Linux that simply don’t exist (or exist to a much lesser extent) on Windows:

**Fragmentation**
On Windows you target one clearly defined platform. On Linux you deal with multiple distros, different library versions, packaging systems, and sometimes incompatible environments. That directly leads to “works on my machine” problems.

**Dependencies**
Shared libraries sound great in theory, but in practice you hit version conflicts, missing packages, and inconsistent naming across distros. Static linking is often discouraged, so you’re constantly balancing compatibility and convention.

I’ve had software released on Ubuntu where a Python dependency was effectively broken by a point release just two weeks later, and the application stopped working. Now try explaining that to users of a freshly released product. And this isn’t a one-off, it happens repeatedly.

**Distribution**
On Windows you ship an .exe or installer and you’re done. On Linux you’re choosing between deb, rpm, AppImage, Flatpak, Snap, or source builds. That’s not philosophy, it’s overhead.

**GUI stack**
X11 vs Wayland, GTK vs Qt, different desktop environments and inconsistencies. That adds real complexity to UI development.

**Lack of a stable baseline**
Windows APIs are relatively stable over long periods. On Linux, what you can rely on depends heavily on the distro and stack.

Linux absolutely gives you more freedom, but that freedom comes with real costs in compatibility, packaging, and maintenance. And none of these “freedom” solutions come even close to the usability of Windows.

For me, as a long-time developer, this is everyday reality. On Windows I build an executable and I’m basically done for years. On Linux I’m maintaining multiple formats, chasing distro-specific issues, and dealing with support cases that aren’t even about my software, but about system setup and dependencies.

And when you add it all up, it also explains why there is still significantly less desktop software on Linux. Which is why many people simply can’t migrate, even if they want to, because they rely on specific tools for their work. And often there are no equivalent replacements.

In my experience, there is no Linux distribution that truly competes with Windows in this regard. It can be “good enough” for some use cases, no question. But if I can’t reliably get my work done, then switching simply isn’t an option.

This individual is on a one man mission to cancel out any praise with criticism in the Linux universe, so be aware that he copies and responds through AI. So don’t bother arguing or correcting him. He’ll just copy your response into AI and tell it to give an opposing answer. No matter what you say, he’ll find a way to argue. It’s not worth you time.

[ampetrosillo]

(delete)

[ampetrosillo]

ABI is a problem only for binaries

Binaries. You mean… the thing users actually run? Ah, right, who needs software when he can have Linux.

Are you being obtuse? If the ABI shifts, a recompile is usually all that is needed (at least, with sane development practices). Users shouldn't care, the maintainers should. And I'm not saying this to be annoying, it's that literally *this* is how it is supposed to work. It's not being romantic either. This system has its pros and cons.

When I said that you are on your own, it wasn't ideological or a responsibility issue, it was a matter of choice.

It is not a matter of choice since there is no choice. If you want to distribute software on Linux, you generally have to go through the same set of constraints and workarounds.

When you develop for macOS, it's the same really. Or Windows, for that matter (although it is slightly easier to do "weird" stuff on Windows). Each platform has its own constraints and workarounds. Why were developers so ecstatic about WSL? Because a huge amount of Linux software was kludgy to adapt onto Windows.

You don't have Ableton. But you have Reaper.

So the solution is basically “your tools don’t work here, use different ones”?
That’s a bold way to define a platform. Hope your doctor doesn’t apply the same philosophy.

It's what doctors do in countries that have no access to Western medications, or (worse) when there is access to such medications but they are too expensive/not covered by your health insurance/etc.

If tools don’t matter, why not just say “use Windows instead”?

Oh right, because for you Linux obviously does matter.
So how do you get from “platform choice matters” for yourself to “it doesn’t matter” for everyone else?

The issue isn’t whether something can be replaced in principle.
It’s that tools like Ableton are not just applications, they are muscle memories, habits, ecosystems, personal connections and workflows built up over years.

Switching DAWs isn’t like switching text editors. It’s retraining, rebuilding workflows, losing integrations, plugins, habits, and production pipelines. And lifetime.

And that’s exactly where “just use Reaper” falls apart as an argument: it ignores that software choices have a reason, and are often not interchangeable without real cost.

If the answer to “this software isn’t available here” is always “use something else”, then the conclusion is not “problem solved”, it’s simply “this platform is incompatible with part of the software ecosystem people actually use”. You better use something else.

Well, we could get a little bit geopolitical here and say that Linux is not an American concern (and a black box, at that) and Linux can be freely adopted by anybody anywhere in the world, so platform matters a bit more than the specific tool.

And we could get a little bit ideological and say that Linux and Linux distros, in general, as diverse they may be, espouse an ethos that goes contrary to the ethos of proprietary software and that might be more important to people than the specific kind of software they use. People like Richard Stallman actually say that explicitly; they'd rather use inferior free software than superior proprietary software (but in that case, neither Reaper nor Ableton apply here). Proprietary software is what makes Logic only available for macOS possible (so much for muscle memory there!).

But ultimately, not many people are *forced* to use Linux. Some people in some parts of the world might be (but they usually pirate Windows anyway ).

By the way, Linux only matters to me a bit. I use Windows 90% of the time. And certainly 99% of the time for audio production. I'm a realist and a pragmatist myself. I only entertain the idea of using Linux as an experiment for audio production because Reaper is available there, although I could also consider using Ardour - if I did, that would be my own "heroic" choice. As a materialist myself, I believe that "praxis", to use a Marxist term, should never force people to make heroic choices, because it would be against the point. It would mean fetishising an idea. But some people do want to be heroes, and some people do want to live somewhere in the mountains in Nepal, and some people do want to use Linux exclusively, and they are free to do so, using the tools they have available.

I think you may be misreading what I’m actually arguing against. And I am unfortunately pretty certain that you are doing this intentionally. You repeatedly try to distract from my points, and you haven't adressed them yet.

The original discussion is about release and compatibility complexity on Linux: fragmentation across distributions, inconsistent dependency ecosystems, multiple graphics and audio stacks, and the absence of a single stable platform ABI.

That’s a real structural property of the ecosystem, not something that disappears by saying “just rebuild it” or “just use a different tool”.

Where I disagree is how you frame the impact of that. I’m not approaching this from an ideological point of view, I’m questioning the conclusion you’re drawing from the technical constraints. Since you obviously miss the knowledge about this part.

Saying “ABI is only a problem for binaries” or “just compile it for the distro” doesn’t remove the complexity, it just shifts it:

from users to maintainers
from vendors to distributions
from runtime compatibility to build-time fragmentation
from Linux to everybody else being the guilty one !

I tell you that i as a developer have much more effort with the Linux binaries, and you tell me that's my fault. No it is not. In the real world it's only the Linux distributions that are responsible for the Linux distributions. Nobody else.

I am *not* saying it's your fault.

I'm literally saying that you do what you want. You can choose to only support ONE distro. MATLAB, AFAIK, is only supported on RHEL, for instance. You can choose to support all distros, and if so, then good for you! It's a big workload. I don't think anybody in the Linux ecosystem expects the original developers to undertake such a massive task.

I'm literally saying that it's the distro maintainers that are responsible for the way the distro works. If a distro f**ks up a point release of a package, it's LITERALLY their responsibility. (Well, not legally speaking, because they deny any responsibility outright, unless you're paying for support, that is, but it is their job, not yours).

At the end of the day, what I'm saying is that Linux gives you the freedom to choose how to tread. There are strategies to deal with the fragmentation (for instance, relying only on mature software that basically never changes, and that comes with its own set of cons, usually lack of features). There are development practices that help with dealing with this added complexity. There also are some positives that this complexity brings (a potentially faster innovation cycle, for instance).

(As an aside, you software people, almost all of you, wouldn't last one day in other engineering branches The overwhelmingly cavalier approach to designing, thorough testing, breaking things and then fixing them later, etc. and in general winging stuff as you go along would sometimes literally kill you if working with electronics or mechanics or construction. Imagine adding something as trivial as a resistor somewhere in a circuit with a "// I have no idea why this works" comment right next to it).

[Tiles]

This individual is on a one man mission to cancel out any praise with criticism in the Linux universe, so be aware that he copies and responds through AI. So don’t bother arguing or correcting him. He’ll just copy your response into AI and tell it to give an opposing answer. No matter what you say, he’ll find a way to argue. It’s not worth you time.

Have we reached this point again? Everybody who does not agree with you is somebody on a mission?

If you have to reduce this to personal attacks and speculation about motives, you’re not engaging with the argument anymore.

Either address the claims directly or don’t respond at all. This kind of dismissal doesn’t add anything to the discussion.

Fun fact, i was dragged back by a man with such a mission.

[Tiles]

... Words ...

Do you honestly believe that throwing more words at this makes your argument stronger? It doesn’t. It only serves to obfuscate the fact that you are still dodging the actual point. You are clearly the one being obtuse here.

You are conflating several valid points while attempting to frame me as your opposition. You wrap it all in rhetorical padding that fails to address the original claim. You are exhibiting the exact same patterns I have seen time and again from Linux fanatics, such as Audiojunkie just moments ago. This is precisely the behavior that I despise in the community because it damages Linux more effectively than any hater ever could.

Yes, a clean ABI break often only requires a recompile. That strawman was never in dispute. The real issue is that in the Linux ecosystem, you do not get a single ABI target in practice. Not even one. It is not that difficult to grasp. Instead of a stable target, you deal with a moving set of distro-specific packaging policies, library versions, patch sets, and release cadences. That is where the friction lies. That is exactly what upstream developers must contend with if they want broad coverage.

Comparing this to macOS or Windows is a false equivalence. On those platforms, you target a single vendor-controlled ABI and runtime environment. The complexity exists there, but it is centralized. Linux is explicitly decentralized. That decentralization is the source of the extra work, not merely a matter of "sane development practices."

Furthermore, saying “users shouldn’t care” is a non-sequitur. Users do not care about ABI details on any platform; they only care whether software works. The entire discussion is about who absorbs the integration cost, not whether users need to study it.

The rest of your argument drifts into predictable nonsense: ideology, geopolitics, and philosophical platitudes about "freedom." That might interest some hamsters in Siberia, but it has zero impact on the engineering reality. It does not change the fact that fragmentation forces projects to bypass the system entirely via bundling, containers, or self-contained distributions. Do yourself a favor and perform a fact check before posting such drivel.

Sure, Linux offers "flexibility." You now have the freedom to choose between Nemo and Nautilus, both of which are lightyears behind Windows or macOS solutions. Or perhaps you enjoy the liberty of choosing a different Bash color? Amazing. Truly. All that is missing are punch cards. The usability is reminiscent of the 1960s.

The tradeoff is predictable: increased integration burden and more edge cases pushed upstream. Pretending this is just a matter of "responsibility" does not magically erase the engineering cost.

But let us get to the real issue. If you want to dance around the point, go ahead. The actual reason people fail to migrate to the Linux desktop is the lack of software. And this is not some mysterious conspiracy. It is a direct consequence of the fragmentation and the friction it creates. Developers do not avoid Linux because they are stupid or malicious. They avoid it because it represents more effort for less return.

In case you have not realized it yet: you are talking to one of those developers. I am telling you exactly what my problems are, backed by facts and technical reality. You, instead, counter with fairy tales.

It is obvious that you refuse to engage with the actual point. You do everything to dodge it, but dressing up your evasion in philosophy, strawmen, and personal attacks does not make it go away. Since you dragged me back into this discussion, you will have to deal with the response. The bad news for you is that I have the facts on my side. We can do this all day. I can disprove your points repeatedly, just as I have already done.

[ampetrosillo]

... Words ...

... Angry words ...

OK, now let's get down to it. What do you propose? How can Linux (whatever that means) become a viable system for desktop developers? Where should the burden lie? How can this be done without impacting the underlying philosophy, which is a big reason a significant portion of users use and develop for Linux? And most importantly, why hasn't it been done yet?

That's the whole problem. Developers like you (which is not to mean all developers, since there are a lot of developers investing time, energy, sometimes even money into desktop Linux software, even if they are a minority) somehow expect the problem to be dealt with, but do not even propose a roadmap or something to help solve the issue.

Besides, why does the ABI (or anything else) change all the time? Is it just out of spite? Is it due to incompetence? Is everybody incompetent in the Linux world (including the kernel! They change the ABI all the time)?