Flatpak 1.0 Released, Ready for Prime Time

https://flatpak.org/press/2018-08-20-flatpak-1.0/

by alexlarsson • 8 years ago

254 206 8 years ago

ddevault• 8 years ago

Ready to ruin the security of Linux, you mean. The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea. Sandboxing applications is great, but it can be done without subverting the package manager.

matharmin• 8 years ago

Package managers work well for the large proportion of software on Linux that is open-source, and has enough users to warrant the effort of packaging it separately for each distro, and doesn't require you to have the latest version (or specific older version) all the time.

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.

v_lisivka4• 8 years ago

It improves usability only. It also creates false perception of security. Malware already found in NPM packages, AUR packages, and other packaging systems without maintainers.

lugg2• 8 years ago

That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time,

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.

gurkendoktor3• 8 years ago

But that doesn't really work for proprietary software. I use Flatpak/Snap for Spotify, IntelliJ, Slack etc. Audited packages are not really an alternative here, and (partially) sandboxed, distro-agnostic containers are the next best thing.

deadbunny17• 8 years ago

Sure it does. I add that companies repo to my sources and install their packages. I'm trusting their keys to install their software. I'm not trusting them to install software they have zero control over.

curt152• 8 years ago

Getting maintainers out of the loop for auditing packages

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.

shittyadmin2• 8 years ago

It's definitely not so cut and dry - maintainers have actually managed to introduce vulnerabilities into software too. The famous Debian SSH key generation issue comes to mind.

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

Sir_Cmpwn4• 8 years ago

Not always and not comprehensively, but they work alongside their users to tune packages as appropriate. It introduces a dispassionate 3rd party for users to report issues to who can fix problems which the upstream has an incentive not to fix.

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.

AnIdiotOnTheNet22• 8 years ago

The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux.

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

dec0dedab0de4• 8 years ago

The split between package vendor and package maintainer has classically been the primary reason for malware being 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.

deadbunny17• 8 years ago

Strange. I have a whole load of proprietary software on my laptop, all installed via native packages.

ynniv3• 8 years ago

The packaging system has very little to do with user adoption of a more complicated interface, or the success of proprietary software in a purposely open system. From the user's standpoint, package management on Linux is usually just hitting the "update" or "install" buttons.

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

Sir_Cmpwn4• 8 years ago

Good. Proprietary software doesn't belong on Linux, or anywhere else for that matter.

akerro4• 8 years ago

There are several linux distros, I'm a single OSS developer. I once tried making my program available for Debian (deb), Ubuntu (ppa) and Fedora (rpm). I ended up supporting only AUR. There are too many differences in packaging managers, different requirements, too many websites I have to register on, too many config files for each distro. Support from people who work as packagers is non-existent, questions on SO out of date, error and warning from packaging software misleading or completely useless. It's a huge mess, and if you think existing system is better than Flatpak/Snap/AppImage, I'm sure you haven't tried porting your software to top 6 distributions. Also, enjoy dependency hell, Debian has old Qt and PA, Mint has PA compiled without noise-cancelling flags, Ubuntu had SQLite3 with not working encryption, Fedora had backported Qt5 patch (old Qt with latest patch) witch fixed one issue, but broke CSS on Cancel/OK button group.

I welcome AppImage and Flatpak.

AnIdiotOnTheNet22• 8 years ago

I'm sure you haven't tried porting your software to top 6 distributions

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.

nickik6• 8 years ago

The split might have some amount of minimal value, but it also has many problems. Just the insane amount of work spent, by literally 100s of different communities is almost beyond insane.

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.

oblio4• 8 years ago

Don't forget the craziness in /etc. Where do I edit the hostname? Where do I edit the network card configuration? How can I check the distribution name and its version number? Where are the configuration files for Nginx and how are they structured? Etc, ad nauseam.

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.

jamesgeck03• 8 years ago

Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea.

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.

Sir_Cmpwn4• 8 years ago

Patches speak louder than bugs. The source material used to prepare the packages is often available and sending a patch to the maintainer's inbox (or other maintainers in similar software if the maintainer is unresponsive) is a sure way to make it easier for them to accomodate you.

ris4• 8 years ago

The version of AbiWord on Ubuntu was out of date and unsupported for a while

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.

moocowtruck2• 8 years ago

linux security is honestly more obscurity; most linux servers by anyone but experts is like swiss cheeses.. and desktops..are just not that appealing to people who want to exploit. hell I could easily get around my login manager in ubuntu without breaking a sweat.. As a linux user I'm eager for flatpak/snap/whatever.

nickysielicki• 8 years ago

I don't agree. If you want to install Flatpak applications that you can trust to the same extent that you currently trust packages, all you need to do is encourage your distribution to host their own Flatpak repository and have current package maintainers move over. They can still implement their own fixes and patches and release cycles.

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.

sandGorgon2• 8 years ago

I dont know but if i just compare https://snapcraft.io/store and https://flathub.org ... I see that snap packages have a lot more adoption by big name vendors.

