Announcement

Collapse
No announcement yet.

Fedora 27 Approves More Features: Flatpaks, NSS, RPM 4.14, Installer

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

  • #21
    Originally posted by Candy View Post
    That's why we need the 11th way of packaing because 10 are not enough.
    flatpack or snaps (or even Nix for that matter) are not the same as others. They are self-contained and this means they are natively cross-distro. Anything you pack as flatpack will work fine on any distro where flatpack is installed.
    If you package a deb or rpm it's not like that.

    I ususally end up advising people to switch over to OSx or Windows, if they don't feel confortable the way Linux does the things.
    Yeah, never fight, always run. That's what forges great men.

    If they want a Windows or OSx behaviour on Linux then why did these people show up at all ?
    Because Linux offers other stuff you won't find on Windows/MacOS. It's not like the main attraction of Linux is the package management.

    If Linux ends up becoming yet another Windows clone (and Windows neared up towarrds Linux quite immense) then why bother using Linux at all ?
    Please explain in detail how changing/adding the package management system to something that allows third party and proprietary (bullshit) applications to work fine in all distros would make Linux a Windows clone.

    Comment


    • #22
      Originally posted by GhostOfFunkS View Post
      Forget the trolls and haters. The new distribution model is very interesting. We all know how this will go down; RH and GNOME will lead the way.

      The single varible in this game is casync. Lennart Poettering is on a mission to push low level synchronization methods into the common stack. This will likely kill IoT deployment as we know it (and snap). Ostree is also rumored to adapt.

      Also pay attention to kde. Like wayland migration they struggle to come up with a proper runtime. QT will be huge PITA. This will only get worse as new regressions are picked up..
      it is kind of sad to see that you have regressed to your old ways more or less straight away.

      Comment


      • #23
        Originally posted by Candy View Post
        After reading this Article I decided to head over to the fedora development mailinglist and started reading the thread of said conversation inside the archives. I pretty much agree with Kevin Kofler's arguments. After continuing reading said archive I noticed an increased tense and violence in the way how @redhat.com tagged individuals started attacking people who have a different - but valid - opinion.
        I noticed that as well. One person in particular was being extremely rude, I was shocked to his reaction to say the least. I am very disappointed about that.

        Comment


        • #24
          Originally posted by GhostOfFunkS View Post
          You can't reason with people like Kevin. Parts of GNOME upstream already moved to expect sandboxing.
          1) To make it clear! Since srakitnican was quoting me! It was not Kevin who I blame. In fact I was completely agreeing with him (as others have done as well). It was the harsh tone that came from the @redhat.com camp (and specially one person) whom I know from GNOME times who simply told him (in a public forum, using his employees signature) - to simply go away (and same he said to some other person with german domain in the mailing list archive). Please understand that I don't use the exact "vocabular" here. In fact you can read the archives on your own.

          2) I believe this is not the way - and has not to be the way - how you should communicate on a mailing list. Specially not if you need to worry about "customers" silently reading that list as well. We have a bunch of RHEL licenses here because we run servers and clients in an military environment. It is essential for us, that no soldier is messing around with the installations we offer. We also need to ensure that packages and updates only pass after we verified them. We need to ensure that the software still operates if they (military) are in operation. We need to avoid that some soldier shows up installing Hangman on one of these clients, playing Games during work time, rather than watching what's infront of the screen and what should be objective to the operation that the system was intended for. How interesting could it be, if these "licenses" aren't renewed and we'd flip over to a more "reasonable" solution ? In trust we believe !

          3) Not everything around GNOME is related to Fedora. There are hundrets of participants working on Fedora, and you rely on their help. This includes @redhat.com as well as Individuals. In fact a lot of military programs are written using the Motif toolkit. Not because it's so much fun, but because we and them and the customer rely on signed "contracts". Needless to mention that a few suppliers extended the Motif toolkit with with time critical (and other) Widgets that we are bound to be using. So you can be sure that we keep a close eye on what's going on within Fedora... Because it's a leading indicator to the direction that RHEL (or CentOS) will most likely go.

          Comment


          • #25
            Originally posted by GhostOfFunkS View Post
            Do you really think that inflating yourself to "important customer" has any value to others than yourself?
            I was just giving an example and I clearly believe, that Phoronix is not the right place to go deeper into exactly that type of conversation.

            Originally posted by GhostOfFunkS View Post
            Customers care about security and quality.
            Of course these are key mandatory expectations any customer has. But you also need to understand, that there are already existing infrastructure and systems operating in the economy, that simply can not be transfered into a sandboxing model. Because a) the contracts disallows this, b) the way the solution was established requires an "non sandboxing" environment, c) The software was written in the 90's and still needs to work.

            With c) - written in the 90's - I mean that the software may be re-compiled and bugfixed (on demand) but that this may also require a new quality assurance process with all employees (customer and contractor) involved. Transferring an existing 90's software into a "sandboxing" modell would probably also require a whole new project management process where the software needs to be re-architectured, parts re-written, interfaces and API adjusted etc... which comes equal to an enormous requirement that no one is willing to pay for.

            And - to make it clear - I never said that Flatpaks are evil... But it should be optional and not mandatory (something I read in the mailing list archives quite at the beginning)... As long as regular RPM's are continued to be delivered as primary packaging format, we all won't get in our ways... Flatpaks for those who believe and RPM's for those who rely on well tested and more or less well working framework...

            Btw: That's my last reply on this subject. Please respect that!

            Comment


            • #26
              Originally posted by Candy View Post
              I was just giving an example and I clearly believe, that Phoronix is not the right place to go deeper into exactly that type of conversation.
              I think it's long overdue that you become WAY more concrete!

              1) How is yum vs dnf a problem? The command line was pretty much exactly the same. Please be specific.

              2) How is sandboxing a problem? It's done in various applications already. Please be specific.

              3) In which contract and how is it worded that sandboxing is not allowed. Please be specific.

              4) In which way do you currently prevent people from installing games in their home directories and why would in future this suddenly not be possible anymore. Please be specific.

              5) In which way will Flatpaks takeover all rpms? Are you aware that Flatpaks are only intended for desktop applications? Please be _very_ specific.

              Comment


              • #27
                Originally posted by Candy View Post
                Of course these are key mandatory expectations any customer has. But you also need to understand, that there are already existing infrastructure and systems operating in the economy, that simply can not be transfered into a sandboxing model. Because a) the contracts disallows this, b) the way the solution was established requires an "non sandboxing" environment, c) The software was written in the 90's and still needs to work.
                Red Hat will make sure that its customers can run the older applications in a compatibility mode. Rpm and flatpak will coexist together for long time and it will be possible to build a flatpak directly from RPMs. The customers and the infrastructure will eventually adjust, especially when the changes bring a lot of benefits - and the sandboxing is just one of them.

                Comment


                • #28
                  Originally posted by GhostOfFunkS View Post
                  Yeah, walk away in anger without solving the problems. Just like Kevin.

                  Expect no respect from those who WILL solve the problems.
                  Because of the background you're most likely asking for highly confidential information and are lacking appropriate security clearance. Arguing further without actually trying to get one is just trolling

                  Comment


                  • #29
                    I wonder why they make a huge fuss over a single package. It's not like in the grand scope of things axing a single 32bit package makes any difference maintenence-wise – they'll keep maintaining all other 32bit packages. Seems like just declaring 32 bit kernels unsupported but keep shipping them is a middle ground.

                    Comment

                    Working...
                    X