Flatpak

>liberates your linux system from userspace insanity
>allows you to create packages that "just werk" on all supported distributions
>allows you to host your own repositories
>can be installed offline via. bundles
>can be used to sandbox and package Windows applications that "just work" on all distributions after initial wine configuration
>making your own packages is as easy as writing a simple json manifest file
>by supporting flatpak you support the cleanup of the userspace mess that distribution maintainers have caused

Attached: flatpak_master_race.png (800x585, 1021K)

Other urls found in this thread:

flatpak.org/
youtube.com/watch?v=o_AIw9bGogo
ftp.mozilla.org/pub/firefox/releases/65.0/
docs.flatpak.org/en/latest/single-file-bundles.html
flatpak.org/setup/
flatkill.org/
flatpak-testing.readthedocs.io/en/latest/distributing-applications.html#gpg-signatures
flatpak.org/faq/
lists.freedesktop.org/archives/systemd-devel/2019-January/041959.html
en.wikipedia.org/wiki/Linus's_Law
twitter.com/SFWRedditVideos

bloat

Does it still shit out all of its config files all over your home directory? If so, dropped.

>libc.so.6: version `GLIBC_[LATEST]' not found
>blocks your path
Nope, they're following the XDG standard since a while now.

Actually, that's another advantage of Flatpak.
All applications that are installed via. Flatpak have their data and configuration files in:
~/.var/app/my.favorite.app

No more home littering.

>flatpak

Attached: 1543084553926-g.jpg (1170x836, 298K)

Not GNOME specific, KDE and Qt applications are also available.
>flatpak.org/
>Flatpak is developed by an independent community, with no lock-in to a single vendor.

I'm not sure if I like that. That's just one more dotfolder in my home dir. Why not ~/.local/bin/foo.app like it's been agreed upon? Why does every fucker have to come up with their own unique way of littering the home directory?

I don't need flatpack, because I use guix.

Attached: 1308972448871.jpg (600x500, 47K)

Its an intrusive shitty second package manager with its own sandbox rather than the sandbox of my choice. No thanks, I'll use.AppImages instead.

THIS

THIS

Assuming you install most / all applications through Flatpak, that will be the only one extra dotfolder while you reduce your overall dotfolder count for programs which don't follow the XDG specification.

Each appfolder is separated into cache, config and data, so it's the same design as XDG. AFAIK, Flatpak is developed by the same people that made the XDG specification (it was previously called xdg-app).

Red Hat is behind this.

But I already have a package manager and libraries installed?
Why should I use another even more convoluted package manager and replicate another library structure in MY HOME DIRECTORY that has subtle bugs, less features, is fragile and doesn't give me customisation or compile from source benefits
Flatpak is imo taking the worst things from Android, making them worse and bringing them to GNU/Linux
Appimage is great
Flatpak is over engineered complicated opaque shit from the same mentality that brought us gnome 3 and systemd
I hope IBM shuts down Red Hat
GNU/Linux is better off dead if it has to rely on Red Hat shit like SystemD, Gnome 3 or FUCKING Wayland

>I'll use AppImages instead
They are extremely hard to get working everywhere with the same reliability as Flatpaks.
Case in poin, I just ran FreeCAD on my system:
./FreeCAD-0.17.13541.9948ee4.glibc2.17-x86_64.appimage
FreeCAD 0.17, Libs: 0.17R13541 (Git)
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2018
##### #### ### ####
# # # # # #
# ## #### #### # # # # #
#### # # # # # # # ##### # #
# # #### #### # # # # #
# # # # # # # # # ## ## ##
# # #### #### ### # # #### ## ## ##

failed to create drawable
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
freecad: ../../src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

Image related, Flatpak version just works.

Attached: Screenshot_20190130_093259.png (1147x611, 68K)

>replicate another library structure in MY HOME DIRECTORY
Not true user, image related. You can even set up Flatpak to have multiple install locations. You can even set it up to use an external drive.
>doesn't give me customisation or compile from source benefits
You can always compile from source if you wanted to. If you're really anal about it, you could even create your own optimized SDK that you can build all available package against.
>systemD
If you have the time and patience, watch this presentation about the tragedy of systemD:
youtube.com/watch?v=o_AIw9bGogo

Attached: Screenshot_20190130_093921.png (488x113, 12K)

you forgot
>runs like shit
every notification i get from a flatpak app the desktop freezes for about 300ms

Haven't had a single one that doesn't work yet. Even that FreeCAD works on Gentoo.

If it doesn't, it's a bug the distro or AppImage can fix, not a case for installing a whole secondary ostree thing with its own sandbox and package manager.

We might as well run a VM with Sabayon or CloverOS and just all do packages for it if we wanted that.

Based. Why did guix never kick off. Would've switched to it from void by now, but I'm too much of a brainlet to learn lisp.

BTW bug tracker suggests this is probably another Ubuntu issue:

Try LIBGL_DRI3_DISABLE=true ./FreeCAD-13522.glibc2.17-x86_64.AppImage

This
Not to mention appimage is simple
>download foo
>chmod +x foo
>./foo
While flatpak has so many layers, caches, indirections, abstractions, bugs, gotchas that no one knows what's going on
They managed to create a new package manager for simple use that is more complicated and less powerful and user liberating and buggy than existing

WTF WERE THEY THINKING
FUCKING REDHAT

That's one of the reasons, almost nobody wants to deal with lisp or scheme, no matter which problem domain.

FLATPAK REDHAT FUD BTFO

>But I already have a package manager and libraries installed?
Yes, and they are the shittiest form of software distribution.
You have to rely and trust the package management team to deliver your code as fast as possible without any modification of the source code.
Plus a developer may not want to use the latest version of a library and use an old one instead, they should be able to do that, right?

It may be convenient from a (power) user perspective (you have to understand that casual users don't know what a "package manager" or a "repo" is, even if they use, say, Google Play or Microsoft Store on a daily basis, they don't know those were built around a pre-existing software concept) but overall it's a pain in the ass, the fact that I can't just take a program and have it work on whatever Linux system I want to install at any given time is simply ridiculous, AND the fact that, given the last scenario, I now have to compile whichever software just because the package maintainers can't be assed to add it to the repos is not only laughable but also infuriating.
Not to mention this only works fine for open source software, you just can't ship a Linux version of your software and feel confident it'll reliably work on every Linux system. And flatpak is trying to solve that, but I feel quite skeptical about it.

Then maybe a re-write in a more popular/better language is in order? I know if it was written mostly in bash scripts, or C, I would have stuck with it for a bit longer.

It was also kinda scary seeing all those symlinks as well desu. Symlinks are great, but having so damn many of them just felt wrong. Although I think this was just because I wasn't used to it yet.

Get a better computer.

how is it different than
ftp.mozilla.org/pub/firefox/releases/65.0/
for example

^ that shit you just extract, afaik you need to install flatpak or something first for it to work

>hey bro, you got this cool free application on your device, give it to me
With appimage you can do it (send the file)
With exe/msi you can do it (same)
With .app/dmg you can do it (same)
With play store you just send the link
With Android you can back up the pkg and send it, easy

With flatpak it's complicated, so complicated because all the support libraries are not included in the application, they have to be downloaded separately
Congrats, you rediscovered the classic package manager, only more retarded, complicated and less powerful
Flatpak is a failed idea
Use appimage

This
Fuck flatpak and fuck red hat

>it just werks
>having to do workarounds on certain distributions
pick one.

This is the direct result of not having a standardized userspace on which you can ship your software. Things break because different distros do things differently.
I don't blame AppImage for this, I wish the userspace was sane. Flatpak provides a standard userspace, which is why applications packaged on Flatpak work exactly the same on all distributions.

Attached: serveimage.jpg (487x740, 194K)

>what are Flatpak bundles
The post.

docs.flatpak.org/en/latest/single-file-bundles.html

>Congrats, you rediscovered the classic package manager, only more retarded, complicated and less powerful

pretty much, it doesnt really solve the universal app problem, but it works well as a secondary universal repo when your distro's own repo is too slow or philosophically incompatible

It works fine except on one buggy distro that apparently broke mesa. No reason to panic, just fix the bug.

Flatpak has no solution to this either, the solution they propose is pretty much inferior to even saying "okay, everyone now runs Sabayon in a VM with seamless window mode and we use that", which actually most people did and do not want to do.

But hey, you go and run Sabayon vanilla. It'll unify everyone's setup soon if everyone does it, brilliant. Plus the package manager is better.

No one wants to test their program on X distributions and fix distribution specific bugs, which is why Flatpak is better. If AppImages would have runtimes that are tested on the major distributions then they would be on the same level as Flatpaks, but they don't and even if they did, we already have Flatpak for that so I don't see the point.

Sure everyone could install that one distribution and call it a day, but that wont ever happen. VMs have a major cpu/ram overhead, which Flatpaks don't.

Flatpak is cool, needs a bit of polishing, but building for flatpak is a nightmare.
Snaps are rather easy to set up, but it supports no themeing which is sad.

>but building for flatpak is a nightmare.
I actually thought it was really easy and straight forward. What were you having issues with?

Compared to snaps, the flatpak API has too many bells and whistles

>If you have the time and patience, watch this presentation about the tragedy of systemD:
Can you tl;dr me on what his main points are? I'll watch it later but I want to know what is even the purpose

tl:dr: systemD isn't as bad as many people make it seem, though there's always room for improvement. He also goes through the common criticisms of systemD.

>>liberates your linux system from userspace insanity
There's no insanity and it saves space/ram
>>allows you to create packages that "just werk" on all supported distributions
Not in official repos = unverified
>>allows you to host your own repositories
ibid
>>can be installed offline via. bundles
Yeah because it's all fucking bloated
>>can be used to sandbox and package Windows applications that "just work" on all distributions after initial wine configuration
Wine works as is and I can sandbox with firejail already
>>making your own packages is as easy as writing a simple json manifest file
Why would I do that when mainterners can do it for me
>>by supporting flatpak you support the cleanup of the userspace mess that distribution maintainers have caused
No, you support degenerecy and windows style botnets. Linux is secure because you don't need to download shit from untrusted sources.

>There's no insanity
Have you ever tried creating an ELF that just works on all distributions? It's insanity when every distribution is defining their own userspace.
>Not in official repos = unverified
Flathub is basically the official Flatpak repository. Applications are inspected before allowed they are allowed to be distributed via. Flathub.
>Wine works as is and I can sandbox with firejail already
Sure, can you package and configure WINE with a Windows program and have it work on every distribution?
>Why would I do that when mainterners can do it for me
That line isn't aimed at you then, but if you were to package for Flatpak you could reap the benefits.

>WINE with a Windows program
that would be illegal for the applications people are interested in
no one cares about free/shareware

Just because it's illegal doesn't mean people wont do it, but it does show the power of Flatpak. Image related.

Attached: Screenshot_20190130_135654.png (1153x770, 163K)

>garbage that takes 30 seconds to launch compared to native package
no thanks

Blender starts basically like a native package on my machine, try again.

>the power of Flatpak
>cd .wine/drive-c/game/
>wine game.exe
better get gorillions of mb of flatpack amirite

blender starts starts fast anyway regardless

>>WINE with a Windows program
>that would be illegal for the applications people are interested in
Not really, the applications are licensed separately from the OS

That's snaps, not flatpak

>not separating wineprefixes per application
Do you even playonlinux bro?

Yeah, if you configure it yourself. Not everyone wants to bother with configuring WINE.
You also need to install multilib on your base system unless you chroot. With a Flatpak you would have all that 32bit junk packed away. Same thing with Steam, you can install the Steam Flatpak and you don't need to have 32bit libs installed on your base system.

and they are usually proprietary

no why should i

i don't see why multilib is an issue and there's not much to configure wine unless you want per prefix for some reason or something

Goto >and they are usually proprietary
And there is proprietary Linux and BSD software. So?

>no why should i
Different lib versions, different emulated Windows versions, uninstall consists of just removing the dedicated prefix whole

>So?
it's called piracy

>i don't see why multilib is an issue
Because there is no reason having them installed on your base system unless you're using a lot of 32 bit applications, which is most likely not the case. You only have them installed because of WINE or Steam.
>there's not much to configure wine
I've been using WINE since forever and I wish this was the case, but it isn't. You need to install the appropriate dependencies of the application which you want to run. If you're lucky, it runs out of the box. Most games require some obscure stuff, such as XACT and other weird dependencies. There's a reason why PlayOnLinux exists.

>PlayOnLinux
I've only had bad experiences with it. Most of the installer scripts just don't work.

>it runs out of the box
it has when i tried some random shit

POL is half-assed, buggy shit with many non-functional scripts. Use Lutris or Steam if you absolutely HAVE to use a GUI for managing your Windows games.

>allows you to create packages that "just werk" on all supported distributions
>applications that "just work" on all distributions after initial wine configuration.

So you really think that this redhat project (brainchild of Alexander Larsson, Principal Software Engineer at Red Hat)... would care about distros other than rhel or fedora?

Do you think they will care about "exotic archs, non-redhat distros, exotic desktops, exotic libcs".

For example exotic distros like Debian.

Attached: Screenshot_20190130_192949.png (923x269, 47K)

Flatpak works fine with debian IDK what you are trying to imply

Eternal reminder that Flatpak solves problems that only affects proprietary software.

I guess you missed the whole debian systemd maintainer stepping down because of bugs systemd upstream wont fix.

Apparently they are aggressively ignoring bugs affecting non-redhat distros like Debian.

Redhat cares about redhat stuff. If you are not using their distro, tech, and desktop (gnome) they pretty much don't care if it work or not.

Not true. If you're a single developer or in a small team working on free software, then you have better things to do than packaging software. Ever thought about who packages the less known or new projects? Either the developers themselves or no one. Having to only make one package takes a burden off small projects.

flatpaks and snaps are both DOA

Flatpak already has multiarch support: i386, x86_64, ARM, ARM64
Check out their officially supported distributions: flatpak.org/setup/
>Do you think they will care about "exotic archs, non-redhat distros, exotic desktops, exotic libcs".
Yes, because it's not just a single entity working on Flatpak and the project isn't endorsed by RedHat either. It's also in the best interest of Flatpak to work on as many platforms as possible, otherwise people would not bother using it.

>be me
>want to install gimp 2.10 because plebian stable still runs on 2.8 and no backports
>check gimp website
>find out about flatpack
>install flatpack but before using it try to check of how and who signs packages
>can't find any info about it
>search about flatpack security
>find this flatkill.org/
>Local root exploit? Minor issue!
>LOCAL ROOT EXPLOIT? MINOR ISSUE!
>still no info if packages are pgp signed or not
>Local root exploit? Minor issue!
nope, no thanks

>still no info if packages are pgp signed or not
They are.

Can you post any link that explains how flatpack package signing works?
I tried to find it and couldn't find anything.

>minor security update
I read that as: a minor update which contains security fixes. All security issues are bugs, if you make a big deal about it, then it will just attract people that are actively looking to exploit it.
You also fail to realize that Flatpak wasn't even officially released in 2017, it has only been released (1.0) in August 2018.

All software have bugs, some of them are security bugs.

Attached: minor_security_update.png (962x757, 96K)

Same things were said about systemd, now its maintainer says that they don't care about non redhat distros.

Also, it is developed by redhat employees, why do you think redhat is paying these guys working on flatpak?

Ubuntu is working on snaps, and here is what opensuse project "chairman" had to say about flatpak:


>Except of course, every single software sandbox ever designed has been breached (including the one used by flatpak already)

>And in all of my tests so far a significant proportion (25%-75% - last month it was 45%) of the flatpaks on flathub do not run ANYWHERE

>And then of course there is the lack of transparency about what is contained within a flatpak, which is less of a problem for flatpak but potentially the legal liability of users when they find themselves breaching the terms and conditions of proprietary licenses they couldn’t read before already installing the flatpak...

> url: reddit Jow ForumsopenSUSE/comments/8fq53v/why_flatpak_is_so_old_in_opensuse/dy79f95

IMVHO: other than redhat I don't see major distros supporting flatpaks.

flatpak-testing.readthedocs.io/en/latest/distributing-applications.html#gpg-signatures

>Same things were said about systemd, now its maintainer says that they don't care about non redhat distros.
Do you have a source for that? The major linux distributions all use systemd...
>And in all of my tests so far a significant proportion (25%-75% - last month it was 45%) of the flatpaks on flathub do not run ANYWHERE
9 months ago Flatpak wasn't even 1.0 and even seriously doubt his claim and he doesn't even provide any evidence. If you claim something like that, then better back that up with evidence.
I'll probably run my own tests to see if it's true, but so far I hadn't had any Flatpak application not work.

Lennart is a cuuuuuuuuuuuuuuuuuuuuuck.

Again, that is like saying that everyone just should run an upstream Sabayon VM in seamless mode, but worse since flatpak is a mess to make packages for and Sabayon is just proven Gentoo ebuilds.

Even then people weren't looking to have the Sabayon files or package manager or an extra VM. Equally nobody wants to deal with ostree, the one sandbox flatpak has, or whatever plans the flatpak devs have to use more systemd/wayland/...
I'm less pleased with the flatpak approach than I'd be with the insane idea to switch everything to Java and let any of the dependency fetching tools there (like sbt, gradle, maven, ...) handle and run the dependencies of software. At least some of that ecosystem is pleasant enough to me in terms of configs and package making and so on.

thank you

I like flatpak because it helps sandbox proprietary shitware that doesn't integrate well into the system

>Again, that is like saying that everyone just should run an upstream Sabayon VM in seamless mode
Flatpak is far from being a VM so that's a bad analogy. The better analogy would be:
Shipping your ELF with all it's dependencies, but some of those dependencies are shared with other applications.
>but worse since flatpak is a mess to make packages for
I don't see how it's a mess. I've made Flatpaks before and I found it easy and uncomplicated to work with. Granted, I have made my own Nix packages as well and they are similar, so I feel at home. Nothing wrong with you prefering ebuiids.

>Equally nobody wants to deal with ostree
But you don't deal with ostree, there's nothing special about it.
>the one sandbox flatpak has
You mostly don't deal with the sandbox, you basically specify the permissions your application needs and that's pretty much it. There are certain cases where you have to deal with it, but for the majority of the applications it's a non issue.
>or whatever plans the flatpak devs have to use more systemd/wayland/...
They removed their dependency on systemd:
flatpak.org/faq/ CTRL+F systemd
>I'm less pleased with the flatpak approach than I'd be with the insane idea to switch everything to Java
May be so, but I can't make a judgement on that as I never really used those build tools.

reddit Jow Forumslinux/comments/agna5n/debian_systemd_maintainer_steps_down_over/

lists freedesktop org/archives/systemd-devel/2019-January/041959 html

systemd dev: we will ignore bugs with exotic archs, non-redhat distros, exotic desktops...

Debian maintainer ragequits: Will stop maintaining systemd in debian for a while. What's going on is just too stupid/crazy.

Please focus on what redhat employee working on systemd has to say about bugs affecting non redhat distros.

>9 months ago Flatpak wasn't even 1.0

I only included that comment to prove the point that only one major entity is pushing flatpak, redhat.

If you are going to claim otherwise, then better back that up with evidence.

AppImage does it better

>systemd dev: we will ignore bugs with exotic archs, non-redhat distros, exotic desktops...
I think you are misunderstanding what they are talking about in the E-Mail conversation. I'll try to explain:

They are complaining about the bugs that are stacking up in systemd and that no one is fixing them and instead working on features. That guy told Poettering that this isn't how you would treat your customers, stability is more important than features. Poettering responds with, "well, we could just tell everyone else to fuck off and work on OUR own stuff (i.e RedHat specific stuff) that our customers use, as _you_ put it" and then comes the sentence which you overread:
>But I doubt that is in your interest either, is it?
Implying that he really wouldn't want them to focus on his customers, i.e RedHats customers, because that would mean everyone else gets the short end of the stick in regards to systemd bugs.

IMO nothing controversial with what he said.

>I only included that comment to prove the point that only one major entity is pushing flatpak, redhat.
How are they pushing Flatpak? They don't even endorse the project. They'd be all over it like all their other projects if they were "pushing" it.

Forgot link, read it from the very beginning.
lists.freedesktop.org/archives/systemd-devel/2019-January/041959.html

Sounds suspiciously like not "just werking"

No, it doesn't. Flatpak includes easy update management and supplements more libs. I've had some AppImages crash on Gentoo because they depended on a system library with built-in CUPS support, which I decided to disable in compilation.

If Steam was packaged as an AppImage, you would need to install 32bit libraries on your base system. Not so with the steam Flatpak available on Flathub, as it's contained to Flatpak.

I don’t understand that smug nigger’s autistic mindset. In just about every amateur VPS shit I’ve set up with Fedora, systemd got in the way of everything. Surely a widespread problem is indicative of a deadly fault in their own main fucking product.

gee, why does this post read like a shameless advertising just like the rest of the “helpful” Flatpak shilling posts in this thread?

AppImages are self contained you retard

They supposedly are, yes. Do explain to me then why an Electron application packed in an AppImage requests a system library for CUPS.
>inb4 >electron
Yeah, but the whole point of AppImages is packing up such shit so I don't have to deal with its weird dependencies, no?

Yeah, he was overly snarky in that email, which honestly doesn't help him as everyone knows him as that asshole systemd/pulseaudio guy and they would expect something as bad as that to actually happen.
>Surely a widespread problem is indicative of a deadly fault in their own main fucking product.
systemd is based on launcherd (from Mac OS), which is why it's a massive undertaking. To be fair though, they are understaffed, RedHat should hire some more people to work on fixing their shit. The idea is good, the current implementation is horrible and needs a lot of work.

They only are if the developers make them fully self contained. That's the problem I see with AppImages, it's up to the developer to make something that works everywhere. It's just too much hassle so the developers only test it on Ubuntu and call it a day.

It's really no better than manually compiling a program on an old distribution and shipping your own dependencies with it. People have been doing that with varying degrees of success, AppImages just make this a bit easier but don't actually provide a sanitized environment in which you run the program in.

if you want windows then use windows and leave the rest of us alone

Attached: serveimage (2).jpg (300x256, 14K)

installing programs containing their own dependencies and libs is a very windows thing to do. Having a package manager update a vulnerable lib fixes it for all packages at the same time. This also forces developers to fix their shit if the security update breaks their software, since everyone will complain about it. Otherwise the devs can leave their self contained software vulnerable forever and say “that’s just how it is”.

KEK
Imagine being so OBSESSED with microshit, that everything they do is now 'a very windows thing to do'
Not to mention all the "YOUR THING BAD" all over here
Absolute state of freetards

Thanks for refuting none of the points I made. So if a distro was created that mimics windows 10’s theme and wallpaper, according to you I’m “obsessed” if I call it out? You’re obviously a troll and I won’t be responding to you again.

Flatpaks share a common runtime which is maintained and security patches are backported.
>Having a package manager update a vulnerable lib fixes it for all packages at the same time.
This has the disadvantage of breaking your programs sometimes, which for me is unacceptable, especially that I primarily use my machine for work. I'd rather have a working program than it break on me, leaving me unable to work or delaying my work. I can't count the countless times programs just broke because of a damn update on a rolling release distro. This led to me just not updating at all for a longer time.
Nowadays I just install a point release / stable distribution and install my programs that need to be recent through Flatpak so shit doesn't break.
>Otherwise the devs can leave their self contained software vulnerable forever and say “that’s just how it is”.
Developers should fix their shit regardless if it breaks or not. They should be called out for their shitty practice if they ship insecure libraries.
en.wikipedia.org/wiki/Linus's_Law applies here as well.

I already have a good package manager. There's pacman, pkg, and even emerge.

Flatpak is good for phone apos, and for SELincucks (Enterprise) users

Attached: 1523573066490.jpg (1280x905, 251K)

>Nekopara Vol 3
wtf I love flatpak now?!

Ok, which one of you glorious bastards was this?

Attached: Screenshot_20190130_190818.png (1361x286, 63K)