curt152• 8 years ago

One advantage of snaps for developers is that if one is already developing on Ubuntu or Debian, the build and runtime dependencies of a snap can be expressed directly in terms of the packages in the distribution's repositories. To build a flatpak requires one to hunt down the original sources and figure out how to build them like what people did before the era of package managers.

TingPing14• 8 years ago

Canonical has a marketing team and outreach. Flatpak doesn't.

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.

sandGorgon2• 8 years ago

im not talking about niche ones - im talking about REALLY big names.

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

mahesh_rm• 8 years ago

What is the position of Linus and Linux Kernel Development crew regarding this?

dullgiulio• 8 years ago

Why would they have a position that is "official"? Linux is the kernel: it provides userspace with a very stable API (which includes the sandboxing primitives used by snaps and flatpacks) but it does not mandate much in userspace.

AnIdiotOnTheNet22• 8 years ago

Linus himself distributes Subsurface using AppImage.

feborges• 8 years ago

Also available in flathub.org

blattimwind2• 8 years ago

Interestingly flatpak doesn't really support drag-and-drop.

alexlarsson3• 8 years ago

It should support it as well as deb or rpm does. I.e. it is completely uninvolved in drag-and-drop.

alexlarsson3• 8 years ago

Well, if you drag-and-drop a file things might be somewhat problematic due to the sandboxing. An app with no access to the file can't read the dropped filename.

deadbunny17• 8 years ago

They mean the apps running in flatpak, not the flatpak installer...

blattimwind2• 8 years ago

No, it really isn't.

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.

jhack• 8 years ago

Flatpak and Snaps are a great step forward for Linux packaging and usability.

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.

AnIdiotOnTheNet22• 8 years ago

Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward.

dec0dedab0de4• 8 years ago

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.

TingPing14• 8 years ago

Just hoping the host never breaks ABI is why we are here in the first place, solutions like that simply don't work and you need a runtime to be portable.

rkeene2• 8 years ago

You might like AppFS, it solves the packaging problem. It doesn't include sandboxing, but that's a separate system that could be built on top.

https://AppFS.rkeene.org/

mediocrejoker2• 8 years ago

I installed Ubuntu 18.04 the other day and was prompted to install some common software such as Slack, Discord and Spotify . I installed all of them, and it mostly worked (navigating to another page in the software centre cancels an ongoing install with no warning).

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.

seiferteric• 8 years ago

I've noticed after updates I believe, the calculator app just won't open. It will sit there with the spinning wheel thing. After a reboot it will be fine. I noticed that the calc app is installed as a snap, never noticed this behavior before.

scns• 8 years ago

Had a similar experience with flatpack. Installed some software 2 days ago and yesterday flatpak told me it is not installed. Teething problems i guess.

AnIdiotOnTheNet22• 8 years ago

The technology has existed since the 80s, it's just that the stuff people are building today is ridiculously over complicating the solution. MacOS classic had simple single-file programs you just dragged and dropped anywhere you wanted on a disk and ran them. The same was true of DOS (it was a folder, but otherwise the same), RISCOS, NeXTStep and modern MacOS via NeXTStep.

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.

evand• 8 years ago

Could you file a bug report here and send me a link?

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

I'll chase it up with the responsible team.

russdpale2• 8 years ago

Perhaps not, I've had a good experience on Fedora 28. Even though I love Fedora, snap and flatpak needs to work on Ubuntu flawlessly before primetime, as its the most popular distro.

cpburns20095• 8 years ago

Snap needs to fix their non-standard directory placement. They ignore the FHS [1] by creating /snap at the root level. And they ignore XDG [2] by persistently creating ~/snap in your home directory. I've heard Flatpak is better in this regard.

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-...

Thaxll• 8 years ago

Does it matters?

akerro4• 8 years ago

They just create ~/.var if you install program for single user, if as root it goes somewhere to /usr/share

lathiat• 8 years ago

Flatpak uses /app so I’m not sure how it’s really “better”

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

baybal22• 8 years ago

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.

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

marenkay2• 8 years ago

What worries me more is that packaged applications come with 1-n standards again.

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.

jcelerier3• 8 years ago

User managed Apps are okay. But: only for private use and never for company use [...]

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

v_lisivka4• 8 years ago

In Linux, you need to download, compile, and install viruses and trojans by yourself. With Flatpack, trojans can be installed in one click.

v_lisivka4• 8 years ago

OMG. I got 2 downvotes before my page with response loaded after submitting. Never saw that. :-[ ] Instant karma.

DoofusOfDeath• 8 years ago

Jokes on HN always run a risk of downvoting, even if really funny.

deadbunny17• 8 years ago

Packaging was a solved issue in Linux, congrats on the 3 steps back.

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.

alkonaut3• 8 years ago

if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push.

How does this compare to the traditional package managers?

cpburns20095• 8 years ago

