I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.

I'm sure it could help with application delivery so long as it's constrained to that. I don't want half of my standard libraries or utilities suddenly becoming sandboxed. For full blown applications sandboxing would be welcomed.

[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

[2]: https://specifications.freedesktop.org/basedir-spec/basedir-...

Problem is they both need to create an area with a full separate file system which doesn’t really fit in with the FHS.

Then there's the question of app-created data, that would normally go into some dot-directory. Flatpak by default redirects all XDG dirs into ~/.var/app/${appid}, but as a part of the required permissions, the apps can request access to the user homedir or specific subfolders.

Some apps abuse it. Yes, I do mind, when an app liters into ~/Documents/. I'm looking at you, Viber.

Yes.

When I ran mount, I noticed that every package I'd installed had it's own entry in the mount list. After I rebooted the machine, these mounts were no longer listed and the software I'd "installed" was no longer available through the gnome menu.

I'm not against finding new and better ways to package software but this experience left me with the expression that the technology is not quite ready to be rolled out and adopted en masse.

Even Linux has had several: NeXTStep style Application Bundles in GNUStep, AppDirs in ROX filer, and AppImage today. They're just not over-engineered enough for the Linux Desktop community to embrace or something.

Portable app bundles are not the goal here. The goal is portable app bundles that the user can install from arbitrary sources on a whim without putting their OS at risk of malware or their data at risk of exfiltration.

Y’know, like on phones.

But also, since these designs aren’t for consumer electronics appliances with a central vendor, but rather are following the FOSS philosophy, you can’t just use a weak sandbox powered by nominal capability manifests signed by a central code-signer, where the app could do arbitrary things outside of its capabilities and the sandboxing wouldn’t catch it (i.e. the macOS approach.) Instead, you have to have a strong sandbox that will actually enforce the capability manifest to restrict what the app can do.

Oh, and the bundles can update by self-modifying their contents, creating new executable binaries in the process, so your sandbox can’t be based on signing the initial contents of the sandbox, but rather has to sandbox whatever is attempting to run in there right now.

If you can come up with a design that fits those criteria and is simpler than Snap or Flatpak, by all means, share.

This is not now nor will this ever be a thing. If you can run software on the host there will always be a way to compromise the host. It is not even 100% safe to run software in a vm because exploits have been found to break out.

Maintaining security on your phone requires the app store owner to invest time in proactively screening manually or automatically for malware or reactively removing it when found. It requires users to avoid stuff that looks like scammy bullshit or software from unofficial sources.

Both of these layers leak and when they do automated protections usually do as well because malware authors can easily test against existing protections, learn from one another, and distribute what works.

That's... inaccurate. More valid statements would be:

- In a sufficiently complex OS, it is unlikely you will be perfectly safe running untrusted executables even with reduced permissions.

- Popular modern OS desktop distributions are very complex out of the box.

- Sandboxing prevents certain classes of attacks effectively, but should not be relied upon as a sole line of defense.

- Vulnerabilities have been found in VMs and containers, but they afford greater protection and isolation than running a process directly on a host system.

IOW, don't go No-True-Scotsman on security. A vulnerability does not invalidate all benefits of an architecture.

So a well packaged app utilising SELinux|AppArmor profiles?

This condescending idea that users can't be trusted to determine this stuff for themselves and therefore we need a centralized signer and a bunch of complicated management framework to deal with it is part of the reason the FOSS philosophy has yet to produce a desktop anyone cares about.

Your argument, by analogy, is “you should trust people to know not to sleep with people with STDs.” Well, you know what? Some people want to sleep with people with STDs. Sometimes those are their significant others. They still don’t want to catch something.

In both cases, the answer is the same: a condom.

A sandboxed App Store is, basically, a brothel where condom use is enforced. You can meet strange apps, play with them, and not worry about it. Because of the brothel’s policy, nobody the brothel hosts is risky. Your safety is enforced at the level of choosing the source.

Whereas something like Ubuntu’s PPAs, are more like a bar. Who knows what you’ll catch? Any individual app might decide to “wrap it up” with SELinux/AppArmor, but you can’t enforce it at the app-store level.

(Also, completely dropping the metaphor: the iOS App Store is frequently exposed—at least for free purchases—to children or even infants. This is actually a capability people want. This is certainly not a case where the user can determine for themselves whether an app is trustworthy.)

Yeah, that's why I said this:

> You only really need to sandbox stuff you're unsure of, or stuff that misbehaves but you need to use anyway.

I'm totally for sandboxing, at the discretion of the user. It doesn't require complicated infrastructure to do this.

A potential malware author must pay 99 usd to submit apps and pass certification for its apps. If apps are detected in review as malware that 99 usd is burned and will have to be spent again potentially repeatedly.

This is probably why there are millions of infected androids and comparatively few infected iphones.

Redhat with 10% of the staff and 1% of the annual revenue doesn't require any fee to release applications. This probably doesn't scale to android or ios proportions unless your sandboxing is perfect.

Unfortunately there is no 100% safe way to fuck disease ridden whores and no 100% safe way to run malware ridden apps. This is a dangerous fiction and an unworthy goal.

Likewise, servers run “malware-ridden apps” every day as well. Do you think AWS or GCP is getting its infrastructure infected when customers run their arbitrary code on it? No. Not even on the shared clusters like Lambda/Cloud Functions. These are competent sandboxes.

There are numerous other examples—running everything from user-supplied DFA regexps to SQL queries on shared servers (complete with stored procedure definitions) to arbitrary Lua code, server-side, in an MMO.

We programmers know how to (automatically!) sandbox arbitrary untrusted code. We’ve done it successfully, over and over. We just haven’t done it for GUI desktop apps yet.

That fact is much more to do with the legacy of the architecture of these GUIs, than it has to do with any inherent problem in sandboxing desktop GUI apps.

https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setu...

I'll chase it up with the responsible team.

I go back and forth on this one.

On one hand I think it would make things much simpler for users who have enough storage and bandwidth.

On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained.

The thing is that package managers have mostly abstracted away the headaches of dependency hell, but have also raised the barrier to entry, so any software not participating seems suspect.

Yes, that's a drawback, but how often is there a major library that shouldn't be part of the set of libraries included as part of the base OS install? And for the ones that aren't, if the vendor chooses not to update at least you have the option of continuing to use, or not, the older version on your own terms instead of having it broken by the package manager when a dependant library is swapped out from under it.

We live with this sort of thing every day in real world business and it honestly hasn't been a big deal.

When I use Linux as my main OS, I lose about a day or so every other month to dealing with upgrade/update fallout. It's discouraging to say the least. With Windows, it's been about every other year, and macOS every major version gives me a little grief for something. Both far less frequent than any Linux distro I've used.

Don't get me wrong, I do enjoy using linux, that said, I still have very weak trust of it as my primary desktop/laptop OS. I use all three regularly.

One of the big benefits of Linux is you have control over this by picking your distribution. If you used, for example, Debian you wouldn't have this problem as updates don't break things. If, on the other hand, you don't mind dealing with the occasional update issue and want bleeding edge packages then something like Arch might be better.

For a user whose machine is managed by others it should consume as long as the machine takes to reboot.

https://AppFS.rkeene.org/

There's a vocal segment of the mobile App developer community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications on iPhone and Android phones.

In reality, it doesn't matter.

I saw a lot of near pension age people, first time computer users, being taught basic usage of Ubuntu at around version 5.10. In our office, we have administrative and corporate treasury staff being taught to use it. The matter of them using it and not complaining "where is the start button here?" is having them RTFM* or get fired.

Not a single time we had to fire anybody over that.

Irony here is that the few Windows machines in the office are used by engineering for things like solidworks, different physics simulation packages, cadence, vivado and etc

[*] available in eloquent Chinese, unlike worse than Google translate Microsoft's manuals

There is no value in having a package manager on top of one.

The real problem is that actual software is trying hard to be too complex and violate best practices for installing software.

User managed Apps are okay. But: only for private use and never for company use since user control IS the actual issue there.

well, private use is by far the majority use case, isn't it ?

I welcome AppImage and Flatpak.

In his world developers don't do that, they throw a pile of source files into the wind and let package maintainers put it together for a distribution.

_("Warning:\n\n" "This version of xscreensaver is VERY OLD!\n" "Please upgrade!\n" "\n" "http://www.jwz.org/xscreensaver/\n" "\n" "(If this is the latest version that your distro ships, then\n" "your distro is doing you a disservice. Build from source.)\n" ),

YES, THAT WHAT USERS WOULD SEE, if only Debian maintainer haven't removed this patch.

jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84

Thus distros have to work around that by freezing lib versions and any software depending on said lib version for the support period of the distro release (5-10 years).

What is "funny" is that Debian here is doing no different from what RH had been doing with RHEL for ages, yet Debian gets all the flak...

Never mind that xscreensaver has a very prominent splash screen with JWZ's email on it on every launch. Maybe if he didn't want every idiot on the net emailing him, he should not show it in their face all the time. He may be brilliant in some ways, but sometimes he can be an raging asshole.

Hell, sometimes i wonder why he keeps supporting Linux as he seems to have no love for anything but Apple these days.

If you want to view the jwz.org link, copy the URL, and open it in Incognito.

However, there is still a large amount of software out there for which the above does not hold. That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, as well as a whole bunch of other more manual methods of downloading and installing. It is this software that solutions like flatpack and snap are for, and it is improving both the security and usability in these cases.

So no. I don't, but that doesn't make curlbash good either.

There are big improvements coming like PipeWire, DConf sandboxing, etc but it will not happen over night.

v_lisivka never mentioned sandboxing as an issue. They were clearly talking about the fact it's a free for all user submitted repo which have a provable history of people adding malware.

From my understanding, Flatpak provides sandboxing and asks the user to confirm exceptions, which if it works reliably does seem like I win something security-wise going from "go to vendor website, use their installation script" to "go to vendor website, get their flatpak thing, know that it can't totally screw my system without me granting it exceptions".

Parent claims it's only a usability benefit, so I'd like to know details about the problems with its sandboxing (totally willing to accept that they exist, sandboxing is tricky and not a cure-all)

On Mac.

This is mostly a sovled problem on Linux. Hell even slackware has this mostly solved.

I will concede there is a lot of Linux users out there either misinformed or simply don't mind the hassle of upgrading via random curl scripts if at all.

Maybe it will help them? Maybe it will just increase the target size making exploitation more worthwhile / likely?

Who knows.

For me, if it's not in the Arch repos (or aur) I'm incredibly unlikely to install it, to the point I don't actually have any software installed out of band other than stuff I specifically work on.

Massive amount of identical work that the WASTE majority of the time, does not improve anything for the end user.

Security should come from moving into well maintained platform, automatic scanners and many users. Instead of the package maintainers being the 'security reviewers' we should have app stores and sub repositories with security reviews.

Nothing stops a distro from only offering flatpaks from their own repo.

Centralizing and automating these things will allow for far better security processes in the long run.

Just try to do some of these steps on 2-3 versions (versions for non-rolling distributions) of each of the following distributions: RHEL, Debian, Ubuntu, Arch, Gentoo.

The Linux distribution ecosystem is insane.

It's also one of the reasons users and proprietary software have been rare on Linux.

It's also one of the reasons users and proprietary software have been rare on Linux.

It may be why proprietary software is lagging, but I think most users prefer an OS level package manager. They just didn't know about them until the Appstore.

The Linux kernel is everywhere thanks to Torvalds (overly late in the opinions of some BSD devs) declaring the API/ABI sacrosanct, and holding the other kernel developers to that (much to the chagrin of some that want to do hail mary changes for sake of security or ego).

But the userspace above had been reimplemented again and again because the various libs and such are fundamentally unstable. In far too many cases you can even do a x.y.z+1 update without getting some kind of breakage.

Often because someone decided that spec adherence was more important than real life stability, and thus pushed a patch through that altered the API behavior to be more in line with a spec that nobody had complained about for a decade or more.

The Appstore works on phones and tablets because they are primarily consumption-only devices, and because users are not given any other choice (also, the installer/uninstaller model has a lot of its own suck). I don't know about you, but that's not what I want out of personal computing.

Nobody is complaining that applications are in a central location.

Edit: I have no idea why you think this is condescending.

Edit response: It is condescending because it imagines the user is incapable or uninterested in the way their system actually works, as a mere pusher of buttons to make the blinkenlights go. Sure, some users are like that, but largely it is a convenient excuse to dismiss criticism.

The market share of any PC desktop operating system has mostly to do with the type of office work that took place in the 90s, when computers took over.

That's slowly changing as the web is taking over, and Chromebooks, Android, Mac, and "regular" Linux desktops becomes a viable platform for sharing your work with others.

Consider that the usecase for a personal desktop computer may be different from that of a smartphone or tablet. There's more to personal computing than a web browser.

Of course an easier to use third party packing system would make the desktop easier to use, but that's not where the pain points are. (Especially since most third party binary packaged software is just something you unpack and run.)

Even the most easy to use packaging system you could imagine wouldn't impact the Linux desktop market share measurably.

Historical reasons like it being an open platform that developers could target without the requirement of third party approval, among other strengths.

Linux doesn't have anything like that traditionally. You have to make a deb, rpm, whatever Gentoo uses, etc. And ./configure && make && make install is laughably unintuitive.

Also, Google have done some serious work to ensure at least some backwards compatibility (and providing a support library, that i fail to recall the exact name of, for backporting various functionality).

While the FOSS world seems to lean on "compile it" along with "lacking resources" as an excuse for not maintaining anything more than incidental compatibility across releases.

The installer/uninstaller paradigm is almost as bad as the package manager paradigm in my opinion.

That's going from trusting 1 person to trusting thousands.

Spotify: https://www.spotify.com/uk/download/linux/

Chrome: https://www.google.com/linuxrepositories/

VSCode: https://code.visualstudio.com/download

Package maintainers can also be a bad idea! They have the ability to make the user experience worse and create a lot of unnecessary work for vendors. The version of AbiWord on Ubuntu was out of date and unsupported for a while. There was a steady stream of people going through vendor support channels reporting bugs that had been fixed a year previously. The maintainers ignored the vendor's requests to update the package to a more recent, supported version.

You can't blame distribution maintainers for not wanting to expose their users to a constant stream of the newest exciting quirky features the authors have decided to cram into the current release just to be able to keep on top of all of the bugfixes. New releases all also tend to implicitly have new or different sets of dependencies, and distributors have a duty to make sure these various dependencies that exist in their distribution can coexist and interoperate

Authors declaring whatever versions they no longer care about as "unsupported" is a rather unhelpful trait that ignores where their users are (distributions) and what a lot of their users actually want (stability).

I'm sure developers would ideally like to have users suckling at the teat of their latest tagged changeset and perpetually excited about the latest enhancements in each and every release. But really I'd wager that most people, of the ~20-30 applications and desktop components they use every day, by and large... they'd just like most of them to behave like they did yesterday - or last week - or last month - as long as it's reliable.

Yes, and that is a great argument for why the unix model of applications spreading themselves over the file hierarchy and sharing everything is completely broken. Something as simple as updating to the latest and greatest version of an application should not require you to rebuild the entire goddamned OS! That Linux Desktop people don't get this is one of the big reasons there will never be a Year of the Linux Desktop.

The "year of the linux desktop" has always been a red herring. Let's leave 2006 behind, shall we?

How many copies of the Win32 widget interface do you think exist on a Windows installation? I'll give you a clue: it's one. This is because Windows has a defined and stable base system that developers can depend on being there so they don't need to ship their own copy of things in the base system.

Linux has no base system because that would mean agreeing on something.

Back-porting bug fixes isn't really an option at that point.

There are real downsides to the maintainer system - it creates a lot of extra, uninteresting work, and frequently no-one's that interested in doing it, especially for smaller packages. That's why there's so much interest in other models.

To give another example, if you install jupyter-notebook through apt on Ubuntu 18.04 today, you get a version with a security issue (CVE-2018-8768) that upstream released a fix for months ago. Package maintainers are not making anyone safer there.

This isn't some hypothetical, for the record. I'm explaining how this actually works in practice.

You're explaining how this works in response to concrete examples of where it hasn't worked. I understand how distro packaging works for some packages, but I've seen it fall down too many times for others, especially more niche things.

Do maintainers commonly audit source code to look for vulnerabilities? And at any rate, aren't the common security-critical libraries for flatpaks, like OpenSSL, already (in theory) provided and maintained by the runtimes?

All the major consumer OSs distinguish between system components, like cryptographic services and graphics libraries, and user-facing applications. The world hasn't collapsed for them so far, and in an ideal world that distinction allows for better delegation of responsibilities.

https://github.com/g0tmi1k/debian-ssh

In 2006 the security landscape was very different. The common understanding of security being a tremendously subtle issue was much, much lower. A typical system from 2006 was much more trivially exploitable than one today. A lot of things can be said about security attitudes in 2006 vs now.

I can't see any real benefits to the Linux approach and never could. It's one of the reasons I ended up moving to macOS. There's hardly any malware there too and yet app developers build packages themselves.

>The world hasn't collapsed for [major OS vendors] so far

Hell yes it has. Malware and user-hostile is running rampant on the "major" platforms like Windows and macOS. Have you ever used a non-technical person's computer for a few minutes? It's like a warzone.

Personally, I think that says a lot about the Linux desktop and its community.

I have used non-technical people's Windows machines, and they were not a warzone. I've looked over the shoulder of plenty of other people using Windows & Mac computers, and generally not seen any obvious signs of malware infestation. There could be unseen malware lurking, but we can't assume that with no evidence.

Maybe this depends on the non-technical people you know, but it's definitely possible for people to use Windows/Mac computers and not be dropped in a pit of malware.

Flathub isn't trying to replace your package manager for everything, just for graphical desktop apps. As far as I'm concerned, it's more than welcome. I'm tired of hearing about a major release of a desktop app and not having it available for months. Even worse, I'm tired of hearing about a major release, experiencing horrible bugs when the maintainer updates it, and not having any long-term option to install the previous version so that I can get work done.

Flatpak solves all of this and more.

The Snap store so vastly improves my user experience of using common apps I switched from Arch Linux (where 50% of the programs I had installed came from the AUR) to Ubuntu, where everything I needed was just there. No longer do I need to run weird scripts from the internet to get simple stuff to run on my non-standard distro (which could be Arch, Fedora, or whatever I am running at the time).

You can hold the position that these things are a big security risk. Distributing monolithic packages with likely old/vulnerable dependencies is not a great idea. But on the other hand, it prevents asking the user to run random scripts (which in many cases are not vendor provided) as root to get their software, and it gives the user integrated automatic updates and other software center integration (as opposed to downloading random stuff from the internet). In terms of increased security through sheer usability and requiring less manual maintenance, the advantages of Snaps and Flatpak add up, I think. Many things in security are a tradeoff, and I feel that getting the user to do the right thing is often extremely undervalued. I think it is also undervalued in these comments.

Flatpak and Snaps still have a lot of problems. Why do we have two competing standards? Why can't I properly get all Snaps running on Fedora or other platforms that use SELinux [rhetorical question - I know the technical reasons]? Why do so many apps not use their sandboxing effectively? Why is it so hard for these things to respect my computer's theme? The list goes on.

The list of problems is long and valid. But I think it's worthy of some celebration that advancements are being made in making desktop Linux usable for users and popular for developers. And I don't think it's clear at all that this is a regression in terms of security.

Especially if you are running a non ubuntu distro you are stuck with snap AND something else rather than replacing your current system with snap.

Further both apt and snap are strictly inferior to nix or guix so you are actually stuck with 2 worse packaging systems in place of one superior one.

For what its worth my experience with a ubuntu/ubuntu derivatives was different. I found the non LTS releases fraught with difficulties and the LTS was out of date sufficiently that I ended up adding over 80 ppas to get up to date version which isn't much different than having 80 some aur packages save that it is less convenient.

The real key to Flatpak and Snap is the entire app "experience" - integration in the software center as a trusted source, automatic updates, clean installs and removals without messing up other parts of the system. Before Flatpak and Snap, this did not exist on Linux, especially not in something that was compatible with all distros.

I don't know about that. This "advancement" is catching up to where every other desktop OS was in the 80s.

Installing a PDF reader should not forcibly install Udisks2 and upower.

A lot of commenters are upset that maintainers are being removed from the equation. Can't each distro just set up their own maintained repository? If I understand correctly, there's nothing about flatpak that actually prevents traditional maintaining. The only thing distros have to do is integrate flatpak, set up their own repository as default, and note that user should use other repositories at their own risk. Which is basically how things already work.

Is there a valid reason to hate flatpak itself, or are you all just too caught up in hating change to actually evaluate it?

Yes Fedora is working on doing so.

I haven't used the feature yet, but supposedly there's a means of easily rolling back to a previous version in case an update has a bug the user can't work around. Rolling back RPM's can be non-trivial when there are many dependencies - it's way easier for me to do rollbacks of an RPM only based system by Btrfs snapshots which of course not everyone can depend on just for undoing an application update.

So I'd say this is definitely an improvement from a user perspective; and it seems no more painful and perhaps a little less painful for packagers.

Also the Snap store allows a larger range of software (WINE repackages, server apps, duplicates, etc) that Flathub does not. Flathub is also hand reviewed so it takes a bit longer for new apps to get in.

firefox, vscode, etc. there is also this - https://www.docker.com/docker-news-and-press/docker-and-cano...

Snap "solves" this issue by not sandboxing some apps. I'm not sure if there is a good solution to sandboxing developer tools.

As an end-user, I want my apps to be getting regular, automatic updates, which means it's vital to get them from some kind of official repo. I sympathize with the one-man developer who just wrote some cool little Electron app that he designed to be cross-platform and promptly gets bombarded by requests from his 10% Linux userbase that wants the app to be packaged for Debian/Ubuntu/Fedora/SuSE/Arch repos. I get it, I've been that annoying guy[0].

So to that end, packaging once as a Flatpak and working everywhere has been great. A handful of those pesky apps I used to have to regularly check for new RPM releases are now on flathub and I can update them automatically.

With that said, flatpak support is still spotty. DNF doesn't support flatpak yet, so I had to install GNOME Software on my Cinnamon DE just to be able to easily support and update them. There's also the issue of the greatly inflated installation sizes. I'm hopeful that support will get better soon now that it's finally at 1.0.

[0]https://github.com/MarshallOfSound/Google-Play-Music-Desktop...

DNF probably won't support flatpak, as it is something entirely different. Gnome Software does support multiple backend thought.

If you want to install/update/remove flatpaks from command line, just use the flatpak command ("flatpak update" will check all the configured flatpak repositories for newer versions and update whatever is available).

Could you not just use the cli?

(Not trying to start a holy war, just a question)

list whatever is available in repository: "flatpak remote-ls repo-name", i.e. "flatpak remote-ls flathub".

list installed packages: "flatpak list"

This because they do not want to admit that distros being slow with rolling out new releases of their software, is because of the dependency tangles that they have created for distro maintainers.

There's plenty of NIH to go around on this one.

The rush towards containers because they're "easy" strikes yet again.

My fear is that the handful of companies that build packages for their desktop apps with abandon them and move to Flatpak/Snap. From the Flatpak docs it looks like anyone and everyone can just get access, even if you don't own the thing you're packaging. So if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push.

It's like they looked at everything bad about Chocolatey/NPM/pip/AUR and just ran with it.

That's an insane thing to say. Literally 100s of people doing the same thing adding no value to the end user. That is a waste amount of resources waste by the open source community.

> My fear is that the handful of companies that build packages for their desktop apps with abandon them and move to Flatpak/Snap.

Good? Why does it matter to you.

> From the Flatpak docs it looks like anyone and everyone can just get access, even if you don't own the thing you're packaging. So if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push.

Nothing stops you or any distribution from having a repo with reviewed or specially selected software.

Also, the waste majority of packagers would not have found that malware anyway.

Or you know developers could package their own software. It's some upfront effort but usually set and forget. Things like FPM[1] make this even easier. Personally I don't know why developers find packaging so hard, I've had to package hundreds of bit of software for different distros (and versions of said distro) over my career and it's usually set and forget with some changes when there are big underlying changes to the OS like sysv > systemd. Granted my experience is with non GUI apps so I can imagine there is likely some pain points between different distros/version when it comes to the hot mess that is DEs.

> Good? Why does it matter to you.

Because I have to go from trusting 1 vendor to install 1 package (and dependencies) to 1 3rd party repo that anyone can push to. That is a huge change in the trust model.

> Nothing stops you or any distribution from having a repo with reviewed or specially selected software.

We already have those.

> Also, the waste majority of packagers would not have found that malware anyway.

This isn't about trusting the software in the package it's about trusting the package maintainer, who could now be absolutely anyone with no verification or validation. See malware in other user run repos like NPM, pip, AUR etc...

1. https://github.com/jordansissel/fpm

When I was a Linux user, I've seen so many packages that worked on one Debian derivative but had problems on another. Maybe this is a solved problem now? It definitely wasn't solved from a user perspective five years ago.

As a developer I can tell you right now that I'm not gone package everything for for 100s of linux distros that I don't even know the name of.

> It's some upfront effort but usually set and forget. Things like FPM[1] make this even easier. Personally I don't know why developers find packaging so hard, I've had to package hundreds of bit of software for different distros (and versions of said distro) over my career and it's usually set and forget with some changes when there are big underlying changes to the OS like sysv > systemd. Granted my experience is with non GUI apps so I can imagine there is likely some pain points between different distros/version when it comes to the hot mess that is DEs.

Have you ever thought about maybe that doing something a lot makes you good at it.

Many developers are not linux expert, and don't know the many difference between the distros and the package managers, or even the different distros using the same manager.

Saying its 'fire and ferget' when there are so many distors who are all moving targets with different targets, release cycles and so on, its just basically lying.

But that's not all, you also have to get bug reports from many different people that you can not reproduce.

> Because I have to go from trusting 1 vendor to install 1 package (and dependencies) to 1 3rd party repo that anyone can push to. That is a huge change in the trust model.

So the fact that some poor debian maintainer had to wrap the venders app with some debian specific glue makes it safer?

If you don't trust the vender of your software, you can trust that they maintain a repo where you can download it. That might be Flathub for some smaller once, but others will have their own.

There is not more trust involved at all, maybe you move trust from Debian to Flathub, but that's it.

> We already have those.

Not with the advantages of the maintainer only having to publish one software package.

> This isn't about trusting the software in the package it's about trusting the package maintainer, who could now be absolutely anyone with no verification or validation. See malware in other user run repos like NPM, pip, AUR etc...

It is already absolutely anybody. Do you know all the people who package for Debian?

Also, if don't want to use apps directly from Flathub, you don't have to. You can only use software that has been validated by the Flathub community, or when somebody like Fedora uses the app.

Forcing 1000s of man hours of voluntary work just so you can claim "Some guy lightly related to the X distro project has taken a couple hours to see if it doesn't crash" so that's what I'm gone base my security on is a insane approach.

That's a terrible, terrible security architecture and the only reason anybody is defending it is because that's who it used to be and that somehow makes it good.

Dude, seriously. Flatpak has issues, but saying "Packaging was a solved issue" when every distro rolls out its own packaging system is the reason we can't have nice things.

Ignoring the problems won't make them go away.

If every distribution was using the same packaging system, would they still be separate distributions?

EDIT: By packaging system I assumed we meant the same repositories, and packages. Since that is how Flatpak seems to work.

Do we even need that many distributions? What's the value proposition for all those hundreds of Linux distros?

My impression is that for many of them its:

A. we want to make my own distro, to learn, get visibility or maybe even make money

B. we want to make our own distro because of an already existing user base from point A.

C. we want to make our own distro because we can't get along with distro X makers

I wish that the barrier to entry to making a Linux distro was higher. People would have to put more thought and effort into it and the overall quality would be higher.

That is a valid point, and why I usually tell people to just use Ubuntu if they're not sure. The value proposition is that different people are doing different things, and even people doing the same thing sometimes like to do it different ways.

I wish that the barrier to entry to making a Linux distro was higher. People would have to put more thought and effort into it and the overall quality would be higher.

I believe that less competition equals lower quality.

While I generally believe in competition leading to better results for users/customers, the real life experience of Linux distros vs Windows or Mac OS doesn't seem to bode well for the free market :p (i.e. Linux distros should be the pinnacle of software quality and they aren't).

