Deploying apps for the Linux desktop is hard. A major problem has historically been library compatibility. Different Linux distributions, and even different versions of the same distribution, have had incompatible libraries. Unfortunately, there hasn't always been a culture of backwards compatibility on the Linux desktop.
This is finally changing. The stability of the Linux desktop has dramatically improved in recent years. Core library developers are finally seeing the benefits of maintaining compatibility. Despite this, many developers are not interested in depending on a stable base of libraries for binary software. Instead, they have decided to ignore and override almost all libraries pre-installed on the user's system.
The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system's runtime libraries, and they now all use containerization to accomplish this.
Flatpak calls itself "the future of application distribution". I am not a fan. I'm going to outline here some of the technical, security and usability problems with Flatpak and others. I'll try to avoid addressing "fixable" problems (like theming) and instead focus on fundamental problems inherent in their design. I aim to convince you that these are not the future of desktop Linux apps.
Suppose you want to make a simple calculator app. How big should the download be?
At the time of this writing, the latest KCalc AppImage (if you can even figure out how to download it) is 152 MB. For a calculator.
This is uncompetitive with Windows on its face. If I ship an app for Windows I don't have to include the entire Win32 or .NET runtimes with my app. I just use what's already on the user's system.
Other solutions like Flatpak or Steam download the runtime separately. Your app metadata specifies what runtime it wants to use and a service downloads it and runs your app against it.
So how big are these runtimes? On a fresh machine, install KCalc from Flathub. You're looking at a nearly 900 MB download to get your first runtime. For a calculator.
[...] Snap and Flatpak in their current incarnations have been around for at least five years. AppImage, Steam and Docker have been around even longer. None of the above is new. The problems with alternate runtimes were known from the very beginning, yet little progress has been made in fixing them. I don't believe these are growing pains of a new technology. These are fundamental problems that are mostly not fixable.
All of these technologies are essentially building an entire OS on top of another OS just to avoid the challenges of backwards compatibility. In doing so, they create far more problems than they solve. Problems of compatibility are best solved by the OS, the real one, not some containerized bastardization on top. We need to make apps that run natively, that use the system libraries as much as possible. We need to drastically simplify everything if we have any hope of attracting proprietary software to Linux.
The full article is a very interesting read.
(Score: 2, Redundant) by Frigatebird on Wednesday November 24 2021, @11:58PM (14 children)
Why would we want to do this? They can just distribute the source files, and everyone can compile for their own system. Do you have a problem with tarballs?
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @02:59AM (2 children)
Oooooh maybe next year will be the year of linux on the desktop.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @07:32AM (1 child)
Those dickheads at Red Shat will finally adopt apt/dpkg?
(Score: 2) by https on Friday November 26 2021, @05:08AM
Not likely, usr/merge (out of redhat land) and dist-upgrades (out of dpkg land) appear fundamentally incompatible, and it's been almost hilarious watching the ensuing debian-devel flamewars as they try to consensus on a workaround that nobody has yet.
Offended and laughing about it.
(Score: 3, Insightful) by arslan on Thursday November 25 2021, @03:23AM
Because if you want it to be the year of the linux desktop - which means mom and pops using like windows - you'll need to.
That is not a flawed assumption - maybe just a difference in desire and opinion than you. Difference does not mean flawed; otherwise you're flawed in the eyes of anyone that has a difference desire/opinion than you.
(Score: 2) by tangomargarine on Thursday November 25 2021, @03:41AM (8 children)
...what?
This is like the OSS equivalent of "let them eat cake".
"Maybe we can convince all those proprietary companies that care about the security and IP rights of their code to just release it open-source." Doesn't sound hard; I'm sure global warming has lowered the temperature of hell by a degree or two by now, or whatever.
Not sure if I'm more confused whether you're actually being serious, or how you somehow got +4 Insightful.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: -1, Flamebait) by Frigatebird on Thursday November 25 2021, @12:41PM (2 children)
It is a real and serious suggestion. Not any more absurd that Linux should try to encourage proprietary code. Who are you, that guy who promoted "open source" over "free software", because "free" might scare the suits? What was that traitor's name. anyway. He was quite a self-promoter, even if he did do some work for free software.
Fuck proprietary software, all of it. If you cannot make a living, without the arm of the law and alleged copyright, perhaps you should seek another line of work.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @03:46PM (1 child)
Tell that to Adele. Or David Bowie. Or Marvel. Or Charles Dickens. Or Beyonce. And so on.
Why is it so hard for idiots to imagine other people's situations? Oh. Right.
(Score: 1, Interesting) by Anonymous Coward on Thursday November 25 2021, @11:48PM
And don't forget to tell it to those who never produced anything because they didn't have copyright, like Alighieri, Shakespeare, Vivaldi, Bach...
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @03:03PM (4 children)
No, this is like "look at Nvidia driver, stupid!"
Your "IP rights" to boilerplate code that talks to FOSS libs, aren't worth the electricity wasted even discussing the stupid concept. And all your "secret sauce" can quite happily live in a precompiled binary that does not call anything outside the shim made of all that boilerplate and compiled in-place. Even better, incompatibilities between library versions can be easily worked around inside the shim, by patches and conditional compilation, leaving the main binary in no need to be updated for any churn that is happening in the distros' libs.
(Score: 2) by tangomargarine on Thursday November 25 2021, @04:55PM (3 children)
As much as we may say this, the proprietary companies are going to beg to differ.
Except that this isn't what parent is talking about, when he clearly says "distribute the source files."
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @05:44PM (2 children)
If they want more problems supporting their shit, it is their funeral.
How exactly is source for a shim not "source files"? Go improve your understanding of written word before your next try.
(Score: 3, Touché) by tangomargarine on Thursday November 25 2021, @06:47PM (1 child)
Because the shim isn't the product they care about? What are you, an Oracle lawyer?
Waiting with baited breath to see how your next reply completely misses the point of this comment as well.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: -1, Troll) by Anonymous Coward on Thursday November 25 2021, @08:17PM
Isn't that "point" merely you trying to bullshit your way around the foot you firmly placed in your alimentary orifice? With the pathetic result of chomping on two feet now. Bon appetit.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @02:48PM
And then do what, when they launch the compiled binary and the UI comes out horribly mangled due to GUI toolkit devs deciding to "deprecate" this or that in the new version? Or when it refuses to compile at all, due to API incompatibility introduced by some library?
When the developers do not want the unenviable task of testing and debugging their software on every single distro it gets used on, then carrying around a known compatible set of libs is really the only choice. It can be done the smart way, like say VMware does; libs are installed in a directory, and those that installer decides are compatible with the system ones, are replaced by symlinks to those. Then security updates for those libs will apply in the normal way, and things would only break if the distro's maintainer dropped the ball and let an incompatible update happen.
(Score: 5, Insightful) by Subsentient on Thursday November 25 2021, @12:11AM (8 children)
I hate Snap and Flatpak and all that containerized shit. If you're that paranoid about the software you're running, you shouldn't be running it at all. If you need to distribute a proprietary program on Linux, let me tell you how I personally prefer you do it.
1. Install all required shared libraries into a folder with your executable.
2. Make a shell script launcher that does this:
3. Make it into a tarball, and give me the tarball.
4. Profit!
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 3, Informative) by bart9h on Thursday November 25 2021, @12:55AM
That is exactly what Firefox does.
I mean, if you download the binary from their page, instead of installing your distribution package.
(Score: 4, Insightful) by Anonymous Coward on Thursday November 25 2021, @02:31AM (1 child)
This has the same major issue as flatpack and snaps (also static compilation). No system-wide security updates for vulnerable libraries.
If an application just dynamically links to the libraries provided by the distribution, and say an openssl exploit comes out, you can have everything on your system that uses openssl patched with a single distribution update to the openssl libraries. Contrast this to every random application distributing its own library versions-- now you have to wait for *every* random application provider to distribute patched libraries.
Also (a general complaint about flatpack et al), one of the great things about Linux distributions is that everything you need comes from a single trusted source via the package management system. Why the hell would we want to give up that to emulate the disaster that is the windows way of distributing applications each from a separate, random site where you really have no idea if you are installing malware. I'll keep my package manager, thanks.
(Score: 2) by Subsentient on Thursday November 25 2021, @07:38AM
Yeah that's true, I would definitely prefer if vendors used dynamic linking and actual builds for recent distros, but sadly that's too much work for them to be bothered with much of the time. At least with my approach, it's portable, easy, and doesn't require a special container format.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by Unixnut on Thursday November 25 2021, @02:46AM
There was an attempt to standardise things in Linux-land, "Linux standard base" (https://en.wikipedia.org/wiki/Linux_Standard_Base) , but it turned out that the different distributions just could not agree on a standard base, which is why that fell by the wayside in (according to the wiki) 2015.
I guess realising that it was futile trying to get every Linux distro to agree to a standard userland, the second option was to just abstract the userland away. This was done with Linux containers, which allowed each process to effectively have its own userland, and only share a kernel.
This is not a new concept, having existing on IBM big iron for decades, Solaris "Zones" and BSD "jails" for years. However on those systems the technology was used more like a "VM-lite" option, when you did not need the full isolation of a VM, with the performance overhead. This is because these Unxies had few variants with little variation in the base userland. None of them had hundreds of different "distros", each with their own idea of how the userland should look.
As such, Linux containers (via Docker) became effectively a software distribution system, where instead of just installing a package, you install the package and the entire userland it has been built and tested with. It is a resource hog of bloat, but it sidesteps the "different userland problem" in a way that is easy for the software developers. They don't have to test and code for every userland. They just decide what userland they want, build and test with it in containers, and when it passes QA just ship the entire thing as a Docker image.
As long as the Docker people build a version that works with your userland, you can be pretty much assured any Docker image will run on it. Hence why (for better or for worse) it has become one of the main methods of software distribution on Linux.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @05:34AM
These were the logical result once computers got enough power to actually do this reasonably well. Distribution maintainers and library authors have been HORRIBLE with backwards and cross compatibility, particularly binary compatibility, and even though many dislike it, most people care about binary compatibility more than source code compatibility.
Furthermore, even if you only care about source code compatibility, getting a lot of packages to build and run these days is a non-trivial endeavor, often resulting in a maze of dependencies (which may need to be compiled themselves) and the various tool chain everybody's-junk-in-the-trunk baggage for every language that so much as breathes on the thing, because it's a foreign concept that anyone would use boring ol' make these days.
(Score: 2) by mth on Thursday November 25 2021, @08:15AM
If you care about security, you should always be slightly paranoid. Even if the developers have the best intentions in the world, bugs could mess up your system and supply chain attacks could compromise the build. Giving applications only the permissions they need is just sensible; it's why we don't run everything as root.
There are problems with the current application container systems for sure, but I don't think containers themselves are the problem. Servers have been running in container-like fashion (chroot, jails) for years. Sandboxing desktop applications is more difficult and less urgent, but I don't see any fundamental reason why it would be a bad idea.
(Score: 2, Insightful) by shrewdsheep on Thursday November 25 2021, @08:33AM
If you hate these solutions, why do you suggest exactly the same thing? A container image is exactly what you suggest: a file container that is extracted into a folder and run from there with the additional benefit of being more strongly isolated and often using an overlay filesystem to safe diskspace.
Unless library versions (including configuration options) are fully standardized across distros and many library versions are allowed (which most distros do not) there is no way around these solutions. I prefer the diversity of distributions and try to minimize the use of flatpak and friends. To me it should be a 99/1 solution. The dstro should package 99% of my packages. 1% I am willing to install through one of the mechanisms.
(Score: 2) by FatPhil on Friday November 26 2021, @08:10AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1, Interesting) by Anonymous Coward on Thursday November 25 2021, @12:12AM (3 children)
"...if we have any hope of attracting proprietary software to Linux."
No thank you. Also the author forgot the GNU part, and how GNU/Linux is built on top of the free software movement.
And it's a question of numbers, proprietary software follows the money. No business in their right mind would invest in an OS with 2.5% of usage share.
Regarding the "containerized bastardization" I would rather have an option, even if that means downloading something containerized, than no option at all.
(Score: 2) by Runaway1956 on Thursday November 25 2021, @05:19AM (2 children)
That is subject to change, depending on how many exploits are found and exploited in Windoze. There may yet come a time when Big Business abandons Windows. Meanwhile, Microsoft is working to alienate consumers, with their blatant tracking and advertising. Not to mention Windoze 11 system requirement that obsolete a lot of hardware that works perfectly fine under any other OS.
Maybe I'm dreaming, but with MS treating people like dogshit, people should start leaving them.
(Score: 3, Interesting) by Gaaark on Thursday November 25 2021, @01:14PM
Only problem is, people seem willing to take ANYTHING Microsoft wants to shove up their arses: i remember laughing when a guy at work upgraded his memory and video card and had to call MS to tell them he wasn't pirating or whatever (don't recall the Windows that forced that and don't really care).
I said i'd be damned before i'd call MS to tell them to let me use my computer.
So glad i use linux.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @03:02PM
Ha! Microsoft has been burning users with terrible security in the early days and mediocre security now, absurdly buggy and slow software, releasing products and then killing them (Zune, Windows Phone, Silverlight, Windows RT), painful license management, and bad interfaces like Win8. It doesn't fucking matter, their market position is too strong. The work Valve is doing is the closest we'll get to The Year of the Linux Desktop, but I don't expect even that to work.
(Score: 3, Insightful) by krishnoid on Thursday November 25 2021, @12:27AM (5 children)
Space and memory usage aren't the problems that need solving as much as the user interface [microsoft.com] ones. At least the existence of guidelines for
would be very, very helpful.
If something uses more space, but provides a user interface that you don't have to relearn each time you move to a new app, wouldn't that be worth it? Fewer apps, which at least guarantee that an agreed-upon programmer/user interface would be available as *an* option (even if not the default) for a subset of the functionality, would probably be better than noodling around on how applications are installed and distributed.
(Score: 5, Interesting) by bzipitidoo on Thursday November 25 2021, @02:07AM (4 children)
Space is more of a problem than that. These containerized apps are so friggin' huge, on the order of a gigabyte for each one, that it makes performance noticeably worse. Startup actually takes several seconds. The waste of space is so great that a few dozen could eat up most of a terabyte. I thought Java was plenty bloated, but this flatpak garbage blows that away.
(Score: 2) by krishnoid on Thursday November 25 2021, @05:57AM (1 child)
Yeah, but none of them are as big as EMACS! Eighty megs and constantly swapping! No wait, that's small nowadays.
(Score: 2) by maxwell demon on Thursday November 25 2021, @07:51AM
Actually it was Eight Megabytes And Constantly Swapping.
Yes, 8 megabytes was once a huge amount of memory.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by krishnoid on Thursday November 25 2021, @06:10AM (1 child)
I'm wondering, though, if people could keep deploying these containerized apps as they do now. In addition, maybe there could be a background mechanism could collect actual statistics on which common components could be "factored out", and feed the info back upstream to creating more common, shareable pieces. Going out on a limb, maybe they could even be refactored on the PC itself after a few runs, but that's kind of a pipe dream.
I mean, I assume Debian provides a framework for guaranteeing the availability of shareable components, through their continuous dependency grinding during the testing process, so I always recommend that. Maybe it needs to be advertised better.
(Score: 3, Insightful) by bzipitidoo on Friday November 26 2021, @02:44PM
"common components 'factored out'" is the whole point of shared libraries!
Admittedly, the system has its issues. Not least is versioning, or "DLL hell" as it has been called in Windows. The reason Windows has that problem is political, not technical. It's all about profiting off the sales of binaries rather than source, the better to "protect" their imaginary property. Also MS used to charge big $ for the compiler, which is a separate item not included in Windows.
The way, THE WAY, that shared libraries work is by compiling against them, and you can't do that without source code and a compiler. Most Linux distros, including Debian, are basically collections of binaries that have all been compiled against the same versions of the same shared libraries. It is a lot of work to keep up all those binaries, as anyone who has ever run Gentoo Linux learned.
One of the things I find most upsetting about the likes of Flatpak is that it is turning to dubious uses the enormous resources we now have available-- the terabytes of storage and gigabytes of RAM in a typical PC-- by using all that to hide the godawful inefficiency inherent in NOT using shared libraries. And why? To woo proprietary software vendors?? It sure as heck doesn't do any favors to the users. I don't want to have to buy an extra terabyte of storage just for that. I don't want my computer thrashing because containerized libraries have pigged out on all the RAM, forcing the OS to resort to constant swapping. That's EGADS, Eight Gigabytes And Debilitatingly Swapping.
Another wrinkle that should be mentioned is that if a bug or security flaw is discovered in a shared library, a single update fixes it. But if a dozen different versions of that library are each packed into separate containers, updating them all is a lot more work.
(Score: 2, Disagree) by VLM on Thursday November 25 2021, @12:52AM (7 children)
The future (well, really the past starting decades ago) is SaaS delivered to web browsers.
Why would I run kcalc locally?
"Alexa what is 2 plus 2"
or type it into google search, or wolfram alpha, or ask siri, or run the calculator on my phone, or run the superior keyboard physical calculator on my desk, or I always have a bash shell open on my desk so run gnu octave or dc CLI calc or ...
Why would I simulate a handheld calculator on my desktop on my PC?
I've been using google docs for office purposes for years, and its all my kids know due to school. I've been doing CAD on onshape for years.
With enormous effort we might be able to replicate the 1984 mac desktop GUI, but in 2021 who cares, I'm using web apps on my chromebook.
(Score: 5, Insightful) by jb on Thursday November 25 2021, @03:53AM (2 children)
There, FTFY. If you really want an all-SaaS world, that's the road it will most likely lead down.
(Score: 2) by krishnoid on Thursday November 25 2021, @06:15AM (1 child)
Sort of. Google now has a reliable offline mode for sheets and docs, so apps can be presented via browser, and (in theory, optionally) synced up when you reconnect back. So all the Google office apps can in theory be run completely locally, making them not mandatorily (?) SaaS.
(Score: 0) by Anonymous Coward on Monday November 29 2021, @07:09PM
Does that work in any webbrowser or just there's?
(Score: 2) by sjames on Thursday November 25 2021, @04:08AM (2 children)
For all of that, I still have galculator on my top of screen tool bar for the simple convenience.
It works and it is really convenient, so why not?
(Score: 2) by maxwell demon on Thursday November 25 2021, @08:03AM
Well, I personally don't find it convenient. For me, both an actual physical calculator and a Python shell are far more convenient to use.
The physical calculator has the added benefit that it doesn't cover any part of my screen, and the Python shell has the advantage that it is far more powerful.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Interesting) by weilawei on Thursday November 25 2021, @12:16PM
I upgraded my venerable TI-89 by running an emulator with the ROM from it on my phone instead of using the hardware directly. It's got a backlight now! and it's still a superior calculator to most everything out there--particularly because I have decades of muscle memory and training with it.
If I need more than my TI-89, I'm going to be writing code.
(Score: 2) by mth on Thursday November 25 2021, @08:29AM
Even proprietary applications that are installed locally are often implemented as web applications and then bundled with a dedicated browser. TFA wants to support proprietary applications using GTK or Qt, but how many of those exist?
(Score: 3, Insightful) by Anonymous Coward on Thursday November 25 2021, @01:06AM (6 children)
Yes, the packaged virtual systems are big and ugly. They promise security that they don't (and generally can't) deliver, they are a pain in the butt to update and they don't deal well with constrained hardware interfaces.
These things are all true, but doesn't reflect properly that they are a reaction to the environment in which they are developed. Weird library incompatibilities or infrequent bugs are an old story, simply because APIs are moving targets and even if you have the source code you're relying on an assumption that the API itself isn't subtly changing - not at all a safe assumption.
All this is really a reflection of the fact that we need looser code interfaces, not tighter. We need versioned APIs delivered by code so that we can actually interrogate and report on available functions, rather than dynamically loading libraries that we hope and pray will do the right job in the expected way. We could even use limited-function shims for untrusted code, and apply the fundamentals of key-based security to them.
But that would require rethinking of operating systems, and the barely adequate is the enemy of the lukewarm good, let alone perfect.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @03:54AM (3 children)
Sounds like a job for.... AI!!! Let it predict what you really meant when typing those GOTO statements.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @12:20PM (2 children)
Can you name the one absolutely, irrefutably correct use case for a GOTO, the lack of understanding surrounding which led to it being considered always wrong.
There is, in fact, one very good, theoretically correct, clean, and elegant usage for a GOTO. If you know it, you've probably also forgotten more about programming than most of the planet's programming population.
Dijkstra knew it...
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @10:26PM
Oh oh oh, is it blasphemy against the holy spirit?
(Score: 2) by FatPhil on Friday November 26 2021, @08:48AM
Dijkstra was a coward. He saw potential harm in "unbridled" use of go to, considering it "an invitation to make a mess". And therefore wanted it cancelled. But that's a category error. "X" and "use of X" are not the same thing. Don't make a mess. Making the mess was the problem. Take responsibility for what you write, don't blame the language.
The last few C jobs I've had, I've used goto everywhere, that was the approved coding style, deliberate avoidance of gotos was considered harmful and would get patchsets rejected from upstream, normally with snark (yup, linux kernel). It's a great solution when used correctly, in a restricted language withouth RAII, a perfect solution.
But, despite being a very happy user of the construct, in almost all other contexts I never use it, as it's not the correct tool for the job, there's almost always a tool that's less "primitive" that's better. I've been a maintainance programmer for many years too - clarity of code is one of the most important things, and misuse of goto can massively reduce clarity.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by sjames on Thursday November 25 2021, @05:15AM (1 child)
We started to see some progress with that in glibc, but many app developers shoot that in the foot by demanding the latest and the greatest rather than accepting the oldest feasible version.
It's not all the developer's fault, the toolchain likes to link the latest that's available on your system.
(Score: 2) by Runaway1956 on Thursday November 25 2021, @05:30AM
Rolling distro here. I have an app that only a year or so ago refused to install from a .deb package, because some python libaries were outdated. Distro rolls along, and the .deb installed, satisfied that I had the correct version. Distro keeps rolling, and now the package no longer recognizes the newly installed packages. One day, the package maintainer will update his package, and list some random python as a requirement, and break it again. I can understand specifying python3.xxx as a minimum. Specifying a very specific version of python is going to break, and soon.
(Score: 3, Interesting) by deimios on Thursday November 25 2021, @06:25AM (1 child)
What I'm reading is:
I just patched my system against some devastating exploit but the packed app will use it's own, older, compromised library?
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @07:31AM
I can only have one game installed. Ever. Each large linux game seems to want a different set of linked libraries. It is a serious PITA to have it update a .so to version .20 which then breaks everything else due to a dependency rule.
Secure? Sure.
Useful? No.
Seriously, why does software installs break other software so often? Does it really matter that some linked lib is now v...20 instead of .19? Can't I choose to just run it? If the rules says include xx.so -.x.19 and I have x.20 .. can't it just work?
(Score: 3, Interesting) by boltronics on Thursday November 25 2021, @08:57AM (2 children)
I wonder what the author thinks about Guix?
The OS allows multiple versions of libraries to be installed simultaneously, but you generally won't have to (or want to). Host OS libraries can also be linked into containers built using the OS tooling. As such, the libraries a container and host uses are usually the same, eliminating efficiency concerns, while still achieving the desired level of application isolation where required. Often, containers can be built in an instant since the creation process simply creates symlinks to the host OS libraries. Symlinks don't take up much space.
Since libraries are all managed via the OS package manager, you can in theory run auditing tools to determine what libraries are outdated, covering the OS as well as any containers you might be running.
When security updates are available, it is possible to use grafts to apply patches, which basically overlay the original binary, and by default will be used for anything that is linking to it. In other words, you don't need to recompile everything depending on it, you don't need to rebuild containers, etc.
On the downside, Guix has a steep learning curve (especially if you're not familiar with Lisp). There's no container store as such, but all this is really just a matter of improving the tooling to be more user friendly and useful.
It's GNU/Linux dammit!
(Score: 2) by wisnoskij on Thursday November 25 2021, @07:29PM (1 child)
Isnt that one of the Os's that you can install in a VM but supports basically zero real world hardware?
(Score: 2) by boltronics on Thursday November 25 2021, @11:19PM
It works on real hardware just fine, but it doesn't support proprietary software, including firmware and microcodes. This is similar to Debian. There are other repositories that aren't part of the official project that you need to obtain such things from, if your hardware requires them to function correctly.
It's GNU/Linux dammit!
(Score: 1, Insightful) by Anonymous Coward on Thursday November 25 2021, @12:44PM
What happened to static linking?
(Score: 5, Insightful) by Ingar on Thursday November 25 2021, @01:34PM (1 child)
Balena Etcher for windows is a 297MB download, for things I do with dd.
The kcalc package for my distro is 584KB.
OP clearly never installed windows software. The installation usually runs fine, and then you spend the rest of the day investigating why the application
doesn't behave until you realize you explicitly need to install .NET version 4.3.2.1.x to make it work properly.
The .NET 4.8 offline installer package is 116MB.
(Score: 2) by MIRV888 on Thursday November 25 2021, @02:57PM
I just had to install .net 2.02 in order to get my bearcat bcd436hp utility running on a new machine.
(Score: 2) by loonycyborg on Thursday November 25 2021, @02:21PM (2 children)
Making an application targeting linux without targeting only particular distro release is near impossible without notion of runtime that exists in Flatpak. That's the main reason I favor it. I don't think it can obsolete distro package systems, yet I'm absolutely sure that it's better for devs that want to reach users without relying on their distro making a build for them. It utterly overpowers disk usage and other concerns since it's better than not having a linux package at all, the state to which distro fragmentation naturally leads. So yeah, flatpak is most definitely the future unless a better way to support distro-independent runtimes emerges.
(Score: 3, Insightful) by wisnoskij on Thursday November 25 2021, @07:25PM (1 child)
I have seen a flatpak version of firefox be so laggy it was unusable. That is basically my entire experience with flakpaks.
(Score: 2) by loonycyborg on Thursday November 25 2021, @07:53PM
I see no point in using firefox in flatpak. It's already in all distros. I use flatpak for Discord and Steam and some bleeding edge apps that aren't available in my distro yet, and things work fine. Also I actually make a flatpak for opensource project I'm a contributor to, namely Battle for Wesnoth.
(Score: 1, Informative) by Anonymous Coward on Thursday November 25 2021, @02:22PM
Pushing proprietary software to Linux will make it like Windows - in which applications control user.
Do we want massive spyware campaigns?
Adware spam-sending botnets?
Or maybe unfixable backdoors which have to be fixed by adding hundreds of abstraction layers, HIPS, etc?
And now, fully in white, the savior comes: Just let the company control your computer!
With open source software, it goes a bit better: even for not well maintained software, there is usually some fork. There is a single exception, but even older desktops which don't eat 2GB of RAM at start are forked from their ancient repos and many times customized to run with newer Linux distributions.
The better way would be to standardize APIs.
--
P.S. The exception is the offline calendar - these apps which are not developed anymore because user's timeline is so valuable thing to steal.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @02:31PM (1 child)
TFA: "The stability of the Linux desktop has dramatically improved in recent years."
Anyone who had the misfortune to maintain a project with GUI in the last decade for longer than an year or two, can attest that the reverse is true.
Every large project, such as Mozilla, Chrome, or LibreOffice, had to implement a homegrown GUI toolkit of its own, using the system-provided one purely for theming, and still regularly gets bitten by breakage of something essential.
For a smaller project, really the only way to escape the hamster wheel of fighting the bitrot, is to target an older toolkit. Like GTK+2 when the hipster boys were playing with GTK+3, or GTK+3 now that their fun and games is (hopefully) confined to GTK+4.
Or, barring that, resort to carrying the entire set of GUI libs, huge as they are, along with the binary. Welcome to the world of 152 MB calculators.
(Score: 0) by Anonymous Coward on Monday December 06 2021, @11:22PM
Note the massive GTK shaped caveat near the end of the blog post.
the irony is that Gnome, the current custodians of GTK, as also the most militant about making a Linux desktop for the masses. This by dumbing everything down so that a grayed chimp can operate it to request grapes.
It is from that camp Flatpak originates. Poetteringware is closely related to Gnome as well. And they keep producing more and more "upgrades". Like a massively over-engineered tool for upgrading firmwares, involving multiple binaries and trips through polkit). Gnome is a pox on the Linux ecosystem basically, thanks the the CADT that JWZ pointed out decades ago.
Then again it was started by a guy that was deeply infatuated with Microsoft, and now works for them.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @02:37PM (1 child)
Because the underlying problems that led to containermania are not going to change meanwhile everyone now has terabytes of SSD and 5G to download a Gigabyte of app in seconds
(Score: 0) by Anonymous Coward on Monday December 06 2021, @11:24PM
Basically the people involved are cloudcookoolanders that live and breath webdev.
They understand JS far better than they understand C(++), and prefer Slack and Discord to IRC.
(Score: 2, Touché) by Anonymous Coward on Thursday November 25 2021, @03:28PM
Everything that becomes popular becomes awful eventually. Here's too linux remaining at sub 5% desktop market share forever.
(Score: 2) by wisnoskij on Thursday November 25 2021, @07:23PM (3 children)
A major problem seems to be that apparently you cannot have more than 1 version of a library installed.
If I go to install an old game, I just install an old .net or whatever, and it works. Meanwhile my new games continue to work as well. If it is really really old, maybe I just place some old .dll in the game directory and it just uses that.
While in Linux, if you are trying to install an app that requires old libraries (this was Linus's problem) these (for whatever reason) overwrite the new libraries and break everything that was using them.
So we have this unstable and fragile tree of dependences that all fails if you are missing one tiny thing.
Let this set in. All Linux's run the exact same executables the exact same way. A Linux binary file is a Linux binary file. But this file is only guaranteed to run on the singular system that compiled it because that is possibly the only system with the exact same dependencies.
That why the community spends millions of hours and millions of tons of CO2 compiling and recompiling and building repositories. Because if I decide to update a library everything that used that library needs to be recompiled.
(Score: 2, Informative) by Anonymous Coward on Thursday November 25 2021, @08:08PM (2 children)
You are totally, completely, utterly wrong.
Any library file is meant to have version string included in the filename, and any version with a different ABI is meant to have a correspondingly different soname (and a matching symlink) for programs to link to. I do not know of any distros violating that decades-old convention.
If anything can be overwritten by installing old library over new, it would be the generic version-less symlink; that one is used solely when compiling new binaries, and is trivial to fix either manually, or by reinstalling the new library (which cannot touch the relevant files and symlinks of the older one(s) due to different version strings in filenames).
(Score: 4, Interesting) by wisnoskij on Thursday November 25 2021, @10:41PM
Can you explain why Apt decided to uninstall Xorg after it needed to install old dependencies to get of Steam to function?
(Score: 2) by darkfeline on Thursday November 25 2021, @11:54PM
The ABI is not conclusive. "Insignificant" changes and bug fixes can break applications. Blah blah fix your app, but as a user I want to run my application, and if I can't then your distribution mechanism has failed.
Keep in mind the entire reason Linux distributions exist is to solve the dependency issue, by having a central repository where all the dependencies are matched up.
Otherwise, we could have a noncentralized, peer verified repository of compiled packages that anyone can pull from using a thin manifest to easily download their own "distro".
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @08:02PM
my opinion is prolly not well informaed since i do no programming ... but if i recall half-way correctly, i needed mouse support for a pascal fractal program and found a "library".
i just "loaded that free mouse support library (human-code)" in my frac program and compiled it to a *.exe but prolly didn't even use all available functions ...
now mostly all libraries that game makers are to lazy to re-invent just use already made libraries (and their functions), most of which have human-code available.
so maybe if we have game "pandora2000", a "optimizer" would check the game code for usage of all the ready made libraries AND their functions, extract the human-code from
them libraries that give those functions and then make a monster library consisting of all functions extracted from all those other separate libraries ...
so you linked ready-made library mouse.so and sound.so but only used function 1 thru 10 from mouse.so and function 33 thru 67 from sound.so. the "optimizer" then extracts the human-code from mouse.so.source and sound.so.source
and makes ONE monster "pandora2000.so" with the functions 1-10 from mouse.so and functions 33-67 from sound.so... voila?
ofc ... the "pandora2000" game maker would have to update their game themselfs and could not rely on a auto-updating of a distro (for mouse.so and sound.so), that is,
they would need to get from upstream new mouse.so.source and sound.so.source, run the optimizer again and then tell their beloved customer that a update is available ...
(Score: 3, Informative) by darkfeline on Thursday November 25 2021, @11:47PM (1 child)
You can quickly tell whether someone supports the philosophy behind the Flatpak approach by whether or not they have experienced dependency hell, and vice versa.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Friday November 26 2021, @03:47PM
methinks if the underlying problem doesn't get solved we will get flatpack, in flatpack, in flatpack, (echoooohoohooh away)?