Well, looking at the procedure for Snap [1] there's no review at all. Flatpak [2] defers to Flathub [3] which has some sort of review: a pull request on Github but I'm not sure how thorough that is. Traditional package repositories have a review phase before you can get your package into the system (that's how it is with Debian at least).

[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

deadbunny17• 8 years ago

If I need software not found in my upstream repos you have 3 options:

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.

scrollaway2• 8 years ago

Packaging was a solved issue in Linux, congrats on the 3 steps back.

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.

dragonwriter• 8 years ago

every distro rolls out its own packaging system

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

dec0dedab0de4• 8 years ago

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.

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.

nickik6• 8 years ago

Packaging was a solved issue in Linux

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.

deadbunny17• 8 years ago

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.

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

digi_owl7• 8 years ago

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

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.

tracker13• 8 years ago

Umn, the software developers for X don't necessarily run the packagins systems for deb, apt, etc. There's nothing stopping RedHat from maintaining their own Flatpak "store", ditto for Ubuntu, etc.

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.

privateSFacct2• 8 years ago

They might want to take a look at snaps - it does something similar and has a good software mix.

AnIdiotOnTheNet22• 8 years ago

Snaps are Canonical's NIH take on Flatpak (previously known as xdg-app). Fragmentation for fragmentations sake.

thibran• 8 years ago

Sure it's Canonical's NIH and not Red Hat NIH, since both got released in December 2014?

Aelius• 8 years ago

I like to run a pretty lean system, and flatpak gives me the ability to install some of the bloatier packages without the deep system dependencies they bring with them in a package manager.

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?

TingPing14• 8 years ago

Can't each distro just set up their own maintained repository?

Yes Fedora is working on doing so.

nickik6• 8 years ago

A lot of criticism smells like 'RedHead systemd conspiracy' vibe.

DCKing2• 8 years ago

The tone of the comments on news like this never fails to disappoint me. Sigh.

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.

baybal22• 8 years ago

We also have the not-so-dead autopackage (listaller)

DCKing2• 8 years ago

Yeah, but it's not just about solving the problem "how do I install package X on a random Linux distribution". I agree there have been solutions for that for a long time. In fact, Snap at least does not even fully solve this problem because its sandboxing depends on AppArmor, which clashes with SELinux on distros that use this - (e.g. anything from Red Hat).

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.

AnIdiotOnTheNet22• 8 years ago

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.

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

delinka• 8 years ago

Do you think perhaps it's not worthy of celebration that advancement happens, even at a slower pace than you would like?

michaelmrose4• 8 years ago

Snap has no concept of multiple repos meaning Canonical is solely responsible for choosing what software you are allowed to run even if you aren't running Ubuntu.

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.

AdmiralAsshat2• 8 years ago

My first impressions of Flatpak have been positive, with a few caveats.

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...

deadbunny17• 8 years ago

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.

Could you not just use the cli?

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

AdmiralAsshat2• 8 years ago

The CLI wasn't terribly intuitive for app discovery, and to be honest until I googled around I couldn't even find the flatpak command to update already-installed apps.

vetinari4• 8 years ago

DNF doesn't support flatpak yet,

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).

dajonker• 8 years ago

Flatpak works much better for me on Ubuntu 18.04 with vanilla Gnome on Wayland: the Snap packages don't appear in the Gnome menu (until you launch an X session) and some Snap packages don't work at all on Wayland. Also, Spotify is updated much more often on Flatpak hub than on Snap.

sam0x17• 8 years ago

I would be curious to know what the differences between snap and flatpak are? Is this just a "flatpak is for RHEL, snap is for debian" situation, or is there something more to it? Just curious.

russdpale2• 8 years ago

You can use them side by side. They are just different options :). If its not on snap, it could be on flathub or the other way around.

cmurf• 8 years ago

I've been using the Slack, GIMP, and Darktable flatpaks on Fedora Workstation (which is GNOME based), available on flathub.org, for quite a while, maybe a year - without problems. I also sometimes use Okular which is a KDE app, and by installing it, the necessary kde.Platform runtime libraries were also installed and kept up to date by flatpak - works flawlessly. There's also a LibreOffice flatpak I have installed, and it seems like the flatpak update "deltas" are smaller than RPM updates, by quite a bit.

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.

lousken• 8 years ago

I know snap makes it hard if I want to modify something inside the package even as root (so it's close to the UWP nightmare). Is flatpack any different?

safgasCVS• 8 years ago

I dont understand the point of this - why is this any better than apt? Based off the top comment here this is meant to be much more user-friendly, but already installing on Ubuntu didnt work properly despite following Flatpak's own guide. And the install process for apps is then basically the same as apt. I dont get it

digi_owl7• 8 years ago

User friendliness is a smokescreen, it is about being upstream friendly. This in that now you get the kitchen sink of dependencies on each install rather than them actually having to care about API stability (not that they did much in the past).

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.

Flatpak 1.0 Released, Ready for Prime Time

Related Stories