Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

401–410 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#401

Earlier quoted context omitted.

Please read https://discourse.ubuntu.com/t/feature-freeze-exception-seed...

*sigh Another firefox blunder to add to their growing list.

If someone (Ubuntu) wants to package and distribute free software (Firefox) in their own format (Snap), the upstream maintainers (Mozilla) shouldn't hinder it no matter how bad the format is - it's not their job.

Re: Ubuntu stops shipping Flatpak by default

#402
post #328

Earlier quoted context omitted.

What wifi chip are you using? Debian by default has no unfree wifi drivers included, so that can cause issues with them. If you have a good wifi adapter by a vendor that pushes drivers upstream like Mediatek, it should work just fine out of the box.

or install from non-free ... which will not be needed anymore for next release https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in...

Yes I was using the non-free version. It was working fine until I'd set the machines to auto-update then one day found out they had zero connectivity after an update. I thought about going around to each machine and manually trying to revert back whatever was in the updates that broke it and just decided to wipe and install Ubuntu back on them.

Re: Ubuntu stops shipping Flatpak by default

#403

Earlier quoted context omitted.

This also happened to me. So I decided to uninstall the snap and “apt install firefox” Guess what I got? A freaking snap. Yes, try it. I’m done with Ubuntu

It is possible to get an apt package, you have to jump through a few hoops but it can be done; I do it every time I install Ubuntu (frequently) because I won't touch that snap shite again. I can't move work off of Ubuntu; it's too embedded now, but I'm looking for something else for home. Switching distro-base isn't so easy when you've been using it for decades though; I tried NixOS but it wasn't comfortable (Nix is…

Would you be interested in a session for me to better understand (and hopefully eventually fix) why Nix was not comfortable? Not looking to evangelize, but to learn about the experience from your perspective.

Re: Ubuntu stops shipping Flatpak by default

#404

Wow they're still pushing snaps, the project with some the worst engineering I've ever seen. - Extremely slow at doing anything, even the most basic commands. - Ridiculous auto-update mechanism (you can't even disable it wtf). - Random, nonsense limitations (why can't I open dot files and dot directories???). So terrible that for most apps that I installed with snaps I end up installing the deb version later on. What…

I've started using Ubuntu in Warthog times, when their value prop was refreshing and sorely needed: an out of the box usable Linux distro. It was my distro until 2020, when I realized they were going in a direction I don't care for (you could argue a direction opposite their original mission), and that other distros have reached and exceeded Ubuntus level of polish. Basically, take your pick, and it's gonna be at least as good.

I ended up with Debian because I like stable but not ancient (CentOS?) and it comes with a release cadence similar to Ubuntu LTS.

Re: Ubuntu stops shipping Flatpak by default

#405

Earlier quoted context omitted.

Everyone's done with Ubuntu. It's just not good. Its got a stereotype at this point for being the easy noob distro but that's not even true. Its top to bottom awful and has been for many years.

I have meager needs so I haven't run into (m)any of the issues here, but what's a deb based alternative that isn't meant for absolute stability at the expense of anything modern? (I ask with actual curiosity; I'm ignorant to most distros.)

I've had several people recommend the testing branches of Debian for relatively up-to-date software while still being stable FWIW

Re: Ubuntu stops shipping Flatpak by default

#406
post #194
post #154

Earlier quoted context omitted.

> Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs." ..wait a minute > (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had secu…

It solves some of the problems, but not all, and it requires a lot of testing and trial and error and setup. Sometimes libraries are hard to statically link. Sometimes you have problems with different glibc versions. I forgot to say: some distros that people still use are too old for us to build for, so we build fully static binaries for those. But you can't really statically link glibc, so we build them on Alpine st…

I have had a lot of success with building against old glibc version and then bundling all required libraries except system ones (glibc, libGL, libX11 etc). Anything optional needs to be loaded with dlopen/dlsym but for many things that detail is already handled by libraries like SDL. That's generally what seems to be the common solution for games (well used to be at least, today most just build against the Steam runtime and call it a day). It's really not that different from Windows IMO except that the set of base system libs that you can rely on to be backwards compatible and don't need to bundle is smaller.

