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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.