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
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.
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.
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.
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.
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.
(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.
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
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.
Thankfully there’s plenty of alternatives where feedback is actually appreciated.
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.
"write Ubuntu ISO to USB flash with dd" (from the video comments)
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!
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.
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.
