"They say disk space is cheap. This is not true, not for the root devices of modern computers. Built-in storage has in fact been shrinking." ♥


"There is one glaring exception to my claims regarding Linux library stability. That exception is GTK. #GTK famously breaks their libraries with reckless abandon."

This is actually bad even for libre systems. Eg.: it means the library doesn't support grafting on Guix, so if you want to push a security fix quickly (or use a customized version on your own system) then you have to recompile every dependent package.


@csepp @Sandra That article is entirely FUD, and the bit about GTK is grotesquely wrong. I contacted the author who *at least* fixed the paragraph about the versioning and LTS policy that has been in place for the past 5 years and that he hadn't bothered to read. He kept the entire section the same, even if the whole thing is contradicted by the official GTK team policy.

· · Web · 2 · 1 · 7
The paragraph you are arguing against (and I agree with your arguments wrt that paragraph) is there as a caveat against the rest of the article. Paraphrased: "Flatpak is bad, but, one argument for it is the flux of GTK's ABI."

To the extent that GTK supports its LTS releases, the case laid forth in the rest of the article is stronger.


@Sandra @csepp No, the article is full of weird non-sequiturs or outright fabrications, like the fact that flatpak, which deduplicates files on disk, consumes "more space". It's based on the mistaken assumption that you can create a stable platform in a volunteer-based, decentralised environment that is predicated on the fact that people can (and will) fork projects, without a top-down decision making chain

@Sandra @csepp Flatpak is necessary because the FLOSS ecosystem is not like Windows. Even Windows has been encouraging app developers to ship their dependencies for 30 years


Article: Flatpak is bad, but, one point in favor of Flatpak is how much of a moving target the GTK ABI is
You: There are LTS releases of GTK
Me: Weird that the specific thing about the article you complained about was the one pro-Flatpak caveat
You: No.

What is the "No" in reference to?


@Sandra @csepp The premise of the article is wrong; the methodology flawed; and the conclusions are bad. On top of that sundae of bad stuff, there was a cherry of long-since debunked FUD that referred to a specific project I work on.

The fact that the author couldn't even get a 5 years old debunked FUD right should illuminate with how much salt you should take the rest of the article.

@ebassi @csepp

That makes more sense, but, that GTK-misinfo was served up as an argument for flatpak, not against it.

It's because of the ecosystem differences (i.e. we have source) that we can have build-centric software distribution like apt, nix, and guix.
@ebassi @csepp

Thank you for constructively and professionally deescalating the argument. Regardless of whether that is easy or hard, it is always appreciated. Keep the internet polite & kind.

@ebassi @Sandra @csepp That debate would be so cute if it weren't so horrible. Almost all of these package management systems sort of refuse to deal with DLL hell, and instead want to circumvent it.

Ulrich Drepper wrote about how to fix it in 2002 - nearly 20 years ago now - in ukuug.org/events/linux2002/pap

What's the secret sauce, extracted from all the technical details about shared libraries and memory mapping and all that stuff?


Wait, that's it? Yes... yes it is.

@ebassi @Sandra @csepp The point of an interface is in the name, but it gets forgotten so often because that name is flung around in so many vaguely different contexts it's become diluted.

An interface is an agreement by which communications between two parties is shaped in such a way that each party can do whatever the fuck they want, as long as the interface stays intact.

(TL;DR you can add to an interface, but not remove from it.)

Instead, developers treat APIs and ABIs as stuff that ...

@ebassi @Sandra @csepp ... only concerns themselves and nobody else, and then get pissed off when shit breaks.

Flatpak is just a symptom of this shit.

@jens @ebassi @Sandra @csepp It is unfortunate that the vast majority of software developers in the Linux community, in my experience based on both online discussions and working along side them in a physical office space, simply do not believe that it is possible to develop shared libraries in such a way that you incrementally add new features without breaking backward compatibility, even when presented with a concrete existence proof (namely, AmigaOS shared libraries, where Kickstart 3.2 can still run Kickstart 1.0 applications, as long as the latter sticks with the library interfaces).

I remember this philosophy being a very core part of the Go community, which was vociferously ridiculed by many as not only unfeasible, but technologically impossible.

@vertigo @ebassi @Sandra @csepp It can be hard.

If a function contains a bug, do you fix it?

If you do, you may break applications that are using a workaround to your bug. While the fix would be correct, you would essentially break the contract with it.

Whether or not that's the case can depend on so many factors, it becomes difficult to determine what to do.

Plus, it means you have to version functions.

@jens @ebassi @Sandra @csepp

With AmigaOS, examples of forward thinking have been built into most libraries which ameliorates most of these concerns.

Once upon a time, back when Kickstart 1.0 was just released, there was a function in exec.library which you used to open other libraries. It was called OpenLibrary(), and it took one parameter: the name of the library.

