Announcement

Collapse
No announcement yet.

Fenrus Linux: A Distro For Performance, Developers

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

  • #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; 25 March 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