it's a freaking mess but ambitious if you want a single code based (with 10 code bases hidden)

Reality is that both snap (2014) and upstart (2006) came before flatpak (2015) and systemd (2010).

Now there might be valid reason why the later options are superior, however accusing Ubuntu to just do something different out of "fancy" seems quite unfair. They did develop a solution for things theat where widely regarded as problems (as evidenced by others later doing the same thing), where they failed (and there are multiple reasons IMO) is getting their solutions adopted by the wider community.

I moved to Debian and found there was not really any small bugs and, as a bonus, no major things completely broken like Ubuntu broke a few packages with some sort of snap dpkg confusion.

Ubuntu has a bit of a stinky vibe lately. The whole lxd thing and the number of people I know, some I have worked with and are great, went to work there and left quickly.

Chances are that if you're installing a server that's new enough to need to run Debian Testing (or newer), you probably already know what you need to know. So yeah Testing is more for Desktops.

I tried the reportbug utility once, it made up an email for me (related to my machine's hostname) and I never ever heard about the bug again. Couldn't find it on the web interface. I'm not that stupid and I failed to report a bug. Beautiful web interfaces are a million times better for bugs, and they're also capable to send e-mail notifications to whoever wants them.

Oh don't worry, no offense taken. It's an interesting problem: dogfooding is definitely a good way to catch problems, but if your release is unstable enough to break machines, you can end up with a wide swath of the company being unproductive. The stability of the overall release wasn't one of my core responsibilities, so naturally I gave more priority to the things that were; I needed a release that worked so I could get my job done.

There might be some cultural solutions to that. For example, if the company expects that employees are dogfooding, perhaps testing out a beta in a specific timeframe, it could be culturally expected that devs might have broken machines during that timeframe. If was that taken into account in both the schedule as well as support paths, that would make things a bit easier. Honestly, though, even if that were the case, it would still be a hard sell for me. Quite simply: I don't like failing at my duties. I would need to be convinced that this was one of my duties, and I'm not sure how the company would pull that off. And that's ignoring other very practical concerns, such as the fact that a fair number of Canonical engineers only have one work machine. Having that machine down, depending on the definition of "down," can make it difficult to get support in the first place.

As for development/hackability: you need to understand ostree, rpm-ostree, and flatpak fundamentals, not be afraid to layer packages where containerization is impossible or inconvenient, and accept that cookie-cutter configuration recipes intended for other distros aren't likely to work.

I'd also recommend distrobox over the bundled toolbox for managing distro environment containers, because useful additional features.

With all that said, I've been using Silverblue+Kinoite daily as a development (Linux + Windows in libvirt-managed VM) system for over a year without no regrets whatsoever, and only trivial complications (e.g., running a trivial shell script to rewrite JetBrains Toolbox-created .desktop files so JetBrains IDEs run in my preferred distrobox container when launched via GUI).

As a shout-out to another Fedora immutable distro, I've also switched to Fedora CoreOS for new home office network service deployments and this has been similarly pleasant and hassle-free.

Can you give some examples? I've been using Universal Blue's silverblue-nvidia extremely happily for a couple months now, and haven't had any issues with it. It's been a great and extremely smooth experience

Thankfully there’s plenty of alternatives where feedback is actually appreciated.