Live data from Hacker News

Flatpak is not the future (2021)

ludocode.com

131–140 of 166 posts

Re: Flatpak is not the future (2021)

#131

Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story: There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old…

> without understanding that there is no holly grail solution and some sort of compromise is always required. Why do you assume that such people don't understand this? Sometimes those compromises mean that the tool can no longer accomplish something important to some users. I don't think that being upset that software has become less useful is terribly unreasonable or hard to understand. > Additionally, as it's natur…

In what way is Flatpak being forced on you?

Re: Flatpak is not the future (2021)

#132

Earlier quoted context omitted.

As far as I'm concerned this is a good thing. I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y. In the last 2 decades I used linux I had this issue so many countless times that as far as I'm concerned nix-style, or AppImage-style "waste space" solution is strictly speaking better. Sick and tired of t…

> I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y This is not "Linux", it's users who mess around with (and ultimately break) dependencies in order to get the latest version of programs at any cost. If one uses, say, an Ubuntu version and 3rd party repositories for that version only, they're not goi…

I used Ubuntu and even Debian for many years. I strongly disagree with you, actually I find Arch significantly more stable than Ubuntu. At least in Arch when dependencies are broken, both X and Y are swiftly upgraded.

At this point, I'm also tired of convincing others that linux package management is broken beyond repair. Until you experience my pain, you won't be convinced. I understand many people will never be able to sympathize with my pain but all I can truthfully and honestly say is that I'm a very experienced GNU/linux user, I used all kinds of distros from Ubuntu to Fedora to Arch to Gentoo and, no, it's all a complete and utter mess when it comes to dependency management. I end up spending hours every month fixing broken versions. The sweet spot is using pacman for very basic things, and AppImage for everything else. I don't care about memory efficiency, I want `MuseScore4.appimage` to contain everything about the app, I want it to behave exactly the same every single time I click on it. No, I don't tolerate even the slightest behavior difference, I do not want glibc to upgrade from x.y.z.t to x.y.z.t+1 because it causes insanity when t+1 causes a behavior change in some random software synthesizer I happen to use. I know that this probably doesn't make sense to 99% of users, but maybe I have a special case. Case in point, in the year 2023 while trying to ship a lot of work I'm producing, a single update broke tons of my workflows, and I finally decided that anything not frozen in AppImage is cursed. If it doesn't work you, I respect your patience and expertise, I just hope some people can understand the pain other users go through.

I have a degree in CS, I write code full time, I manage linux containers in my day job, and I still can't manage the mess I have at home in my local Ubuntu/Arch installs. I don't know how people who don't know how to code do, but all I know is that I'm done spending hours at a time on fixing glibc at this point. I just want to work on my hobbies, thank you very much.

EDIT: And before people come here, no, OSX and Windows are even worse. I won't consider using them either.

Re: Flatpak is not the future (2021)

#133

Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story: There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old…

> arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo.

This sort of narrative is common cope from developers who make substandard software. Ego blinds them to their own limitations so they blame the users. Just look at the difference between Pulseaudio and Pipewire. Pulseaudio is widely hated and the developers said it's because people just hate new things. But Pipewire is newer and people love it, the supposed reflexive hate for new things doesn't manifest for Pipewire. So what's the difference? Pipewire does what it's meant to and doesn't cause problems for people. Pulseaudio caused endless grief, that's why people hated it. SystemD earned ire by causing people problems; had it not done that most users never would have realized they were using it in the first place.

Re: Flatpak is not the future (2021)

#134

Earlier quoted context omitted.

> I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y This is not "Linux", it's users who mess around with (and ultimately break) dependencies in order to get the latest version of programs at any cost. If one uses, say, an Ubuntu version and 3rd party repositories for that version only, they're not goi…

I used Ubuntu and even Debian for many years. I strongly disagree with you, actually I find Arch significantly more stable than Ubuntu. At least in Arch when dependencies are broken, both X and Y are swiftly upgraded. At this point, I'm also tired of convincing others that linux package management is broken beyond repair. Until you experience my pain, you won't be convinced. I understand many people will never be abl…

Zypper has excellent dependency resolution, it hasn't given me any trouble. DNF is just as good, from what I hear. Apt and yum are an earlier generation of package manager, and I've seem them get themselves into jams on more than one occasion so I understand what you're saying and can sympathize with your perspective, but those shortcomings aren't inherent to the premise of traditional package management.

I use AppImage for the sort of software that won't get packaged (proprietary or obscure) and zypper for pretty much everything else (excepting a few programs I build myself due to reasons.)

Re: Flatpak is not the future (2021)

#135

