Linux Desktop Powers Consider Uniting For an App Store (zdnet.com) 133
An anonymous reader quotes a report from ZDNet: Now, leaders from the GNOME Foundation and KDE Foundation, along with Debian Linux, are considering [...] building an app store on top of Flatpak, a universal Linux software deployment and package management program. This idea of replacing traditional but not very friendly ways of delivering Linux desktop apps, such as DEB and RPM package management systems, has been around for a while. Besides being easier to use, Flatpak and its rivals, such as Appimage and Snaps, can also run on any Linux distribution. All the programs do this by containerizing applications with all their necessary libraries and associated files.
Now, as laid out in former Google chairman Eric Schmidt's Plaintext Group, the proposal is to "Promote diversity and sustainability in the Linux desktop community by adding payments, donations, and subscriptions to the Flathub app store." Behind this idea are several Linux desktop leaders, such as GNOME president Robert McQueen; former GNOME executive director and Debian project leader Neil McGovern; and KDE president Aleix Pol. Flatpak, unlike the earlier store attempts, works on essentially all Linux distros. This makes it much more interesting.
Why Flakpak, instead of its chief rival, Snaps? They explained, "Flathub is a vendor-neutral service for Linux application developers to build and publish their applications directly to their end users. A healthy application ecosystem is essential for the success of the open-source software desktop, so end-users can trust and control their data and development platforms on the device in front of them." [...] Be that as it may, while the proposal for a paid Flathub app store remains just an idea, it's still one that may garner support. If this plan can generate enough support, and then the revenue, to cover its costs, it may create the first popular universal Linux app store. Then, who knows, maybe the Linux desktop will finally become broadly popular. Stranger things have happened.
Now, as laid out in former Google chairman Eric Schmidt's Plaintext Group, the proposal is to "Promote diversity and sustainability in the Linux desktop community by adding payments, donations, and subscriptions to the Flathub app store." Behind this idea are several Linux desktop leaders, such as GNOME president Robert McQueen; former GNOME executive director and Debian project leader Neil McGovern; and KDE president Aleix Pol. Flatpak, unlike the earlier store attempts, works on essentially all Linux distros. This makes it much more interesting.
Why Flakpak, instead of its chief rival, Snaps? They explained, "Flathub is a vendor-neutral service for Linux application developers to build and publish their applications directly to their end users. A healthy application ecosystem is essential for the success of the open-source software desktop, so end-users can trust and control their data and development platforms on the device in front of them." [...] Be that as it may, while the proposal for a paid Flathub app store remains just an idea, it's still one that may garner support. If this plan can generate enough support, and then the revenue, to cover its costs, it may create the first popular universal Linux app store. Then, who knows, maybe the Linux desktop will finally become broadly popular. Stranger things have happened.
Please say you're kidding (Score:5, Insightful)
This is astoundingly bad idea. Ditch RPMs and DEBs for containerized installs? Easy to install, near impossible to debug.
Ugh, this whole thing makes me sad. Beginning of the end...
Re: Please say you're kidding (Score:5, Insightful)
Re: Please say you're kidding (Score:5, Insightful)
If it is just like every other desktop OS (i.e. Windows and Apple), I might as well just get Windows or Apple. They're much more mature and more things run on them. If I use Linux it's because it is the type of system/OS that I want to deploy code on minus the windowing system (headless). All of a sudden now, what I am coding in/on is no longer the same since it is in some container and running with different resources/limits. I might as well not use Linux at all for a desktop.
These groups are trying to find a way to be Apple or Windows. Canonical is. I can't fault them, they are trying to find a way to commercialize and make money off of their investments, same as Redhat and Suse.
Re: (Score:2)
That's you. Your use cases are not the same as other peoples.
What are the most successful Linux distros? Android and Chrome OS. Both have an app store with containerized app deployment. Clearly there is demand for that.
I could see myself using it, along side installing stuff via apt or some other package manager. It depends what I want it for. No need for LibreOffice to run outside a container, especially if I'm going to be handling documents from other people. I'll take the extra security, thanks. Would be
Re: (Score:2)
No shit that's me. Thanks for that insight Sherlock.
Re: (Score:2)
I haven't see many Chromebooks in the wild. Maybe that's a market I'm just not interacting with? Medical maybe?
Education is the biggest one. Go spend some time in school, primary, secondary or post-secondary. There's also a great deal of enterprise usage, especially in corporations that have gotten all of their important enterprise apps moved to web interfaces. IT support cost for Chromebooks are incredibly low. There's a lot of individual usage as well, mostly by older people who need something simple and bulletproof (the machines are often purchased for them by their children who are tired of fixing mom's laptop e
Re: (Score:2)
All of a sudden now, what I am coding in/on is no longer the same since it is in some container and running with different resources/limits
THIS.
You can say all you want about containers, but the fact of the matter is they do NOT integrate with the host system at all. It's a programmer's attempt to genericize the underlying host system. Of course, the programmer shouldn't have to do that, the host system should provide proper standardized APIs. But of course Linux on the Desktop has never done that properly. Even though Linux has it's own versions of LoadLibrary() and GetProcAddress() in the form of dlopen() and dlsym(). They are rendered com
Re: (Score:2)
If it is just like every other desktop OS (i.e. Windows and Apple), I might as well just get Windows or Apple.
If you judge an OS based solely and exclusively on the way that apps are distributed and installed then sure you may make that conclusion. It think basically everyone else on Slashdot probably has some additional criteria to weigh as to what OS they use. But it's good to know you don't give a shit about telemetry or privacy since the only reason you seem to be using Linux is the lack of a unified app store.
Re: (Score:3, Insightful)
Re: Please say you're kidding (Score:5, Interesting)
It depends what you mean by "container". Apps delivered as APKs are installed in containers, with no access to anything else by default. Android gives them a virtual filesystem and to the app it appears they are running on a machine with nothing else installed, no contacts, no data files etc. They can request access to more things from there, but they are always running in a container.
APKs are designed to facilitate that. Something like an RPM or DEB is not, they are designed to be integrated into the system and run with the same permissions as the user. The install process itself typically runs as root, and often binaries go into shared system paths.
An RPM or DEB doesn't need to be a complete package, it can explicitly depend on other packages, and on having access to the system. An APK is complete, everything needed by the app is contained in it, and the OS can install it inside a box by itself.
Re: Please say you're kidding (Score:2)
Cheese...a lot of boilerplate and extra code for such a little thing....
docker pull rust
docker run --rm --user "$(id -u)":"$(id -g)" -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust cargo build --release
There, just distribute the single ELF binary, and it runs on any Linux distro. No dependencies required. Docker is only needed to compile it, it's not needed to run it.
You can do similar things with other languages, the rust project just happens to provide a ready-made and IMO quite elegant solution to solve
Re:Please say you're kidding (Score:5, Interesting)
Wait until Debian-Security pushes a fix for a library 0-day but users still get p0wned by their old flatpacks and the press concludes "Linux wasn't as safe as everybody thought. "
Re:Please say you're kidding (Score:5, Insightful)
If Eric Schmidt is involved, hold on to your wallet and your privacy. Debian/Ubuntu/etc's method of updating is far superior to the flatpack method... and even Snaps get updated (although they also break the model of dependencies by containerizing apps).
This will come to no good.
Re: (Score:2)
Also an end to dependency hell.
Re:Please say you're kidding (Score:4, Informative)
Yes, but it's a cost that all apps include their own dependencies, thus you have the same libraries reused many times. It's nice for the must-always-work even if the distribution updates, or for applications on a thumb drive. But if you have many applications set up this way it could get bulky.
Re: (Score:3)
The must-always-work you defined also includes applications that get old and do not get support, like plenty of small utilities that survived decades as windows .exe still available on the internet. I find it frustrating that sometimes the best way to run some old linux software is to grab the old windows exe and execute it through wine, because compiling the old code or old dependencies is not possible anymore on a modern linux.
As example I used to use some specialist applications like QUCS (an electrical
Re: (Score:2, Insightful)
Re: (Score:2)
Bulk isn't something I typically associate with Linux. Even if everything was delivered as a flatpack the resulting install would still be smaller than MacOS / Windows.
You're missing one other feature: The ability to update independent of bypassing the distro maintainer's package management. There's only been a few times in my life I have seen a truly hosed Linux system, and they have all been related to manual installation from source of libraries clashing with some that were installed, or so many PPAs add
Re: (Score:2)
Beacuse linux isn't just PCs. Its on small embedded devices too, even older PCs without a lot of room, or runnable from a flash drive, etc.
Re: (Score:2)
It's a tradeoff. Which problem do we consider worse?
I hate dependency hell way more than I need things to be as space-efficient as possible. Disks are cheap. My time is not.
Re: (Score:2)
I never found much dependency hell. Not compared to Windows anyway. Just use the package manager and all dependencies get added. The problem comes with really old packages that are no longer supported, and a snap/app/flatpack might work for those.
Re: (Score:2)
>thus you have the same libraries reused many times.
So what? Unless you are on some super limited crappy embedded system disk is cheap and plentiful. You would have to install so much crap to run out of disk space from redundant libraries that your CPU would choke and melt a hole through your motherboard if you ran even a 1/4 of it at the same time.
Even bottom barrel systems come with 1TB drives these days. You have to either dig deep into the cheapest of the the cheap crap, or buy Apple to get down to t
Re: (Score:2)
Probably there are more embedded linux systems than linux PCs.
Re: (Score:2)
Your point being? This is for desktop use cases. Period. Not server, not embedded, not kiosk ( unless it is a desktop style kiosk )
Embedded systems are going to be optimized to hell and back to squeeze out every Hz of performance and FS space, and won't even think of installing snap / flatpack / appimage. They will make their own little custom distro just like always. They will also be locked to whatever libraries are in a whole image flash, so it's always a known and cohesively compiled environment with a
Re: (Score:2)
From the same people who used to complain about DLL hell. How times change.
Re: (Score:2)
I've only had dependency hell with RPMs. I've not had an issue in Kubuntu using apt or deb based installers.
Re: (Score:3)
Re: (Score:2)
And you still can.
That said, I do understand the frustration. It's annoying when have the apps I want to install only have an offical docker version.
Re:Please say you're kidding (Score:5, Funny)
Are you kidding? It's going to be great!
I heard Lennart Poettering is going to head the project.
Re: (Score:2)
Citation needed? Seems a thin joke as stands.
Re: (Score:2)
Are you kidding? It's going to be great!
I heard Lennart Poettering is going to head the project.
Citation needed? Seems a thin joke as stands.
It was very much a joke. Poettering works for Microsoft now.
Re: (Score:2)
Thanks for clarifying. I should have done the websearch.
Re: (Score:2)
We can only hope that this will never happen.
Or, at the very least it requires something like:
apt install appstore
(Replied to undo my fat figured moderation, sorry)
Re: (Score:2)
Ditch RPMs and DEBs for containerized installs
They did not say they would ditch the native package systems. It's just another way to install applications. It means users small distros that do not have everything will gain access to a larger software library. Too often when I look on the internet how to do something and find a blog post with "the best 10 linux software for doing X", I choose by figuring which one if any is in my distro. I'd rather test them through flatpak and, if I like them, do the effort to compile it locally or request it from the d
Re: (Score:2)
Even Ubuntu Server 22.04 LTS is being riddled by Snaps nowadays.
The whole reason that I run that distro version is to have a relatively simple and reliable "headless" server. Without any kind of GUI, the perceived 'dependency hell' is just that, it only exists in your mind.
And yet, when the installers asks you to select a role for your new server, practically all are based on Snaps. While I have no real problem with the concept of containers, Snap isn't so great as an implementation. FlatPak is less bad, bu
Re: (Score:2)
If that is what you want, you may want to look at ahref=http://www.openbsd.org/rel=url2html-15520 [slashdot.org]http://www.openbsd.org/ />
Re:Please say you're kidding (Score:5, Interesting)
I don't think the containerization idea is so bad. They often have _better_ reproducibility at runtime than traditional Linux packages, which BTW represent a sort of anti-Desktop rubric that demands a bit too much from users (who become captives of the OS vendor's repository unless they learn a lot of skills) and way, way too much from dedicated app developers (like, package your app in 8 different ways and test it in 8 different sets of lib versions and etc/env settings or you're not cool in Linux land).
Apple Macs had an early version of this container-like dependency system. An app dev could take the easy road and package all their non-OS dependencies within their own app folder... drag and drop installation. IIRC, something similar is possible with Windows msi installs (one double-clicks the msi, and most of its 3rd party dependencies go under a single folder).
So this business where we make OS maintainers the ultimate arbiter of which apps can have which libraries/versions and making installs a process of spewing the app's files all over the filesystem in hundreds of pieces.... it is not working on the desktop. Apple and Microsoft knew it didn't work way, way back. Enough is enough.
OTOH, there are at least several more large steps before using "Desktop Linux" is anything like a real consumer OS on a long-term basis. For one, having the kernel as the identity of the OS will still cause much confusion among consumers. And the not-committing-to-a-GUI is even worse (in my book, different GUI = different OS and that's how it goes down when users need tech support: on a Linux distro they are told to use the CLI almost always). And not having an official hardware certification program that licenses a special compatibility logo is also quite bad. A lot of confusion and brokenness there, and I know because I did the whole turn people on to desktop Linux for over a decade.
On brokenness: It really is broken if the GUI isn't standardized heavily, not just the graphical forms but also the responses, menus and the settings/admin integrations. In computer science, a shifting interface is by definition broken because an "interface" is a "contract" or promise for consistent interaction. Linux enthusiasts suddenly drop this idea of consistency when it comes to _user_ interfaces. Its not flying and that's why (I say this here every couple years) you cannot even GIVE it away to most people.
Re: (Score:2)
Oh, and if you say "But we need the Freedom to make all these things different because a sliver of the techie demographic and server admins like it that way" .... then "Linux" cannot be an OS to the other demographics. It will remain a non-entity to most people, the same way the manufacturer of the transmission inside their car is a non-entity.
So what that means is the Android model (which is mostly the MS and Apple model)... wins completely, and deservedly so.
Re: (Score:2)
Re: (Score:2)
My understanding of "containers" is they were originally a way to collect or organize different apps that may need different service configs or library versions. They were billed as a way to maximize hardware utilization (thus, a tool for admins or system architects).
The "VM" idea is used very loosely with avid container users, IMO. To me, VM means either a bytecode RE like Java or a hardware-enforced isolation space managed by a hypervisor Xen, KVM, etc. To these users, VM seems to mean a container-like
Re: (Score:2)
Container images for desktop apps makes sense for closed source applications: those can't be packaged properly by distros and running them inside containers provides extra safety against intentional or unintentional threats they might pose.
What I don't understand is why Ubuntu is pushing Snap for open source applications. I hope and assume that GNOME and KDE are merely providing better integration for Flatpak apps and not pushing for it as the primary way of installing their own applications.
Re: (Score:2)
Relying on application developers to use runtimes with backported security fixes also doesn't work.
There is no silver bullet, but every app potentially coming with a custom build runtime is the worst of all worlds. There is no fixing that for maintainers. Windows can force a new redistrubutable on an application, a distro silently replacing part of a completely custom compiled runtime for a security fix is defacto impossible.
Re: (Score:2)
Here's the thing: This is the desktop. It has to have a certain level of richness, and that has to be "built-in" or standard. If you have a good desktop platform like OS X has been for many years, users will read about the rich new features and think about cool stuff they can do and often buy the Mac/PC for that reason and learn how to develop for that platform. If the platform is good, the overwhelming number of dependencies for most apps will be _inside_ the OS.
Devs do not want a multi-headed hydra of
Re: (Score:2)
i don't think they can ditch traditional package managers, only distro and package maintainers could do that.
let them have their universal appstore to make their business, i will have no use for it but there is surely some audience who will love it. it could be a problem if this had such an overwhelming success (e.g. imagine it really comes to the year of the linux desktop) that some distros or package maintainers just shrug and fold. i really don't think it will come to that, but worst case scenario i assu
Re: (Score:2)
Beginning of the end...
To me the beginning of the end started with the requirements needed for GNOME3, or maybe a bit before with desktop.org. Now they are doubling down.
Instead of focusing on making applications secure, they decided to go with what I call the "MS-DOS" model on steroids. Each Application is in its own "Walled Garden". Apple here we come.
The new model is "Our Application is Secure because it cannot see data outside our Walled Garden." Well, if the Garden is rotting away, seems that is now OK.
Re: (Score:2)
No argument with you on that!
Since no one's done it yet... (Score:4, Insightful)
Obligatory XKCD [xkcd.com].
Re:Since no one's done it yet... (Score:4, Insightful)
Slight problem with your theory: Flatpak is already one of the many standards that exist. This is a bunch of the "players" declaring that one of the existing standards is good enough for their purposes.
Re: (Score:2)
I was thinking more of the app store itself, not the packaging system used behind it.
Re: (Score:2)
According to TFS, that "remains just an idea"....
Re:Since no one's done it yet... and also ... (Score:2)
Another XKCD on packaging: https://xkcd.com/2116/ [xkcd.com]
Re: (Score:2)
I was thinking of this one [xkcd.com]. Or even this one [xkcd.com].
I hate the app store paradigm (Score:3)
But all the kids these days expect there to be an app store when you use an OS, so it has become a necessary evil.
I do too, but it's easy to see how we got here. (Score:2)
This is because kids only have experience with walled gardens, in the form of their phones or tablets, or school devices (ipads/chromebooks).
Few even know how to use a mouse anymore, and I'm not fucking joking. I work K-12 IT and have for a very long time - this trend has been a running one for at least 10 years and has been accelerated by various factors.
Re: (Score:2)
To be fair I thought the app store was the greatest concept ever borrowed from the Linux world. What is APT / RPM if not a curated app store by a maintainer?
The issue is when you don't want to rely on just that one maintainer.
Please no... (Score:3)
Shameless plug - why hasn't Snap or Flatpak won (Score:3)
https://bryanquigley.com/posts... [bryanquigley.com]
tldr. Neither can take over the ecosystem in their current iterations.
This could be ok if (Score:3)
2. They have some policy not to let everything in that can pass the quickest of malware tests.
3. Has a working search function.
Also, for Linux in general, some nice and easy way to walk someone thru downloading, installing, and managing something into your system from GitHub. I have yet to successfully build(?) anything and have it work. And I pretty my attempts at doing so are part of the reason my system is flakey.
Slow? (Score:3)
Are flatpaks any more efficient than snaps? Snaps are slow, slow, and slow (and did I mention slow?). For instance, the Authy snap for Ubuntu takes 30 seconds to launch on my 24-core AMD Ryzen Threadripper 3960X.
Re: (Score:2)
Depends on what is in the image. If it's a pre-compiled application link-time-optimized against only essential libraries, it's going to start quick. If it has to JIT compile hundreds of libraries, it's going to be slow.
Re: (Score:2)
Launch speed and operating speed are not the same thing. Many pieces of software are launched rarely and when they are end up running just as fast as any the same software installed in any other format.
How do dependencies work? (Score:2)
Does anyone in the know understand how Flatpak handles dependencies?
Leaving dependency updates up to the application author sounds like a nightmare for security, so I imagine there must be some clever solution.
Re: (Score:3)
The Year of (Score:2)
Maybe if the path to the Year of the Linux Desktop involves an App Store then I don't want it after all. We have a 'watch what you wish for' situation here.
Re: (Score:2)
Package managers are very difficult indeed (Score:2)
Right, 'apt install <package>' is sooo difficult. What is really needed is an AI to interpret user drool patterns and automatically install packages based on that. And, of course, avoiding containers unless absolutely necessary.
Re:Package managers are very difficult indeed (Score:4, Insightful)
That's actually not the problem.
The problem is that APPLICATION DEVELOPERS need to invest time to build and package for
1. Debian stable (with its own can of worms). ... ad infinitum
2. Fedora 26 (with its own can of worms).
3. Ubuntu 22.10 (with its own can of worms).
4. Arch Linux (with its own can of worms).
So, what ends up happening? The dev makes his software available for one, maybe two large distributions/the one(s) he happens to run and the rest can go fuck themselves or deal with building from source (fuuuun, especially if you need to update the dependencies for the next version manually).
Flatpak, Snap, and Appimage solve these issues, resulting in distribution agnostic binaries with predictable and controllable dependencies, which is what each application developer wants.
The latter ways of packaging provide a nice and convenient way for Joe Average to install software and prevent infinite discussions like "why doesn't the software run on my distribution?"
What is at issue for me is that there's no app store supporting flatpak which is desktop environment/window manager agnostic, so it can be run in xfce, but also bspwm, fluxbox, i3, etc.
Re: (Score:2)
No they don't.
I know this because one distributed OS independent binaries they work across distributions. Basically... You link in all the dependencies statically and it works. I don't know why people find this so hard. I have a binary I made in 2004 which still runs!
Re: (Score:2)
Users are spread thinly (Score:2)
Or you could be like sane people and only create deployments for distributions that have the most users.
I think part of the problem is that the top two X11/Linux "distributions that have the most users" probably make up less than half the X11/Linux user base. I suspect that covering 90 percent of X11/Linux users would need packages for at least a half dozen distributions.
Provide the source code for the rest.
Many applications in a segment for which free software is perceived as impractical, such as games, streaming players for rented video, and tax return preparation. I don't see how the publisher of a proprietary application would be willing to
Re: (Score:2)
Right, 'apt install <package>' is sooo difficult. What is really needed is an AI to interpret user drool patterns and automatically install packages based on that. And, of course, avoiding containers unless absolutely necessary.
For the GUI-challenged out there...try using synaptic instead of forcing yourself to learn devilish CLI incantations.
App stores are great, just not mandatory (Score:2)
App stores really are great things for 99% of consumers. They just shouldn't be mandatory like on iOS. Honestly, I believe Google's Android does it the best. There are about 7 levels of menus a user has to jump through to be able to install apps outside of the Play Store. If you cannot figure out how to jump through those levels of settings menus, then you probably should be installing applications that aren't from a highly trusted source. (The play store is sketchy enough for the vast majority of users.)
Appstores are a thing because they make money (Score:2)
But 30% of free is nothing, so why do you want an app store? You don't get security. You don't get discoverability. You don't get attribution. Appstores provide none of the things they use to justify appstores. But they have a reason for lying: money. What is your reason?
Re: (Score:2)
Appstores provide none of the things they use to justify appstores.
App stores provide a one-stop shop for installing programs. I have no problems whatsoever with them making money for the services they provide. 30% is absurd, but there is a reasonable amount somewhere. It takes money to run the infrastructure, like any other endeavor.
Re: (Score:3)
If 30% is absurd, then why is it the normal rate? And who is going to pay the app store fees for my little program? 30% of free is still nothing. App stores create the illusion of a "one-stop shop", and they do that by making the alternatives look dangerous or difficult, but then you look for a popular "app" and they swarm you with evil clones and lookalikes. Sometimes the real app isn't available for your device and you ONLY see the fakes. Conversely, lots of good apps aren't even in the official app store
"Unfriendly?" (Score:5, Insightful)
Pardon my French, but what the fuck is so "unfriendly" about installing DEBs?
RPM and DEB are an absolute $(GOD)-send to users, particularly those who've had to suffer under the scourge of Windows, where you have to update each application individually, each usually with its own bespoke updater (many of which will try and up-sell you on shit you don't need). And if it turns out said program needs an updated MSVC++ runtime? Nothing will warn you; you get to find that out The Hard Way when it crashes, and then you get to grovel through Microsoft's awful site looking for the latest MSVC++ runtime, and pray to the gods that abide that upgrading it doesn't break something else.
DEB just fucking works. Except for very rare hiccups (in my experience), upgrading a package magically upgrades all the dependent libraries along with it. If you get sick of a program and delete it, all the libraries it required get deleted as well (if nothing else also needs them), saving you disk space and reducing potential attack surface. And you drive the whole updating process from one place -- not one program at a time, not with special snowflake updaters the marketing department occasionally throws over the wall. A consistent, reliable management system for all the software on your machine.
DEB is awesome.
Re: (Score:2)
DEB is awesome.
Same can be said about her step-sister DNF and her distant cousin PACMAN.
Not sure what to say about the daredevil "related by marriage only" named RPM.
Deb for what version of what distribution? (Score:2)
Pardon my French, but what the fuck is so "unfriendly" about installing DEBs?
If you don't run the same same version of the same distribution against which the deb package was prepared, you're in for a rough time. You might have trouble, for example, running a deb for Debian on Ubuntu or vice versa, or running a deb built for one major version of Debian on a different major version. It gets even more difficult to use a deb on a distribution that uses a native package format other than deb, such as Arch or Fedora.
Are there rules of thumb to make a deb that installs and runs correctly
Re: (Score:2)
It's a pain in the ass to make a universal DEB, but it can be done. Generally you end up making a container for an older supported distro and toolchain that targets several.
I think it might be easier to build for AppImage [slashdot.org] and make the appimage tools the single dependency for all your binary distributed Linux software. Same idea for snapd.
Re: (Score:2)
Re: (Score:3)
They're thinking from the perspective of the developers distributing the applications, not from the perspective of the end user.
DEBs etc. work great, but each package file works only on one release of one particular distro. Building for all in-use releases of all relevant distros is a lot of work. For popular open source applications, that work is done by the distros, but for niche or closed source applications it falls upon the application developers.
Re: (Score:2)
Pardon my French, but what the fuck is so "unfriendly" about installing DEBs?
Nothing, providing it's the right deb and it plays along well with your distro. But start adding more sources to your apt repos, start installing debs of different versions that are already part of your distros' sources, and eventually you can very quickly get to a point of truly fucking up the system.
There's few times I've seen truly messed up Linux systems but they've all been the result of installing libraries from source, incompatible with what you already have, installing deb files, adding PPAs, and ge
Party like it's 1999 (Score:2)
We have a welcome party for the Linux scene next month.
I hope they like 2023 as they seem to be stuck in 1999 with all their own fancy tools.
Re: (Score:3)
Let's be honest here. Modern tools are horseshit [theregister.com]. The most popular IDEs are web browsers with some JavaScript to make them into IDEs, with really screwy permission and security model.
Re: (Score:2)
An IDE is just a glorified text editor. Hell, I prefer Notepad++ or VIM for a lot of tasks when coding.
It shouldn't have any security concerns except which files you're allowed to access and open with it.
I have the Internet (Score:2)
Why the F do I need an app store? I can go on the Internet and download stuff, often for free. I've been doing this for 25 years, some people for much longer than that.
Re: (Score:2)
If an application is proprietary and commercial, and there are no close substitutes distributed as free software, you may need some sort of app store to purchase and remember a license to download and use the application.
Re: (Score:2)
I don't think that's necessary.
Re: (Score:2)
I can't tell what "that" refers to. I'm not sure if you mean proprietary apps are not necessary or that remembering your license to redownload a particular app after having paid for it is not necessary.
Why should this work better than anywhere else? (Score:2)
I mean look at App-Stores on mobile devices. Those turned the idea of a smart phone into a cesspool of the worst parts of IT. Many applications there include third party tracking. Apps trick their users into giving them high reviews.
If you want to do something for software funding, make an easy and transparent way to donate.
BTW there is such a thing as over funded Free Software. Firefox is a good example. For several years now they got hundreds of millions of dollars each year. Saved wisely that would be mo
We need a Flatpak distro (Score:2)
Until Flatpaks have planning and QC at least on the same level of native distro packages they are a bad idea.
Valve is the only company doing containerization right. Shared runtimes shouldn't be voluntary as in Flathub, but mandatory. Anything that can reasonably be shared should be shared, if a first party developer uses a custom runtime you just don't use his Flatpaks, a maintainer for the distro should compile their own according to distro guidelines.
Once such a distro exists, then you will have a good se
For Gnome? Keep it (Score:2)
DEB is my friend (Score:2)
What is not friendly about .deb?
It the easiest way i ever had to deal with to manage apps and OS install and upgrades.
If the command line is not your friend there a bunch of GUI for it too...
Stupid idea (Score:2)
flatpack? (Score:2)
Now I'm hungry
Re: (Score:3, Informative)
Linux doesn't have a desktop hold because it doesn't come preinstalled on notebooks / desktops, and that's it.
That's only part of the reason, and I don't think it's a particularly big one. The biggest reason Linux doesn't have a major desktop presence is because the software most people use don't have a Linux version. That leads to a Catch 22.
As it stands, if Linux were preinstalled on every desktop and laptop, it would be removed by the vast majority of people when they found out that the software they want just isn't there. People don't run operating systems. They run applications. If the application isn't availa
Re: (Score:2)
The other reality is that a lot of big name applications are now just clou
Re: (Score:2)
...to claim the existing methods for fetching software have some kind of issue or usability problem is moronic.
Not at all. Package managers are great, but there are oodles of circumstances where they fail and fail hard. Plus, saying that the need to drop to a command prompt to type an installation command with sometimes difficult parameters is not a usability issue is just wishful thinking. Sometimes just figuring out the name of the package that you need to install is a showstopper all by itself.
Then there is the issue of time. A large program with dozens and dozens of dependencies can take a long, long time to in
Re: (Score:2)
Re: Ubuntu won't support it (Score:2)
Just install it
sudo apt install flatpak