Would RedHat switching to apt make Debian redundant?

yes because Debian (stable) and Kubuntu have different KDE packages

> Would RedHat switching to apt make Debian redundant?

- no because they apply different patches - yes because I think that both Debian and Red Hat and any distro which applies patches is already redundant with Arch

Flatpak is entirely decentralized, anybody can make a custom runtime (Debian/Fedora ones exist), and anybody can host a repository.

If they used the same packages, then there would be a question if they are separate distributions.

But, they don't. Lots use Debian’s, for instance.

What this does is allow software to keep working when a library update happens without having to spend hours/days tracking down wierd scripts you don't even understand and running them as root to fix your problem. Not everyone wants to write OS-level software or fix every bug themselves.

Hell, my GF watched me install something that wasn't in the UI app center (whatever it is called) via command line, and was like, "WTF do you have to do that? That's the most stupid thing I've ever seen." The fact is, she's not wrong.

How does this compare to the traditional package managers?

[1]: https://docs.snapcraft.io/build-snaps/upload

[2]: http://docs.flatpak.org/en/latest/publishing.html

[3]: https://github.com/flathub/flathub/wiki/App-Submission

This is identical to every traditional distro like Debian or Fedora.

1. Packaged by the developer/publisher, see Virtualbox, Spotify, Chrome, Slack etc...

