Ask HN: What Next After Ubuntu?
I have been running Ubuntu on servers and desktops for around twenty years, but ongoing changes to their platform have shaken my faith in its future. The first serious breach of trust was forcing their users to use their untrustable snaps (e.g. Firefox on 22.04), but the last straw for me has been breaking apt upgrades on 20.04 LTS in order to push their Pro agenda.
I am looking to replace Ubuntu with something that will be stable and supported for the next twenty years, without being ruined by corporate interests. What are my best options?
344 comments
[ 43.5 ms ] story [ 752 ms ] thread[1] - https://www.debian.org/
Though in this case it's likely to keep it accessible to people we slow internet connections.
It depends on whether you're looking at just the HTML or at the page as a whole. The HTML is that small, but there are a couple of JPEG photos on the home page, each weighing on the order of hundreds of kilobytes; the total including these photos is around 1.4 MB.
I thought you were just a legend, like Kayser Soeze.
With a recent price drop I decided to upgrade the storage on my Thinkpad T480s, so I had occasion to reinstall the OS. I went with Debian Bullseye. Choosing all the default settings with LightDM and XFCE, everything except wireless "just worked." Understandably, I had to enable non-free for the Intel wireless firmware, but a simple apt install had that working flawlessly.
Everything about my base system is perfect for me. Booting is quick. Power management is great, with the battery (now at 90% of its original capacity) easily lasting all day. Full volume encryption setup was effortless. I even got Secure Boot running after following some steps (more or less copy-and-paste) from the Debian wiki. When the time comes to upgrade the laptop wholesale to something with a more recent CPU, I half expect that simply moving the M.2 SSD from my current laptop to the new laptop will just work, or at least will require minimal tweaking.
I've tried using snap to get more recent versions of things, but that ended up being more trouble than it's worth. Now I just build my own containers, running them with UID/GID mapping, giving access to X11, and bind mounting a dedicated home directory for the app. Sort of like a poor man's snap or Flatcar Linux, but it's easy enough to figure out, I get more customization, and I get to keep my old familiar Debian environment.
For home workstations, as an ex Ubuntu user, I like Manjaro (and the whole Arch ecosystem) A LOT. Fedora is pretty nice as a dev workstation also.
But it's still my favourite. All the power of Arch with none of the hassle.
Could you be more specific? I upgraded from 20.04 to 22.04 without any issues.
Sure, this might be a simple bug in their apt implementation, but it’s been present for weeks now. It’s a sign of corporate-driven rot, and my 30 years experience in the industry tells me that this is the tip of an iceberg that could sink their Titanic. I want off the boat before it sinks.
The thing I really don't get is that I always assumed 'universe' was mainly driven by 3rd parties. Who's writing the security patches? I can't imagine Ubuntu is capable of doing that for +23k apps, so I'm guessing the maximum they're doing is packaging and the minimum is simply giving us a new repository name that's paid instead of free.
Plus, how does "best effort" work for LTS updates if the finished patch/update is already sitting in the ESM repo? There's not really any extra effort required to push those into another repository, so I think the support for 'universe' will become arbitrary.
My hunch is that 'universe' updates are going to cease to exist in Ubuntu if you're not paying for Ubuntu Pro. I have no definitive proof of that, but it's not clear what they're trying to do and I tend to assume the worst in those situations.
That forum thread feels like they're being intentionally vague about what they're trying to do which I don't like.
Can anyone here explain what's actually going on with updates in Ubuntu now?
1. https://ubuntu.com/security/esm
2. https://discourse.ubuntu.com/t/why-is-extended-security-main...
It did it twice, but I couldn’t figure out why.
I am mildly peeved at the whole CentOS debacle but wouldn't mind running Fedora on a personal server.
Absolutely. I also use Squid[0] as a proxy for updates[1] which, after initial download for one of the dozens of my Fedora boxes, caches the updates, reducing bandwidth usage and (more importantly) speeding up updates significantly.
[0] https://serverfault.com/questions/837291/squid-and-caching-o...
[1] https://linuxiac.com/how-to-use-yum-dnf-command-with-a-proxy...
I also use Manjaro on the side but for a rolling release it lags slightly behind OpenSUSE Tumbleweed. AUR provides a good supplement of software but more are providing alternatives via Flatpak nowadays. Fedora is a good choice too. I recommend trying all of these before making a decision.
The centos debacle was poorly handled but I think what red hat was /trying/ to do made sense. The community just wasn’t there to sustain it. Red Hat was paying to give away free RHEL basically lol. CentOS Stream should have just been called RHEL Stream. It’s basically RHEL minus minor bugs that would only effect small pools of people.
I’m glad Rocky and Alma sprung up and have budding communities though.
“We work on LMDE primarily for us, to get that information. It is not a priority, certainly not compared to Linux Mint itself…” https://blog.linuxmint.com/?p=4276
A large chunk of the gcc/glibc/GNOME/Wayland/... developers are employed by Red Hat and Fedora shows that, it's where the Linux workstation is going and has an amazingly good of integration of new tech. Most other mainstream distributions trail by several years.
https://linuxmint-user-guide.readthedocs.io/en/latest/snap.h...
Another Ubuntu derivative that does not use snaps is System76's Pop!_OS
I happen to dislike snaps as well. The hard coded install directory is a passion point for me. But at least the permissions issue they are getting right.
I wish that desktop distros would adopt the Android permissions paradigm.
Honestly, I don't think a weather app would access a camera or microphone. That seems like a bad example. Honestly, I put a piece of tape over my camera. It looks like other posters in this thread have solutions.
Using more hard drive space than needed and not being able to control the service are show-stoppers for a lot of people, and it looks like the permissions issue has another solution.
Fedora is especially useful for a new hardware workstation with that year of support. Any longer than that in my experience you tend to run into issues. For example: DXVK, for Windows games with Steam/Proton, just moved to requiring Mesa 22.0 as a minimum and Fedora 35 has Mesa 22.1 something. Similar issues with Ruby development in the past.
Updates are more limited, with a few select packages kept rolling compared to a true rolling distro like Arch. When a new kernel series is release (6.0 => 6.1) Fedora holds off for a few weeks to test until 6.0 goes EOL. Gnome is kept to it's major release with only minor versions to fix bugs. Mesa is updated until a Fedora is released. Firefox is kept up to date and I use the snap for VSCode and Chromium based browsers. Most other packages are not updated to major new versions, except for Vim (and Emacs if I remember).
I could also see people not wanting Wayland by default, though that has been working fine for me and the software I use.
I've only been using Fedora for 2 years, but apart from those two decisions, it's been a lot more stable than my time with Ubuntu.
It takes a single line change in /etc/gdm/custom.conf to disable it.
It does not actually say how it interacts with existing rpms or whether said rpms will continue to exist or be maintained in the future.
I would say it's too early to get up in arms about just yet.
Me personally, I agree with this approach, but a lot of other people clearly won't.
https://ask.fedoraproject.org/t/proprietary-video-codecs-are...
Fedora isn't really noon friendly, and probably will never be, because of copyright limitations compared to the UK where Canonical is based.
It's still a shame for AMD GPU users, of course, although understandable from the point of view of legal risk management.
Also dnf-autoupdate doesn't support auto restarts to update the kernel.
Here “supports” means “does not result in itself in a loss of support coverage”. It's been possible to do it in an unsupported fashion before.
1. Restart is ok: automatically apply all security updates as they come out ("dnf-automatic), then restart if required ("needs-restarting -r").
2. Restart is not ok: automatically apply all kernel patches as they come out("kpatch auto")
However its o my going to work on rhel 10 or anything that has very very up to date DNF version.
A bad decision was to use a Fedora mix with KDE. It works very well, but I think its rough edges would simply not be there if I'd chosen the GNOME path. You get the sense that the RH team default to GNOME and KDE is an afterthought. Which is fine by me, but its a bit of a shame, cos I much prefer it.
I've been using Fedora as a desktop for many years and agree that KDE is annoying. That said, I understand your point of view, but I find Gnome to be even more so.
Which is why I use XFCE[0] instead. It generally works pretty well, although I don't push it all that hard. Perhaps it might be a good desktop for you too?
[0] https://techviewleo.com/install-xfce-desktop-environment-on-...
I cannot begin to address the issue of "agendae" of various Linux and BSD distro builders, as any number of disagreements have arisen about almost any of them for many reasons (i.e. systemd, dbus, proprietary software, personality differences, etc. etc.)
I'll just add that if you have time, set up several Linux and/or BSD OSes in VMs and take them each for a spin to find what suits you.
It's a good idea, and if you like the idea of setting up your computers by programming in Scheme, Guix will be right up your alley.
For an end-user machine, I've found that rolling release is much better than point release (much newer, less buggy/crashy -- paradoxically -- versions of software and GPU drivers). (Although, surprisingly, Fedora seems to have very fast package updates despite being a point release.) For rolling, Manjaro is my top pick. Arch is a close second, assuming you've mastered the arcane art of its installation.
You might be thinking, "But a fringe, rolling release distribution can't be as stable as Ubuntu, the de facto default point release distro that ostensibly claims 99% of Linux marketshare." You would be insane to not be thinking that. But I guess companies' potential for incompetence is even more insane since that's been the opposite of my experience. I've had less installation issues and crashes during daily use of Manjaro than on Ubuntu over the last few years, which really surprised me. It's like Ubuntu is decaying. Or maybe I just got bad RNG. Or maybe it's that program and DE devs are always working on the latest version of their software while older versions are an afterthought, so rolling distributions that keep you up to date with the latest versions seem stabler. :p
Archinstall [1] exists, so there isn't much reason to use Manjaro anymore (which has a lot of its own issues anyways [2])
[1] https://wiki.archlinux.org/title/Archinstall
[2] https://manjarno.snorlax.sh/
For production, take a look at SUSE (3 production servers with no hiccups, good support and no particular weird design decisions), CentOS stream after RHEL debacle (have 1 deployment on client request, no complaints or production issues so far), and of course the good old Debian if you want familiar things with Ubuntu
Look even further at Devuan, made by people who conder Debian as a bit dirty. (I use both as needed, I'm just riffing on your comment)
In what case do you need to opt for a different init system than systemd? Genuinely curious, as I've been using debian with systemd for almost a decade now and haven't run into any issues regarding it.
But really, the “I use both as needed” is the statement which pokes my interest. When do you need something else than systemd? What is the actual work which doesn't run with that particular init system? I'm honestly unsure if you were just joking or if there's really something more to it.^^'
If you want technological merit, chose Debian. If you want to join the conservatives of Linux, you should go for Devuan.
Debian is reputable because it is widely widely used for ages.
Devuan is not disreputable. It is simply a fringe variant of Debian that has much fewer users and no obvious reason to adopt for most people.
Debian has a good reputation.
Devuan does not have much of a reputation at all, because most people that might use it have no problem with using Debian and systemd.
No, it wasn't. There was only one ex-Debian person in their team.
I know it's weird for me to object to your comment without implying that you're insane. It's alright to feel like using systemd after a tangle of init scripts was a breath of fresh air. I understand that point of view. I don't understand the invective against people who put their money where their mouths were.
I understand that legacy users and orgs may have vested interests in sticking with older init systems, but personally I think systemd solves a challenging problem space in a very easy to use manner.
I much prefer writing a systemd unit file than having to wade into sysvinit or runit.
Politics aside - I just find systemd far easier to work with.
Long term though there's a query over support for anything other than systemd in Debian, hence the move towards Devuan.
For home use, Debian testing is usually a good balance between things not breaking and things not being ancient.
For servers, Debian stable is probably a better choice.
Even the current stable is fairly “new” so I don’t even mind.
In practice this means adding something like this to /etc/apt/preferences (along with adding entries for `unstable` in /etc/apt/sources.list)
That way apt will pull in any packages missing in testing from unstable, and once the package is reintroduced to testing, will prefer that version rather than continue to track unstable.Maybe I've been lucky but I've been running testing on my non-server desktops and laptops for 13 years now and have only rendered my system unbootable once (required having to boot up a live CD to reinstall an older working version of some bad libpcre update that had been rolled out).
I think it's better to avoid pinning to testing since it gets a lot of updates right after a stable promotion (after the package unfreeze), which you probably don't want.
You can do that with any distribution, unless you expect your configs to line up exactly.
If you don't keep your /home on a separate partition, back it up. Install Debian, making sure to separate /home and root into different partitions this time. Go through your ~/.configs, find the ones you've changed (most of this will probably be browser shit) and put copies aside. Then take all of the configs out of your home directory backup (including the originals of your changed configs) and put those aside in a different place, deleting them from the backup of your home directory. Backup the virgin ~/.configs from your new install (do not delete them from the new home directory.) Then copy your old home directory files (sans configs) over your new ones using rsync. Compare your manually changed files to the virgin files from the install - has the format changed, will they still work? Are they located in the same directory in Debian as in your previous distro? If it looks fine, copy them in. See if they work. If they don't, look up why not. They probably will.
If you keep your home on a different partition, then install as if you don't, and let Debian create a home in the same partition as the new OS. Do the same config dance as above (annihilating your old configs other than the customized ones), and switch your /home to be mounted from your old home partition.
Or at least this is what I do. On your desktop, you probably want to install testing, on your servers stable.
Warning: if you're used to PPA life in Ubuntu Debian doesn't offer an equivalent that I'm aware of. EDIT sibling comments indicate home brew might solve this.
The problem with Debian is you can't usually pick "a thing" from another channel, you mostly have to fully commit. Testing is great until it isn't and anecdotally sid/unstable never fixed that for me - I just had to learn to build the occasional package from source
Ultimately I'm a lot happier having gone on that journey but it can feel very arduous the first few times apt doesn't have a recent enough version of something available
Distros with rolling releases seem to do much better.
That exists only in your imagination, so, imagine whatever you like.
Sounds like you want Debian, but you might want to explore the disgruntled CentOS forks/replacements if you want the appearance of an enterprise distribution (that's what "stable and supported for the next twenty years" means) without the pesky problem of having to be aware that there is an enterprise driving it.
May as well look at FreeBSD while you're here, though.
I switched mostly to Manjaro a long time ago and I've only had a couple of issues with it, for whatever that's worth.
1. Snaps are infecting all distros, not just Ubuntu. This affects desktop more than servers, though LetsEncrypt/Certbot are major culprits on servers. I have managed to work around this on my debian servers with a combination of podman & certbot's dockerhub images but it's a sad state of affairs that such fuckery is needed.
2. Hardware support is the perennial issue on desktop & I was still getting hit by this in 2022 on Debian with AMD drivers & multi monitor/KVM support. This obviously isn't a worry on servers.
---
* fwiw I switched away from Debian on desktop to Gentoo, which I used to use years ago before getting a little fed up with compile times. Have found compile times to be absolutely miniscule on modern hw compared to what I remembered, & binary ebuilds much more plentiful than in the past too. Had always found it the most sane, stable & up-to-date distro in the past, with compile times really being the only downside, so would recommend for anyone looking to try out something new. Unlike Arch, Gentoo does a lot for you: it's really just the initial install that's a pain.
It's cool if you like it's default DE setup, but I don't see any real advantage over Debian, & unless you're using LMDE, it's gonna suffer from all the disadvantages of modern Ubuntu. It's been hit just as hard by snaps - Debian is being hit too but not as hard as Mint or Ubuntu.
There is also a Debian-based Linux Mint (LMDE) which might be preferred to regular Debian for desktop use.
ArchLinux is the unassuming kind of distro that gives way to upstream.
tl;dr: Asahi works great on Apple Silicon. There’s a small collection of software (like Widevine/Zig) that isn’t available on Asahi/ARM64, and some important features that are still in progress (Speakers/Webcam/Mic/External Monitors). GPU and Sleep support is still experimental, but the device is usable enough for me (No critical showstoppers so far).
I am one of them, having switched from Ubuntu to Arch two or so years ago due to frustrations with the platform. Arch is a bit more hands on, especially at first install, but it has solved all my complaints from Ubuntu. If OP is interested, I would recommend looking at EndeavourOS, which is probably the most friendly way to get into the Arch ecosystem, without it getting in the way.
They are doing a great work with their shell on top of Gnome and their own DE is on the way. Even though they are a company, they take the community seriously.
I can't wait to have a DE with screen independent workspaces.
https://distrowatch.com/
Try some out as VMs before comitting to bare metal installs.
EDIT: I see that MX Linux continues to reside as the "top" distro according to that site's methodology. MX has been on top there for a very long time.
Very pragmatic mindset towards daily driver on whatever(common) hardware under whichever circumstances.
Maybe that motivated users to rank it up there? (I didn't, btw.)
https://distrowatch.com/dwres.php?resource=popularity
However, I use Debian for all of my personal projects and infrastructure.
The reason? There's no for-profit corporate interest directly controlling the project. The project's organizational structure resembles a constitutional democracy:
https://www.debian.org/intro/organization
There is an incorporated entity in the United States to handle a number of intellectual property and financial concerns:
https://www.spi-inc.org/projects/debian/
However, it exists as a non-profit with a very narrowly defined, specific set of purposes:
https://www.spi-inc.org/corporate/certificate-of-incorporati...
Because of this, I feel like the Debian project has a good combination of people and resources, making it easy to rely on long-term, but without the for-profit corporate interests that may conflict with my own in the future.
as a long time debian user in the 90s, ubuntu was an exciting new step for debian based distros.
Many different technical decisuons.
A very different project governance.
I'm not implying that these things are bad! But different enough they undeniably are.
The fact that I can install .deb packages on my box using a port of apt does not make it Debian. (Saying this as a dedicated Debian user since 1998 and until the switch to systemd.)
Can confirm, it will continue to keep working, however there might be some things that piss one off in a similar manner as Ubuntu's snaps. I hate systemd for example, but grudgingly accept it.
I don't like everything depending on systemd it feels like too much complexity at the wrong part of the stack. It doesn't jive with my sense of architecture, it's not well designed software.
Basically, a task running as pid 1 (including in a container) could call a new kpid1() syscall, which would cause the kernel to completely take it over. The kernel would take care of all the usual init work, and it would expose the minimal API (presumably using a new kind of fd) to allow a different task to give it instructions and manage zombies as needed. And that’s it.
It’s worth noting that the entire concept of pid 1 is very unixy, but not in a good way. Reasonable modern designs (e.g. all the Windows variants) don’t have any real equivalent.
If you take anything resembling a fresh look at this concept, it's absurd. Imagine if every open file had a systemwide unique id, and one specific process owned that id and would continue to own it until it released it.
Reasonable designs use weak references that don't have values that can be compared across processes. These are usually called "handles" or "file descriptors", and they don't have this problem at all. Nothing reaps sockets, for example, and nothing needs to.
Zombie reaping could have a reasonable API. (Signals are miserable.)
PID 1 is magic in problematic ways. In particular, if PID 1 crashes, the whole system goes down with it. And having PID 1 be a normal program running from a normal ELF file means that that ELF file is pinned for the life of the system or at least until it execs something else. So handoff from initramfs to a real fs either involves PID 1 calling execve() or involves leaving the init process around. Upgrading the package containing PID 1 requires execve(). Running PID 1 from a network filesystem or an unreliable device risks a kernel panic for no good reason.
With PID 1 moved to the kernel, the actual service management job is no longer coupled to PID 1’s legacy. A service manager could hand off to another one by saving its state to disk and exiting, by running the new one and moving its state after the new one starts, or by any other ordinary means. And if it crashes, you can ssh in, read logs, save work, and then restart it or the whole system as appropriate.
As a minor additional benefit, having PID 1 in the kernel could enable some optimizations. Right now, a process must enter the zombie state when it exits, and it must stay in that state until its parent wakes up and reaps it. So a service exiting fundamentally involves some complex bookkeeping and a context switch to a single, unrelated process. If the kernel knew that kpid1 was in use and that nothing in the system actually needs to be notified of exiting children of pid 1, then a child of pid 1 that exits could simply go away, as it would on a sensible system like Windows.
(Yes, it's okay to admit that, in some respects, Windows is substantially better than Linux/Unix.)
> text files or symlinks for configuration and text files for logging.
Systemd gets this right and arguably pushed the whole ecosystem in this direction. The old rc scripts could barely be considered a text file and symlink configuration system — they were a pile of text files containing a miserable combination of code and configuration mixed together, along with a very simple configuration (this service is enabled in these runlevels, more or less) that got translated, hopefully correctly, into symlinks. Of course, nothing really kept the symlink farm consistent with itself or anything else except a pile of additional scripts associated with packages that tried and usually succeeded.
I'm not sure what the "right" solution looks like, perhaps a directory of TOML or JSON files. Perhaps the aforementioned + executable shell scripts with predictable naming? handwave handwave as long as it's "UNIXy". (consist of easy to edit text & not invent a new anything & be composed of pieces which do one thing well)
> text files for logging
...just sucks, on both embedded systems and production servers. (I.e. anywhere where you aren't debugging the machine on the machine, but rather from another machine.)
Either the program just writes to a plain text file forever — and so fills up your disk the first time it goes haywire (so now you have two critical runtime problems!); or it implements its own log rotation and compression (as must every other daemon — not very unixy!); or it must be specifically wired to work with syslog APIs in order to use rsyslog (which, by the way, uses binary wire protocols as well; logging at scale hasn't been text-based in a long time.)
Journald, meanwhile, just sits on the other side of the pipe from any systemd service-unit's stdout + stderr; manages log rotation + compression in a centralized way (which also means you get cross-unit log compression for free); and offers CLI tooling to pipe the multiplexed log stream back into anything that wants to read from it, in whatever format those things want to read from it (i.e. tools that want JSON Lines, get JSON Lines; tools that want plaintext, get plaintext; tools that want a binary record stream, get a binary record stream.)
Is this a Unixy approach? Well, it's pretty much the same one taken by the extremely venerable Unix/Linux line-printer (lp) subsystem — CLI commands, with textual config files, for interacting with a system daemon (lpd) that manages and manipulates binary state files, within daemon-owned directories. Would you complain that the contents of /var/spool/lpd aren't human-readable?
Ehrm, no. Managing a sizeable fleet, with a central logging server for 1.5 decades, and we never had the problems you mentioned:
> and so fills up your disk the first time it goes haywire.
This is a bug of the program or configuration mistake or your monitoring is not working as intended.
Funnily, we're seeing more disk pressure from systemd journals. Go, figure.
Just remembered: syslog daemons have rate-suppression mechanisms to prevent big lines repeating too fast and preventing your disk from filling up. So even your program enters an infinite loop, a well configured syslog daemon (rsyslog, syslog-ng, whatnot), should note "X similar errors have been supressed.", where X can be anything from 2 to 1000 (or even more).
> or it implements its own log rotation and compression
Which you can disable 99% of the time and just delegate the stuff to logrotate.
> it must be specifically wired to work with syslog APIs in order to use rsyslog
rsyslog is just a syslog daemon. syslog is kernel plumbing at this level. You can terminate this pipe with anything.
> Journald, meanwhile, just sits on the other side of the pipe from any systemd service-unit's stdout + stderr; manages log rotation...
And provides nothing new when compared to syslog plumbing. A binary log, some tooling around that, and that's it. It even makes per daemon log monitoring harder by blinding syslog-aware monitoring and automation tools, hence we need to enable rsyslog on the system too. Now we have two journals. Neat.
> venerable Unix/Linux line-printer (lp) subsystem
Which only handles "line-printer" subsystem, and yes, it's more UNIXy. It doesn't get the text output, bashes into a binary data structure, and doesn't try to replace anything and everything from boot to logs to time sync to user login to tap water temperature.
It just stores its state in binary file. Which almost every UNIX daemon does. Incl, but not limited to X11 & CUPS.
So configure journald correctly? It has multiple options to control disk usage from logs -- `man journald.conf` and search for "MaxUse" for the relevant options.
> Just remembered: syslog daemons have rate-suppression mechanisms
So does journald. Relevant options are RateLimitIntervalSec and RateLimitBurst, and individual services can set their own limits as well.
So configure logrotate correctly; you hardly need journald for that.
Like...Systemd?
How is that different from I don't like relativity theory at a fundamental level. It feels abundant, bloated, and not very physical. I'd rather have my Newton's law with a handful of augmentation.
I fought against systemd for a while, too
I was wrong
The "if it ain't broke, why fix it" approach with 'classic' init scripts led to a far far messier place than systemd
My only complaint about systemd is that I haven't found a way to push the journal to text simply ...and that's most likely my poor google-fu or not having enough to time to fully dive into it, rather than "systemd's journal sucks"
Systemd does use "text files or symlinks for configuration"
It's very well designed - though you may happen to have a preference for a different architecture (...but the one you described is pretty much systemd, my friend :))
Would you write an optimizing compiler in multiple small tools as well? Essential complexity can’t be reduced, IPC will blow up your accidental complexity budget. Many times a monolith is indeed the best design choice.
Now it's better, not but perfect, and a lead dev working for Microsoft doesn't inspire confidence about its long term agenda.
I can post links to comments of mine if you're interested further.
I’d like to learn more!
For myself, eh. I find it a little annoying but basically tolerable, sort of like a reinvention of SMF from solaris. Linux system config / init has gotten a hell of a lot more complex since I first touched it in the mid-90s, sometimes we get more functionality for that and other times the grognard in me wants to bin it all and retreat to Slackware or something. What was the old joke, Microsoft admins have solitare.exe and Linux admins have "fiddling with text files"? :)
My issues with it are:
- If you setup an atypical configuration, particularly involving luks volumes, it is not hard to break systemd and dracut's assumptions, and then you will have a hell of time trying to boot and survive systemd updates.
- When it breaks, figuring out what the hell is going on involves having to learn a lot of systemd, which has lots of its own unique vocabulary and logic. There are many pieces and moving parts. It feels like someone went "microservice-crazy" with the init system and like there has to be a simpler way. The surface area of systemd is enormous.
- The whole anti-split /usr crusade is excessive. You might want to have /usr as a separate volume so you can mount it with the nodev option, for example. Why should that be forbidden?
If you conform to systemd's expectations about system configuration, I'm sure it works fine regardless of its elegance/inelegance and excessive complexity. If you would like to do things differently in ways that Linux's building blocks otherwise permit, you could be in serious trouble.
:P
For me it's more to worry about: the influence that paid Ubuntu developers gain, year after year, inside Debian. Or the presence of ubuntu/canonical changes inside Debian packages.
Regarding Ubuntu... I'm forced to use it at work, and we use to "debianize" ubuntu servers... this is: remove snaps and snapd, remove netplan (for ifupdown), remove lot of dependencies that come with the minimal install (used only for their paid services), remove many services/packages (cloudinit, multipathd, polkit, motd-news, lxd, apport, etc)...
And the recommends of the recommends of the recommends of the recommends of all that.
In the last LTS, we we're forced to build our own installer at the end: a minimal live system + debootstrap + a couple of scripts (parted/mkfs/grub-install).
With the previous debian-based installer, we were able to fix most of the Canonical decisions via preseed... with the last version it was a pain until I did our own installer.
Still, for many people, being driven by ubuntu, is perfectly fine. They use to hate forced UI changes (i.e. my mum), but everything else is fine for them while "it works".
It's maybe just more technical people who are bothered by the underlying changes.
https://www.debian.org/social_contract
Works for me without systemd, no problem.
I already use systemd in hundreds of systems at work and personal servers/vps.
But on my personal laptop, I have too many custom stuff after 20 years of thinking around, glued across all the layers (kernel, boot loader, init, background services, tty, graphical environment) and I did choose to keep my laptop with the traditional equiv of all the things that systemd does, just because of that.
Debian is really flexible to allow you to choose components in the system, or to have more than one equivalent component, and to configure how they interact, and still be considered an official Debian system.
And even to allow to people like me to do your own Debian if you want. That is the "official Debian" that I like, the one that allows me, that doesn't force me.
> In the last LTS, we we're forced to build our own installer at the end: a minimal live system + debootstrap + a couple of scripts (parted/mkfs/grub-install).
That is a lot of work. Why not use Debian itself? If you want that lts support you can use AlmaLinux in the RHEL clone camp. Not aware of any upsells in that system from my usage of it as a kiosk. The desktop is rough with some common packages missing from EL9, but the server would be excellent. Even CentOS Stream has longer free support than free Ubuntu LTS.
Everyone's entitled to their opinion, but everytime I hear this, I have difficulty listening to the rest.
Systemd is 10x easier and more manageable than every alternative.
(As a sysadmin of 15 years, I can clearly say all of them have their advantages and disadvantages, but being easy and manageable is not an advantage of systemd, but a property of all of them)
The huge list of services with not-for-human names so your job can look complicated and essential.
It's been 10 years now? I wouldn't go back, most of the suggested alternatives are so basic that troubleshooting becomes a chore. Almost all the hate is because they don't like Lennart.
We should fork it, get someone else to head that with a different name to get them on board.
Yeah, the dependency is a fine feature, but before it was even *easier*... just put a number on the rc.d symlink.
c'mon, if you think that is harder than editing a dozen files, remembering weirdly named camelCase attributes and then pointing to randomly named services, then i don't know what to say. But again, i also accepted it, for better or worse.
Now, i don't care about lennart, but i hated systemd for most of the time because they pushed an incomplete crap over something that was working, just to get contributors. If redhat wanted their cisco/windows services management clone, they could have worked on it. Doing what they did (i call it to pull a gnome) was just shitty behaviour and they should always be remembered for such action.
I think this why a lot of people really hate systemd. Suddenly a bunch of arcane knowledge used to maintain specific scripts got made redundant.
Also, I have only seen two or so massive scripts about services. Most of them were slight variations of a standard boilerplate code.
Create a service that starts on boot:
And the harder things get, the bigger the advantage. Like if you want to mount a disk, create a socket, and then afterward start unprivileged service...all very simple.(Block systemd in a preference file with priority -1. apt install openrc (for example). Read the warnings. Reboot. apt purge systemd. Freedom.)
I suspect OP is considering a change from Ubuntu because Ubuntu itself has diverged so far from its original identity as a reasonably stable Debian-unstable fork.
It was several years ago that I abandoned Ubuntu in favor of Archlinux for that very reason. These days, I'm almost exclusively using NixOS, but can't recommend it to impatient or non-technical users. NixOS is incredibly stable, very fresh/up-to-date, and incredibly chaotic to use. Someday, I expect, there will exist something of a "distribution" of NixOS that - much like Ubuntu did circa 2008 - caters to the average user. I hope that day comes soon.
But back to the "ubuntu exists" premise you started, it is because a rich guy wanted to take over debian and sell an enterprise solution based on it.
remember at the time enterprise was all the rave. google was pushing their enterprise suite, and there was ton of startups (zoho, etc) it was a crowded space then and red hat, suze were completely fumbling with their linuxes.
they paid for "CD vending machines" at several locations where you could get free cds... that is more expensive than a billboard and practically buys you a spot on specialized magazines. They were going those marketing campaigns all over the place.
Debian ultimately follows the OSS community for most stuff, and the 'community' is often corporation backed. Just look at systemd. A lot of distros didn't want it, but ultimately were stuck between maintaining masses of stuff themselves, or accepting Red Hat to maintain it for them. There are many other examples.
1: https://pop.system76.com/
[1] https://coreos.github.io/rpm-ostree/container/
Then the safest bet is to choose something that was popular and stable twenty years ago.
https://en.wikipedia.org/wiki/Lindy_effect ("...the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy")
You *probably* just want Debian. There's many reasonable options but that one's the Schelling point for this question (I think).
edit: Here's the list of Slashdot linux threads from 2003. I think anything flamed in there that's still around is a Lindy candidate.
https://www.google.com/search?q=site:linux.slashdot.org/stor...
Ubuntu is completely based upon Debian. Going back to Debian ensure familiarity with tools (like apt). Also, the longer release cycle is perfectly adapted for people using only Ubuntu LTS (which, in itself, is quite awkward as Ubuntu was created to allow short release cycle for desktop users).
There’s also multiple companies offering Debian support if needed.
And it can safely be assumed that Debian is probably one of the 10 operating systems with the most probability of still being supported in 20 years.
On the downsides, you may end using some experimental/external repositories to have some bleeding edges applications and those make dist-upgrade often problematic (not that it is better with Ubuntu). You may also lose some automatic configuration at install time. I’ve one laptop which, for example, does not have middle-click working out-of-the box (it is just one apt-get away but you have to know what you want).
So, yeah, Debian should be one of the first to consider.
My impression is that Ubuntu had people testing it on modern hardware, either on the Canonical side, or perhaps on the Dell side (even though I don't own any Dell now)
About 10 years ago I installed Debian on a desktop, and I remember having graphics issues that I didn't have with Ubuntu.
I guess I needed the proprietary driver that Ubuntu offered? I don't remember exactly. Probably some nvidia crap
But either way, I just want to buy some hardware and have the graphics and sound work.
Is Ubuntu currently any better than Debian in that regard? Do they have more testing, or are they the same now?
The good news is that Debian is a very popular distro. You'll be able to find copious amount of information online to guide you to relevant hardware support [1].
It's not at all a "it just works" situation. But if you're comfortable with getting your hands a bit dirty, and you're not using any super exotic hardware, it's not at all bad.
[1]: https://wiki.debian.org/NvidiaGraphicsDrivers
Now Debian seems to run on everything I throw it at. YMMV of course.
- https://cdimage.debian.org/images/unofficial/non-free/images...
and apt config:
The non-free installer is separated from the "official" installer though. There is a general push to "fix" the multiple installer issue, but I think how exactly to fix it is still up in the air. The listed winner in the 2022 vote to "Change <the debian social contract> for non-free firmware in installer, one installer" also notes it needs a 3:1 majority (but I don't know much about the machinations of Debian policy/voting).- https://www.debian.org/vote/2022/vote_003
// add: everyone says Debian. good Linux. but OP didn't say Linux, they said stable over decades, no corpos.
For personal use... I fell in love with Arch. Between the Arch User Repository (AUR) and the quick upgrades, I really struggle to use anything else these days.
Arch takes a bit more work to get online than some of the other distros, but I've been amazingly happy running it across all my personal machines (from desktops to laptops to servers to media machines) - It's a fantastic engine to build a machine around, but you will have to do a bit of building.
Something that is hard to quantify - arch uses vanilla software, almost entirely. Very very few patches/configurations are deployed. This means you're actually learning about the upstream software, not the distro.
What you learn on Arch, generally applies to other distros as you know something about the upstream software. I don't know a thing about debian, but I can generally figure things out.