Announcement

Collapse
No announcement yet.

GNOME Might Need To Crack Down On Their JavaScript Extensions

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

  • GNOME Might Need To Crack Down On Their JavaScript Extensions

    Phoronix: GNOME Might Need To Crack Down On Their JavaScript Extensions

    Longtime GNOME developer and Red Hat engineering manager Jiri Eischmann has looked at recent Fedora Workstation crashes and other problems happening with the GNOME Shell and the most common denominator is problems caused by the GNOME Shell extensions written in JavaScript...

    http://www.phoronix.com/scan.php?pag...-Exts-Problems

  • #2
    I wonder why did they have a poor implementation of JavaScript in the first place...

    disable GNOME Shell extensions when the shell crashes.
    The shell still crashes though, causing loss of work.

    decoupling GNOME Shell and Mutter to more gracefully handle crashes and to be able to restore clients.
    This is the best option, to be honest... We want reliable.

    GNOME developers may need to consider limiting the API exposed to these JavaScript extensions
    What about some of the extensions that really need to re-layout the shell to make it usable?
    Last edited by tildearrow; 07-31-2018, 12:36 PM.

    Comment


    • #3
      JavaScript is much the best performing and most stable interpreted language. Much much faster than python or ruby etc.
      the solution is to fix the bugs.

      Comment


      • #4
        JavaScript is not so much of an awful idea on its own. I don't know what implementation they're using in GNOME but most of them are decently fast and memory usage is not too awful, especially not when you have to deal with something as simple as a shell extension. I don't like the language and I hate anything related to web tech, but it's hardly really going to matter here.
        The big bonus with JS here is that many people know how to write in JS and that it isn't hard to learn either because it's so widly used.

        If shell extensions manage to crash GNOME, it's not really the language at fault, but the way bindings are done. From what I'm seeing from this dev's blog, they're absolute insanity if your focus is on stability. I bet it's trivial to take the whole shell down with a few lines of JS, just because you have such a huge amount of control over the shell.
        If the design is similar to what I think it is, it's surely because it was at the time the easiest solution to let extensions be really extensive while not being a nightmare to implement.

        Seeing the comments on that blog post, it looks like many of those crashes could certainly be prevented by hardening the code to things that could as well be warnings.

        Comment


        • #5
          Originally posted by tildearrow

          The speed isn't in the language. It's in the implementation.
          Only partly true. Strictly speaking, a JS implementation could always generate code of an as good quality as a modern C++ compiler.
          But when you get a language without strong typing and abstracting things a lot, its implementations will be slower.

          Comment


          • #6
            It's not only exclusive to GNOME. I've seen extension crashing KDE quite a bit, they are using JS derivative.
            They need to do some sandboxing, easier said than done, I know.

            Comment


            • #7
              Originally posted by tildearrow View Post

              "Decoupling GNOME Shell and Mutter to more gracefully handle crashes and to be able to restore clients."
              This is the best option, to be honest... We want reliable.
              The questuion is, why is even done in the first place? Like seriously, why they wouldn't let window-manager to handle all of... ehm... window managing... things like Cinnamon (with Muffin) or Pantheon (with gala) does? Both are forks of mutter 3.x, and both prove it is possible (and even better). I guess because no one would use Shell then, for example, I would use flashback session if mutter handles all of the window managing things (alt-tab, overview, virtual spaces etc.), it already does handle animations..., Gnome-Flashback on mutter (instead of metacity) would be much faster than Gnome-Shell and very functional, there is no justification for not doing so in my opinion.

              Comment


              • #8
                We don't want widely distributed software to be developed under "accessible" conditions. We want snide, snarky, arrogant assholes writing this stuff. Then we can have a high standard of quality.

                Comment


                • #9
                  Originally posted by leipero View Post
                  The questuion is, why is even done in the first place? Like seriously, why they wouldn't let window-manager to handle all of... ehm... window managing... things like Cinnamon (with Muffin) or Pantheon (with gala) does?
                  There used to be some retard working in their PR department who was arguing for brand identification i.e. banning system themes etc. But it could also be related to technical simplicity of sorts, it is easier to have one monolithic application instead of two processes and a messaging interface in between.

                  Interestingly enough coupling Mutter and Gnome Shell was lambasted already when the idea was first published, way before the release of Gnome 3.0. The reason was that it would make it impossible to run Gnome with the then-popular Compiz window manager. But I don't think they would still support alternative WMs even if Gnome Shell and Mutter became two separate processes.

                  Comment


                  • #10
                    That already becomes hilarious ‚Äč

                    Gnome needs [JS] extensions to fix broken things in Gnome, extension that break the system broken by default, by smart decisions.

                    Which came first: the chicken or the egg?"
                    Who was first broken [by default],
                    a.Gnome
                    b.Gnome extensions.

                    Comment

                    Working...
                    X