You can still pacakge that distro-agnostic build up into distro-specific package formats to make updates easier for users without needing zillion of different build roots just for Linux.

Re: Ubuntu stops shipping Flatpak by default

#407

Earlier quoted context omitted.

This puts too much unnecessary burden on developers and maintainers. It doesn't make sense to adapt software to tens of distributions (and then to different OS like FreeBSD). Apt should be used only for system software (like init system, system libraries) but not for applications. Also apt allows to run scripts as root during installation and this is not secure.

There's a Pareto effort, of course. If you release Debian and Redhat packages, you cover 80% of the user base. It's not hard to maintain, if you compare to building msi installers. Further, the process of generating packages for derivatives of debian or redhat can be mostly automated, so user coverage is bound to grow if your package is popular. As for root requirements, what you are asking for are (non privileged) u…

> If you release Debian and Redhat packages, you cover 80% of the user base.

That means you need three builds to cover Ubuntu and its derivatives (20.04, 22.04, 22.10). Two to cover Debian (10 and 11). Three to cover RHEL (7,8,9) and also a few more if you want to support Fedora. If you want to support multiple architectures you get at least twice as much builds.

No matter how you put it, that's a lot more work than maintaining a simple flatpak manifest, which allows you to target all those platforms with one automated build for each architecture. And you also get the benefit of being placed in the app store and not being hold back by whatever API is the lowest-common-denominator between all those platforms or having to clutter your code base with `ifdef`s; if you want your app to use an API which was only added in GLib 2.74, then you can just do that and it'll work.

Re: Ubuntu stops shipping Flatpak by default

#408

Earlier quoted context omitted.

Conversely, `pacman -Syyuu` doesn't complete reliably without user intervention, which is far from ideal. I say this as an Arch user - the expectation that I'm going to manually attend to package upgrades in practice leads to me using outdated packages

I'm genuinely curious about this, as I see people say it a lot but it's not my experience at all. I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine. I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine. I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more…

> I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more prone to it, or something?

Liferea is currently broken as of the latest update 5 days ago due to https://github.com/lwindolf/liferea/issues/1217

I also suffered from the grub issue mentioned here elsewhere, had to rescue my laptop after it became unbootable (though it was very simple to Google the problem and to fix it). I don't think using grub is particularly unusual choice in packages.

I also had to downgrade Samba and wait a couple of weeks for a fix to a bug it had mounting password protected shares. Again, Samba isn't exactly an exotic package.

Also had to downgrade something in my audio stack (I forget if it was pipewire, pulseaudio or a kernel issue that was the root cause) and wait a couple of weeks for a fix due to bluetooth issues.

There's also the occasional update that requires manual intervention.

All of that said, I don't think I cumulatively spent all that much time on maintaining my Arch systems as all these errors are spread across a long period of time and didn't take that long to handle. I probably spent a lot more time and nerves on Ubuntu as I don't think I've actually ever had a dist-upgrade work flawlessly and each time takes a lot of effort and mental energy.

Re: Ubuntu stops shipping Flatpak by default

#409

So, for a developer, what's currently the best hassle-free desktop Linux Distribution?

I personally would recommend Fedora. It's not rolling release like Arch so packages might be a bit behind, but with Red Hat using Fedora as their staging distro it's usually not very far behind and occasionally even ahead. And you don't have to worry about updates breaking everything. It's also one of the big distros so it's well supported

Re: Ubuntu stops shipping Flatpak by default

#410

Earlier quoted context omitted.

> Snaps/Flatpacks/other binary-containerised stuff is one of the major reasons why I abandoned Linux distributions after 22-odd years (1999-2022), and am now a happy Apple user (the other one being abandoning X11 in favour of Wayland, and a switch to laptop-first usage, on which Linux still has horrible power-consumption). Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside some…

> This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins." Surely distros could be based on top of Nix with carefully curated sets of packages with less effort than it takes to p…

Translating from Nix to another packaging ecosystem usually entails removing specificity. This is why going in the opposite direction is harder. So I suspect we can provide escape hatches from Nix into Debian/RPM/Arch/Gentoo so that one would only have to maintain one fully specific package, but get easy translators for the other ecosystems.
Post reply on HN