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

[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]

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

[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]

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.

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

[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!

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

[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

[Anvil]

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.

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

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.

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.

you got that right, but i'd try about 10 years.

[Candy]

flatpak is a Mess,

Pretty much spot on. It just took me a while to figure out, where flatpak installs all the stuff.

cd /var/lib/flatpak/

If you look inside the "repo" directory structure (that was installed before GIMP) I instantly started crying. That's - pardon my wording - the biggest mess I've seen.

I will let one of my scripts run this night and have the system revert to the last backup that I made a few days ago. Sorry but No. This is not even close to what and how Apple or Google bundles their Apps for download.

cd /var/lib/flatpak/runtime/org.gnome.Platform/x86_64/3.28/f78d82e0dbe1bb8ed67e4f626d1d6428a7f21b1e3105e66783 7acf9054f9b753/files
ls -l

and you run away.