This is the reason I switched over to Arch Linux. I have never been able to upgrade an Ubuntu system without some kind of obscure breakage without a documented fix. I've never encountered this problem with Arch, and archlinux.org both has great documentation and does a great job of alerting users when package upgrades require manual intervention.

Arch is like the CI/CD analogue of operating systems. Small upgrades makes breakages much less common, and much easier to repair. This comes as a trade-off of less battle-tested stability than e.g. Debian, but if you're able to make small repairs proficiently then Arch is the way to go. I'd strongly recommend Arch on a personal computer - it makes a good OS for a pet (although Debian, because versioned releases are much more thoroughly tested, makes for much better cattle OS).

I have a laptop I bought in 2009. I installed archlinux when I got it and upgraded regularly, and it still works.

Debian unstable follows more or less that "CI/CD" approach you're describing, but it is called unstable for a reason: sometimes, a significant change is necessary, which may lead to significant breakage as well, but most of the time, you get small breaks here and there, which are usually easy to fix (and hopefully report, so that break can be handled by the package upgrade process directly).

I wonder how's Arch in that regard. You speak about breakage less common, but there has to be some significant breakage from time to time: for instance, for a shift as important as moving from traditional sys-v init scripts to systemd, it must be expected that a lot of OS configuration related packages would break, unless every package maintainer is made aware that this change would happen, and that he/she has to prepare its package (if necessary) to that shift, AND that the shift only happens when everyone's ready. But Debian (and I suspect Arch as well) do not follow such a rigid scheme, and so there has to be breakages and fixes to follow.

I've encountered far more esoteric, game-breaking issues during Arch upgrades than I ever did with Debian-flavored ones.

I haven't encountered a showstopper arch break, but it might be a statistical thing.

When you install arch, you install each piece on-demand. So only the pieces you have chosen are dragged through updates.

my arch installations tend to be quite lightweight.

> my arch installations tend to be quite lightweight.

That may explain why you don't get that many problems.

If you start pulling in many different components, the set of potential interactions grows exponentially. And if you add to that external software, it easily becomes nightmarish.

I've seen other comments saying that they've been running Debian or what have you for years without any upgrade hickups, and personally I've never had that. The easiest way was always to simply remove as much as possible, start the upgrade, and then pull back whatever I removed, so that the system setup would correctly fall back in to place. And even with that, I sometimes get problems.

The main issue is probably not that upgrades are issue-less. The problem is perhaps the lack of cooperation between distros so that everyone could benefit from the experience others built along the way. But How does one organize that sort of cooperation?

Or maybe there's too much friction between distros and upstream developers?

> If you start pulling in many different components

But if you've made that choice, you will likely be more aware of what you're dealing with.

There are definitely valid reasons to go with big-upgrade-every-year-or-two kinds of distributions. It can make developing software that depends on other software easier, especially if you need binary compatibility. A book or article about that system won't be out-of-date immediately.

Personally I wouldn't mind a few spread-out glitches throughout the year compared to frantically trying to repair a broken system after a dist-upgrade and losing a weekend.

I have had a few glitches with arch, but I think they were mostly some manual intervention for signing keys and didn't harm the system.

Why use Unstable instead of Testing?

Arch looks like it's got a lot going for it, and I sometimes find myself looking at their documentation when I'm trying to shoehorn a package into ubuntu. Even though I used Gentoo linux for a long time, very similar to Arch in lots of ways, I haven't been able to install and configure Arch successfully on my computers. I'm sure if I spend a lot more time on it, I'll be able to do it, but I just don't have that much time to spare, so I stick to ubuntu and variants. But I really do like what I see on Arch.

I also prefer the arch world way over ubuntu. More specific, manjaro.

But sadly I also really can not recommend it, to anyone who does not know english, nor the command line (or have someone close, who knows).

Upgrading from 18.04 isn't supported until July, when 20.04.1 hits. The LTS->LTS upgrade path is handled more conservatively.

