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

  • #51
    Originally posted by duby229 View Post

    A good backup startegy is absolutely required if you use btrfs, you -will- need to restore from them sooner rather than later.
    I've used btrfs for about 7 years, and never had filesystem corruption. During this period, I've mainly run on work-supplied laptops with shitty Intel GPUs, where hard lockups are not unexpected. I can tell you have a bee in your bonnet over btrfs. Maybe you were bitten by the RAID bug? Maybe you just used the FS without putting much thought or researching into it? Anyway, I've used it personally for years, and seen companies use it ( in particular the snapshotting feature ) for years, and never seen corruption. User error?

    Comment


    • #52
      Originally posted by dkasak View Post

      I've used btrfs for about 7 years, and never had filesystem corruption. During this period, I've mainly run on work-supplied laptops with shitty Intel GPUs, where hard lockups are not unexpected. I can tell you have a bee in your bonnet over btrfs. Maybe you were bitten by the RAID bug? Maybe you just used the FS without putting much thought or researching into it? Anyway, I've used it personally for years, and seen companies use it ( in particular the snapshotting feature ) for years, and never seen corruption. User error?
      It's more like "many and various design flaws". Many of which are hardcoded into the disk layout and can't be fixed.

      I know it's obvious I don't like btrfs, but who would?

      EDIT: There are several reasons why the balance command can corrupt it. The first and most likely reason is undetected checksum errors get balanced and every napshot becomes corrupted. That happens constantly and most, if not all, btrfs filesystems in production most definitely currently have such undetected checksum errors.

      EDIT: Which, btw, is the root cause for the RAID 5 corruption problems, exactly the same flaw causes both symptoms, and it is unfixable because of the disk layout and COW.

      EDIT: The logic used in the RAID 5 mode is actually capable of detecting the corruption that exists. It doesn't mean the corruption isn't there when your not using RAID 5. in fact it is there, there just isn't any mechanism in the filesytem driver or tools to detect it. If that corruption occurs in a txt file or a png or something, you'll never notice it.

      Last edited by duby229; 30 March 2019, 12:03 AM.

      Comment


      • #53
        aOriginally posted by dkasakView Post
        I've used btrfs for about 7 years, and never had filesystem corruption. During this period, I've mainly run on work-supplied laptops with shitty Intel GPUs, where hard lockups are not unexpected. I can tell you have a bee in your bonnet over btrfs. Maybe you were bitten by the RAID bug? Maybe you just used the FS without putting much thought or researching into it? Anyway, I've used it personally for years, and seen companies use it ( in particular the snapshotting feature ) for years, and never seen corruption.
        Agreed, I've known quite a few opensuse users who swear by btrfs snapshots, and run systems stably for years at a time.

        Comment


        • #54
          Originally posted by andyprough View Post

          Agreed, I've known quite a few opensuse users who swear by btrfs snapshots, and run systems stably for years at a time.
          Or at least at minimum they believe they do....

          Comment


          • #55
            The Fastest Linux Distributions For Web Browsing - Firefox + Chrome Benchmarks On Eight Distros
            The answer is none of them, both the browsers are a bad joke.

            They don't have hardware acceleration disabled by a user config option, but at build time. You have to enable the options, and apply patches to get it to work. So even if you use something like --ignore-gpu-blacklist you still won't get video acceleration on Hulu, Netflix, YouTube, etc in 2019.

            Comment


            • #56
              Originally posted by debianxfce View Post

              https://www.cnet.com/how-to/3-ways-t...s-performance/

              " There is some debate on whether hardware acceleration helps or harmsperformance"

              Enabling that option causes troubles often.
              In addition to the type of acceleration they discuss in that page I'm talking about hardware video acceleration, ie va-api. Without it playing a H264/HEVC/etc video eats nearly all CPU, causes fans to spin at full speed, etc. Chrome/Chromium still does not support video acceleration under Linux even when checking various experimental boxes in config. It needs a patch that has existed for many years, at least since 2014, but is still not applied. Yet it works just fine under ChromeOS, it seems they have vested interest in not having it work under regular Linux.

              The same general situation applies to Firefox as well.

              The Firefox bug is here:
              Last edited by calc; 30 March 2019, 02:23 AM.

              Comment


              • #57
                I made myself a script to compile Chromium(would compile Firefox but it is harder) from Git with -mtune=native, -march=native, LTO + PGO and it runs significantly(the difference in the startup times is night and day) faster than any browser I could use - Chromium compiles all of its dependencies, so you basically optimize the entire stack, the dependencies + the browser itself.

                Comment


                • #58
                  debian gives eye enojoyable all rounded performance.

                  Comment


                  • #59
                    Originally posted by calc View Post
                    It needs a patch that has existed for many years, at least since 2014, but is still not applied. Yet it works just fine under ChromeOS, it seems they have vested interest in not having it work under regular Linux.
                    It seems there's a mesa bug blocking the patches as it causes heavy corruption on AMD cards: https://bugs.freedesktop.org/show_bug.cgi?id=106490

                    Comment


                    • #60
                      Originally posted by V10lator View Post
                      It seems there's a mesa bug blocking the patches as it causes heavy corruption on AMD cards: https://bugs.freedesktop.org/show_bug.cgi?id=106490
                      Not a particularly good reason to leave the code out altogether instead of just hiding it behind an experimental flag like they do with other things. And could blacklist the AMD cards on top of it like they do for other graphics issues.

                      Comment

                      Working...
                      X