Proton did not claim anything; the CEO of Proton claimed that Republicans (not Trump) would do better on big tech anti-trust.

This view is not that crazy given that the person Trump appointed was doing her job quite well. Too well to the point that Trump removed her from the position later on.

You’re forgetting that Universal Blue doesn’t just ship Fedora stuff.

They include stuff from Homebrew and Flathub out of the box.

Homebrew shipped the backdoored xz library while (by luck) Fedora stable didn’t.

Do they still do 15 minute bugs? That could still use some work.

Occasionally I get an itch to try Plasma and immediately get disappointed every time as I encounter some sort of bug just setting up the panel. Last time I tried was 6.6.5, so it wasn’t just a point 0 software issue.

As a side note, I still get so confused by the “new” panel/desktop edit mode introduced in 6.1.

I don’t think there’s much of a package up-to-date difference between LMDE and Linux Mint. Both Debian and Ubuntu LTS are released every two years. Ubuntu in even years, Debian in odd years. So every year they trade being more up to date.

Main difference now is that Linux Mint has access to Ubuntu’s hardware ennoblement stack.

Preface: I have been daily driving Fedora Atomic for the last couple of years and have also used a bit of Aeon and NixOS.

My opinion is that while atomic/immutable desktops are overall a good idea, they are marred by poor planning, a refusal to fix existing tools, and some cope.

There are way too many package managers and waste in this space. I think flatpak is a large cause of all this friction due to fact that it is always “sandboxed” and only focuses on GUI apps. The fact that it does not aim to support CLI apps (despite being able to handle them quite well!) means that we must have another tool, traditionally podman via toolbox/distrobox. The sandbox doesn’t play well with certain subsets of apps, notably things like VSCode. At least Flatpak Next seems like it will address this part with its unsandboxed mode.

I also find it quite strange how some developers revel in wasted space and inefficiency. So many duplicated libraries between the host, flatpak, podman, and homebrew. With better planning, we could’ve had shared runtimes (such as Freedesktop) between the OS, flatpak, and whatever CLI package manager. Instead we have something like Fedora packages for the host OS and podman (not shared), flatpak using Freedesktop, and brew shipping their own stuff.

I also think that systemd sysexts are poorly designed, it’s crazy they’re being pushed. It’s pretty much a package manager without dependency management. And for what upsides? It has no sandboxing, it’s not portable between distros and distro versions, and must vendor dependencies to work around having no concept of dependencies. And we’re already seeing fragmentation with Fedora and OpenSUSE working on their own frontends to manage sysexts.

Flatpak aimed from the beginning to be distro-independent, and consequently the Freedesktop SDK isn’t a repackaging of Debian or Fedora or Alpine Linux, but something more like a DIY Linux From Scratch build. As an app user you don’t notice any of this, because it’s very well executed and apps just work. Again, it’s hard now to imagine a parallel universe where the main Flatpak runtime was Fedora in a trenchcoat, but perhaps that would have impeded the success of Flatpak. (Of course Canonical still built their own app store technology, but I suspect that Canonical re-inventing things is part of every parallel universe).

I still find this “distroless” talk funny. There’s so little difference in whether the Freedesktop runtime is built like “Linux From Scratch” or assembled from Fedora packages. Fedora is also assembled like “Linux From Scratch”. At the end of the day, they’re both just taking upstream code and compiling it. Fedora just has an intermediary step of creating a package.

The only practical differences are the release scheduling, support length, and compile flags. In another world, the Freedesktop runtime could literally just be Fedora packages but with different compile flags that are less restrictive in terms of patents/codecs. And it would make almost no difference apart from the support length being different.

They disabled it with flags, but manifest V2 still existed in the code and could be enabled. This is about Google now removing V2 from the code. That will make it harder for third party browsers to include V2, since they would need to patch it back in and develop new patches to keep it working.

Now I wish I didn’t upgrade to 26.5 from 15 a couple weeks ago. I could’ve entirely avoided the worst parts of 26 design.

Interesting, what hardware do you run?

I haven’t used Plasma for any significant length of time since 5.27. Coincidentally, the first major version of Plasma where Wayland was actually daily drivable for me, previous versions would have at least one desktop crash a day.

But my experience on Gnome Wayland has always been good. At least, better than X11, even on NVIDIA before the Wayland compatibility was “good”. Don’t remember exactly dates or version umbers, but it was shortly after it got hardware accelerated Xwayland and before NVIDIA added GBM support. And when I switched to AMD, it only got smoother and more stable.

And recently have been trying out labwc/wlroots and it’s been a very stable experience too.

6.12.90 is the latest release, you’re good. Just make sure you’ve rebooted since installing it.

Sorry, I guess labwc isn’t as well known as I thought it was.

labwc is a lightweight Wayland compositor based on wlroots. Unlike most other window managers, it uses “floating” windows (like Gnome and Plasma) rather than automatically tiled windows (like Sway and Hyprland).

