-- Leo's gemini proxy
-- Connecting to warp.geminispace.club:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en
> The first part has nothing to do with Lagrange and the way to compile it, if you are looking exclusively for that documentation jump directly on Part 2.
Some months started the effort to bring Lagrange into Debian but the process of making a deb package can be long and must follow the Debian release cycle, which means going through "Experimental", "Unstable", "Testing" and eventually "Stable" stage.
In the meantime to easily get Lagrange on Debian or Devuan anyone has the option to use the appimage or the flatpak version.
I have been using so far the flatpak version, however flatpak packages require a lot disk's space; for instance the Lagrange appimage is around 9.1MB (which is fine) but for the flatpak version the space required grows up in order of GB...
In this particular Virtual Machine where I am currently writing I have installed only Lagrange as shown below:
flatpak list Name Application ID Version Branch Installation Lagrange fi.skyjake.Lagrange 1.9.4 stable system Freedesktop Platform org.freedesktop.Platform 20.08.16 20.08 system Mesa org.freedesktop.Platform.GL.default 21.1.8 20.08 system openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 system
However if I check the size of the flatpak folder the runtime and libraries required to run a small binary occupy more than a gigabyte of space:
du -h -s /var/lib/flatpak/ 1.1G /var/lib/flatpak/
We are talking about 9.1MB vs 1.1GB... :scream:
Something got wrong with flatpak... And generally something get always wrong when for design you solve a problem creating a new problem, in this case the ridiculous amount of wasted space!
At least the appimage bundle strips down all the unnecessary libraries and runtimes in order to keep the bundle leaner as much as possible.
Flatpak is advertised to be able to deduplicate shared libraries however this would occur if two different software were built against the same libraries and runtimes, but the reality is that anyone is free to package a flatpak applications using their own specific runtimes, even installing few applications you are likely going to install different version of the same runtimes and libraries ending up wasting gigabyte of space for no reasons.
The evil mechanism of Flatpak is well explained here:
With agnostic solution like the "Nix Package Manager" and "Guix Package Manager", that can be mounted on top of your current package manager there was not any real necessity of Flatpak or Snap, even though Flatpak has been around for a while and before Snap as "xdg-app"; considering also that appimage solves fine the retro-compatibility issues that affect the whole Linux ecosystem, what is the meaning behind flatpak (and snap)?
> what is the meaning behind flatpak (and snap)?
I can only imply an answer, but excluding appimage, the left universal package managers share something in common that is pretty peculiar and is quite self-explanatory: both are project born from two of the major companies that work and make money with Linux.
With all the plethora of Linux distributions available only two of the three main enterprise distros that are backed by a corporation felt the need to create or to switch over a universal package manager (UPM), this cannot be a coincidence.
Basically you don't need anymore to maintain several versions of the same software for all your distributions still actives. Since it is "universal" it works on older and newer release across several different release cycles. For instance Canonical has several mid-cycle release and LTS release that often overlap themselves during their lifespan, Red Hat maintains several versions of Fedora, RHEL and now CentOS stream. Maintain third party software across all these distributions costs money, I guess.
We are accustomed in the Linux realm that projects/products are presented in a certain way while have a total different scope. The UPM affair is the classical representation of this behavior, while the mantra is about "sand-boxing" and "proprietary software", the reality is the sand-boxing has been often ignored or badly implemented and proprietary software, except for the communication tools which are eventually all electron apps and some few others that already exist before the UPM, aren't arrived yet and probably will not even for the next future.
What is it left then? Money, just money.
> Maintaining a single release of Chromium is a significant time investment for the Ubuntu Desktop Team working with the Ubuntu Security team to deliver updates to each stable release. As the teams support numerous stable releases of Ubuntu, the amount of work is compounded.
This is what Canonical said about it.
The same applies for Red Hat, there is not any reason to think that another company that operates in the same space doing the same things has a different opinion.
So the problem here is not giving to the software publishers or software vendors more autonomy or flexibility for delivering their products (what horrific word) but to alleviate such corporations from the burden to maintain software that is outside their business goals.
We may bet this would apply almost entirely for the desktop application, and we also may bet if any desktop software is within the area of their needs, this will be carefully provided to their end-users/customers.
The trick works using a well tested pattern and must be done without rushing otherwise you will receive a community backlash, like happens to Canonical every time it tries to accelerate the process to change the Ubuntu behavior:
The pattern follow the steps described below; however if you think about any recent introduction (systemd, wayland, flatpak, pipewire, etc...) you will recognize this very same pattern as pretty common; although some novelties like pipewire were really welcomed because the former solution (which has of course followed the same pattern as well) pulse-audio had been a pain in the heck for a very long time.
Check this out by yourself:
First: Generally an employee starts addressing some marginal issues of a certain specific area in his/her spare time (e.g. the better boot-up speed of systemd against sysvinit).
Second: artificially is created a interest through tech journalist PR in order to gain traction (usually are always the same well known tech journalists).
Third: when the traction has been triggered, the principal bleeding edge distros do the early adoptions (like Fedora and Arch Linux adopted systemd before all the other distros).
Fourth: a lot of PR made by trusted sources, blog articles by employees, affiliated and unaffiliated podcasts and youtubers start the brain-washing machine.
Fifth: once the ground has been prepared and the general opinion has been enough manipulated, the real plan starts to be distilled across the multiple annual conventions.
Sixth: to make all this process more credible is necessary the blessing of the unaffiliated communities, hence the brain-washing machine is converted into the tech-pressure machine with the scope to put pressure on the community distros (mainly Debian) with all the meaning available: tech journalists, donations, direct contacts, youtubers, podcasts etc.
Seventh: when all the process appears eventually as a broad community decision the change can be applied ignoring the complaining of the minorities (someone says Devuan?).
Regarding Flatpak we are approximately in the middle of the Fifth stage:
The principle is to bring down the containerizing methodology from the Server/Cloud to the desktop; some distros, Like EndlessOS and Fedora Silverblue, are already doing something similar, however while the whole idea may make a sense, as usual is the methodology that is wrong!
The doubt here is if containerizing the desktop space is our "true" concerning or it came anywhere out there for reasons outside my needs, yours needs, or the community needs.
Someone may argue to goal is to have a stable environment with the most updated software, and I agree that is a cool idea. However this concept wasn't brought on the light which such strength by anyone, except by Probono, but rather is born from this other reason:
> the amount of work is compounded!
The goal of pushing this technology is completely separated by the idea of helping or pleasing end-users. When is time to speak about the Linux desktop we always face this kind of bizarre issues, the point is you cannot apply commercial rules over projects that aren't commercial products. If you want use newer software use rolling distros, if you want use stable software use stable distros. If you want both I suggest to learn how compiling by yourself. Today UPM are fine tomorrow they will not!
> Today UPM are fine tomorrow they will not!
I do not think UPM will reshape the packaging scenario, maintainers matter!
Community distros like Debian or Arch are made by developers, maintainers and users!
> maintainers matter!
Maintainers matter, they are the glue that makes stick all together happily! They assure consistency and quality, they make the distro alive!
Community distros maintained by volunteers do not think atrocity like:
> the amount of work is compounded!
They do their job voluntary and they do what they can! And if they cannot they cannot!
End-users use their distro and help them as much as they can, giving a sense to maintainers amazing effort!
Maintainers for more than 20 years have been keeping your distros a safe place: they clean the code, they patch the code, they inspect the code for you and therefore have been the filter and the primary defense against user hostile practices.
If you detach the "desktop software" from the distribution you enable and allow software publishers and vendors to introduce all those annoying habits that are typically of proprietary OSs like Windows or MacOS, you as end-user are not anymore in control of the software you use, the software you use is not anymore subject to follow some design principles: you get the software "as-is" unfiltered. At this rate when the damage is already unrepairable the distros who claimed the UPM strongly can simply justify themselves blaming the others as usally do.
Do you really want toss in the garbage 20 years of good practices just because baked distros do not want anymore packaging software as the community distros do?
While we haven't already reached this point someone else from richest part of the world think that storage and internet connection is already cheap for anyone hence wasting your bandwith and disk space is worth the (arguable) innovation:
> have 18 runtimes, totalling 8.7 GB of storage (deduplicated), not “tens of gigabytes”. The top 5 most-used runtimes on my system cover 128 of the 163 apps.
> Personally, I think the trade-off is absolutely worth it for me and for Endless OS users, particularly since going all-in on Flatpak means that the base, immutable Endless OS install is just 4.2 GB.
Well, when nothing of these explain which software he has installed, by my side this is what this Virtual Machine (Debian) is currently occupying: approximately 7GB; and I have heavy software like Thunderbird, Firefox, LibreOffice, Inkscape, Gimp etc...
49M boot 2.7M core 9.7M etc 9.8M root 664K run 6.3G usr 600M var
13GB vs 7GB, nice accomplishment for a company that aims to better tackle the digital divide.
Anyway it is clear that containerizing the desktop-software is a concerning that belongs only to companies whether those are for-profit or non-profit.
I don't have anything more to add but this:
> Think carefully when technology shines just to make you blind.
This had to be just a simple documentation to compile Lagrange but suddenly became a rant against UPM and main stream Linux distros, what energetic impulse for this 2022 beginning!
By the way if you are still interested in reading how to compile Lagrange just follow the link below:
For comments or suggestion write me at:
-- Response ended
-- Page fetched on Tue May 21 20:15:02 2024