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.
Team Silverblue Succeeds Fedora Atomic Workstation, Aims To Be In Great Shape By F30
Collapse
X
-
Originally posted by calc View PostWell 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.Last edited by Danielsan; 03 May 2018, 01:37 AM.
Comment
-
-
Originally posted by starshipeleven View PostPlease 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).
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.
Comment
-
-
Originally posted by Candy View PostAprox 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...
Originally posted by Candy View PostThe 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.
Comment
-
-
Originally posted by Candy View PostIf 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.Last edited by pal666; 03 May 2018, 09:11 AM.
Comment
-
-
Originally posted by Candy View PostNo offense, but we have a different understanding of "clean", "maintainability", "customer requirements" and "QS".
Comment
-
Comment