@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.
Heck. Supporting source for others who were wondering:
@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 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.
@Sandra @csepp A useful blog post to get some numbers: https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/
Ulrich Drepper wrote about how to fix it in 2002 - nearly 20 years ago now - in https://www.ukuug.org/events/linux2002/papers/pdf/dsohowto.pdf
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.
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 ...
@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.
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.
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.
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: https://www.bassi.io/articles/2017/08/10/dev-v-ops/
In short: Linux distributions work like sysadmins deploying OS and C/C++ apps to users. Nothing really works like that any more.
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
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?
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.
@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.
@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
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):
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!