Team Silverblue Succeeds Fedora Atomic Workstation, Aims To Be In Great Shape By F30

[Anvil]

Same here.


Go and have a look how ridicolous this flatpak stuff is. The command line magic is more horrid than using "dnf install gimp" or "apt-get install gimp".

Here an example:

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.gimp.GIMP

or

flatpak install https://flathub.org/repo/appstream/o...IMP.flatpakref

to launch it

flatpak run org.gimp.GIMP

That's how everyone memorizes installing Gimp using flatpak.

I think I'll stay with "dnf install gimp" or "apt-get install gimp" and click on a simple Icon, once it's installed. It's even more secure than relying on a flatpak with outdated and hostile old libraries that comes bundled with it.

flatpak is a Mess, its one of the reasons i got rid of linux. i may go back to it but it maynot be Fedora. its a good way to keep New users away from Linux this Flatpak Mess. im sure Microsoft will be rubbing there Hands together

[starshipeleven]

There are huge advantages if there is one unique package (and package format) to generate an operating runtime package that works on almost all distributions. No need for dozens of spec files, no need for descriptive apt (however they build their stuff). One unique set of permission and permission flags and overall consistency through all the packages. This all set by good rules that every package needs to follow.

I'm unsure of what you're saying here.

Different applications need access to different things to work. If you want to make a single spec file for all then you have a so permissive one that it defies the purpose.

Theoretically the application developer(s) would be the ones writing down this spec file for packaging their application with flatpack, similarly to how they are the ones that write the distro-agnostic systemd units for their services, but you know people, maybe they don't want, they don't care, or whatever, and then third parties do so.

Rather than brewing their own set of "spec" files for building packages, everyone can work on a unified meta-file (or spec file) to build the final runtime.

Again I'm unsure of what you're trying to say. Flathub (the bigger flatpack repo around) has and enforces rules about how the applications must be sandboxed and packaged. https://github.com/flathub/flathub/w...p-Requirements

The thing is - the overall acceptance.

For most practical people it's going to be a no-brainer, you go here https://flathub.org/apps or on your favourite application's site, or in your distro's flatpack-aware "store" (aka GNOME Store or Discover for KDE, don't know about others), you click and install your application, which is then kept updated and working regardless of the rest of the distro.

Right now it still looks quite controversal to me.

I don't see anything controversial, Flatpack is just very immature, you're looking at a product that needs 2-3 years still. It's already usable to some extent, but it's not in its final form, far from it.

Theming the applications so they don't look out of place was added very recently https://www.linuxuprising.com/2018/0...e-correct.html , Portals (kinda like Android, popups that ask the user if he wants to grant a sandboxed application access to a specific resource outside of its sandbox, temporarily or not) are still mostly a to-do https://github.com/flatpak/flatpak/wiki/Portals
And so on and so forth.

[Candy]

