Ubuntu 24.04 LTS is so buggy you can't install the OS [video]
youtube.com
youtube.com
Firstly rust for an installer UI? Does it need to be especially fast or memory safe? Maybe. Does it have nice bindings for a UI layer? Maybe, or did they create the bindings for flutter (a UI framework designed for object-oriented Dart) by themselves? So why flutter? I guess it can do some pretty animations. Being maintained by Google and designed for Dart, it may just get abandoned in some time, amplified by the fact that noone uses Dart, except for flutter.
This is them actually discussing the installer: https://ubuntu.com/blog/flutter-and-ubuntu-so-far
Canonical often invents things that other parties like Red Hat then reinvent, often learning from the mistakes Canonical makes, leading to a better end result for everyone. I dread to think what systemd would've looked like had upstart not laid the foundations for a normal service management system on Linux.
Flutter is an open-source UI software development kit created by Google. It can be used to develop cross platform applications from a single codebase for the web,[4] Fuchsia, Android, iOS, Linux, macOS, and Windows.[5]
it's a freaking mess but ambitious if you want a single code based (with 10 code bases hidden)
Apparently Microsoft writes their installer in HTML, CSS and JavaScript and that also works fine.
It is very embarrassing they Canonical somehow manages to screw up something as simple as an installer.
... it's just Shuttleworth's latest fancy, I expect.
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.
About the upstart thing... even the creator of Upstart acknowledged that systemd's design is more sound -- on Canonical's bug tracker no less -- and kudos to him for doing that. TL;DR: Upstart was essentially callback hell in a different form.
... but to GP: my point wasn't really about when projects were started per se, but they should have been ended much sooner than they were. I absolutely support innovation around the platform, but maybe we shouldn't be too stubborn.
(on the other hand, Debian's bug report is stuck in the 1920's, still being completely based on e-mail)
Edit: also, if you use new hardware, just install Debian Testing, configure /etc/apt/sources.list to say "trixie" instead of "testing", which will ensure that next year you'll be using Debian Stable then Trixie becomes Stable.
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.
Nope, the process can start with "reportbug" utility, which needs a setup in the first run, but allows bug reporting from the comfort of your terminal.
On the other hand, once you install Debian, you won't be reinstalling it for the next two decades. It'll just update.
> also, if you use new hardware, just install Debian Testing...
Sure, that's fine for personal systems & office workstations which are behind a NAT, with a peaceful network.
For any server and internet facing devices, install Debian Stable with NetInstall ISO and enable firmware installation. Testing does not get security updates. I repeat: Testing does not get security updates.
--Sent from my Debian Trixie box.
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.
The good thing about reportbug is, it works on your system with your own configuration, and walks you through the process. Microsoft Windows has a full invasive API to enable that with web browsers.
The mailing list tool used by Debian (Majordomo) is a bit backwards, but you can send command e-mails to bugs to be added to CC, or be removed, or to reclassify stuff. The best thing about it, these e-mails are also logged, keeping a nice trail of "who did what, when" kind of information. Please keep in mind that Debian e-mail lists start in 1994, so there are a lot of things to migrate when things move.
I personally also like KDE's Bugzilla, but finding correct components is a pain sometimes, so I directly use "report a bug" tool under "Help".
I don't think reportbug is perfect, but it does its thing way better than it looks. Maybe it can be improved. I need to look into it.
That is why so much software sucks.
Because the people who make it don’t use it, and hardly care to thoroughly test if it works.
We’re lucky to catch things with extensive dogfooding.
(Also, no blame here. I could imagine working for Canonical and not even running Ubuntu.)
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.
In general, a VM for my work doesn't change anything. It doesn't magically keep anything backed up: I still need to commit/push regularly, and so on. If the host explodes, I'm still down, even if what I'm doing is in a VM. I could immediately reinstall an older release and get set back up, but that isn't really dogfooding for an OS. I would need to report a bug and actually get the issue resolved, which generally means running in a broken state for a while to get there.
Beyond that, I've used a VM for my day-to-day work in the past, and honestly I found it maddening. I couldn't fully utilize my computer without starving the host of resources, and there were a thousand other papercuts relating to hardware access and general instability. I try to avoid that development story these days.
As you can see, my concerns here have nothing to do with losing code or data. They relate to lost productivity and not satisfying my primary duties.
For complex software, real-life testing all the corners is impossible.
You'd get some value out of people running it on VMs, some people running it on the same old hardware, some people running it on cutting-edge hardware, some people running it for extended periods and doing dist-upgrades, some people constantly reinstalling it (even within a VM).
There are so many places software could fail. Especially things that aren't repeated often seem to fail: For example, websites where logging in works, but creating a user fails and nobody notices, because all employees already have accounts.
But no, I've actually never seen this. Probably better to lose people who leave over their employer messing up the work hardware than spending 3k per 2-3 years for a second machine.
Not all software is easily dogfoodable.
A funny incident:
There's a git forge called https://ayllu-forge.org/ that they use to develop itself.
`git clone` had broken, and it hadn't been fixed because the developers had already cloned the code.
Having your developer workstation break while you have a backlog full of stuff to do, would absolutely make you less motivated to run the developer release. Especially if you're not on the desktop team.
Well, yes. You bet the encryption works. Even an advanced hacker will have a hard time unlocking the hard drive... if after the install the TPM refuses to escrow the key, and you can only see your recovery seed AFTER a successful installation!
It's ironic cuz it's supposed to be the most stable, mainstream one. But, from installation to day to day usage, it was crashtastic in the years I was on it.
By comparison, my equal number of years split between Manjaro and Arch, I've had almost zero issues. Somehow, the scary, dangerous rolling distros seem the most stable. It's hard to wrap a brain around.
We (SUSE) have extensive testing and quality control, if you are looking for something very stable. Leap is the version built out of the same bits as the enterprise version. The "Micro" part means it is smaller, transactional, and immutable. It's built for containerized and virtualized applications. You can install the nvidia OS bits in the OS, and then build a container with libraries.
I switched to sid from arch because their approach to software major release is dangerous (i.e. adopt plasma 6 the day of release)
Comes with the drivers you need, super nice and streamlined UX.
So far I only tested the Noble release in VMs and containers (docker, incus, kvm on ARM and Intel) and that seemed to work just fine. LXC still broken, though.
Never gets far enough to write to hdd.
Still sticking with it and attempting to hold out for 24.04.1 before going back to Fedora. I much prefer apt over dnf.
I realize it's my own damn fault for owning a Dell instead of a Thinkpad, but afaict my ruggedized Dell is the only semi-affordable way to get a sunlight readable display in a laptop. I'd kill for a sunlight readable Framework >_>
That said, I have a suspicion the same crashes also happen on other distros, Ubuntu just offers the ability to send a crash report.
Be warned that the do-release-upgrade -d might well make your system unbootable.
More info at: https://www.omgubuntu.co.uk/2024/04/dont-upgrade-to-ubuntu-2...
Or at least be prepared with a backup and a reinstall from scratch, or just switch to debian.
"write Ubuntu ISO to USB flash with dd" (from the video comments)
EDIT: I remember I got up to enabling third-party drivers before partitioning, it was behaving weirdly so I went back, then it crashed and I restarted to see no partitions. I don't remember the details but my thing is I'm sure it was before partitoning.
So, yeah. Okay.
(Speaking as ex-Canonical, and still Ubuntu user. I upgraded my ThinkPad 2 days before release, and it was a catastrophe I had to manually un-fudge with the help of the apt maintainer. It was a packaging problem).
My feeling on this particular release is that it was rushed out, and should probably have been kept back for a month or two. The xz and t64 (2038) issues occupied some unexpected time this cycle.
Also, there used to be a dedicated QA lab which did a whole slew of automated tests. I don't believe that still exists.
Also, also. The Ubuntu community has shrunk, which means fewer people doing QA.
Also, also, also. The guy running the desktop team left the day after the release. Read into that what you will.
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.