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.
Ubuntu stops shipping Flatpak by default
401–410 of 624 posts
Re: Ubuntu stops shipping Flatpak by default
#402Earlier 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...
Re: Ubuntu stops shipping Flatpak by default
#403Earlier 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…
Re: Ubuntu stops shipping Flatpak by default
#404Wow 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 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
#405Earlier 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.)
Re: Ubuntu stops shipping Flatpak by default
#406Earlier 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…
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
#407Earlier 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…
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
#408Earlier 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…
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
#409So, for a developer, what's currently the best hassle-free desktop Linux Distribution?
Re: Ubuntu stops shipping Flatpak by default
#410Earlier 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…