Announcement

Collapse
No announcement yet.

Ubuntu 20.04 LTS To Optimize GNOME For Fast/Modern PCs, Ubuntu 20.10 For Slow/Older PCs

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

  • #31
    I don't think there's an reason to argue at this point. For the better or worse, I think it's fair to say that Daniel kickstarted an new focus on performance improvements within GNOME. There has been some friction in working together between GNOME and Canonical, but it's getting better.

    Personally, I had pretty much stopped using GNOME due to lack of performance, and only started using it again after patchsets of Daniel's patches resulted in some major improvements. To this day I'm using a patched GNOME, but I might stop doing this with GNOME 3.34.
    Last edited by brent; 25 October 2019, 04:07 PM. Reason: grammar

    Comment


    • #32
      Originally posted by Britoid View Post

      If most of the work that went into 3.34 was put into 3.30 in the state it was in, we'd end up with a shell with a ton of regressions. His work also touched on areas that was already being worked on.



      That is a gross misinterpretation of what happened and a lie.

      Only GNOME Developers (reminder, Daniel is not a GNOME dev) can attach labels to MRs, this is pretty normal and allows them to manage merge requests properly. He tried to go around this by placing labels in the title and attaching it to MRs that didn't impact performance, which put outside pressure on the GNOME maintainers to merge the request without proper scrutiny and testing, that wasn't fair.

      GNOME Shell didn't have really any meaningful way of finding the cause of performance problems until fairly recent, his MRs often relied on checking CPU usage in top and trying to lower it, which he even admits in this post was a mistake.
      One question. Is possible to contribute with acceptance tests? The real problem that I have see, is that they have a lack of tests. When I have enough tests, then I can merge a branch in days and not in a year. So I am thinking to contribute, but I have only seen unity tests in their code base and I would not like to be the first to add some acceptance tests.

      Comment


      • #33
        Originally posted by royce View Post
        Getting flak from users on gitlab isn't nice, that's for sure. But the fact a sizeable amount of people take the time to create an account to complain comes to show the level of frustration your users have with your product. You have a very poor record at listening to user's feedback, or at least at communicating to users "look people, we know this is a problem, we're working on it".
        The problem with every FOSS projects is that everyone feels entitled to flame a technical opinion, no matter how fucking nonfactual (or sometimes nonsensical) it is. How many times lots of knowledgeable people have shared here that GJS isn't a problem (or at least an important one). You would however have tons of people shitposting here that the problem with Gnome is that it uses JS, day in, day out. Gnome developers (or systemd developers, or whatever) could have a friggin online PhD program about the shortcomings of their software. People would still complaint in the most unfounded ways. I rather read a Windows user hating on windows just calling it crap that a Linux user hating on some component of his OS because the problem is that the reference counting of the symbols used to translate the move instructions to the GPU via shared objects written in OCaml is stupid (or some other nonsensical comment like that).

        DVG seems to be doing a great work and I am happy for it. But if you ever developed even a 300 lines python script, just reading at the Gitlab's discussion you can tell the guy is difficult to work with. Even more, the tone of his blog post, although incredibly interesting (and educational), is a really big PR stunt, written from the perspective that the only improvements for Gnome were the ones Canonical (i.e. him) contributed. Gnome developers had already started taking performance as a priority since, I think, 3.30. There were several articles here at Phoronix about that.

        I hope the guy can become a better fit for the community, then we'll all benefit even more. And I also hope that he (or Georges, or whoever) manage to fix the idling bugs soon.

        Comment


        • #34
          Originally posted by sabian2008 View Post

          The problem with every FOSS projects is that everyone feels entitled to flame a technical opinion, no matter how fucking nonfactual (or sometimes nonsensical) it is. <...> Gnome developers (or systemd developers, or whatever) could have a friggin online PhD program about the shortcomings of their software. People would still complaint in the most unfounded ways. I rather read a Windows user hating on windows just calling it crap that a Linux user hating on some component of his OS because the problem is that the reference counting of the symbols used to translate the move instructions to the GPU via shared objects written in OCaml is stupid (or some other nonsensical comment like that).
          Yup. This. Almost as bad as the “I’m entitled to choice” cancer.

          Comment


          • #35
            I'm just glad to see Canonical working on optimizing GNOME over the next year instead of duplicating their labor working on Unity.

            Comment


            • #36
              Originally posted by sabian2008 View Post
              The problem with every FOSS projects is that everyone feels entitled to flame a technical opinion, no matter how fucking nonfactual (or sometimes nonsensical) it is. How many times lots of knowledgeable people have shared here that GJS isn't a problem (or at least an important one).
              See below, there was a huge issue just last year in Gnome 3 with garbage collection due to not properly doing refcounts on objects.

              Originally posted by sabian2008 View Post
              DVG seems to be doing a great work and I am happy for it. But if you ever developed even a 300 lines python script, just reading at the Gitlab's discussion you can tell the guy is difficult to work with. Even more, the tone of his blog post, although incredibly interesting (and educational), is a really big PR stunt, written from the perspective that the only improvements for Gnome were the ones Canonical (i.e. him) contributed. Gnome developers had already started taking performance as a priority since, I think, 3.30. There were several articles here at Phoronix about that.
              Actually I believe it was 3.28 which was when Canonical switched to Gnome for 18.04 and the resulting large increase in users immediately exposed that there was a huge desktop killing memory leak related to javascript use in gnome-shell, of which Phoronix has an article.

              So the performance issues have been being worked on for a while but its mostly due to the large increase in users, and complaints, due to Ubuntu's switching from Unity to Gnome 3.

              Comment


              • #37
                Originally posted by DoMiNeLa10 View Post

                You probably need at least a 5GHz modern CPU to have GNOME run at bearable speeds anyway. If Cannonical wants people to hate GNU/Linux, using GNOME is a great way to accomplish their questionable goals.
                A 2007 Sony VIAO Core Duo laptop with 4 GB RAM and a 2005 LG Tablet PC run Gnome Shell smoothly as long not too many heavy 3D applications got involved due to the limit of hardware.

                Comment


                • #38
                  Originally posted by finalzone View Post

                  A 2007 Sony VIAO Core Duo laptop with 4 GB RAM and a 2005 LG Tablet PC run Gnome Shell smoothly as long not too many heavy 3D applications got involved due to the limit of hardware.
                  Meanwhile, I can reassure you that i5-8400 with GNOME is laggy even when no applications are running. Animations drop frames all the time, which is distracting and looks bad.

                  Comment


                  • #39
                    just imagine how much could've been done if canonical was doing this from the start

                    Comment


                    • #40
                      Not sure how they do it, but Intel's Clear Linux it's on top of most benchmarks and not like Canonical, who want to separate users on LTSs and ordinary Ubuntu releases.

                      Comment

                      Working...
                      X