[mftb]

It is the same old problem and what's interesting to me is that I never see it articulated very well. I suppose it's because people disagree about what the problem is.

To me it's this, Linux and it's distribution mechanism is skewed towards servers, and IT since that's where most of it's installed base is.

That's great. The distro/repo system is great, and works well. In addition to it, we need another system that serves workstations better. They don't have the same requirements in general. In particular there's a big divergence in availability, and security requirements. I really doubt there's enough economic inventive to serve this second use-case, but it's too bad, because I think we could have the best of both worlds.

[corrral]

> To me it's this, Linux and it's distribution mechanism is skewed towards servers, and IT since that's where most of it's installed base is.

It's not just servers—not having a very capable, standard, base set of packages to rely on for a workstation-targeting release (say, of GUI programs) is a huge problem. Instead, distros differ wildly on what they provide, users may have different versions of packages or even entirely different programs or libraries (the entire window server may differ!) serving similar purposes, some libs may simply be absent, et c. This is kinda OK if you stick to running software your distro bundles and only at the official version for your release of the distro, but quickly becomes hell (for the people packaging your programs, if not for you) as soon as you step outside that.

This is why you see a lot of companies that support Linux for their commercial software being very specific about supporting e.g. only one or two distros, at some very limited set of versions. It's very hard to support "Linux" in general, especially for desktop-targeting software, because the Linux GUI and multimedia stacks are... well, they're a shitshow, frankly.

[skyde]

could someone explain why you say linux gui and multimedia are a shitshow!

GUI heavy application like chrome, firefox or openoffice run on all districts without any hiccup!

what am i missing ?

[corrral]

There are a ton more ways that very basic APIs and services can present to the user and to their programs, meaning far more ways for things to break. Way more possible combinations of not just version, but even which library or program is providing some capability.

The closest thing to a solution is picking one of the two big desktop environments and targeting that to give you some amount of consistency and stability, but it's not like people will only run your program in that DE (again, possibly not even in the same window server you developed on) so you may end up with bugs when e.g. your QT/KDE program runs under Enlightenment, plus a ton of basic stuff can still vary a lot even if you restrict support to one DE (think: audio daemon) which may affect all kinds of things in unexpected ways.

> GUI heavy application like chrome, firefox or openoffice run on all districts without any hiccup!

Ever seen a thread full of people exchanging advice on how to get these programs not to exhibit certain widespread glitches on Linux, many of which have been a problem for years? Thinking especially of things like tearing, or multimedia playback problems. They even crop up here on HN from time to time.

[mftb]

Agree. I have definitely dealt with that stuff at my work. My goal is to try and frame it in a way, that gets people discussing it productively.

[lmm]

Even for servers, debian-style package management is increasingly inadequate. Linux package management was designed for the C era of a small number of large libraries with infrequent releases. Distribution maintainers are unable or unwilling to adapt their processes to support the model that most modern software ecosystems are converging on: large numbers of small libraries with frequent releases. (Frankly, they're often hostile to the idea that they should support it, despite this model being preferred by both developers and users). Yet they're also hostile to the idea of getting out of the way and letting ecosystem-specific package managers handle ecosystems that need more frequent releases.

In the era of servers that were hand-tended by a BOFH who upgraded only rarely (and screw the users who want to use something newer), the distro/repo system worked. But even servers are not generally maintained that way anymore. I honestly think we're going to see that model fade away in the next decade or so.

[erik_seaberg]

Just because parts of the ecosystem are constantly cranking out small changes doesn’t mean my employer wants my team to spend time alpha testing all of them at the risk of downtime.

I’m fine with an author saying “I no longer want bug reports from that version,” and I’d like someone with the distro to act on those instead.

[lmm]

Most effective employers I've worked for have found that staying close to upstream's rolling releases saved more time and effort in the long run compared to leaving a bigger gap between upgrades (which, sure, saves time if nothing breaks, but the worst case becomes a lot worse).

[wvh]

Well, run something rolling such as Arch Linux or Debian Unstable on desktop, and an LTS distribution such as Ubuntu LTS or Debian Stable on servers. If you're not a complete beginner, there are many benefits to run a distribution that tracks upstream closely so you can contribute and get fixes almost immediately.

If you need local development/production environment version parity, use container images or package locking files available in most programming language ecosystems.

[mftb]

Indeed, agree. I'm on a rolling distro (Manjaro) and I'm pretty happy. I see a lot of discontent in Linux land around this conflict though, so I though I would try to lay it out. Example a lot of people don't like the practice of curl'ing shell scripts on to their boxes, that many developer tools like Rust and Deno use for installing their tooling. The more server oriented folks see it as border-line crazy, while many developers are totally fine with it. Clearly to me they're coming at the issue from different points of view and it would be nice to fully support both communities.

[wildmanx]

> In particular there's a big divergence in availability, and security requirements.

I strongly disagree about the difference in security requirements. I don't want anybody to pwn my banks servers, not less or more than pwning my home desktop or mobile phone.

[mftb]

That's totally understandable. I did not mean to imply that workstations have no security requirements, just different. I feel pretty much the same about the host OS on my workstation, but I also spin up lots of temporary environments that I need to abuse badly. They are thrown away again, usually within hours or days.