3 ms·

Developers are lazy, thus Flatpak

30 points by ecliptik 3y ago

xena 3y ago
Developers aren't lazy, packaging software is fucking bullshit.
shrimp_emoji 3y ago
Laziness is a desirable trait in programming: it gets you to do things smarter, not harder. Packaging once and installing everywhere instead of packaging `n` times for pointlessly conflicting formats is like that. Sandboxing and optional static linking is a bonus. The paradigms we've been using date to times when memory was scarce and software was rarer (there was literally less of it for maintainers to worry about) more innocent (no crypto jackers) and simpler (with less dependencies). We don't live in those time anymore.
DethNinja 3y ago
Flatpak isn’t ideal and it has lots of room for improvement but what is the better alternative? I would say that at least Flatpak is on the right direction.
jmclnx 3y ago
Yes, and I would add flatpak ensure security issues are never looked at. I believe if something in flatpak has a security problem, it will never be addressed. Why, because it is in a flakpak and is separated from the OS, so the issue just sits there. This could end up being a problem for distros not using flatpak and for that matter the BSDs.
- curioussavage 3y ago
  This is absolutely a false assertion. If your distro integrates flatpak then you will be prompted to update the runtimes. If you manually installed it then it’s on you to update things. Now if the dev bundled deps then yes there is the possibility that they neglect to update those. But this situation is improving as runtimes add more popular deps, baseapps are also a new way to share bundles of deps which could reduce that burden. Repositories can also scan flatpak manifests and flag issues too.
yjftsjthsd-h 3y ago
Good article, terrible title. In fact, the author seems to ack the main problem with the title themselves: > But packaging for distributions is hard > That's the best thing! Developers are not supposed to be the ones packaging software so it's not hard at all. It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in. It's not "devs are lazy"; devs shouldn't be worrying about packaging in the first place! And the lazy comment doesn't even come up in the actual post.
- curioussavage 3y ago
  To me the prescriptive declarations in this whole conversation make it insanely stupid. Who the hell gets to tell developers what they should do. Your users want your software so you get it to them how you can. End of story dudes. Immutable distros with flatpak apps are the future for desktop Linux. Thankfully wining about it seems to get less attention.
superkuh 3y ago
Containers on the desktop are a symptom of disease in much the way that a fever is a symptom of disease. Fevers mitigate viral replication efficiency. Containers on the desktop mitigate future shock from the underlying libraries changing so fast that software written at T+3 years cannot be compiled or run on system libs from T+0 years. Like a fever they cause lots of other problems that damage the system but at least preserve most functionality. The accepted pace of churn in software has now shrunk below the release cycle rate of operating systems. The problem is caused by developer's obsession with the bleeding edge, not being lazy. But it's not just devs. These days if you haven't made a change in your software in the last year people will start asking if it's no longer developed. The eternal wave of now has to be surfed and stability is just a dream from the past.
- lylejantzi3rd 3y ago
  > It's caused by developers obsession with the bleeding edge, not being lazy. Exactly. If developers really were lazy, the libraries wouldn't change as fast as they do.
  - taeric 3y ago
    Ish. Stability of API takes a lot more effort than Rambo engineering.
- Dalewyn 3y ago
  Daily reminder that Microsoft's devotion to backwards compatibility in Windows is legendary.
  - cedilla 3y ago
    As legendary as it is overstated. It's excellent for many common software, but for most specialty software, it's often lacking. Despite all the decades of cruft still supported by current Windows, especially 32 bit editions, there are still tons and tons of XPs and Server 2008s and NT boxes in the wild just to support software that would otherwise break.
