I find it really arrogant to claim "this software does everything I need, so it should never change", while in reality you are but an infinitesimally small part of the user base said software has to support.
Sure, all the software can stay where they are if all the developers had to serve is you. But that is just not the reality.
There isn't a magical different userbase Linux has to serve which has somehow bizarre needs not served by thoughtfully-designed older software, but which newer, poorly-designed software somehow meets.
Yes, we need a newer web browser, but that could run on old-school Linux/Unix just fine. Aside from that, there isn't anything wrong with nineties Linux which couldn't have been brought up to modern standards with a bit more discipline.
Someone decided ALSA (or OSS, it doesn't matter) was rough to deal with, so they build Pulse and JACK on top of it, rather than a modest expansion of ALSA. Someone didn't like the network layer, so they build a userspace wrapper, and someone didn't like that, so they wrapped it up in a GUI.
At the end of the day:
1) Everything is slow, requiring literally more than 100x the resources it once did.
2) Everything is complex, with layers upon layers, and text files with comments "This is managed by my hack. DO NOT EDIT THIS BY HAND. I keep the exact same data elsewhere, in my own config file, since I couldn't be bothered to read what's in the line below."
3) Everything is brittle and hard-to-understand. I knew how nineties Linux booted. Today, the logic is distributed among dozens of layers, mostly because people wanted to reinvent new things, rather than polishing/improving/fixing old ones. Different apps go for the wrong layer, and tutorials point to the wrong ones too.
Now Ubuntu is throwing its hands up at the mess, and building snap to hide all this under yet. another. layer.
As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.
Maybe you should fine community that shares your views.
I don't use pulseaudio, networkmanager, desktop environment, works perfectly in Arch Linux [1]. Arch has great wiki, it is correct. System is quite transparent.
I am fine with systemd but, for example, Void Linux [2] uses runit, Alpine Linux [3] uses OpenRC and is compiled statically.
Arch Linux pacman serves my needs perfectly, it is quick, it shows only relevant information. AUR provides ready made PKGBUILDs.
Lots of Linux distributions is its strength. It allows people with niche requirements find its home. We are far better members of societies when supporting our system than grunting.
I have never had problems distributing binary builds for Linux. There are a number of system libraries that are backwards compatible: glibc, asound, libGL, etc. - test on the oldest you want to support and any other libs you just ship yourself. And that would not be different with only one distro either unless you only care about one release of that distro.
> Arch Linux [1], Void Linux [2], Alpine Linux [3]
Gentoo is feeling left out. It's the OG distro for those who have strong opinions on how their system sould work but not strong enough to do eveything by hand.
wegs reminded me experience with Ubuntu. I've started with GNOME, tried XFCE, Openbox, system become brittle and it raised questions like "How to configure WiFi without DE?".
I've switched to Arch Linux, base install covers network configuration. It gave me stable platform, I can grow my knowledge, I can fix my system.
Void Linux and Alpine Linux are just examples of what could match voiced concerns. I lot of people recommend Manjaro, looks like a simple way to try Arch based distro. Some problems stem from upgrading release, Debian Testing could help. But I have not tried them.
I've tried Ubuntu, I don't like distribution upgrades, default theme, constant experiments on users. Gentoo is my first distro, as C++ dev at that time, compilation was fascinating. I still enjoy 3 commands joke [1], looks like it is possible to install binary packages these days. I've tried Alpine, I don't like apk, systemd and glibc are good enough for me. I've tried OpenBSD, hardware support was not as good as on Linux. I'm playing with NixOS but I am so used to Arch.
And I want to stress, each of these system has something I enjoy. It is just me who is driven by minimizing negative points.
> As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.
Nah, even ALSA was a needless overcomplicated mess. They should have just built on top of the super simple /dev/dsp. Instead we got new incompatible APIs wile OSS apps were left with requiring exclusive access to your sound card.
Computers aren't things I enjoy. They're things I stomach. I think I'd use OpenBSD if I were confident that after setting it up, it worked reliably, without changes, for the next few decades, with transparent system upgrades.
Part of that is working Bluetooth, power management, webcams, video conferencing, OBS, and similar. Historically, OpenBSD was behind Linux on working reliably.
Debian used to do this before:
1) It fell behind on hardware support, as laptops took over desktops; and
2) Ubuntu/Fedora started putting out massive numbers of half-baked technologies, and everything building atop those.
I switched to Ubuntu, without Gnome, but increasingly, things don't work without Ubuntu's UX, and snap shows a future I don't want to head down anymore.
Webcams and power management work fine on OpenBSD (assuming there exist drivers for your hardware), but Bluetooth isn’t supported at all.
What I like about it is the simplicity of everything. If you want to change your mouse sensitivity, you add a line to a particular file in /etc. If you want to autojoin a particular WiFi network, you add the SSID and password to a particular file in /etc. If you want to start a daemon on boot... you get the idea. No massive complex configuration systems with giant blobs of XML that nobody understands.
Unfortunately the flip side is that things move more slowly — they won’t support Bluetooth until someone writes code that meets the system’s bar for correctness, simplicity, reliability, documentation, etc. — which might be never. But the stuff that does work is fantastic.
If hardware/software support requirements tie you to more mainstream OSs, I do agree with other posters that Arch is the closest thing to what you want, but it’s still far from perfect.
3) How is video support with ATI/Nvidia? Will my multimonitor setup break?
The other thing which scares me is the manual upgrade process. On my systems, I've done apt-get update/dist-upgrade for a quarter century now, with never an issue.
1) There isn’t a standalone binary, but you might be able to get the web client working in Chromium. I’m not sure.
2) I don’t know.
3) AFAIK it should work.
Using the BSDs as a workstation, rather than a server, is a bit niche. Like Linux, but even more so. So unfortunately it’s still a labor of love and a lot of modern stuff won’t be supported.
Especially in the Linux world where not asking too much of their own PC is seen as a virtue, so people are running tiling WMs from the nineties, spend their time in Emacs and say everything is fine.
Meanwhile I want my Linux system to run VR, multiple 4K displays, very demanding games and bluetooth headphones. And Linux is the worst for it, because everything feels laggy and half polished there and on the proprietary OS my setup feels MUCH faster.
Sure, it's not Linux's fault, but let's stop saying everything is fine and dandy because Emacs is still running.
SGIs ran VR, multiple displays, and very demanding apps in the nineties too. They did all sorts of wonky, complex, 3d input devices too. So did DEC Alphas. This is the stuff Unix was built for.
My claim is that nineties Linux was much closer to having the right architecture for it than 2020 Linux for this sort of stuff. The reinventions and onion layers didn't help; they hurt.
I think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware (USB, Bluetooth, displays, etc.), and the level of power management. Modern Linux never got that architected or integrated quite right, because it was built with hack upon hack upon kludge. It's split up in bizarre ways between kernel and user space which would be really tough to clean up right now.
* My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac.
* My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too.
* I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in.
* The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable.
.. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back.
Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.
And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought
It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical.
It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.
Sure, all the software can stay where they are if all the developers had to serve is you. But that is just not the reality.