Announcement

Collapse
No announcement yet.

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

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

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

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

    Red Hat's Matthias Clasen has announced to the Fedora Council members that the Fedora Atomic Workstation is now known as "Team Silverblue", while the name is a bit awkward and abstract, they do have plans for making Silverblue into great shape for the Fedora 29 and 30 cycles...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I had to read the article several times to even figure out what they're doing. This doesn't bode well for a rebranding. So basically they've renamed Atomic Workstation to this ridiculous Team Silverblue in hopes of making it more attractive to users or potential participating developers... So something somewhat descriptive (programmers know what atomic means in context) becomes totally non-descriptive and vague.

    I get what the project is trying to do, separate the applications via flatpak and other container projects from the base OS in hopes of a more stable environment for user space development. They aren't the only Linux project working on moving to containers rather than traditional package management trees. Regardless of the politics of containers versus packages debates, this brand change does not help me understand what the product is. The name sounds more like a team of developers working on yet another ill-fated attempt to make a hybrid UI that tries to please everyone, but instead irritates nearly everyone like Bluecurve back around the Fedora Core and RH v9 days.

    Comment


    • #3
      Not a fan of rebranding exercises in general, but Silverblue is a whole lot less awkward and abstract than say, "Ubuntu". U-whatnow?

      Comment


      • #4
        Originally posted by stormcrow View Post
        I had to read the article several times to even figure out what they're doing.
        Same here.

        Originally posted by stormcrow View Post
        I get what the project is trying to do, separate the applications via flatpak and other container projects from the base OS [...]
        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.

        Comment


        • #5
          I'm not sure how I feel about flatpak et al. I'm a big fan of Linux packaging, I use logitechmediaserver from the AUR, and I'm confident that when the source gets updated, some random guy from Poland or somewhere has my back, and I get the update.

          People moan about Linux packaging, saying they release an update, and it's x months until anyone actually gets to use it. But I think the people who maintain packages in repos are doing the Lords work, I can't speak highly enough of them. I run Arch because I want the latest and greatest, somebody who doesn't care about that might run Debian stable and that's their choice. Somebody else might pick something in between.

          I suspect I may be misunderstanding all this stuff, and I probably need to look into it more. But as far as I'm concerned, packaging is fine as it is. Happy to hear opposing arguments if I'm being stupid/ignorant though.

          Comment


          • #6
            Originally posted by stormcrow View Post
            Regardless of the politics of containers versus packages debates, this brand change does not help me understand what the product is.
            From my understanding the product will remain Fedora Workstation.

            I see this as a project name to fold the features of Atomic Workstation into the main Worsktation product (or alternatively, rename Atomic Workstation to Workstation and the current workstation to something else.)

            Before doing this they want to iron out any issues (Fedora infrastructure does not provide flatpaks yet) that ordinary developers may face after the switch.
            Last edited by You-; 02 May 2018, 12:09 PM.

            Comment


            • #7
              Originally posted by Candy View Post
              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.
              The way I installed gimp flatpak was to go to the flathub website, click the install button, let the Software app do its thing.

              (When I searched for the Gimp in software, the flathub version wasnt listed.)

              Then I ran it by clicking the icon.

              I think for most people that is a reasonable - especially if it showed up in Gnome Software.

              Comment


              • #8
                Originally posted by Candy View Post
                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.
                I really hope that distro maintainers will use *pak* only for very, very few applications. It did more sense when the most important applications and libraries lacked even basic features, this is not true anymore, at least for the applications I use most. I can wait for new versions of LibreOffice, Octave, Krita and few others to show up on regular repositories.

                Comment


                • #9
                  Originally posted by You- View Post
                  The way I installed gimp flatpak was to go to the flathub website, click the install button, let the Software app do its thing
                  I can use yumex or dnfdragora or gnome-software to install the appropriate rpm or deb package from the correct repositories (or even via terminal=. Knowing that the source is reliable, the packages tested, updated, maintained etc. I don't see any personal benefit in using flatpaks. Most of the package management these days are automate processes anyways. So the argument for maintainers overloaded with work isn't true.

                  But then: As long as Fedora keeps producing rpm packages side by side I am more than fine if there are a small amount of people who like to dream about an isolated Apple or Google like eco-system. I also don't see that to change anytime soon or later in the future. There are plenty of package maintainers (owners) on the Fedora devel list that stand 100% behind rpm. For the sake of operability of Fedora, I don't see anyone who want's to turn these badly needed maintainers away.

                  Comment


                  • #10
                    Originally posted by kaprikawn View Post
                    I'm not sure how I feel about flatpak et al. I'm a big fan of Linux packaging, I use logitechmediaserver from the AUR, and I'm confident that when the source gets updated, some random guy from Poland or somewhere has my back, and I get the update.

                    People moan about Linux packaging, saying they release an update, and it's x months until anyone actually gets to use it. But I think the people who maintain packages in repos are doing the Lords work, I can't speak highly enough of them. I run Arch because I want the latest and greatest, somebody who doesn't care about that might run Debian stable and that's their choice. Somebody else might pick something in between.

                    I suspect I may be misunderstanding all this stuff, and I probably need to look into it more. But as far as I'm concerned, packaging is fine as it is. Happy to hear opposing arguments if I'm being stupid/ignorant though.
                    It is though highly pleasant to compile against Flatpak. You have a known target set of libraries called a runtime and you have an SDK for building against those libraries in a reproducible and consistent way. Runtimes are widely shared and strongly versioned allowing API and ABI stability

                    Comment

                    Working...
                    X