sudo flatpak install flathub org.gimp.GIMP
Required runtime for org.gimp.GIMP/x86_64/stable (org.gnome.Platform/x86_64/3.28) is not installed, searching...
Found in remote flathub, do you want to install it? [y/n]: y
Installing: org.gnome.Platform/x86_64/3.28 from flathub
[####################] Downloading: 218.2 MB/217.5 MB (1.2 MB/s)

Wait ? 217.5 MB GNOME ? I thought I will be getting GIMP only ? GTK2 and GTK3 are already installed on my system. And nice that it downloads 218.2 MB of the 217.5 MB mentioned Must be lost bytes.

[####################] 10 delta parts, 76 loose fetched; 213101 KiB transferred
Installing: org.freedesktop.Platform.ffmpeg/x86_64/1.6 from flathub
[####################] 1 delta parts, 2 loose fetched; 2652 KiB transferred in 2
Installing: org.gnome.Platform.Locale/x86_64/3.28 from flathub
[####################] Downloading files: 118/119 22.1 MB (1.8 MB/s)

Now it installs 119.2 MB of locales...

Installing: org.gimp.GIMP/x86_64/stable from flathub
[############ ] Downloading: 28.3 MB/50.9 MB (2.2 MB/s)

and finally 50.9 MB of GIMP

But why ? I mean. If flatpak would test the existence of GTK2 and GTK3 and only download the required subset of packages or instruct dnf to install the missing subset. But please not the entire GNOME Platform.

Sorry but this is definately not what I wanted. I think there is still some more work needed to get me convinced. I really thought giving it a try. But No! Thanks!

[gnufreex]

I think Red Hat needs to buy Invisible Things Lab, and port QubesOS from Xen to KVM. And then they can also have VMs and not only containers in this Sliverblue. With VT-d passtrough.

[starshipeleven]

That's not... entirely true. A Flatpak targets a specific version of a runtime. These runtimes are not maintained indefinitely (not clear at this point how long they will be) and porting your Flatpak to a newer version of a runtime requires development effort. The upsides is you don't need to do that often and you can be sure your Flatpak won't break while using the exact same runtime version

Would having an unmaintained runtime be an actual issue? Because afaik they could just leave them sit there in the repo to let people run legacy applications and just correct vulnerabilities in the packaging if such is discovered in the future.

[starshipeleven]

You are missing one of my previous comments. Most modern distros have automated processes for generating (e.g.) RPM packages. But then. Even flatpacks need to be made... By people who are working for free... Their own choice by the way...

Lol you have no fucking idea. The issue isn't creating a rpm/deb/tar.gz/whatever, that's just an archive format.

The issue is making sure that all software compiles and runs properly with the system libs at version X + patches Y and Z, plus all other customizations you might have in the distro.

This adds a fuckton of QA and time wasted on the part of maintainers to track down why component A craps out when you update one of its dependencies. And if they don't catch that in the beta phase then the user will get the bug introduced by packaging the application.

With flatpack the developer himself decides and integrates the libs his packaged application will use, which will likely be the ones he developed and tested it with, did QA or whatever.

[starshipeleven]

Aprox 10 years ago every of them said "It's up to the package maintainers (e.g. distro) to make packages. We only provide the sources!".

Sources for that statement?

I see many developers ranting about how distros are frustrating them by shipping older or broken versions of their programs, spread bug reports all over the place with their own bug trackers, and so on and so forth.

some random rants (
https://criticalindirection.com/2015...xapppackaging/
http://freshmeat.sourceforge.net/art...x-applications (this is from 2003 btw)

This is a known kde contributor
https://pointieststick.wordpress.com...re-of-distros/

And this is the rant from Martin Graesslin, a well-known KDE dev
https://blog.martin-graesslin.com/bl...s-the-quality/

Also Torvalds has the same opinion https://www.youtube.com/watch?v=5PmH...utu.be&t=5m40s

[Candy]

In the meantime, just like with Debian packages and apt-sources, people making the packages themselves can (should) also release the "sources" of the package, aka the build manifest (its configuration) so people can build their own flatpack to his spec after they checked for bullshit permissions.

This makes sense - Yes.

There are huge advantages if there is one unique package (and package format) to generate an operating runtime package that works on almost all distributions. No need for dozens of spec files, no need for descriptive apt (however they build their stuff). One unique set of permission and permission flags and overall consistency through all the packages. This all set by good rules that every package needs to follow.

The same way when we look in apk files (Android) or their counterparts for Apple. If you look inside their "packages", then you see a unified and unique structure going through all the different software they offer in their repositories (e.g. app store or pay store).

Rather than brewing their own set of "spec" files for building packages, everyone can work on a unified meta-file (or spec file) to build the final runtime.

The thing is - the overall acceptance. For example: It took me quite some time to get along with systemd. But nowadays I find it quite trivial to use (not that I have to maintain large chunks of systems anyways). But I see the benefit of masking, unmasking, enabling and disabling multiple services by just one underlaying "thing", rather than messing around with dozens of scripts. Even if there are pros and cons.

Same is valid for letting go mplayer in favor to mpv (after all the years, since mplayer has shown up).

Maybe I can see myself getting along with flatpaks one day. But then, people and changes are always a difficult thing. Let's first see how the overall acceptance within the Linux community is. Right now it still looks quite controversal to me.

[starshipeleven]

not, if they move gimp out of repo to flatpak
and nothing prevents flatpaked apps to be run via simple icon or be installed via simple gnome software

Btw, I can install flatpacked applications with Discover (the Gnome Software equivalent for KDE Plasma) on OpenSUSE Tumbleweed the same way. Doubleclicking on a flatpack app link on the website or on a flatpack file opens Discover to install it.

[starshipeleven]

Technically wearing a space suit before leaving the house is also more secure than leaving the house by wearing normal clothes.

Technically speaking, no. A space suit's 2 main goals (keeping you in a pressurized environment AND distributing heat properly) are unnecessary in a pressurized environment like on the planet surface. Sure it would also provide decent NBC protection, but that's not anywhere near its main goal.

NBC suit/gear is not anywhere near as clunky, unwieldy, heavy deathtrap while actually providing the same level of protection a space suit would provide on a planet's surface. And this is closer to what Flatpack is.

Who says that the locking down sandboxing system is without errors ?

If a malicious attacker wants to hack a target without sandboxing he does not need to find out how to defeat the sandboxing. If there is also sandboxing, then the attacker doesn't just need to hack the program but also break the sandboxing.

The task is made harder, maybe not worth it, possibly impossible for long periods of time between the discovery of vulnerabilities.

Someone could release a faked flatpak somewhere on the net and the user installs it. The fake can be anything. Keylogger, Passwordlogger, Hidden advertisments and so on.

This is unrelated to my point. I said that compartmentalizing applications make them more secure, not that Flatpak applications are automatically trustworthy.

I would really like that (to work like Android where applications are actually untrusted and sandboxed by default), I hope that they will add something along these lines as it matures, because otherwise we are still going to have to rely on trusted repositories (like flathub for example) that enforce sane rules on flatpacks they offer.

In the meantime, just like with Debian packages and apt-sources, people making the packages themselves can (should) also release the "sources" of the package, aka the build manifest (its configuration) so people can build their own flatpack to his spec after they checked for bullshit permissions.

The main difference is that the build manifest isn't source code, it is human-readable even for non-developers. It's not hard to look into the build manifest for bullshit permissions, see here an example/explanation https://ramsdenj.com/2018/03/26/pack...h-flatpak.html