drowsspa 3y ago
C is what, five decades old? Seems like building and packaging software should be a solved problem by now. Instead every single language has to re-invent everything, and it seems it's mostly because of these binary dependencies.
- nmz 3y ago
  Static compilation solves everything, that and cosmopolitan should solve the portability problem. Looking at redbean, we could be programming native applications in lua that would be portable across OS and be lean as well as static (and fast, without depending on a browser). The main problem is dynamic compilation, I wouldn't fault the "every lang wants to reinvent everything", go took its lessons from plan9 and seems to me the correct method of compilation in nix. for versioning, the only way to do it correctly is tossing away the FHS and using the structure of gobolinux.
- taeric 3y ago
  C is the last of the old guard languages where every major target had their own toolchain to build with. Microsoft shops used the visual studio compiler chain. Sun used their own, sgi, etc. Gcc broke the mold by being unattached to a platform and usable.
boudin 3y ago
I don't really get the point it's trying to make. - The UX of Gnome Software can be improved (a lot) but this is kind of unrelated to Flatpak. - Turning the argument around, having a declarative permission system allows to list what permission an application requires, which is a good improvement. The way it's presented can be improved but it's still great. - A flatpak package is still something that needs to be managed but it's true for any form of software distribution. A lot of flatpak packages are community managed so the attention they get will vary. As any form of community managed project, it's possible to step in and contribute, which is the good side.
smallerfish 3y ago
If app sandboxes were enforced (and better) then a lot of this could be forgiven. Though, either way, I really don't like third parties being able to package and maintain a vendor's commercial binaries on Flathub (IntelliJ, Zoom, apparently also Edge).
jitl 3y ago
The kind of entitlement in the article title is so off-putting. Every time I read an article about the “distribution” and “packaging” situation on Linux, I come away happy I don’t target desktop users on that platform via a native app. I’m very happy to have the browser runtime between me and Linux desktop software stacks. I’ve seen plenty of complaining about NPM, go dep, and other language package managers, but I’d much rather be able to pick and lock my dependencies than have them semi-randomly assigned by myriad vendor teams. If I did have to target Linux desktop, I would only use Flatpak, fully static binaries, or similar, and be very happy to have a container boundary etc that allows me to pin my dependencies.
Rhedox 3y ago
> It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in Not necessarily and that model doesn't scale.

30 points by ecliptik 3y ago

xena 3y ago

Developers aren't lazy, packaging software is fucking bullshit.

Laziness is a desirable trait in programming: it gets you to do things smarter, not harder. Packaging once and installing everywhere instead of packaging `n` times for pointlessly conflicting formats is like that. Sandboxing and optional static linking is a bonus. The paradigms we've been using date to times when memory was scarce and software was rarer (there was literally less of it for maintainers to worry about) more innocent (no crypto jackers) and simpler (with less dependencies). We don't live in those time anymore.

DethNinja 3y ago

Flatpak isn’t ideal and it has lots of room for improvement but what is the better alternative? I would say that at least Flatpak is on the right direction.

jmclnx 3y ago

Yes, and I would add flatpak ensure security issues are never looked at. I believe if something in flatpak has a security problem, it will never be addressed. Why, because it is in a flakpak and is separated from the OS, so the issue just sits there. This could end up being a problem for distros not using flatpak and for that matter the BSDs.

curioussavage 3y ago
This is absolutely a false assertion. If your distro integrates flatpak then you will be prompted to update the runtimes. If you manually installed it then it’s on you to update things. Now if the dev bundled deps then yes there is the possibility that they neglect to update those. But this situation is improving as runtimes add more popular deps, baseapps are also a new way to share bundles of deps which could reduce that burden. Repositories can also scan flatpak manifests and flag issues too.

yjftsjthsd-h 3y ago

Good article, terrible title. In fact, the author seems to ack the main problem with the title themselves: > But packaging for distributions is hard > That's the best thing! Developers are not supposed to be the ones packaging software so it's not hard at all. It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in. It's not "devs are lazy"; devs shouldn't be worrying about packaging in the first place! And the lazy comment doesn't even come up in the actual post.

