No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    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.


    • #52
      Originally posted by calc View Post
      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.
      Last edited by Danielsan; 03 May 2018, 01:37 AM.


      • #53
        Originally posted by starshipeleven View Post
        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.


        • #54
          Originally posted by Candy View Post
          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
          Originally posted by Candy View Post
          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


          • #55
            Originally posted by nanonyme View Post
            These runtimes are not maintained indefinitely
            it is not like there is some planned obsolescence built into runtimes


            • #56
              Originally posted by Candy View Post
              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.
              Last edited by pal666; 03 May 2018, 09:11 AM.


              • #57
                Originally posted by Anvil View Post
                i got rid of linux.
                keep us posted


                • #58
                  Originally posted by Candy View Post
                  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?


                  • #59
                    Originally posted by Candy View Post
                    They all test the stuff, sign the QS working sheet and deliver the final product to the customer.
                    do they test gimp? on how many distros? flatpaked gimp has to be tested once and it will work anywhere.


                    • #60
                      Originally posted by Candy View Post
                      No offense, but we have a different understanding of "clean", "maintainability", "customer requirements" and "QS".
                      obviously. you think some people with windows background have to maintain third party software on all possible combinations of disros and package sets. we think that software vendor has to maintain its blessed build which always works everywhere