Live data from Hacker News

Flatpak is not the future (2021)

ludocode.com

161–166 of 166 posts

Re: Flatpak is not the future (2021)

#161

Earlier quoted context omitted.

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

Sounds a lot like appealing to emotion, since you're the one using the term forced.

OK, I see your point. That wasn't my intent.

I'll rephrase: while software is in that state, it shouldn't be released.

Re: Flatpak is not the future (2021)

#162

Earlier quoted context omitted.

> This is why people run games through Wine instead of using the Linux versions They do? When I have a choice between the two, I'll take the Linux version every time.

I would love to as well, if the Linux versions would boot up and run on Steam Deck. Even when I was gaming on my desktop, which is pure Arch, I remember regularly needing to edit Linux games or recompile dependencies to get them to work. Flibitijibibo has some good commentary on when to dynamically/statically link libraries, leaning towards statically linking dependencies when possible to avoid relying on the OS too…

Ah, OK, so this is an issue with the Steam deck and Arch? I thought that it was a general comment about Linux. My mistake.

Re: Flatpak is not the future (2021)

#163
post #152

Earlier quoted context omitted.

> 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 Pipe…

While Pipewire is certainly better than Pulseaudio, let’s not forget that the latter actually surfaced the millions of bugs in sound drivers by simply using them in a more advanced way than just putting out audio, so while it was buggy initially, most of those stem from a layer below.

Pulseaudio is buggy to this day, and switching to Pipewire is most often the easiest way to fix problems with audio, particularly bluetooth audio. They're both meant to do the same thing, but using the same exact drivers Pipewire just works better. This is why all the major distros are switching to Pipewire; a transition which hasn't earned the ire of the users who are supposedly mad at anything new.

Re: Flatpak is not the future (2021)

#164

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…

This is very gross disinformation and/or incompetence (which explains why "others" won't listen).

The default Debian tools, apt and apt-get (and related tools, like gdebi/aptitude) won't put the system in an inconsistent state, unless the user forces them to do so. Dpkg will do, which I suspect is the tool you're using.

Even when one adds a repository with incompatible package versions (say, the system is Focal and the repository distribution is Mantic), the upgrade will stop before upgrading the packages.

What's happening is that you're forcing broken dependencies, likely to chase the "latest and greatest versions", then complaining that the package manager is broken.

Re: Flatpak is not the future (2021)

#165

Earlier quoted context omitted.

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…

This is very gross disinformation and/or incompetence (which explains why "others" won't listen). The default Debian tools, apt and apt-get (and related tools, like gdebi/aptitude) won't put the system in an inconsistent state, unless the user forces them to do so. Dpkg will do, which I suspect is the tool you're using. Even when one adds a repository with incompatible package versions (say, the system is Focal and t…

Uh... Such is linux life, when you're hit with issues and complain, it's "This is very gross disinformation and/or incompetence". No wonder some people won't bother dealing with it.

Again, I truthfully experienced all of this and my day job is to handle things like this, so I personally know that it's neither of those things.

What's happening is a variety of issues (not one) and it can be anything from package maintainer not knowing whether a version is incompatible with their package, to dependency being noted wrong in package. For example, if I write package X and depend on numpy, but don't realize numpy 2.24 breaks it, Debian will happily accept the update breaking my package for users. It's the maintainer's fault but ultimately if the OS didn't upgrade dependencies for every program it would have worked. Which is why freezing dependencies is the way to go in terms of stability.

There are countlessly other scenarios, for example using a program compiled outside of Debian and dyn linking then Debian upgrading the dependency not knowing about the 3rd party program. It's all a trap for broken software.

Re: Flatpak is not the future (2021)

#166

Earlier quoted context omitted.

I would love to as well, if the Linux versions would boot up and run on Steam Deck. Even when I was gaming on my desktop, which is pure Arch, I remember regularly needing to edit Linux games or recompile dependencies to get them to work. Flibitijibibo has some good commentary on when to dynamically/statically link libraries, leaning towards statically linking dependencies when possible to avoid relying on the OS too…

Ah, OK, so this is an issue with the Steam deck and Arch? I thought that it was a general comment about Linux. My mistake.

> and Arch

It is a general comment about Linux. Arch Linux is a major distro, if people using Arch can't run Linux software using existing packaging systems, the packaging systems are broken.

If the natural result of existing packaging systems is that software only works on distros like Ubuntu and Fedora, then that is very much a general Linux problem.

Post reply on HN