- the procedure for upgrading to a newer release of ubuntu it you run sed as root to fix your sources.list, then you do-release-upgrade, but it doesn't work because it has an undocumented dependency on pciutils

- at this point i should be used to this pciutils thing since ~all software has undocumented dependencies on autoconf, automake, autotools, libtool, cmake, ninja, rust, python2, python3, calling the binary called python in your path and expecting it to be a particular version that is 2 or 3 but some stuff needs 2 and other stuff needs 3, perl, npm but not the latest npm, clang but not the clang in the repositories, gcc, nvm, ruby, lua but not the latest lua, bazel, make, openssl, libressl, libcrypto, a different version of libc that will break almost all software on your machine when you install it, a bunch of optional obscurely named C header packages that install the headers into folders that the build won't search for header files and that turn out not to be optional if you want the thing to work at all, and a hundred different javascript build automation and test automation tools that exist mainly to call each other

- snap will just install broken package updates for you and is incapable of undoing this operation by design

- systemd-resolved will randomly just start taking 250+ms to return cached DNS entries so if you call connect() many times per second you need a much bigger threadpool than you may have expected (and this is maybe an architectural change to your software if your previous threadpool size for connect() offloding was 1 or if you were naively calling connect() on your thread where you do actual work)

- if you thought you knew how to set the open file limit for a user, systemd has rearranged your furniture and by the way this operation now requires you to reboot your computer

so i'm not sure ubuntu has been a great fit, but i'm also not switching to anything else

I no longer recommend Ubuntu for this reason to people looking to get into Linux for the first time for developer-adjacent reasons. My recommendation is now Mint or Pop_OS, as they are effectively Ubuntu without Snap.

Edit: I am not blindly against snap, or against its idea outright. I understand what it is for, and if it delivered on that without issue, I would welcome it. My avoidance of Ubuntu is due to having to repeatedly (and increasingly) help Linux newbies through problems, where lately all of those problems have wound up being based in snap.

you can set up systemd in WSL 2 now, and it's supported, but it gave my Ubuntu distro a lot of problems so I disabled it there. in Debian it works great so I left it on.

Never tried Firefox, cannot day works or not, have Firefox on Windows' side of the things.

Are you talking about upgrading an lts release to the next dot.1 lts release, without dodgy third party apt-sources enabled?

When you skip releases, no distro will officially support such upgrades (except for Ubuntu LTS-to-LTS, without skipping an LTS), and things might break.

Also, when you really want to skip releases, it is often better (IME) to change the sources manually and not use do-release-upgrade, but use aptitude and/or synaptic and/or other such tools to fix the dependencies manually. In any case, you might have to fix some breakage afterwards (or mid-upgrade…), as it is untested & unsupported.

I'd have assumed Arch and friends.

> I'd have assumed Arch and friends.

I'm a huge Arch (and NixOS) user. But one of the things that I think is difficult about Arch in an enterprise is that by design it is difficult to standardize enterprise tooling around. Ubuntu, on the other hand, has a bunch of defaults that can be more reliably be predicted for in an enterprise.

I'm a security engineer and I've thought long and hard about why enterprise applications often lack Linux support -- it would be difficult to have something that works across the board (there are so many choices of desktop environments, notification daemons, network subsystems, etc.). If I were to write enterprise applications that targeted Linux I would probably target the default config of the current LTS release of Ubuntu (Gnome as the desktop environment, etc.).

I feel like Ubuntu is the desktop developer environment for the enterprise that is forward enough to support desktop Linux.

I've been trying to have a similar strategy to you with regards to enterprise long-uptime application deployments. I target RHEL and Debian Sid because they move at a almost glacial pace and have quite a bit of documentation.

Do you ever wonder what the trajectory of Microsoft and Canonical looks like with regards to an M&A perspective? It would be a good contender to counter Red Hat's dominance in the enterprise space.

Same reason they brought MSSQL to Linux.

Azure integration

But that doesn't say anything about the majority of the developers out there. From my experience Python and Ruby guys usually do use Linux and macOS, while .NET and Java devs run almost always Windows on their PCs and laptops.

M1 has made a lot of people eager to jump too.

However with containers running directly on top of hypervisors and serverless, it is only a matter of time until the actuall OS of the server room is irrelevant.

Until then, Linux and BSD (which they also support) are business relevant.