Announcement

Collapse
No announcement yet.

Silverblue Still Aiming To Be In Great Shape By Fedora 30 Next Spring

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Silverblue Still Aiming To Be In Great Shape By Fedora 30 Next Spring

    Phoronix: Silverblue Still Aiming To Be In Great Shape By Fedora 30 Next Spring

    DevConf.US is happening this weekend in Boston, a Red Hat sponsored event for free and open-source software. Among the interesting talks is Red Hat's Matthias Clasen providing an update on the Fedora Silverblue initiative...

    http://www.phoronix.com/scan.php?pag...evConf-US-2018

  • #2
    Livestreams are here: https://www.youtube.com/channel/UCmY...Gm_kPvemBc_qwg

    Comment


    • #3
      i cant see this being Mature untill around Fedora40 at least

      Comment


      • #4
        Originally posted by Anvil View Post
        i cant see this being Mature untill around Fedora40 at least
        Technology from "this particular corner" (aka GNOME) has never been Mature. What matter is, that they stuff it inside peoples throaths fast enough. so if they say Fedora 30, then they mean it that way... Mature or not.. No one cares...

        Comment


        • #5
          lol, two kde 4 users before me

          Comment


          • #6
            It's been almost four years and I still don't understand how any of this works.

            If it's about providing applications in the form of images containing all the required dependencies, could we not have gone with AppFolders or something like macOS's DMG?

            How in the world will containers make things better? Is all this worth it just to 'segregate applications from the core operating system', seeing as how Fedora Silverblue is aiming for the containerized version of Fedora to take over Fedora Workstation?

            As it is right now, after I install a distribution, I no longer make changes to the system or installing anyhing via the package managers beyond the devel packages for things like glibc, libstdc++, gtk3, Qt5, KDE5, etc. Everything else I build my own from source into /home/<user>/External and run them as such:

            LD_LIBRARY_PATH=/home/<user>/External/lib:$LD_LIBRARY_PATH PATH=/home/<user>/External/bin:$PATH ./<name of binary>

            Will I not be able to do this anymore under a containerized version of Linux? And with OStree making / and /usr read-onlu, does that mean that I can no longer build and install kernels from kernel.org into a distribution? And what if I need to add new firmware into /usr/lib/firmware?
            Last edited by Sonadow; 08-21-2018, 03:05 AM.

            Comment


            • #7
              Originally posted by Sonadow View Post
              It's been almost four years and I still don't understand how any of this works.

              If it's about providing applications in the form of images containing all the required dependencies, could we not have gone with AppFolders or something like macOS's DMG?
              The primary delivery mechanism for applications on Silverblue will be Flatpak. We're working on a system for turning existing Fedora RPM packages into Flatpaks automatically, so in addition to third party (and direct-from-developer) sources, there will be a solid base of high-quality open source apps.



              Originally posted by Sonadow View Post
              As it is right now, after I install a distribution, I no longer make changes to the system or installing anyhing via the package managers beyond the devel packages for things like glibc, libstdc++, gtk3, Qt5, KDE5, etc. Everything else I build my own from source into /home/<user>/External and run them as such:
              You can do that, although rpm-ostree has a great feature where you can "unlock" the system and install arbitrary RPMs locally, and then these changes are merged when you update.

              However, we expect the primary workspace for installing arbitrary software will be in "pet containers" — a docker-style workspace container where you can go nuts with local changes without risking messing up the main system.


              Will I not be able to do this anymore under a containerized version of Linux? And with OStree making / and /usr read-onlu, does that mean that I can no longer build and install kernels from kernel.org into a distribution? And what if I need to add new firmware into /usr/lib/firmware?
              I'm actually not sure about installing these things without first making your own local RPMs.... I'll check with the ostree devs.

              Comment


              • #8
                Feature which will enable non-RPM updates like that: https://github.com/projectatomic/rpm-ostree/issues/1370

                Comment


                • #9
                  Originally posted by mattdm View Post

                  The primary delivery mechanism for applications on Silverblue will be Flatpak. We're working on a system for turning existing Fedora RPM packages into Flatpaks automatically, so in addition to third party (and direct-from-developer) sources, there will be a solid base of high-quality open source apps.
                  This really doesn't even start to tell me anything because I already do not use RPMs beyond the most essential devel packages (as mentioned, glibc-devel, libstdc++-devel, etc).


                  Originally posted by mattdm View Post
                  You can do that, although rpm-ostree has a great feature where you can "unlock" the system and install arbitrary RPMs locally, and then these changes are merged when you update.

                  However, we expect the primary workspace for installing arbitrary software will be in "pet containers" — a docker-style workspace container where you can go nuts with local changes without risking messing up the main system.
                  See answer above. I don't even use RPMs. I direct install all my software from source into /home/<user name>/External with make and make install




                  Originally posted by mattdm View Post
                  I'm actually not sure about installing these things without first making your own local RPMs.... I'll check with the ostree devs.
                  And as I mentioned again, I don't use RPMs. Only make and make install

                  Originally posted by mattdm View Post
                  Feature which will enable non-RPM updates like that: https://github.com/projectatomic/rpm-ostree/issues/1370
                  This is even more limiting and useless. The use case here talks about copying only one binary into the protected /usr/bin directory. When I build out-of-band drivers or system daemons (like Intel's IWD) from various sources, they usually install more than just a single file; they have the .ko file, sometimes a .dat file, some firmware files and sometimes even their own additional libraries. And the provided install script already contains the instructions on which files are to be dumped into which directory upon running make install. So a non-developer such as me is supposed to read through the INSTALL file, memorize their install paths, and then copy them one by one using some super complex instructions into rpm-ostree?

                  Is this chaos really going to be the Fedora for workstations?

                  Comment


                  • #10
                    Originally posted by Sonadow View Post

                    This really doesn't even start to tell me anything because I already do not use RPMs beyond the most essential devel packages (as mentioned, glibc-devel, libstdc++-devel, etc).


                    See answer above. I don't even use RPMs. I direct install all my software from source into /home/<user name>/External with make and make install
                    Okay, so.... good news for you. This will barely affect you at all. You can keep doing the above all you like.


                    Originally posted by Sonadow View Post


                    This is even more limiting and useless. The use case here talks about copying only one binary into the protected /usr/bin directory. When I build out-of-band drivers or system daemons (like Intel's IWD) from various sources, they usually install more than just a single file; they have the .ko file, sometimes a .dat file, some firmware files and sometimes even their own additional libraries. And the provided install script already contains the instructions on which files are to be dumped into which directory upon running make install. So a non-developer such as me is supposed to read through the INSTALL file, memorize their install paths, and then copy them one by one using some super complex instructions into rpm-ostree?

                    Errrr, I think you're misunderstanding. This feature is exactly for the use-case you describe. See https://www.mankier.com/1/ostree-admin-unlock.

                    Comment

                    Working...
                    X