Announcement

Collapse
No announcement yet.

The Fastest Linux Distributions For Web Browsing - Firefox + Chrome Benchmarks On Eight Distros

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

  • #11
    Originally posted by andyprough View Post

    It should not be benchmarked for performance. Default configuration includes btrfs instead of much faster EXT4, balloo running constantly on KDE and interfering with performance as it does an initial index of the entire system, and a CPU governor on top of it.

    Why are these the defaults? openSUSE is the testing ground for SUSE enterprise linux, for which btrfs is an important technology, and which has a goal of stability despite a wide range of technologies. I'm assuming that's the reason why.

    Anyone who wanted performance would not run it this way. They would install it on EXT4, turn off balloo indexing, and switch the CPU governor to "performance" mode. Among other things. Personally, I would run Mate for a better performance instead of KDE. Also, I get better performance when I compile my own kernels.
    Well, for damn sure if Suse was concerned about stability they definitely wouldn't have chosen btrfs as a default. Obviously stability is their very last concern.

    Comment


    • #12
      Originally posted by shmerl View Post
      Is anyone working on adding VAAPI support to Firefox?
      Don't think so. The VA-API bug is blocked on OpenGL accelerated layers, which isn't enabled due to the (formerly?) abysmal driver situation on Linux. Luckily, accelerated layers is a requirement for WebRender which is slowly rolling out to Windows builds (Beta with recent graphics chips/drivers), Android/Mac/Linux coming later. Linux Nightly just got initial support for the downloadable graphics driver blocklist, so Mozilla should be able to block bad graphics drivers more granular now, allowing gradual roll-out of WebRender there as well.

      Comment


      • #13
        Originally posted by johnp117 View Post
        Don't think so. The VA-API bug is blocked on OpenGL accelerated layers, which isn't enabled due to the (formerly?) abysmal driver situation on Linux. Luckily, accelerated layers is a requirement for WebRender which is slowly rolling out to Windows builds (Beta with recent graphics chips/drivers), Android/Mac/Linux coming later. Linux Nightly just got initial support for the downloadable graphics driver blocklist, so Mozilla should be able to block bad graphics drivers more granular now, allowing gradual roll-out of WebRender there as well.
        Yeah, I was suspecting that no one is working on it, waiting for WebRender switch first. I'm running Firefox beta with WebRender enabled for a while already (amdgpu/radeonsi), and it works fine.

        Comment


        • #14
          Originally posted by duby229 View Post
          Well, for damn sure if Suse was concerned about stability they definitely wouldn't have chosen btrfs as a default. Obviously stability is their very last concern.
          Depends on how important snapshots and other btrfs features are to your customers. SUSE has been promoting btrfs for years now with a fair degree of success.

          Comment


          • #15
            Originally posted by andyprough View Post

            Depends on how important snapshots and other btrfs features are to your customers. SUSE has been promoting btrfs for years now with a fair degree of success.
            That is, just until you start wondering why you're getting out of free space errors when you can plainly see hundreds of gigs being unused...... And that's it's first and still unfixed flaw....

            Comment


            • #16
              Originally posted by duby229 View Post
              That is, just until you start wondering why you're getting out of free space errors when you can plainly see hundreds of gigs being unused...... And that's it's first and still unfixed flaw....
              Well, if you are going to use btrfs, it's usually desirable that you know HOW to use btrfs. I mean, avoiding that problem is pretty much something you would learn about on your first install. And it's not a flaw - it's got to do with how you allocate space and set up snapshots and so forth. btrfs will be more than happy to make and keep endless snapshots taking up all your space if that's what you tell it to do.

              Comment


              • #17
                Originally posted by andyprough View Post

                Well, if you are going to use btrfs, it's usually desirable that you know HOW to use btrfs. I mean, avoiding that problem is pretty much something you would learn about on your first install. And it's not a flaw - it's got to do with how you allocate space and set up snapshots and so forth. btrfs will be more than happy to make and keep endless snapshots taking up all your space if that's what you tell it to do.
                Which, of course, triggers btrfs's second -still unfixed- flaw. The balance command will cause corruption.

                EDIT: Besides, I always felt like it should balance automatically. It should be incorporated straight into the filesystem driver. Period.
                Last edited by duby229; 29 March 2019, 02:18 PM.

                Comment


                • #18
                  Originally posted by duby229 View Post
                  Which, of course, triggers btrfs's second -still unfixed- flaw. The balance command will cause corruption.

                  EDIT: Besides, I always felt like it should balance automatically. It should be incorporated straight into the filesystem driver. Period.
                  Anytime you move millions of data blocks around, the snapshots that previously pointed at those blocks run the risk of corruption. A good backup strategy (not just snapshots) would be in order prior to playing around with btrfs balance.

                  EDIT: And I don't think you would want btrfs balance running automatically. Or at least I wouldn't. I'd want to be running very close control over the system if I decided to balance.

                  Comment


                  • #19
                    After having used Chrome for ~8 years, I thought now would be a good time to switch back to Firefox. However, Firefox on Linux scrolls terribly (Arch Linux). I get there are fixes for smooth scrolling, but why in 2019 doesn't Firefox on Linux have good defaults that don't require tweaking.

                    Comment


                    • #20
                      Classic Linux community. Even when unrelated, someone will still complain about something they don't use and likely don't develop for.

                      Anyway, the difference between Debian Buster and Ubuntu seems interesting. Because Buster and Ubuntu 18.10 shouldn't be that different, right? Just slightly more recent.

                      SyXbiT I am not sure what the greatest difficulty for Firefox is wrt Linux. Maybe they forgot about it, or maybe there is too much politics needed to get things like hardware acceleration for Linux enabled by default. And no way to get hardware accelerated video decoding either..
                      Last edited by Compartmentalisation; 29 March 2019, 02:46 PM.

                      Comment

                      Working...
                      X