Announcement

Collapse
No announcement yet.

A Five-Way Linux Distribution Comparison In 2010

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

  • #61
    Originally posted by Michael View Post
    That's what's usually done and then there are the people complaining that I ignore those running older hardware, so once in a while it's switched up.
    You seem to ignore the real issue with that approach, and that is that there will always be someone complaining if you do it like that. If there is always someone complaining maybe it's not the audience that has a problem... Maybe it's time to introduce more color variation in the graphs and do more complete reviews with more systems and configurations.

    Comment


    • #62
      The all distro story is just crap.
      I'd like to build me own LFS, but hell, it takes too long for nothing, so i stick whit a distro (DISTRO = a package manager, some repos and some config files). I don't really trust this benchmarks. If it's the same source code, than is just a matter of default configs (so the mainstream is to blame) or kernel compile-time configuration (so copy and paste the config files from ubuntu and compile your own kernel).

      Nobody should be proud of a distro or be hangry at it. Actually, for the sanity of our beloved OS, we should all hope that one day there will be a single one big distro thus avoiding this waste of time/bandwidth and human brains.

      Comment


      • #63
        Originally posted by devius View Post
        Maybe it's time to introduce more color variation in the graphs and do more complete reviews with more systems and configurations.
        Indeed. I can try x264 tonight, I have an Arch install on a 64-bit machine (core i7 860), a Mandriva cooker x86_64 (both kernels have not the same schedulers) and a livecd of Suse 64 bits.

        Comment


        • #64
          wow, Arch got owned so bad! (had to say it again )

          The truth is that many Arch users install using the standard wiki explaining howto, and don't deviate (much) from that. Since most people install their OS in the same way they get it, it really does mean that Arch under performs, no matter what you say.

          These benchmarks prove to me, time after time again, that you might as well install a distro with fast/easy graphical installation and then config it to whatever you like... you'll end up with a much faster system.

          Comment


          • #65
            Originally posted by Cape View Post
            The all distro story is just crap.
            I'd like to build me own LFS, but hell, it takes too long for nothing, so i stick whit a distro (DISTRO = a package manager, some repos and some config files). I don't really trust this benchmarks. If it's the same source code, than is just a matter of default configs (so the mainstream is to blame) or kernel compile-time configuration (so copy and paste the config files from ubuntu and compile your own kernel).

            Nobody should be proud of a distro or be hangry at it. Actually, for the sanity of our beloved OS, we should all hope that one day there will be a single one big distro thus avoiding this waste of time/bandwidth and human brains.

            I agree with your sentiment but the choice of distros is a good thing as it allows maximum avenues to be explored without brand poisoning.

            I think a more productive approach would be for the heads of projects to actively show the communities how to collaborate by example. This is something canonical could do much better on.

            Comment


            • #66
              Originally posted by yotambien View Post
              Woah, I didn't expect Arch to be that slow. I'll make sure I stay away from it.

              X D
              If you're unthinking one then better stay away from it.

              Comment


              • #67
                wow.

                lets take a logical look at this:

                what affects the speed at which a task is done?

                - the program in use
                - the kernel (simplified, but its a good general category)
                - any applicable configuration
                - any other system service/program that may be running during testing

                so lets examine where this issue could stem from.

                - Regressions within the Kernel
                - Regressions within the Program
                - Regressions within the Compiler
                - Any distro specific patches applied to the program (unlikely, arch uses vanilla packages)
                - Improper configuration


                So what does this tell us?

                Excluding the unlikely possibility that all other distro's incorporated a patch that isn't accepted upstream (yeah, right)

                Either:

                The specific version(s) of the packages used have a regression that caused the problem, in which case, it would be the exact same behaviour on any other distro if you upgraded it to that version, built with that compiler. This could be veiwed as a drawback of using a rolling release distro, but in all honesty if something starts dying horribly after an upgrade, you can always downgrade again. If this is the case it hardly is any reason to call arch "slow" because different regressions pop up all the time - this is just a simple fact of how things work.

                Or:

                The system was improperly configured in some way, or excessive system services were installed. as configuration/package installation of arch is largely left up to the user, this would fall under user error.


                I don't have any desire to jump to an unsubstanciated conclusion and state that Micheal isn't capable of properly configuring arch, but on the other side of the issue, if you are going to test something that -has- no default configuration, then you should probably provide the information on how you -did- configure it. also considering packages change from day to day, the specific version of every package tested is probably a good thing to include as well.

                Devoid of this information the results from arch are, well, entirely meaningless.

                though honestly, all you are accomplishing in a distro showdown is benchmarking different kernels/filesystems/compilers/program versions/configurations/patches in a random assortment, which, to me, does not seem to be a very sceintific test.

                as someone else said, i think limiting benchmarks to a single component at a time would provide much more meaningful information.

                Comment


                • #68
                  @Mr Elendig

                  Don't waste your time speaking to an idiot flaming with another one. It's probably some kind of way to feel better or to have a good time for a moment. The one mentioned his lovely Novell, because it produces his lovely mono and another one shows his anti Linux attitude as always.

                  Comment


                  • #69
                    I'd just like to take this opportunity to say that I think Arch is okay.

                    Comment


                    • #70
                      One slight, but obvious mistake in the article:
                      With our first Bullet Physics Engine test, Arch Linux came out ahead of the four other Linux distributions but it was only faster by the slowest distribution in this test (openSUSE 11.3 RC1) by 5%. The other four Linux distributions performed close to the same speed.
                      Looking at the graph it's obvious that it's Ubuntu 10.04 that is the slowest and not OpenSUSE.

                      About all the flame wars: when pressing the "comments and discussion" button, I always think: "so, why is this test invalid?" And I always get an answer. So I believe that it's not the tests, but the public that are having issues here.

                      But yea, the idea of Linux Olympics is rather interesting indeed

                      Comment

                      Working...
                      X