curioussavage 3y ago
To me the prescriptive declarations in this whole conversation make it insanely stupid. Who the hell gets to tell developers what they should do. Your users want your software so you get it to them how you can. End of story dudes. Immutable distros with flatpak apps are the future for desktop Linux. Thankfully wining about it seems to get less attention.

superkuh 3y ago

Containers on the desktop are a symptom of disease in much the way that a fever is a symptom of disease. Fevers mitigate viral replication efficiency. Containers on the desktop mitigate future shock from the underlying libraries changing so fast that software written at T+3 years cannot be compiled or run on system libs from T+0 years. Like a fever they cause lots of other problems that damage the system but at least preserve most functionality. The accepted pace of churn in software has now shrunk below the release cycle rate of operating systems. The problem is caused by developer's obsession with the bleeding edge, not being lazy. But it's not just devs. These days if you haven't made a change in your software in the last year people will start asking if it's no longer developed. The eternal wave of now has to be surfed and stability is just a dream from the past.

lylejantzi3rd 3y ago
> It's caused by developers obsession with the bleeding edge, not being lazy. Exactly. If developers really were lazy, the libraries wouldn't change as fast as they do.
- taeric 3y ago
  Ish. Stability of API takes a lot more effort than Rambo engineering.
Dalewyn 3y ago
Daily reminder that Microsoft's devotion to backwards compatibility in Windows is legendary.
- cedilla 3y ago
  As legendary as it is overstated. It's excellent for many common software, but for most specialty software, it's often lacking. Despite all the decades of cruft still supported by current Windows, especially 32 bit editions, there are still tons and tons of XPs and Server 2008s and NT boxes in the wild just to support software that would otherwise break.

drowsspa 3y ago

C is what, five decades old? Seems like building and packaging software should be a solved problem by now. Instead every single language has to re-invent everything, and it seems it's mostly because of these binary dependencies.

nmz 3y ago
Static compilation solves everything, that and cosmopolitan should solve the portability problem. Looking at redbean, we could be programming native applications in lua that would be portable across OS and be lean as well as static (and fast, without depending on a browser). The main problem is dynamic compilation, I wouldn't fault the "every lang wants to reinvent everything", go took its lessons from plan9 and seems to me the correct method of compilation in nix. for versioning, the only way to do it correctly is tossing away the FHS and using the structure of gobolinux.
taeric 3y ago
C is the last of the old guard languages where every major target had their own toolchain to build with. Microsoft shops used the visual studio compiler chain. Sun used their own, sgi, etc. Gcc broke the mold by being unattached to a platform and usable.

boudin 3y ago

I don't really get the point it's trying to make. - The UX of Gnome Software can be improved (a lot) but this is kind of unrelated to Flatpak. - Turning the argument around, having a declarative permission system allows to list what permission an application requires, which is a good improvement. The way it's presented can be improved but it's still great. - A flatpak package is still something that needs to be managed but it's true for any form of software distribution. A lot of flatpak packages are community managed so the attention they get will vary. As any form of community managed project, it's possible to step in and contribute, which is the good side.

smallerfish 3y ago

If app sandboxes were enforced (and better) then a lot of this could be forgiven. Though, either way, I really don't like third parties being able to package and maintain a vendor's commercial binaries on Flathub (IntelliJ, Zoom, apparently also Edge).

jitl 3y ago

The kind of entitlement in the article title is so off-putting. Every time I read an article about the “distribution” and “packaging” situation on Linux, I come away happy I don’t target desktop users on that platform via a native app. I’m very happy to have the browser runtime between me and Linux desktop software stacks. I’ve seen plenty of complaining about NPM, go dep, and other language package managers, but I’d much rather be able to pick and lock my dependencies than have them semi-randomly assigned by myriad vendor teams. If I did have to target Linux desktop, I would only use Flatpak, fully static binaries, or similar, and be very happy to have a container boundary etc that allows me to pin my dependencies.

Rhedox 3y ago

> It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in Not necessarily and that model doesn't scale.