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

[pal666]

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

and you run away.

why would you do that? what is your concern?

[pal666]

i got rid of linux.

keep us posted

[pal666]

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.

it is impossible to do. how flatpak is going to make sure that your gtk2 and gtk3 are of correct versions? i guess it can check signatures but you can bet your wouldn't match. and when you will upgrade/remove system libs, flatpak would have to immediately download missing pieces. too complex for imaginary benefits. entire gnome platform is only needed once for all versions of gimps, libreoffices, etc. and on fully flatpacked system maybe you will not have system gtk2 and gtk3 and only have them inside gnome platform. and storage is cheap anyway.

[pal666]

These runtimes are not maintained indefinitely

it is not like there is some planned obsolescence built into runtimes

[pal666]

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!". Now you encourage them to wear the shoes by creating flatpaks...

now we make it trivial for them to create flatpaks. because there are too many disros and too few packagers

The only valid point here - which I fully agree with - is a base packaging format over all distributions. But this is more a wet dream by someone. Different distros have different philosophies. That's why there are so many different distros.

nobody is preventing distros from having philosophies. they can apply their philosophies to all packages they have manpower to make. but when they lack manpower surely it is better to install flatpack, than build some git checkout manually

[Candy]

Please explain why flatpack is worse or even different than industry-standards like say docker, which basically does the exact same thing (but is far less flexible and wastes more space imho), i.e. shipping an application in its own fake root directory tree, with its own dependencies (other applications/libraries in fake root trees).

I don't know anything about Docker (besides having heard of the name) and their "industry standard".

1) But I also never heard about Docker telling me that everyone will be using Docker and that regular RPM or DEB Packages is going away in favour of Docker. They most likely do their own business in their own niche and don't get in the way with others. Here on Phoronix I was told (during a nomal conversation) that Gimp regular Packages will likely to go away in favour to flatpaks. This caught my attention.

2) When I read "Jan 1970" in one of my directories, then I usually contact the Admin and telling him to fix his clock.

3) I know how chroot environments work. My daily work is related with chroot environments. The only difference: No containers and the structures look cleaner.

4) I do understand that that you need some sort of clean binary compatible foundation to base all compiled programs on. But not "This". When I install a Gimp flatpack then I would at least expect that it installs the smallest amount of subset there is to get Gimp running. Nothing more!

Flatpak installs GNOME as core "root" or "chroot" system. The first thing it does!

Now I rightfully ask myself how "baobab" (is it called that way) or "gnome-maps" (I memorize having read that name, from yesterdays experiment) is related to the execution of Gimp If you want to set up a base chroot system for the user then go with regular packages. Glibc, Coreutils, Bash, ... Glib2, GTK2+ along the chain to get exactly Gimp runing. I would want to see something like "resolving dependency chain for gimp.flatpak" "installing glibc.flatpak, coreutils.flatpak, bash.flatpak ... gimp.flatpak". I don't want to have or see things, that are not related in any ways to the execution of Gimp. Same applies for other flatpaks.

Imagine your customer tells you to strip down RHEL as much as possible. Remove all icons from the desktop. Install some sort of role based SSO (single sign on). Have the military software set up and running.

... and later, somewhere in Afghanistan ...

I find a soldier playing "sudoku" that came "mandatory" bundled as part of a "chroot" environment with flatpak, during military operation. This is an absolute no-go. All the symlinks around the flatpak eco-system that tries to simulate a different type of "organisation" opens doors for possible problems to show up in the future.

5) When I have to read, that someone writes, "we will replace Fedora Workstation with Fedora Flatpak Workstation" (so everyone understand it) one close day, then this will get my attention. This is pure egoistic nonsense that ignores all the Fedora, RHEL and CentOS installations running on thousands of virtual machines and "high critical" (well not Fedora: except the development machines the developers use) real time operating military environments. In industrial environments and corporates.

6) Fedora is an early indicator where RHEL might be going one day. Flatpaks are an indicator where everything (for whatever reasons) may be going. Even if Fedora Servers are not used in "high critical" environments, we still throw an eye on Fedora.

7) Same applied for the bunch of "associate" kids that were let play on DNF as a "drop in replacement" for YUM, which caused our entire very own infrastructure to break down for many months because of internal and external incompatibilities. We had a crutch running for around 1 year. Luckely this is solved now.

Guess how long industry is going to get along with this ? Everything what happens inside Fedora is an indicator of what *may* happen with RHEL. Guess how long customers are going to follow this road.

[Danielsan]

Well flatpaks and snaps will solve one thing, the fact that Linux is lighter on memory usage than Windows. With all those different versions of runtime you'll need a server amount of memory just to run a regular desktop.

This is true, however Flatpak respect to snap and appimage tries to share how much libraries it can between applications, so in case two application use the same runtime those are going to share it.

[calc]

Well flatpaks and snaps will solve one thing, the fact that Linux is lighter on memory usage than Windows. With all those different versions of runtime you'll need a server amount of memory just to run a regular desktop.

[Anvil]

Yeah, Microsoft will love to get their hands on that juicy less-than-1% of the desktop market while it's getting raped on the embedded and server and HPC markets.


your butt. Is it hurting much?

Microsoft are making the Money on the Desktop, , linux will only make money on Servers, thats bout all.

[starshipeleven]

No offense, but we have a different understanding of "clean", "maintainability", "customer requirements" and "QS". We have people to feed and these people come all with different skills from different architectures (most of them Windows). We create, deliver and hope no-one calls up because something blews up. Once delivered we continue with the next project or any contracted services. Day on, day off. Trying to stay in competition within this rough segment. There is no time for "experiments". It's easier to isolate a RHEL or Fedora installation via VMWare and throw it away in case it blows up, than dealing with this. It's also less expensive in time and costs.

No offense! There may be a marked for this. And the marked will come for sure. But not in an - by my standards - imaginable close future. Clearly not with Fedora 30.

Did you copy-paste some random corporate description from a pamphlet or something? Quit this crap, this isn't explaining anything.

Please explain why flatpack is worse or even different than industry-standards like say docker, which basically does the exact same thing (but is far less flexible and wastes more space imho), i.e. shipping an application in its own fake root directory tree, with its own dependencies (other applications/libraries in fake root trees).