Announcement

Collapse
No announcement yet.

Fenrus Linux: A Distro For Performance, Developers

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

  • #16
    Originally posted by korrode View Post
    'zomg i do stuff a little different that takes liek 20 seconds to change an existing distro to do... shit, better release my own distro'
    Fenrus Linux is described as having a novel packaging workflow and update mechanism, which one really can't change in about 20 seconds on an existing distro.

    Comment


    • #17
      Originally posted by korrode View Post
      i still think this whole 'zomg i do stuff a little different that takes liek 20 seconds to change an existing distro to do... shit, better release my own distro' stuff is unproductive at best.
      I disagree. I think this kind of diversity is what makes Linux great. If the ideas are working out well and take only 20 seconds to implement, then other distros will adopt them quickly.

      Comment


      • #18
        Originally posted by Vadi View Post
        How are the benchmarks to be read?
        for each test, the "best of the rest" score is used as an index (e.g 100%). the score for Fenrus Linux is then indexed against this score and a delta percentage comes out.
        (the scores are always "higher is better", for those PTS tests where Lower-Is-Better, the result is inverted)

        each "point" on the graph is a release of the distro (rolling release model)

        Comment


        • #19
          Originally posted by chithanh View Post
          I disagree. I think this kind of diversity is what makes Linux great. If the ideas are working out well and take only 20 seconds to implement, then other distros will adopt them quickly.
          The innovations that Fenrus Linux attempts could have been done by modifying Gentoo via an overlay. With that said, I have nothing against people trying to do things differently and I wish Fenrus all the best.

          Comment


          • #20
            Originally posted by randomizer View Post
            This person is an upstream developer. I think we can cut him some slack and let him run his own pet project if he feels like it.
            He can do whatever he likes. I don't expect he'd be discouraged by my comments on this forum. I wouldn't be, in his position.


            Originally posted by moilami View Post
            Thanks for sharing?

            <large image>
            No worries, glad you enjoyed my post.


            Originally posted by Ex-Cyber View Post
            Fenrus Linux is described as having a novel packaging workflow and update mechanism, which one really can't change in about 20 seconds on an existing distro.
            Good. I hope it does actually offer new distinct features, I hope my comments don't apply to it, like they do so many others.


            Originally posted by chithanh View Post
            I disagree. I think this kind of diversity is what makes Linux great. If the ideas are working out well and take only 20 seconds to implement, then other distros will adopt them quickly.
            And hopefully merge where & when reasonably applicable.

            ---

            I'm sorry if some people don't agree with my opinion that increased unification and tighter resource pooling would be a good thing, but that is my view.
            Understand too; I don't at all suggest all distros combine. Some are simply too different and have outright incompatible philosophies.

            Comment


            • #21
              You have to hover the graphs to see the little dots that, I take it, are fenrus's builds.


              The test results are impressive but the lack of information is holding me back from downloading.


              Can you load a live session into ram? does it have an installer?


              just how primitive is it?


              In ubuntu 13.04 I have been fucking with upstart and systemv and I managed to shut off some services that I don't use like CUPS and bluetooth, that and deleting the lenses makes a night and day difference. when idle I'm at 280 mb and 3% cpu.

              Make sure you build a nice little GUI that let's you shut off services like cups etc...

              BTW the name should have been Fenrir, what the hell is a fenrus anyway?


              google search edit: Oh wow a gay videogame character ... way to spell 'professional distro' there buddy
              Last edited by Pallidus; 03-25-2013, 11:16 AM.

              Comment


              • #22
                Originally posted by ryao View Post
                The innovations that Fenrus Linux attempts could have been done by modifying Gentoo via an overlay. With that said, I have nothing against people trying to do things differently and I wish Fenrus all the best.
                hmm. Gentoo wouldn't be the first distro to come to my mind while developing high efficient software update technology
                (doing binary delta's of only those files that changed, solving the depsolving issue etc etc)

                Comment


                • #23
                  Originally posted by fenrus View Post
                  hmm. Gentoo wouldn't be the first distro to come to my mind while developing high efficient software update technology
                  (doing binary delta's of only those files that changed, solving the depsolving issue etc etc)
                  You might want to look at Sabayon Linux, which is Gentoo based. Its package management runs on top of Gentoo's package manager. Gentoo Portage is used to generate binary packages, which are then repackaged for use in Sabayon. The Sabayon package manager takes care of installation, updates, etcetera. The abstraction afforded by this would permit implementation of things like binary deltas and a solution to the "depsolving issue", without the heavy lifting required to maintain tens of thousands of packages.

                  I suspect that the Sabayon developers would be interested in innovations in this area, especially since they are well positioned to benefit from them.

                  Comment


                  • #24
                    Originally posted by ryao View Post
                    You might want to look at Sabayon Linux, which is Gentoo based. Its package management runs on top of Gentoo's package manager. Gentoo Portage is used to generate binary packages, which are then repackaged for use in Sabayon. The Sabayon package manager takes care of installation, updates, etcetera. The abstraction afforded by this would permit implementation of things like binary deltas and a solution to the "depsolving issue", without the heavy lifting required to maintain tens of thousands of packages.

                    I suspect that the Sabayon developers would be interested in innovations in this area, especially since they are well positioned to benefit from them.
                    Equo can be configured to use deltas too

                    Comment


                    • #25
                      Originally posted by fenrus View Post
                      hmm. Gentoo wouldn't be the first distro to come to my mind while developing high efficient software update technology
                      (doing binary delta's of only those files that changed, solving the depsolving issue etc etc)
                      Well, Fedora (and openSUSE as well I think) use Delta RPM's by default which are binary diffs. Can you explain what you have in mind that is different?

                      Comment


                      • #26
                        Originally posted by fenrus View Post
                        for each test, the "best of the rest" score is used as an index (e.g 100%). the score for Fenrus Linux is then indexed against this score and a delta percentage comes out.
                        (the scores are always "higher is better", for those PTS tests where Lower-Is-Better, the result is inverted)

                        each "point" on the graph is a release of the distro (rolling release model)
                        I also think that you need to explain it better on the actual page.

                        I still don't understand how the delta is being calculated - the first plot shows systemd-boot-kernel, suggesting that the "best of the rest" line is 100%, but systemd-boot-total shows "delta (%)" varying from below 6000% to above 7000%. I assume you are plotting here some absolute values and that "% delta" is incorrectly labelled? Or is there a problem with the test results?

                        If you just want to plot % change from other distributions, then why is the delta offset for many of the plots 0% rather than 100%? e.g. in the plot for system-decompress-xz/zlib the offset is from 0 (delta), but the other compression graphs are all plotted with the base at 100 (absolute %, not delta). Assuming that the variation is not going to be huge, it would seems to be better to show the +/- % delta from 0 for all graphs.

                        Comment


                        • #27
                          Originally posted by RahulSundaram View Post
                          Well, Fedora (and openSUSE as well I think) use Delta RPM's by default which are binary diffs. Can you explain what you have in mind that is different?

                          (I presented about this at Plumbers last year, several key RH guys were there and we talked about it afterwards as well)

                          Delta RPMs don't really work well. In that for small changes, they're 100x less efficient than is possible/what should happen.
                          xdelta isn't all that great for delta's, and the whole mechanism is not efficient in that the RPM needs to be reassembled and then full installed on the target system.
                          So lets say I fix one word in a French translation, every OTHER file from the package now hits the disk 2 times; and this is independent of the network traffic size
                          (which is also pretty bad, not just because the delta is big, but also because the OS metadata is big and doesn't really get delta'd)

                          Comment


                          • #28
                            Originally posted by chrisb View Post
                            I also think that you need to explain it better on the actual page.

                            I still don't understand how the delta is being calculated - the first plot shows systemd-boot-kernel, suggesting that the "best of the rest" line is 100%, but systemd-boot-total shows "delta (%)" varying from below 6000% to above 7000%. I assume you are plotting here some absolute values and that "% delta" is incorrectly labelled? Or is there a problem with the test results?

                            If you just want to plot % change from other distributions, then why is the delta offset for many of the plots 0% rather than 100%? e.g. in the plot for system-decompress-xz/zlib the offset is from 0 (delta), but the other compression graphs are all plotted with the base at 100 (absolute %, not delta). Assuming that the variation is not going to be huge, it would seems to be better to show the +/- % delta from 0 for all graphs.
                            yeah I'll try to clarify the page tonight, clearly it's not well done right/clear enough right now; thanks for the feedback.

                            let me give a specific (but made up) example.
                            Say some test gives frames-per-second (e.g. a higher-is-better test).
                            And lets say, Fedora 17 is the best-of-the-rest at 50 frames per second.

                            If Fenrus Linux would also get 100 FPS, the score would thus be 200%, however, for the purpose of showing a delta, 100% is subtracted (hence the "delta") and the score will 'only' be "100%" in the graph.
                            If Fenrus Linux would get 25 FPS, the score would be 50%, but the delta would be 50% - 100% = -50% in the graph.

                            Comment


                            • #29
                              Originally posted by fenrus View Post
                              (I presented about this at Plumbers last year, several key RH guys were there and we talked about it afterwards as well)
                              Do you happen to have a link to any video of this talk?

                              Comment


                              • #30
                                Originally posted by fenrus View Post
                                If Fenrus Linux would also get 100 FPS, the score would thus be 200%, however, for the purpose of showing a delta, 100% is subtracted (hence the "delta") and the score will 'only' be "100%" in the graph.
                                If Fenrus Linux would get 25 FPS, the score would be 50%, but the delta would be 50% - 100% = -50% in the graph.
                                Are the little hover-dots the test results on Fenrus as someone suggested above? If so, how come the plotted line is smooth? ie. hover on systemd-boot-kernel and you see one single performance jump around Feb 18th or so, but the curve rises up gradually over 2 weeks as if performance was slowly changing every day. It looks like a line of best fit? The problem with that is it doesn't show change very well - in these kind of metrics change tends to be instant rather than gradual.

                                So systemd-boot-userspace really is 300 times faster on Fenrus? And systemd-boot-total is 70 times faster?

                                Which distributions are you currently testing? Would it be possible to do some graphs directly comparing them, eg. plotting Fenrus vs Ubuntu vs Fedora vs Gentoo, so we can see what the "best of the rest" actually is, and which distributions are best for performance?

                                I am curious if there really are significant differences and potential gains to be made, because most benchmarks I have seen suggest there is little real difference between competing modern distros. But this could be because the benchmarks are designed to be tests of the hardware (bound by CPU, GPU, disk IO etc.) rather than tests of distributions.

                                Comment

                                Working...
                                X