If you're not on LTS, then you should upgrade every 6 months when the OS tells you a new distribution is ready, and you'll be fine.

It has a long tradition. It happened to me many years ago: I've upgraded from one version of Ubuntu to another doing the "upgrade" but I had more and more problems. Then I've reached for help over the internet. The answer was "oh you upgrade to the new version? We never try this, we backup our home and install from scratch."

Another interesting point from these times: it was even then often written that the Linux and Ubuntu are better for the use of older computers compared to Windows. That wasn't true either. With every new version less of my hardware worked as expected. The memory demands only for the GUI installer were bigger than the demands of Windows, forcing me to attempt to install from the text mode, and still having the issues later. Windows just worked on the same machine (with the existing drivers).

I've also lived through my (other) old hardware breaking on Windows too: my notebook on which all the hardware worked as expected on Windows 7 was declared by the Windows 10 as "totally would work" and it totally didn't -- the Intel devices on it never got the drivers that worked on Windows 10, neither by Microsoft nor by Intel who simply stopped supporting them.

No OS is immune from the scenario (or even the company claims) "it will work" which than turns out not to be true with a new version.

Long story short, in this case, backup your /home, install from scratch. Backups are good anyway. Any other attempt will probably give more pain. Also don't expect the newest OS to always work with the old hardware. Be prepared for these kinds of events too.

For a real long term, there's Red Hat.

Hopefully people realize it's an Ubuntu problem, and not a general Linux problem.

I pin my Debian machines to the "Testing" branch and "apt-get dist-upgrade" once a month, and I've never had a problem, except once or twice when NVIDIA drivers needed to be re-installed. It's worked great for me for 15 years, but YMMV.

The CPU/memory usage almost certainly has more to do with the software being used than with the distro. The Linux kernel and GNU system utilities can run on very low resource machines, but most "desktop environments," like GNOME, KDE, and even XFCE, are targeting up to date systems. IME, using old hardware usually means putting in some effort to find and configure software that will run well on it - I'm pretty sure it's the same on any OS.

Nah, it's not Ubuntu problem, it just happens because software is complex. It depends on so many factors and things like Debian break just as often.

I've personally had the same install across six Ubuntu installs in total and I know other people like that as well. Anecdotal experience but so is claiming Ubuntu's breakage ratio is higher.

No, Debian releases do not "break just as often". If you really couldn't got from release n to n+1 via apt(-get|itude) due to new packages migrating into testing, this would be a release-critical bug, and have to be corrected before the n+1 release were to be marked stable.

There are certain situations where a Debian upgrade will break a specific package - maybe due to upstream messing up really badly, or maybe due to some unusual way of configuring it. But in that case, the release notes that Debian publishes for each release would cover that particular problem for sure. Mistakes happen, and noone's perfect - but Debian tries to be, and they're very near that ideal in terms of ensuring your ability to upgrade your installation.

Fir me Debian releases are broken to start with. Fresh install of 10.3 resulted in gnome desktop that could not use gui sudo and some package with broken dependencies. Replaced with xubuntu that just worked. This was not the first time I tried Debian with similar results. The "stable" part just means that they distribute an old version of some software and not that it all works.

I thought Debian also moved to a fixed schedule release policy? Doesn't it make it harder to stick to a "release when ready"?