I only use linux for daily use but deploying software on it is the worst out of any OS that I know of with windows being the best. Every update can potentially break things because who knows what changed in that library you depend on, and its not like you can avoid that by shipping static libraries to prevent this since for whatever reasons everyone has conspired against static libraries, I'm guessing because they ta…

Maybe Guix is for you?

Re: Flatpak is not the future (2021)

#137

Earlier quoted context omitted.

I really like Nix, but I think "is still considered too arcane for most people to use" is a contradiction of "has already definitively solved this problem". Being usable for most people is an important part of solving this problem, which I unfortunately don't think Nix has accomplished. Maybe there is some way to improve its UX while keeping the fundamental model intact, in order to solve this problem.

The core idea of Nix that has basically "solved this problem" is simply trying to control for all possible inputs to a build-time and run-time environment, and lock them all down with hashes, which is in essence basically treating a build like a pure function. (In theory, this should result in deterministic builds and deterministic runs. And in practice, nearly 100% of the time, it does.) The point of a "derivation"…

I understand why it's a great theoretical solution, but my point is that if hardly anybody is using it, then it hasn't solved the problem, because most people are still experiencing the problem. It doesn't really matter why it isn't being widely used, just that it isn't. Like, if it were the opposite, a very poor theoretical solution to the problem that is very easy to use, but nobody used it because it just didn't solve the core problem well enough, that would also clearly not be a solution. A solution requires both things, it must be both fit for purpose and usable.

Re: Flatpak is not the future (2021)

#138

Earlier quoted context omitted.

> without understanding that there is no holly grail solution and some sort of compromise is always required. Why do you assume that such people don't understand this? Sometimes those compromises mean that the tool can no longer accomplish something important to some users. I don't think that being upset that software has become less useful is terribly unreasonable or hard to understand. > Additionally, as it's natur…

In what way is Flatpak being forced on you?

I didn't claim that it was. I was speaking to the more general point that ceronman was making.

Re: Flatpak is not the future (2021)

#139
post #110
post #6

Flatpacks solve no problem that I have, and bring their own headaches, so for me, flatpack is certainly not the future. Same with snaps, although I dislike snaps more.

What about transactional updates? Applications might have undefined behavior if their libraries or other assets are changed under their feet.

If there's a security issue, I want to be able to update libraries and such independently of applications rather than waiting for the application devs to do it.

I don't think it's caused a problem for me in the last 10 years or more. It may have and just forgotten about it, though. If it happens, it's not a huge problem to fix it.

Re: Flatpak is not the future (2021)

#140

Earlier quoted context omitted.

> But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well develo…

The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos. Most apps that I have been getting from third party repo were not included because most majors distros are us projects that can't ship patent encumbered libs/apps, not because distros mainteners couldn't package them. > This is why people run games through Wine instead of u…

> The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos.

I mean... citation needed :) I run Arch and I am not dismissing at all the frankly incredible work that the Arch maintainers do bundling software and making it available. It is a miracle that it works as well as it does, to the point where my Arch systems are often more stable than non-rolling-release distros I occasionally run. Fantastic work by the maintainers.

But it's not a solved problem and I can only imagine how much effort and work is getting burned to keep it running as smoothly as it does. Step outside of the official Arch repos into AUR or (heaven forbid) into completely separate ecosystems and all of those problems come back. And I don't want to ignore the software outside of the repos, I didn't start using Linux so that I would be beholden to some kind of "official" distro app store.

There are tons of Open Source applications with no legal barriers in place that are not getting packaged in official repositories for no other reason than that they're niche and there is a lot of software to package and not enough people to do package it all.

And of course any non-OS games are also going to run into these problems. That's a problem that distro maintainers can't solve, it doesn't matter how much work they put into it, they can't repackage source-available or closed source software. "People shouldn't ship that" -> but they do :) So ideally we'd be able to handle that without descending into dependency hell.

> No, the main reason is that the linux versions do not exist for the most part

I'm not talking about games where the Linux versions don't exist, I'm explaining why I'm currently running the Windows version of Inscryption on my Deck even though it has a native Linux port. Do I want to be doing that? No, of course not. But the Linux version doesn't boot, most likely because there's some dependency chain missing or an environment variable is wrong, or... I don't know, I don't want to crawl through forums and debug that myself, I want to play the game.

And I'm not alone in that, it is common advice on Linux to use Proton instead of Linux native versions. And that stinks, it's bad for the ecosystem and it's bad for users and it's bad for games. But the Linux versions have so many more problems because they make assumptions about the underlying system that turn out not to be true. Of course Windows builds also have those problems, but the difference is that they run in a containerized environment that gives them the system they expect.

Post reply on HN