2. Packaged by a single 3rd party, see PPAs

3. A central 3rd party repo populated by anyone, NPM, AUR, pip, Snap/Flatpak etc..

Case 1: I have to trust the developer/publisher which is sensible, you're already trusting their code to run.

Case 2: I have to trust some random 3rd party, sometimes this is possible, sometimes not but if I do trust them I'm trusting them for one package (and maybe it's dependencies). I may have multiple options of who to trust to provide this package.

Case 3: Anyone can package anything if they get there first they can publish things however they like. The problem is that they are implicitly trusted by the repo, not me.

The first 2 are acts of active trust, I have to verify the person/company I'm downloading and make a decision whether I trust them or not. With a 3rd party central repo (it doesn't matter what format) I do not have that option, I either trust everything that anyone can publish to be correct or I don't use it.

It gets easier on updates since you only have to check diffs between versions. I believe you are making a wrong decision if you trust anything on the AUR implicitly.

That's basically my entire point.

Basically they did just that. The only "desktop" devs left in Linux land are really cloud devs that dabble in desktop on the side. Damn it, i have been basically told to clam up when i complained about the cloud mentality having no home on the desktop. Because apparently only could mattered because it was the big Linux user case.

When you drag-and-drop a file from e.g. a file manager into some application, then the DnD events do not contain the file. Instead, they contain something like `text/uri-list` enumerating the file paths. If you sandbox some app, then you need a bit of software to map and translate these paths. If you do not provide such software, then your sandbox does not support DnD.