Personally, I don't think that Ubuntu is less perfect that Debian wrt. upgrade quality, it's just that (it seems to me that) the workforce is not as large, and that they also have other projects on their plate (not to say it should be that way or not, I'm merely trying to state the facts).

No, it makes "release when ready" easier, since the entire distribution doesn't have to wait for that single software release becau the next distro release is not that far away. At least that's how it works for Java. (I'm not that deep into Linux distros.)

How is that supposed to work? I understand that it possible to pull the plug on packages which are not ready at time T, but it also means pulling the plug on all the packages that depend on it.

So if libreoffice depends on package P, and that one is not ready, is Debian going to simply drop libreoffice until next release?

Nothing is dropped.

At a very high level, it works like this:

New versions of stuff go into Unstable. When they've been tested a while they get pushed to Testing. Periodically Testing is frozen and branched into a new Stable release. If a package doesn't make it into Testing before the freeze then it's out of luck and has to wait for the next release.

For example, assume libreoffice 1.0 and libfoo 1.0 are in Unstable, Testing and Stable. If libreoffice 1.1 comes out and depends on libfoo 1.1, but libfoo 1.1 is broken in Unstable, then libfoo 1.1 and libreoffice 1.1 won't be pushed to Testing until the issue is fixed. If they don't make it into Testing before the release freeze then the next stable will ship with libreoffice 1.0.

After the freeze, when the libfoo 1.1 is fixed in Unstable, then libreoffice 1.1 and libfoo 1.1 will go into Testing and wait for the next Stable to get branched.

It is surely not anecdotal and telling about "people I know" but the top comment of this thread for Lubuntu 20.04 LTS:

"the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install."

Note that 18.04 was also LTS, so whoever tries to upgrade from one LTS to another, will probably be able to start the process (like before) but at the end will with huge probability be better off just biting the bullet... and fresh install.

If the "people you know" upgrade faster then LTS to LTS they won't see a problem this time.

But being able to upgrade from one LTS to the next LTS is completely reasonable user expectation. I don't even want to try to prove that it will be broken this time.

> but the top comment of this thread for Lubuntu 20.04 LTS:

The one I replied to said Ubuntu not Lubuntu. Big difference.

I have used a lot of distros.

In order of stability from most to least.

LTS -> Bleeding Edge -> 6 month release cycle distros

Stuff like Ubuntu non LTS seems to break as much as bleeding edge but take longer to fix it. It's the worst of both worlds.

I take this approach on all operating systems now; I think I learned it from my dad when upgrading windows 95 to 98. A fresh install has less variability. Sure it takes a little more time to reinstall, but it’s an up front investment in not having complex research tasks later when things are weird.

This is why I abandoned Ubuntu for Arch.

This is not tenable, really.

The things I change are all over the place. From say /var/lib/mysql to /usr/local/bin and of course various /etc things ... it's not enough to say "backup /home and wipe the rest".

Yes, I know, unfortunately there is still too much attitude of "just change as root x y in some/path/accesible/to/root"

A dose of a "normal-user"-hostility is kind of a given in Linux platforms, the best reflected by:

https://xkcd.com/619/

and sometimes it's, unfortunately, unavoidable for us when we are in the user's role to have to "just change as root that x y somewhere."

Long term, the goal should be to raise the awareness that there is a real need for most of the configuration to be easily transferable from the installation to the installation. But what we get instead is "just change as root wherever" and the containers for containers being run in the containers -- more bloat, but still not less demanding to maintain.

I really think Red Hat is not appreciated enough for their work on maintaining stability. The optimal solution will be when we have really stable platforms on which we will be able to easily and cheaply have recent languages, but also stable. Knowing how unstable practically a lot of programming platforms are, I am aware we're still not there. But... raise the awareness!

Honestly the only Linux distros worth trying are Gentoo, Arch, Fedora and RHEL/Oracle/CentOS. With anything else you are just wasting your time with amateur hour attempts to cobble together a Windows/Mac OS competitor without a good understanding of how all the components fit together.

Under no circumstance should anyone listen to this user nor should they run Gentoo or Arch on a production machine. I use Arch on my personal computer but for work I find Debian testing to be the perfect distro. Stability is a trait which matters.

I've been super happy with Gentoo in production for at least a decade. I don't see the issue? I have Gentoo on my desktop+laptop too. But, I also run loads of Debian server systems too. My worst upgrade experience has been Ubuntu systems

Does that mean, you compile updates elsewhere and load the binaries on production?

(Many) years ago I knew someone who was very happy running their business off Gentoo. "It took two weeks to "make world" with the ultimate optimization settings. "But it runs great!"

I never could bring myself to ask if they were ok with being down for 2 weeks if they needed to re-install. Say, in a case where they had an intrusion and didn't trust their backups...

There's no reason they'd have to be down for two weeks in that case. They could use a binary distribution to immediately get back into shape, and then switch over after compilation's finished, or they could compile without -OX and it'd take almost nothing, and then they'd be good to go.

Really, though, nowadays compiling everything, even compiling things for optimal performance, doesn't take that long. Your production machines shouldn't have web browsers, and without the C++ garbage behemoths on it, compilation takes like half an hour on most machines.

I'm not a Gentoo user, but it's kind of silly to act like it makes recovering substantially harder than any other distribution.

This was at a time when compiling just the kernel took 30 minutes, so YMMV. But obviously, I don't know. Just didn't seem to me like the choice is want to make for running a business. Again, ymmv...

I imagine anyone doing this seriously would have a spearate system for building binaries. Obviously if that system was compromised, you would not be in a great situation, but it should be much easire to lock that down.

Do you find debian testing to be stable enough compared to debian stable, for servers?

For similar reasons (stability), I always go for the current stable (although I've a couple machines on oldoldstable, because it takes a while to upgrade...).

fwiw, i run debian unstable in production for 6+ years, updating every few weeks, with 0 issues.

i would assume that testing should be rock solid.

I run Arch Linux for work even though we're a Debian shop, and it has a great many efficiency advantages. I think in hours they are more than worth the three hours of productivity loss it would take me to repair my machine in case something bad happens. Indeed, AUR and the extreme adaptability of Arch probably saves me 2-3 hours a week.

Meh.

I see a lot of people in IT who don't directly do systems-related work (think of QA people for example).

Without Ubuntu they'd be either running mac os or windows.

Ubuntu lowers the bar of linux-on-desktop accessibilty by a lot.

For a lot of people it's okay not to have a good understaning og how all the components fit together.

Agreed, but also: it's important to know that some of the "hardcore/tunable" distros don't provide a good understanding of how components fit together either.

I don't know how it is now, but many years ago it was a running joke that most Gentoo users hadn't the faintest idea of how anything worked, but felt "hardcore" because they could pass many command line flags to the build and felt they were "optimizing" their system -- actual gains were not demonstrably noticeable, but they "felt fast" -- and they had no understanding whatsoever of gcc flags for example. Experienced users had to patiently explain that no, you shouldn't pass that experimental flag to gcc or everything would break.

"Hardcore" Gentoo users believed that by "installing from source" they somehow magically ended up with a faster system. No empirical evidence, of course, just a heartfelt belief compiling source code was magical.

This kind of "hardcore" Gentoo users was very, very, very annoying. Users of Ubuntu were better off: they understood what they worked with regularly and didn't pretend to understand what they didn't need to understand.

I see similar issues from a lot of Arch users tbh. There seems to be a lot of posturing of being a more advanced user, when thats not always the case. I once saw someone confidently explain that their drive device was /dev/nvme instead of /dev/sda because its an arch thing.

I've tried one such "hardcore" distro once (Crux to be exact) and while it was fun for a while, I also wasted a lot of time. Nowadays, I just stick Ubuntu Flavor (am actually running Lubuntu right now) because everything works mostly out of the box. Yes, I know it has its own set of problems, but I have different priorities. I dont particularly care if I get labeled a noob for it.

I also do know a bit of super linux knowledgeable people who dont need to tweak their system and use ubuntu. Sure they used to run super tweaked systems but by now they use lts ubuntu, manually tweaking g their desktop gets old fast. (That said, they do tune the embedded file system they build on that distro and that they are responsible of.) Or developers that work on their interesting problem which is not tweaking a linux desktop.

What does Ubuntu offer over Fedora or Red Hat enterprise Linux?

I'm not saying everyone should run Gentoo, I'm just saying that there is a much more of a justification for Gentoo existing than Ubuntu.

Ubuntu just re-invents the wheel with a bunch of nonstandard stuff so Canonical can sell support see AppArmor, Snaps, Mir, Unity etc...

I just (last 2 weeks) switched from Gentoo to Ubuntu for my personal/home VMs (Linode!). The risk of crap breaking on a emerge world ... was just too high. I think the final straw wsa something related to python2/3 issues breaking emerge it's self. I rebooted it into safe mode, spun up a new Ubuntu image, and rsync'ed to /old_linode/ and then reinstalled bind9 and apache2 and etc. The thing I liked about having local compiles for everything is you could gdb any system binary. As a C programmer for many years, I like seeing real code.

Or, we've been using Linux for a long long time and have no time for compiling from scratch, and like it or not, Ubuntu is the best tested out there for the desktop/laptop. Fedora isn't bad either, mind you.

I'd never run Ubuntu on the server by choice, mind you, but servers are constrained by other considerations.

Since we're talking about compiling from scratch, I spend about a third of the time compiling since I've got Arch on my machine (albeit a fairly powerful Ryzen). The vast breadth of the AUR saves me a lot of time having to figure out how to compile version z of software x.

Care the back that claim up?

Sure, Ubuntu and Debian change the source code/setup of upstream packages, and generally add very little value compared to just using Gentoo/Arch/Red Hat based distros which actually use upstream components with much less touches and provide a more sane way to install your own packages, run docker container etc. In addition, Ubuntu does not do any real work pushing desktop linux forward.

Ubuntu focuses its efforts on ill-advised efforts like writing its own compositor (Mir) and Desktop environment (Unity).

Currently, most work to advance the Linux desktop is focused on a new project called Wayland (Used by Fedora for last few releases), yet Ubuntu has decided to double down on X11, a legacy project that clearly has no future and has issues like screen tearing that are basically impossible to fix.

Another tangible example related to developers: On Fedora/Arch you can run docker containers without requiring root due to Red Hat's work pushing podman forward, however you cannot do this on Ubuntu/debian because they lag behind upstream

I feel like I've gone back in time to 2013 reading your comment.

What was wrong with unity? Plenty of people preferred it.

Also Mir was ill-advised back in 2013 and was dropped in like 2017.

Wayland has been around as long and is only just becoming usable.

Or are you saying that Ubuntu should have funded Wayland development?

Any proof they're "doubling down" on Wayland?

If Ubuntu isn't pushing desktop Linux forward. Gentoo, Arch or Fedora sure ain't.

Also lol. Podman seems to be an alternative to docker. Why should I use that? Why isn't that ill-advised? Is it because Red Hat made it?

What's wrong with this?

https://docs.docker.com/engine/security/rootless/

Podman is a technical superior implementation to docker. No background daemon is required to run.

See details here: https://developers.redhat.com/blog/2019/02/21/podman-and-bui...

I'm not sure what you mean by Ubuntu doubling down on Wayland. They have no plans to migrate to Wayland.

That article told me nothing useful.

Honestly it seems like a clone of docker selling the slight advantage of root less.

Which docker already does.

I don't understand why I should care that it's a Daemon. In fact that blog post says that they won't go into why it's bad. Just that they do things different.

In fact it seems like it's a "Not invented here" implementation from Red Hat.

Searching Hacker news there's not many posts on it. Seems like it'd be as silly as using Mir to run this in production.

Also on my doubling down, I misquoted you saying they're doubling down on X11.

There doesn't seem to be any evidence of this. I wasted time googling it and it looks like they decided not to use Wayland by default in 20.04 because of certain bugs they didn't deep acceptable.

But it comes with Wayland out of the box, and you select it on the login screen.

Lubuntu plans to support Wayland in the 20.10 release by porting Openbox to Mir, which supports Wayland. https://lubuntu.me/lubuntu-development-newsletter-9/

If you choose a distro based on default GUI, I question your Linux knowledge.

I think having a MacOS/Windows competitor is a good start, a lot of people try a Linux distro and choose a flavor that's familiar (Linux Mint is very similar to windows for example).

How is Debian different from all of those in this regard?