I agree in the case of Fedora Atomic, they’ve stuck to flatpak and podman (so far, they have their system extension manager tool in the work) and have rpm layering as a fallback.

But not all atomic distros have that fallback. Universal Blue, more specifically Bluefin, does not want to allow layering at all; this is already implemented in the LTS version (though it’s just bootc, so you can build your own image to install rpms). This is also true for “distroless” models like Gnome OS (and there you don’t have any prebuilt packages to pull in even if you made your own buildstream image). So for these, you have to make-do with the package managers they provide or you’re out of luck.

In an ideal world, I think we should have a single package manager that sits on top the the OS that can handle everything: GUI apps, CLI tools, sandboxed by default but also able to be disabled completely for the apps that don’t work well with sandboxes. The closest thing we have to that right now is snap.

In an imperfect but more likely world, I would be fine with two package managers. Flatpak for GUI apps and something else for CLI tools. “Flatpak Next” could fix one issue with its unsandboxed mode. But I still haven’t found something that universally works well for CLI apps.

• Podman is the classic answer, but it can be a bit annoying jumping into and out of boxes. Doesn’t work well for more “system tooling” like Tailscale that also want services.
• Homebrew is a more modern suggestion and actually works pretty well. But I’m not a fan out how hijacks PATH in a way that can break OS packages (such as by making homebrew dbus and systemd used over OS versions). And last I tried, the homebrew version of tailscale didn’t work (though I have read that others did get it working).
• Coldbrew is an interesting alternative to coldbrew, which uses alpine packages and doesn’t mess with PATH directly, but it does place some stuff in .local/bin that could end up overriding some binaries anyway (though not to as high a degree as homebrew, and thankfully doesn’t affect libraries). But has integration issues due to sandboxing (personally had an issue where I had an app that wanted to open my browser, but it couldn’t see my browser because of the sandbox).
• I still need to test Nix on an atomic distro

When something as fundamental as git requires multiple obscure commands to install, you’ve got to think twice about the target audience.

Ideally the tooling gets better and you don’t have to do anything else but “toolname install package” or have a declarative list of what to install.

why Linux power users (i.e. most Linux users on lemmy) aren’t suited to immutable distros.

I think the main problem is that immutable distros haven’t thought things through from the beginning.

It started out as just using flatpak and podman. But each of those has limitations. But rather than improving them, we just keep creating / bringing in new package managers. Homebrew, cold brew, system extensions, nix, etc.

Funnily enough, the only entity who is sane in this regard is Canonical. If snap has a limitation, they just update snap to not have the limitation rather than brining in another package manager.

But honestly I think the biggest offender here is flatpak. If not for its mandatory sandbox and anti CLI tool stance, it could have handled everything. “Flatpak Next” seems to be address the first issue as it is planned to have an unsandboxed mode.

Flatpak is decentralized, though I do have reservations with how some people only want Flathub to exist.

Flathub uses CDNs, so they are effectively the mirrors.

Glad that compact mode will be officially supported again. Makes such as big difference on a laptop screen.

Because AIs don’t need salaries, don’t unionize, can work 24/7.

For some tasks, AI has already completely obsoleted humans. An AI can write a shitty PR filled newsletter faster and cheaper than a human. It keeps getting better at certain tasks, like programming.

All AI companies want to be the one that controls the best AI. Because if they do, then other companies will pay them to rent out AIs for cheaper than human labor.

Companies fear falling behind. So they dump loads of money into AI. And currently, investors like hearing about AI. So the more companies say and push AI, it increases investment into the company.

The main problem is that it’s just not battle tested like GNU coreutils are. And Canonical has only tested this in one cycle, 25.10, before introducing it in an LTS. Would’ve made more sense to wait until 26.10.

Other find problem with it being MIT licensed.

I had a couple of problems with the profile manager.

For one, there’s now two profile managers that do not work together. You can’t use an old profile in the new profile manager or vice versa. You can access the old one via .desktop entry or from the CLI. But you can’t access the new one from the CLI.

It’s also a bit buggy. For example, if I have my “Personal” profile open and middle click the Firefox icon, it will open up another “Personal” window rather than show the profile manager. And to access the new profile manager, I first have to aim for a tiny target (especially tiny on my 100% scaled 4K monitor) and do 3 clicks. With my solution, I explicitly choose which profile to use from my dock.

It’s also hit or miss on which window a link from an app will open up in. Whereas with my solution, I can set “Firefox (Personal)” as my default browser and always have stuff open there.

I don’t use openSUSE, but seeing their security reviews tempts me…

It could be improved. Sebastian Wick and Lennart Poettering made comments on how hard POSIX makes it hard to be secure. There are better APIs that try to be safer.

• https://blog.sebastianwick.net/posts/how-hard-is-it-to-open-a-file/
• https://mastodon.social/@pid_eins/116459585811044061

And since uutils is not Linux only, it can’t use these safer APIs directly, or at least not without writing more platform-specific code.