The Foss community is giving yet another try with an app store for all Linux OSes:
Some influential people in the open-source community are pushing for the adoption of a one-stop app store for Linux-based operating systems. The store would be built on Flatpak, a popular software deployment and package management utility, and it could provide customers with the same user-friendly approach other popular app stores in the consumer market are known for.
[...] The proposal's main goal is to "promote diversity and sustainability" in the Linux desktop community by "adding payments, donations and subscriptions" to the Flathub app store. Flathub is the standard app repository for Flatpak, a project described as a "vendor-neutral service" for Linux application development and deployment.
[...] The universal app store proponents say that "a healthy application ecosystem is essential for the success of the OSS desktop," so that end-users can "trust and control" their data and development platforms on the device they are using. Flathub has been jointly built by the GNOME foundation and KDE, and it isn't the only app store available in the Linux world.
Alternative solutions like Canonical's Snaps, however, are sitting under the control of a single corporation and aren't designed as a universal Linux app store from the get-go. Canonical has recently decided that neither Ubuntu, nor the other Ubuntu-based distros (Kubuntu, Lubuntu, etc.), will give their official support to Flatpak. Users can manually add the tool after installing the operating system, though.
Besides providing a universal app store for the entire Linux world, Flatpak supporters also want to "incentivize participation in the Linux application ecosystem," and remove financial barriers that prevent diverse participation. For this reason, the proponents are planning to add a new way to send donations and payments via Stripe within this year.
(Score: 5, Insightful) by bzipitidoo on Tuesday March 07, @06:35AM (23 children)
As solutions to the problem of library incompatibilities go, this idea of bundling libraries with apps is terrible. It takes way more space, in both RAM and drive storage. Nice, for hardware vendors.
I'm suspicious of the real motives behind it all. Seems it provides a way to leverage proprietary, closed source software onto Linux systems.
(Score: 5, Insightful) by psa on Tuesday March 07, @07:13AM (1 child)
It's kind of the way linux is headed, though. With systemd pulling the backend into a single uniform monolith and the remaining parts of freedesktop.org defining the frontend contracts, the large corporations that founded freedesktop.org and have taken over the other main organizations (linux foundation, OSI, GNU) just need to get a handle on user land to finally get what they always wanted: a single, controllable platform standard to target. Flatpak reduces linux to kernel and freedesktop.org, effectively commoditizing distributions and placing all of the power over the platform in those two places.
The only battle left seems to be which containerization package system(s) will be supported in the future.
(Score: 3, Insightful) by darkfeline on Tuesday March 07, @09:35AM
The Linux kernel and LFS (and by extension bespoke distros) will always exist. The fact is that most people do not want to be futzing about with their system getting things to work. Hackers are welcome to continue.
Join the SDF Public Access UNIX System today!
(Score: 2, Interesting) by Anonymous Coward on Tuesday March 07, @07:27AM (4 children)
It depends. If something is your "killer app" then why not statically link all its dependencies? It would save us from what Windows users always called "DLL Hell". Funny how some problems are universal. If you have no particular killer app and are switching all the time, then yeah you get a bit more swapping but is it really that noticeable on modern systems? I have to agree with the "just throw more hardware at it" crowd when it comes to scripting languages vs. compiling; but maybe I'll agree with them in this case and... hello... if the apps are open source it seems like apps using shared or static libs should both be available.
I thought a more likely complaint against this scheme would be along the line of XKCD [xkcd.com] when it comes to adding a standard to fix the problem of competing standards.
(Score: 4, Informative) by bradley13 on Tuesday March 07, @09:52AM (3 children)
Yes, but we already saw what happened in Windows. Granted, it was decades ago, so the younger generation doesn't, but: you wind up with massive bloat, because zillions of different apps bring in the same libraries. Only it's arguably worse today, because each library today now brings in a zillion other libraries that it depends on. You could easily create a 1GB "Hello World" app, just by bringing in a couple of dependencies.
In a few years, people will complain that their Linux partition is taking up hundreds of GB, or - who knows - maybe even a few TB. So then they will try to reduce bloat by noting common libraries. Which will give us the Linux equivalent of the Windows registry. Which I'm sure will be integrated into SystemD.
Honestly, there is no perfect solution. I understand the desire to have 100% control over the libraries installed with your app. Still: I think this movement is a mistake...
Everyone is somebody else's weirdo.
(Score: 2) by RS3 on Tuesday March 07, @05:28PM (1 child)
Pretty much agreed. I don't think it'll get as bad as TBs in the near future, but your point is strong and well received.
I might be misunderstanding- I had hoped that new libraries would never break older APIs. Is that not the case? IE, new libraries might break older applications?
(Score: 3, Informative) by ChrisMaple on Wednesday March 08, @05:17AM
There are 2 problems I'm aware of.
Sometimes new libraries do break old programs.
Some programs, to guarantee against such breakage, specify a specific version of a library, neither older nor newer. That contributes to storage bloat as multiple library versions must remain on disk.
Intertwined with those 2 are Makefiles that link libraries to specific versions, changing links that other Makefiles have made.
(Score: 4, Interesting) by stormreaver on Tuesday March 07, @09:38PM
You're thinking like a techie, whereas this proposal is targeting normal users. Space is barely even an afterthought for normal users. They care much more about "it just works" simplicity. Download a Flatpak (in a fraction of the time it takes to download and install DEB/RPM/other. packages and their dependencies), right-click to properties to give it execute permissions (even this is asking a lot of normal users), click, and it runs.
You're thinking like a techie, etc.
(Score: 4, Insightful) by darkfeline on Tuesday March 07, @09:31AM (1 child)
The amount of extra space used even if you install hundreds of apps, is likely smaller than a short video.
"It takes more space" stopped being an interesting argument a long time ago. Go buy a $5 Micro SD card or something for your tiny device that can't afford such space.
I guess I should mention that libraries are only one aspect. These tools also namespace the filesystem, PIDs, sockets, etc etc.
For me, the biggest advantage of flatpak is that you can install applications in your home directory, and thus migrate your home directory along with your applications across systems trivially.
Something like flatpak is basically mandatory for immutable OSes (e.g., Fedora Silverblue, SteamOS).
Join the SDF Public Access UNIX System today!
(Score: 3, Interesting) by lentilla on Tuesday March 07, @08:38PM
Unfortunately, a video that needs to be mostly stored in RAM for the duration the application is being used.
(Score: 0) by Anonymous Coward on Tuesday March 07, @09:57AM (5 children)
How many times have you run a program on linux that just won't run because your system has library.3.0.2 and the program just absolutely needs library.3.0.1.
How many Windows programs install and just run?
There you have it.
To this day I still have a blank partition on my drive just so I can install a version of linux and the absolute correct configuration of libraries needed to run a program. It is frustrating as heck. Seriously, disk space? I have GB. RAM? 64Gb atm. What's the issue?
(Score: 5, Insightful) by bradley13 on Tuesday March 07, @10:12AM (3 children)
Um...almost never? Maybe once every couple of years? And if it does happen, that's one of the things a VM (or a container) will handle for you. I always have a fresh Linux and a fresh Windows install hanging around in VirtualBox, just as a way to experiment. Install your critical-but-badly-designed app there and take a snapshot.
Everyone is somebody else's weirdo.
(Score: 3, Interesting) by RS3 on Tuesday March 07, @05:36PM
All good if you can afford the hardware (CPU cores, RAM, HD size...). I will concede that more powerful hardware is making its way into the used / inexpensive realm. My biggest problem / concern is if and when the HD / SSD dies. It's not trivial nor inexpensive to back up multi-TB drives. Maybe use USB FLASH drives for some of the partitions / VMs... just thinking out loud...
(Score: 2) by stormreaver on Tuesday March 07, @09:50PM
You're thinking like a techie, whereas this proposal is targeting normal users. Package managers are great, but they do fail. And when they fail, they sometimes fail spectacularly. I have had several times in the last couple years where multiple levels of library conflicts appeared unexpectedly because package maintainers made a metadata mistake. It isn't supposed to happen, but it does.
No regular user is going to use a system that says, "Library conflicts. Please install a VM" unless the VM is automatic, reliable, installed quickly and transparently, and the troublesome program is then automatically installed quickly and transparently. And all this needs to be done in roughly the same time as if everything went right without the VM. In short, it will never work.
Most of what you typed about the VM is an argument FOR the Flatpak, as it (in theory) eliminates this failure mode. My family uses Kdenlive extensively, and they can almost download and install the AppImage without guidance. The Kdenlive AppImage has spectacular resource leakage, though, so it's not ready for prime time, but the basic proof of concept is sound.
(Score: 0) by Anonymous Coward on Wednesday March 08, @03:09AM
TBH it is the games that are annoying on Linux. However, it has happened a number of times with utilities. It has gotten to the point where a VM is required for programs that can stand alone. Containers seems to be a good solution for this, but getting them working properly can be a pita.
(Score: 5, Insightful) by pe1rxq on Tuesday March 07, @11:49AM
Multiple versions of a library can co-exist just fine.
For those libraries that do not want to co-exist: FIX THE DAMN LIBRARY to properly handle versioning! Don't work around the problem by duplicating your entire system.
(Score: 0, Redundant) by Woodherd on Tuesday March 07, @10:23AM (1 child)
+5 Insightful. At least it is not rpm, or yum. Wait, maybe it is? Anyone know the backend of this insidious bloat?
(Score: 2) by janrinok on Friday March 10, @06:55AM
The 'backend' is completely irrelevant. It is a total package - how it is put together is of no interest whatsoever. You do not update its contents, you update the package.
(Score: 5, Insightful) by digitalaudiorock on Tuesday March 07, @01:31PM (1 child)
Vulnerabilities are a bigger issue. On a sane system, when there's a bug found in a library, you get a fix for it in the only copy your system should ever have and you're done. What happens when there are countless fucking "apps" lugging around their own versions? I will say however that this trend goes well with the way systemd has been turning the once awesome Unix/Linux into Windows. I'll take my Gentoo for sure.
(Score: 0) by Anonymous Coward on Wednesday March 08, @03:12AM
That's nice. Exactly what happened in several cases, which then killed anything else that absolutely would not run with a different patch level of that library. It has happened for bigger programs such as VirtualBox. Something about the config file having the wrong filter for dependencies. When the solution given to people is 'rebuild your system back to where it was a week ago' then something has to change.
(Score: 3, Touché) by DannyB on Tuesday March 07, @05:08PM
While that it is good, you understate how good it is. It is even more gooder. It takes more network bandwidth to download. So it's also good for ISPs. Extra double plus goodness.
<no-sarcasm>
It may also be good as a new vector for introducing security vulnerabilities.
</no-sarcasm>
How often should I have my memory checked? I used to know but...
(Score: 3, Interesting) by tekk on Tuesday March 07, @07:52PM (1 child)
What you've described is how appimage works. On flatpak you build against a common pseudo-distro and those are only installed once. For example your gtk application will build against the gnome desktop target which is mounted ro into your app's namespace.
(Score: 0) by Anonymous Coward on Wednesday March 08, @03:14AM
I have wondered about this. Can't the container detect that the system has all the correct libraries and use them except for AwesomeFontGenerator.3.4.1 which it can then add to the flakpak as needed?
Oh look, your system has AwesomeFontGenerator.3.4.2 which is terrible because this flatpak/snap/whatever NEEDS AwesomeFontGenerator.3.4.1 and can only use AwesomeFontGenerator.3.4.1 so it will just grab that. For everything else, load the system libraries.
Or is this just Too Hard
(Score: 2) by stormreaver on Tuesday March 07, @09:27PM
You're thinking like a techie, whereas this proposal is targeting normal users. Space is barely even an afterthought for normal users. They care much more about "it just works" simplicity. Download a Flatpak (in a fraction of the time it takes to download and install DEB/RPM/other. packages and their dependencies), right-click to properties to give it execute permissions (even this is asking a lot of normal users), click, and it runs.
You're thinking like a techie, whereas this proposal is targeting normal users. They care much more about "can I do what I want to do?" For most people, the answer on Linux is, "sometimes, but not usually". Linux NEEDS proprietary software too, or it will always be third place in a 3-system race.
(Score: 5, Interesting) by Snospar on Tuesday March 07, @08:25AM (1 child)
Is this just the first step to declaring WINE Bottles as the de facto standard for running applications on Linux? Why build all those pesky Linux applications when the same "great" Windows applications will work (with all the added telemetry you've been missing).
Or is it a way to make it easy for us to pay for the Free Software we've been enjoying, for free. Who is having dependency hell or DLL issues in this day and age? Surely that's a throw back to a distant point in Linux history or have I just been incredibly lucky these past 20 years?
(Score: 2) by stormreaver on Tuesday March 07, @09:33PM
This has absolutely nothing to do with wine or forcing us to pay for Free Software. It's a way of making it very simple, reliable, and fast for regular users to install and use end-user software (in theory). In practice, it will all depend on the implementation. If done the way it has been presented, it can only help Linux adoption.
(Score: 5, Insightful) by Rich on Tuesday March 07, @10:37AM
Right from TFA:
May I kindly point out that I don't identify as part of that community. I am convinced that dpkg is just fine. RedHat should just adopt it instead of poisoning the well. Maybe they could work towards a "portable dpkg" convention where installation can happen anywhere. (Which mostly is a problem due to the RMS legacy of wanting absolute paths everywhere to make binaries non-portable.)
Which can't be said in a more weasely, greasy, slimy way. They can fuck off.
(Score: 3, Interesting) by Rosco P. Coltrane on Tuesday March 07, @12:40PM
are the lazy packager's way of resolving dependency problems.
Get ready to buy more RAM and bigger disks...
(Score: 5, Insightful) by Runaway1956 on Tuesday March 07, @02:30PM
Distros are pretty secure, because almost all apps, and all libraries are vetted one or more times before it gets to you. Snap, flatpack, pip, and the rest? Not so much. Didn't we just read about py being infiltrated with malicious apps? What's to prevent some "developer" specifying some version of a library with a know security flaw, just so his bot network can hack into your system?
None of the app stores are really secure. Yeah, Google and Apple kinda screen apps, but they're not putting a stamp of approval on anything they didn't write, themselves. They only remove apps after it has been reported that the app is malicious, and/or causes problems.
People who make extensive use of a Linux app store will soon enough realize that they have a compromised machine, much like Windows or Android. Infestations may or may not be easier to deal with on Linux, but why invite the problem in to start with?
Abortion is the number one killed of children in the United States.
(Score: 5, Insightful) by Ingar on Tuesday March 07, @02:55PM
No.
(Score: 3, Interesting) by pgc on Wednesday March 08, @07:31AM
It somehow sounded like a reasonable idea, until this came along
'...The proposal's main goal is to "promote diversity and sustainability" in the Linux desktop community by "adding payments, donations and subscriptions"...'
What the actual f?
And what is wrong with Apt? Besides the money aspect apparently.