Announcement

Collapse
No announcement yet.

Eight-Way BSD & Linux OS Comparison

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

  • #31
    Originally posted by droidhacker View Post
    Isn't it about time for you to get banned for being a stupid motherfucker?
    Seems to me that compared to other similar AGED distros, it won some, and lost some. Overall, about the same. THAT IS PERFORMANCE ONLY, which is far from the only consideration when selecting a distro. You know that some people choose their distribution philosophically, don't you? Their (canonical's) lack of upstream contribution is a great reason to avoid them. Also their crappy UI, and other attempts to break compatibility with GNU/Linux.
    Concerned about the compatibility thing too. It's in a distro's interest to fracture it so that software compiled and distributed for them will be exclusive to them and force Linux users to have to use their distro, like Android for example. Ubuntu with their Mir display server makes me think oh great, now I have to make my software compatible with Xorg (if it doesn't get completely replaced by Wayland), Wayland (if it becomes popular), and Mir? I'm all for improving Linux, but if there are no standards in place that the improvements are using then it is just fracturing. As if Linux needs MORE software ecosystem earthquakes at this point. Linux hasn't even solved universal software distribution issues yet so that a healthy ecosystem can exist. Way too many packages out there with big dependency requirement lists that you're on your own to find.

    What distro do you think is better, anyway? Mint is based on a lot of Ubuntu's stuff but may dump Mir when it comes. Debian seems to be a better choice but I thought it still had a lot of usability issues. Fedora seems slick but there are always problems with it being too bleeding edge and I feel like an alpha tester for Red Hat when I use it a lot of times, while other times it seems fairly stable. RPMs also seem much slower than DEBs to install.

    Comment


    • #32
      Originally posted by eLDST0RM View Post
      regarding ext4 being insecure:



      I don't get it. The link is to some tests that show that performance on a database improves if you turn off barriers on ext4. I don't understand how you can take that fact and use it to conclude that ext4 is inherently unsafe.
      You are right. What I meant is that you can make ext4 insanely fast at the cost of having an absolutely unreliable file system. Compared to the overhead implied by zfs or btrfs, this would provide Linux an unfair advantage. What I'm saying is that, ideally, to really compare operating system performance, you should use the same file system, or at least the same CLASS of file system.

      Comment


      • #33
        Originally posted by oleid View Post
        The only thing he might be referring to is the "nobarrier" option. Yet, even then his statement makes no sense.
        Indeed, the nobarrier option. Sorry for using the word 'insecure'; what I wanted to say is that you can make ext4 ridiculously fast, and hence the benchmarks doesn't really compare operating system's performance: i.e benchmarks are useless.

        Comment


        • #34
          Originally posted by Sergio View Post
          Indeed, the nobarrier option. Sorry for using the word 'insecure'; what I wanted to say is that you can make ext4 ridiculously fast, and hence the benchmarks doesn't really compare operating system's performance: i.e benchmarks are useless.
          That's a non sequitor. Many Linux filesystems have knobs to toggle some of the performance/safety characteristics including Btrfs. Benchmarks are done with the default safer options usually and any reasonable ones must publish the tweaks done to improve performance if any.

          Comment


          • #35
            Originally posted by RahulSundaram View Post
            That's a non sequitor. Many Linux filesystems have knobs to toggle some of the performance/safety characteristics including Btrfs. Benchmarks are done with the default safer options usually and any reasonable ones must publish the tweaks done to improve performance if any.
            Well, I think benchmarks comparing operating systems should use the same file system or, if not possible, at least the same class of file system.

            Comment


            • #36
              I wonder if you didn't change something during your install Michael. I'm using Mageia 3, fresh install and the cpu governor is set to ondemand.
              Code:
              [root@localhost ~]# cpupower frequency-info
              analyzing CPU 0:
                driver: acpi-cpufreq
                CPUs which run at the same hardware frequency: 0
                CPUs which need to have their frequency coordinated by software: 0
                hardware limits: 850 MHz - 1.70 GHz
                available frequency steps: 1.70 GHz, 1.36 GHz, 850 MHz
                available cpufreq governors: ondemand, userspace, performance
                current policy: frequency should be within 850 MHz and 1.70 GHz.
                                The governor "ondemand" may decide which speed to use
                                within this range.
                current CPU frequency is 850 MHz (asserted by call to hardware).
                boost state support:
                  Supported: no
                  Active: no

              Comment


              • #37
                Originally posted by Sergio View Post
                Why use crappy and insecure (and hence extremely fast) ext4?
                Just because it doesn't have all the data integrity features of file systems like btrfs or zfs doesn't make it 'crappy and insecure', that is just pure BS.

                Everything is a balance, I as a desktop user are perfectly happy with the performance/features/safety of a filesystem like ext4, as such I see no reason to use a more resource demanding file system like btrfs or zfs, in short, for my needs I don't think their additional features make up for the increased resource use and loss of performance, YMMV.

                This is also mirrored in all other Linux distros I've come across, as they (if they default to anything) default to ext4. Given that PC-BSD is a desktop oriented 'distro' it seems as overkill to default to ZFS.

                Originally posted by Sergio View Post
                Well, I think benchmarks comparing operating systems should use the same file system or, if not possible, at least the same class of file system.
                I'd agree if this was a file system comparison, but it was a 'out-if-the-box' comparison between a bunch of Linux distros and a BSD distro.

                Obviously you have to view the results with that in mind, there's no doubt that each and every one of the tested systems could be tweaked to run faster for certain tests than in their default settings.

                Comment


                • #38
                  Originally posted by XorEaxEax View Post
                  Given that PC-BSD is a desktop oriented 'distro' it seems as overkill to default to ZFS.

                  I've always felt that desktop-oriented BSD distributions use ZFS as the default system 'just because they can'.

                  Think about it: the user gets all the benefits of ZFS in the default install and the performance hit is typically not noticeable to all but the most perceptive users.

                  Comment


                  • #39
                    Originally posted by Yfrwlf View Post
                    RPMs also seem much slower than DEBs to install.
                    What make you jump to that conclusion? Have you tried pure RPM and DPKG commands to validate your points or you are comparing YUM with APT?
                    Yum does more stuff than APT in single command (behaviour can be modified via yum.conf) imaking speed advantage moot.

                    Comment


                    • #40
                      Originally posted by finalzone View Post
                      What make you jump to that conclusion? Have you tried pure RPM and DPKG commands to validate your points or you are comparing YUM with APT?
                      Yum does more stuff than APT in single command (behaviour can be modified via yum.conf) imaking speed advantage moot.
                      I was comparing yum vs. apt, and if yum does extra things that help then great, but from my experience I've had package breakage happen more often on systems using yum so I'm not sure what as a user yum gives me over apt. The breakage could just be due to poor repo maintenance in Fedora but it doesn't help increase my belief in Yum/RPM.

                      All I know is Fedora takes a lot longer to install updates than Ubuntu even if they are small updates, and that doesn't seem to be beneficial.

                      Comment


                      • #41
                        Originally posted by Yfrwlf View Post
                        I was comparing yum vs. apt, and if yum does extra things that help then great, but from my experience I've had package breakage happen more often on systems using yum so I'm not sure what as a user yum gives me over apt.
                        All I know is Fedora takes a lot longer to install updates than Ubuntu even if they are small updates, and it doesn't seem to benefit me as a user.
                        Default behaviour of yum is to check if there is newer dependencies, conflicts and update before the install. You can speed the process by enabling cache via "yum makecache" first then do the installation via "yum -C install". Apt default behaviour requires manual checking i.e. it cannot do all process at once without separate command.
                        Note that a newer version of you temporarily called dnf expected to be ready for Fedora 22 will use libsolv library which should speed up the process.

                        Comment


                        • #42
                          Originally posted by XorEaxEax View Post
                          Just because it doesn't have all the data integrity features of file systems like btrfs or zfs doesn't make it 'crappy and insecure', that is just pure BS.

                          Everything is a balance, I as a desktop user are perfectly happy with the performance/features/safety of a filesystem like ext4, as such I see no reason to use a more resource demanding file system like btrfs or zfs, in short, for my needs I don't think their additional features make up for the increased resource use and loss of performance, YMMV.

                          This is also mirrored in all other Linux distros I've come across, as they (if they default to anything) default to ext4. Given that PC-BSD is a desktop oriented 'distro' it seems as overkill to default to ZFS.


                          I'd agree if this was a file system comparison, but it was a 'out-if-the-box' comparison between a bunch of Linux distros and a BSD distro.

                          Obviously you have to view the results with that in mind, there's no doubt that each and every one of the tested systems could be tweaked to run faster for certain tests than in their default settings.
                          Yes, you are right... I guess what I wanted to question is the interpretation of the results; indeed, because it is NOT a file system benchmark, it is misleading to use two completely different kinds of beasts, as are ZFS and HAMMER on one side, and ext4 on the other.
                          Yes, I know the whole out-of-the-box thing, but I'd be more interested in the following:
                          1. If the intention is to compare OS performance, then use the same file system. This is specially true now that ZFS for Linux is considered for production use.
                          2. If not possible to use the same file system, at least use the same class of file systems (ZFS, HAMMER, BTRFS are in the same class; UFS and EXT2FS are in the same class).

                          Comment


                          • #43
                            Originally posted by finalzone View Post
                            Default behaviour of yum is to check if there is newer dependencies, conflicts and update before the install. You can speed the process by enabling cache via "yum makecache" first then do the installation via "yum -C install". Apt default behaviour requires manual checking i.e. it cannot do all process at once without separate command.
                            Note that a newer version of you temporarily called dnf expected to be ready for Fedora 22 will use libsolv library which should speed up the process.
                            Great, sounds like something that should be run by cron periodically by default then, but regardless so far my experiences have been poor.

                            I could care less about these package managers anyway as they do not provide a cross-distro packaging solution for easy Linux program sharing which has only hurt the Linux software ecosystem. Linux has a horrible reputation for terrible and confusing software installation for any out-of-repo program for a reason.

                            Maybe PackageKit, AppStream, and Listaller will come to the rescue though if Zero Install doesn't see more uptake.

                            Comment


                            • #44
                              Originally posted by Yfrwlf View Post
                              Great, sounds like something that should be run by cron periodically by default then, but regardless so far my experiences have been poor.
                              Which version of Fedora did you use at that time? I both use F18 and F19 without problem related to yum. To enable that run with cron, simply install yum-cron.

                              Maybe PackageKit, AppStream, and Listaller will come to the rescue though if Zero Install doesn't see more uptake.
                              You can try using pkcon command from PackageKit

                              Comment


                              • #45
                                Originally posted by Sergio View Post
                                it is misleading to use two completely different kinds of beasts, as are ZFS and HAMMER on one side, and ext4 on the other.
                                Well they are the defaults as such I can't complain given this is what the test was based upon.

                                On the other hand I personally find broad unfocused comparisons such as this one to be rather pointless, worthwhile comparisons are those were you focus on one particular feature and then make sure that the surrounding environment match up as much as possible so as to interfere as little as possible with the final results.

                                That's not really the 'Phoronix' way of benchmarking though, ambiguousness often seems to be the rule by which these tests are devised.

                                Comment

                                Working...
                                X