Starting with Kickstart 1.1, they realized it wasn't enough. So, they introduced a new OpenLibrary() that took two parameters: a library name and a version. The old OpenLibrary was renamed OldOpenLibrary, and that function still exists to this day. OldOpenLibrary("foo") is equal to OpenLibrary("foo", 0).

With Kickstart 1.0-1.3, they realized they were running out of reserved fields in the NewScreen and NewWindow structures for supporting new functionality. Starting with Kickstart 1.4, they introduced a new set of functions to open windows and screens based on tag-lists. Those functions have remained ever since. The old functions still work, by the way; you just won't get the features that are accessible only through taglists.

Taglists allow for open-ended and even optional argument lists.

Starting with Kickstart 2, they realized that the old, statically allocated list of gadgets approach to UI development wasn't flexible enough to handle the now dynamically sized window frames, and user-selected fonts and sizes. So, they introduced a new method of developing UIs, called BOOPSI (Basic Object Oriented Programming System for Intuition) which is as expressive as Objective-C, and has since come to dominate the way you code GUIs on AmigaOS.

The old gadget-list approach, by the way, still works fine.

exec.library is an interesting case study because over time it kept getting more functions added to it to deal with features in the newer CPUs (68020 and later). Mostly caching related, but ISTR that there were a few MMU-related functions too.

AllocMem() is worth a look as well, as it is used to allocate memory out of specific memory pools (e.g., only CHIP RAM, or only FAST RAM, etc.). In AmigaOS 4.0, there's a new flag that allows it to allocate memory out of that process' private memory space, preventing that block of memory from being visible to other processes in the system. Meaning, AmigaOS 4 is a hybrid single-address and multi-address space operating system.
I am not sure if this feature has been back-ported to Kickstart 3.2 or not; but, there is no technical reason why it couldn't be.

My point here is that it's not as hard as is frequently claimed. Damn the torpedoes, and fix your bugs! If people can make use of "feature-flags" to control A/B tests and all this other stuff, they sure as hell can use the same, or at least very similar, techniques to maintain backward compatibility for more than one or two generations of their software.

P.S.: Kickstart still fits in a 512KB ROM image. The combined size of all of AmigaOS remains below 100MB, with a minimum core probably still needing no more than 10MB.

@vertigo @ebassi @Sandra @csepp Win32 is doing the same stuff.

For all the shit you can give Win32, backwards compatibility isn't a part of that.

@jens @ebassi @Sandra @csepp Nope. And, I give Win32 a lot of well-deserved shit. 😏

COM is another good technology that is worth studying, I think. It makes the notion of an "interface" a first-class design issue.

@jens Rich Hickey of Clojure talks in very similar terms about names, interfaces, versions and namespaces in his classic keynote "spec-ulation":


@ebassi @csepp @Sandra
@clacke I need to listen to that; I heard and commented on the sequel https://idiomdrottning.org/separating-schema-from-selection
Spec has some issues as a library.
@Sandra I didn't understand the schema vs selection talk when I heard it. Will have to listen again some time. Maybe it helps if I learn Clojure and Spec first?

@clacke @ebassi @csepp @Sandra Well, yes, any reasonable engineer would. He says, as if that makes him reasonable.

Joking aside, it's a kind of thinking that requires up-front design (up to a point), and many people prefer more exploratory approaches. The two are not incompatible, but often hard to reconcile.

@ebassi @Sandra @csepp but doesn't the author in OP have a point, though, regarding disk space bloat. The counter-argumenter makes the point that he only has ~9 GB of runtime on his machine, but these only span about 4 years worth of binary updates. The original thesis is that *in the future* it would amount to tens of GBs, and taking into account the reference timeframe of 25 years (the win32 argument) and the admitted deduplication rate of about 40% (low sample rate though, also bound to be varying a lot), it doesn't seem too far off the mark

@codeforchaos @Sandra @csepp In general, deduplication is highly affected by reproducibility in builds; if components stay the same across both applications *and* run times, then the efficiency goes up in the face of new releases.

The point, though, is still the same: you either do this, or you have to expect that every project is going to be built and shipped by your downstream, which has well known scalability issues

@codeforchaos @Sandra @csepp The FLOSS world does not, and cannot really have a centralised single place where to package all software; the closest thing you get are Flatpak run times, or Steam bundling Ubuntu 12.04 for years in order to have games run without rebuilding them from scratch everywhere

@codeforchaos @Sandra @csepp I wrote a thing a few years ago: bassi.io/articles/2017/08/10/d

In short: Linux distributions work like sysadmins deploying OS and C/C++ apps to users. Nothing really works like that any more.

@ebassi This is a golden article, and one that I think a lot of people should read.

