Earlier quoted context omitted.
I agree. Maintainers are useless middlemen (at best) who only exist because of Linux userland's particular diseases and a desire for distros to rule over their own little repo fiefdoms. No other desktop OS has done it like Linux and for good reason. People have been citing this as a reason they don't want to use Linux as a desktop for decades to mostly deaf ears, who then turn around and wonder loudly why no one want…
This has to be the dumbest take on this thread. If you want the dystopian hellhole you seemingly long for, just use Android and enjoy the ad-infested crapware? No reason to moan about things you seemingly don't understand.
Ubuntu stops shipping Flatpak by default
191–200 of 624 posts
Re: Ubuntu stops shipping Flatpak by default
#192Wow 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 have no idea how to update firefox because of this. I get some notification about not being able to update but it doesn't tell me why.
Re: Ubuntu stops shipping Flatpak by default
#193Earlier 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…
The system package manager is convenient when it works, because it's already there. But that's about it. Using it to install any random apps is a recipe for disaster, it leads to fragmentation since everyone on a different distro uses different commands/workarounds to fuck up their systems in different ways when trying to install poorly packaged software.
If everyone just used Debian, we wouldn't need Flatpak, but obviously that's not the case. Whenever you find a "linux app" that's packaged for distroA, but you're on distroB, there's a chance that it will work. That is 100% luck and coincidence, because most linux distros just so happen to ship the same family of system software/libs, sometimes even with the same versions.
Rather than leave it up to the undefined behavior lottery, a standardized non-system packaging format can guarantee that things will work across any distro. That's better for everyone involved: users, sysadmins, distro maintainers, and developers. Whether Flatpak is that format idk, but IMO it's the best overall out of the three main contenders (Flatpak, Snap, AppImage)
Re: Ubuntu stops shipping Flatpak by default
#194Earlier quoted context omitted.
As someone who does this for a lot of distros (ZeroTier), I can say that it is hell and I understand why devs don't want to do it. Two specific examples: (1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not…
> 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…
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 statically linked with musl. That usually works okay. It's the best we can do for the old stuff.
We've invested a lot of time in this. For most developers I totally understand "fuck it."
Re: Ubuntu stops shipping Flatpak by default
#195Earlier 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…
Re: Ubuntu stops shipping Flatpak by default
#196Earlier quoted context omitted.
Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for. You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.
> You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.
Re: Ubuntu stops shipping Flatpak by default
#197Can we go back to just shipping apt packages? They worked fine, and I don't feel like having multiple types of containers and update methods and mounted image file systems really made anyone's life better.
Would their apt repo suddenly disappear? Probably not, but who knows.
Re: Ubuntu stops shipping Flatpak by default
#198I'm sure their enterprise side is fine, but their consumer side is disappearing rapidly.
Re: Ubuntu stops shipping Flatpak by default
#199Earlier quoted context omitted.
> You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.
Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.
Re: Ubuntu stops shipping Flatpak by default
#200Wow 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…