@purple @ebassi @codeforchaos @csepp

First of all, when you tag in four people in a reply like that, be clear about who you mean. I had to go digging through the post database to suss out the reply id.

Second of all, maybe your browser settings are borked because his post is black text on white background:

@purple there is only a small introductory text that acts as a side note/commentary, and does not matter; the main content is black text on white background

@ebassi @codeforchaos @Sandra Still reading it, just a quick note about "insert_your_language_here":
maybe it wasn't the case in 2017, but nowadays Nix seems to be pretty popular with Haskellers.

BTW Nix and Guix actually give you what you want with tools like guix pack, while still letting people replace dependencies. Eg.: "How can you host a repository...", the answer is Nix flakes or Guix channels.

@csepp nix/guix come with their whole OS/distro, which means they solve the packaging and distributing software problem just like switching everyone to RHEL solves the packaging and distributing software problem—i.e. not at all.

Some of the ideas about non-trivial restructuring of file system layouts are interesting, but Nix is still based on the assumption that apps are safe to use, and limits sandboxing to the build step, instead of the execution step.

@ebassi They aren't really distros though. You can't use RHEL on top of Arch, but you can use Guix or Nix (or even both) on top of RHEL, or Arch, or whatever. They are more like virtualenv in that sense.
And yeah, there is work to be done on sandboxing but having very precise control of package inputs should make that easier, and there is ongoing work to harden Nix. I can't remember the name but someone got an NGI grant to do that? I think?

@ebassi Found it:
also of interest:

So sandboxing is definitely not something that Nix can't do.

Hopefully they don't share that issue with Flatpak mentioned in the OP where $HOME access leads to full system compromise.

@csepp @ebassi Do keep in mind that you can always just remove the filesystem permissions, and there's often work in the background to help improve things as well.

Unfortunately, any time an application doesn't use portals, and you want out-of-the-box filesystem access, there isn't much of an alternate choice.

@ebassi @codeforchaos @Sandra The argument about having fewer intermediaries is interesting. Most of what you and the OP focus on seem to be "leaf packages". Here too having a Guix package (even in a custom channel, or just a guix.scm file in the root of your software's git repo) is very useful, because sometimes it's not a leaf package I want to get directly from the dev, but a library.

@ebassi @codeforchaos @Sandra (cont.) With Flatpak, I'm not aware of any way to replace an intermediate library. With Guix it's a simple rewrite rule. And yes that's something I've actually used. So, idk, for me the value proposition of Flatpak is... not great. (2/2)

@csepp Non-leaf packages have two use cases: system dependencies, in which case you have them in the base OS or in the "run time" layer; or a dependency for a leaf node. If the system/run-time is entrusted to the OS vendor (e.g Fedora or Debian) then nothing changes. The only change is if you need a specific dependency for your application, one that is either not available in the OS (because nobody packaged it) or because you need some special flag (so sharing is impossible)…

@csepp If a Flatpak app needs a dependency that is not in the run time, then you can add it to the app's manifest, and build it as you want. Flatpak separates the run time from the application's own build, so even in case of overlap—e.g. you want a more recent version of GTK than the one shipped by the GNOME run time—then your app will link against the one you built yourself…

@csepp The value proposition of Flatpak is not "building software" (though it's there); it's distributing software directly on any Linux distribution, and running software in a sandboxed environment

@ebassi Thanks!
Tbh I'm trying to see how Flatpak would be better than Guix, but even with the goals you list ("adopt better standards", "have the tools to modify the software they are using"), I can't really see it being any more useful than guix pack. Also Christine Webber seems to think that Guix is especially well suited for OCAP. And configuring a system in Scheme is Very Nice. So "Adopt better standards" for me means Guix. Maybe with Flatpack as a guix pack target.

@ebassi Like, reproducible and well structured software that is easy to build is usually very neatly packageable on Guix. And that way I get all the neat features Guix has. If we are adopting better standards and reproducible builds and stuff, I think Guix is a better target to aim for.

@csepp I'm not trying to convince or sell you on Flatpak, to be honest. If you find Guix better suited for you, that's absolutely fine by me. I don't particularly care about Haskell, and I don't really like Scheme, so for me, Guix/Nix are kind of useless complications on top of a system that is already complex enough.

We can all benefit from reproducibility and from well defined software manifests; and if Guix ever gets sandboxing, we can share the Portals needed for access negotiation.

> In his talk at the 2017 GUADEC in Manchester, Richard Brown presented a set of objections to the current trend of new packaging systems — mostly AppImage, Snap, and Flatpak — from the perspective of a Linux distribution integrator.

The YouTube link for the talk is broken for me; Here's the non-YouTube video (direct link to webm):

@ebassi @codeforchaos @csepp @Sandra
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!