5 ms·

While I am a long-time Gnome user, I don't think it has a bright future. The project leadership continuously makes weird decision rooted in the believe that Gno

by fuoqi 6y ago

While I am a long-time Gnome user, I don't think it has a bright future. The project leadership continuously makes weird decision rooted in the believe that Gnome is THE Linux DE and everyone should dance under their flute. It does not help that project is riddled with technical issues (most notably memory leaks), quite inconvenient without installing a number of extensions (which often break from versions to version, no stable extension API, really? JS as the extension language does not help either) and fiddling with settings (e.g. to enable Ctrl+Alt+Left/Right with grid workspace layout). I don't have time to play with different DEs right now, but as soon as I find a suitable replacement, I quite probably will ditch Gnome for good. Unfortunately, Gnome sucks a lot of corporate support, leaving alternative DEs quite dry in that regard, which significantly hinders their pace of development. P.S.: The animated favicon is REALLY f*g annoying.

29athrowaway 6y ago
The decision to not render icons using nautilus anymore, and instead use Gnome shell to render them was an awful decision. The Gnome shell desktop extension is not as robust as nautilus. If you move a file by dragging and dropping a file, there is a good chance that Gnome shell will hang. I disabled the desktop icons extension because of this.
- PuercoPop 6y ago
  In principle it was the right decision. Opening an application shouldn't take over the root window. The was specially obvious for people who don't use gnome but use nautilus. The problem is that as you mention "The Gnome shell desktop extension is not as robust as nautilus"
  - 29athrowaway 6y ago
    If I have nautilus extensions for different purposes, those won't be available for the desktop because it's managed by the desktop icons extension. It makes the file management experience inconsistent. That is not the case on macOS or Windows.
PuercoPop 6y ago
> JS as the extension language Just to reinforce why it is a bad decision. One of the selling points of JS is that vast amount of libraries available to you. But in GNOME's case they use spider-monkey as their JS engine, which means that although JS is the extension language not using node means _no_ npm (or node APIs like the fs module)
- est31 6y ago
  TBH that makes GNOME more attractive to me as it means that simplest apps only include the code that's needed instead of gazillions of dependencies.
  - devwastaken 6y ago
    Copy+paste from the github repos of each package is hardly superior to just having package management. Node doesn't magically make every program bulky. Avoid authors that feel the need to include lots of bulky packages.
    - est31 6y ago
      even if you just do copy+paste you copy over less dependencies because there is a cost. Each time you wonder: is it worth it? Ideally you don't do it at all though. As for avoiding authors who bloat up your hard disk, it's easier done on a platform that puts stones into their way like GNME does.
    - canofbars 6y ago
      Copy and paste makes the developer aware of how much they are dragging in. Its easy to run yarn add and then import millions of lines of code. If you tried to do that by hand you would stop and rethink if isOdd() actually requires that much code.
- devwastaken 6y ago
  V8 is superior in lots of other ways too. Interop with C is well defined and there's a lot of documentation. Overall integration is much better supported. Spider monkey has no purpose in existing anymore by comparison.
vondur 6y ago
How well do you think KDE is in regards to Gnome regarding it's future? I see GTK 4 was just released, will this help anything in Gnome 4?
- fuoqi 6y ago
  >How well do you think KDE is in regards to Gnome regarding it's future? As mentioned I haven't invested enough time into testing other DEs yet. >I see GTK 4 was just released, will this help anything in Gnome 4? I doubt it. The problem is not purely technical, the problem is the project's leadership, direction which it pursues, and relationship with the wider Linux community.
  - cycloptic 6y ago
    I have said this before but there is a chicken-and-egg problem here. Alternative DEs don't get a lot of corporate support so as a result they don't contribute much upstream. When they don't contribute much upstream they fall further behind and the relationship with upstream deteriorates because nobody is there to advocate for downstream. I don't know what the solution here is but complaining at leadership to shift in an unspecified direction is probably not it.
Blikkentrekker 6y ago
> While I am a long-time Gnome user, I don't think it has a bright future. The project leadership continuously makes weird decision rooted in the believe that Gnome is THE Linux DE and everyone should dance under their flute. This is an issue I've found scaringly true. I've debated with some of their lead developers and they really seem to lack perspective. I once talked about that I don't run either ConsoleKit or PolKit, this being before logind existed, and Bassi was competely convinced that I had broken my system and did not know what these things did — for surely everyone would run them, and would use the features he listed they would bring. Of course, there is also McCann's immortal quote “I have no idea what XFCE is or does sorry.” — this is one of GNOME's leads who in 2010 apparently did not know XFCE even existed. Talking with many of these persons often leaves one quite stunned at how they can be so ignorant about what goes on outside of their little bubble.
dleslie 6y ago
JS as an extension language, at the time and less so now, came at an _enormous_ performance impact. Core event polling was pushed through to JS in 2010! We were accustomed to snappy, 60 fps UIs and along comes Gnome3 as it struggles to render a response within a few hundred milliseconds of user input. It's still unusably slow on low end machines; like ARM SoCs.
- pjmlp 6y ago
  That is what made me jump to XFCE.
- curlypaul924 6y ago
  Is the issue JS as an extension language, or is it using JS for core events? Or maybe something else? People write successful games with Pygame, and Python's VM is much less optimized than what's available in the JS world, even in 2010. To get 1-frame response time, you need to poll and redraw in the same 16.67ms window. That's an eternity inside a computer. I can write a JS curses app using blessed and it feels pretty snappy, so I'm guessing JS isn't the fundamental problem. The GNOME folk have always been a fan of IPC though (remember ORBit?), so I wouldn't be at all surprised if the latency is due to context switching.
  - dleslie 6y ago
    JS in 2010 was not nearly as efficient or fast as it is today. But yes, it was a number of things as well as Javascript. It was entirely possible to spend time in stock Gnome3 without executing JS with any meaningful frequency, because the core Gnome shell doesn't really have much; but being the extension language, using any Gnome3 extensions would immediately bring JS into the profile. Being someone who likes to customize my desktop, and typically uses hardware five or more years out of date, the Javascript was a pain point for me. There's an excellent blog post from 2019 by one of the Ubuntu devs regarding their efforts at the time to fix Gnome3, as they were abandoning Unity: https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095 https://discourse.ubuntu.com/t/boosting-the-real-time-perfor... Going farther back, Gnome3 was plagued with lots of similarly bad design decisions, like allocating and freeing large amounts of memory on the same thread that handles animation rendering: https://bugzilla.gnome.org/show_bug.cgi?id=745032 https://bugzilla.gnome.org/show_bug.cgi?id=745032 It's quite a storied history for Gnome3 performance; it's come a long way in the last decade. Sadly, it's still nowhere near as responsive or efficient as Gnome2/MATE.

by fuoqi 6y ago

29athrowaway 6y ago

The decision to not render icons using nautilus anymore, and instead use Gnome shell to render them was an awful decision. The Gnome shell desktop extension is not as robust as nautilus. If you move a file by dragging and dropping a file, there is a good chance that Gnome shell will hang. I disabled the desktop icons extension because of this.

PuercoPop 6y ago
In principle it was the right decision. Opening an application shouldn't take over the root window. The was specially obvious for people who don't use gnome but use nautilus. The problem is that as you mention "The Gnome shell desktop extension is not as robust as nautilus"
- 29athrowaway 6y ago
  If I have nautilus extensions for different purposes, those won't be available for the desktop because it's managed by the desktop icons extension. It makes the file management experience inconsistent. That is not the case on macOS or Windows.

PuercoPop 6y ago

> JS as the extension language Just to reinforce why it is a bad decision. One of the selling points of JS is that vast amount of libraries available to you. But in GNOME's case they use spider-monkey as their JS engine, which means that although JS is the extension language not using node means _no_ npm (or node APIs like the fs module)

est31 6y ago
TBH that makes GNOME more attractive to me as it means that simplest apps only include the code that's needed instead of gazillions of dependencies.
- devwastaken 6y ago
  Copy+paste from the github repos of each package is hardly superior to just having package management. Node doesn't magically make every program bulky. Avoid authors that feel the need to include lots of bulky packages.
  - est31 6y ago
    even if you just do copy+paste you copy over less dependencies because there is a cost. Each time you wonder: is it worth it? Ideally you don't do it at all though. As for avoiding authors who bloat up your hard disk, it's easier done on a platform that puts stones into their way like GNME does.
  - canofbars 6y ago
    Copy and paste makes the developer aware of how much they are dragging in. Its easy to run yarn add and then import millions of lines of code. If you tried to do that by hand you would stop and rethink if isOdd() actually requires that much code.
devwastaken 6y ago
V8 is superior in lots of other ways too. Interop with C is well defined and there's a lot of documentation. Overall integration is much better supported. Spider monkey has no purpose in existing anymore by comparison.

vondur 6y ago

How well do you think KDE is in regards to Gnome regarding it's future? I see GTK 4 was just released, will this help anything in Gnome 4?

fuoqi 6y ago
>How well do you think KDE is in regards to Gnome regarding it's future? As mentioned I haven't invested enough time into testing other DEs yet. >I see GTK 4 was just released, will this help anything in Gnome 4? I doubt it. The problem is not purely technical, the problem is the project's leadership, direction which it pursues, and relationship with the wider Linux community.
- cycloptic 6y ago
  I have said this before but there is a chicken-and-egg problem here. Alternative DEs don't get a lot of corporate support so as a result they don't contribute much upstream. When they don't contribute much upstream they fall further behind and the relationship with upstream deteriorates because nobody is there to advocate for downstream. I don't know what the solution here is but complaining at leadership to shift in an unspecified direction is probably not it.

Blikkentrekker 6y ago

> While I am a long-time Gnome user, I don't think it has a bright future. The project leadership continuously makes weird decision rooted in the believe that Gnome is THE Linux DE and everyone should dance under their flute. This is an issue I've found scaringly true. I've debated with some of their lead developers and they really seem to lack perspective. I once talked about that I don't run either ConsoleKit or PolKit, this being before logind existed, and Bassi was competely convinced that I had broken my system and did not know what these things did — for surely everyone would run them, and would use the features he listed they would bring. Of course, there is also McCann's immortal quote “I have no idea what XFCE is or does sorry.” — this is one of GNOME's leads who in 2010 apparently did not know XFCE even existed. Talking with many of these persons often leaves one quite stunned at how they can be so ignorant about what goes on outside of their little bubble.

dleslie 6y ago

JS as an extension language, at the time and less so now, came at an _enormous_ performance impact. Core event polling was pushed through to JS in 2010! We were accustomed to snappy, 60 fps UIs and along comes Gnome3 as it struggles to render a response within a few hundred milliseconds of user input. It's still unusably slow on low end machines; like ARM SoCs.

pjmlp 6y ago
That is what made me jump to XFCE.
curlypaul924 6y ago
Is the issue JS as an extension language, or is it using JS for core events? Or maybe something else? People write successful games with Pygame, and Python's VM is much less optimized than what's available in the JS world, even in 2010. To get 1-frame response time, you need to poll and redraw in the same 16.67ms window. That's an eternity inside a computer. I can write a JS curses app using blessed and it feels pretty snappy, so I'm guessing JS isn't the fundamental problem. The GNOME folk have always been a fan of IPC though (remember ORBit?), so I wouldn't be at all surprised if the latency is due to context switching.
- dleslie 6y ago
  JS in 2010 was not nearly as efficient or fast as it is today. But yes, it was a number of things as well as Javascript. It was entirely possible to spend time in stock Gnome3 without executing JS with any meaningful frequency, because the core Gnome shell doesn't really have much; but being the extension language, using any Gnome3 extensions would immediately bring JS into the profile. Being someone who likes to customize my desktop, and typically uses hardware five or more years out of date, the Javascript was a pain point for me. There's an excellent blog post from 2019 by one of the Ubuntu devs regarding their efforts at the time to fix Gnome3, as they were abandoning Unity: https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095 https://discourse.ubuntu.com/t/boosting-the-real-time-perfor... Going farther back, Gnome3 was plagued with lots of similarly bad design decisions, like allocating and freeing large amounts of memory on the same thread that handles animation rendering: https://bugzilla.gnome.org/show_bug.cgi?id=745032 https://bugzilla.gnome.org/show_bug.cgi?id=745032 It's quite a storied history for Gnome3 performance; it's come a long way in the last decade. Sadly, it's still nowhere near as responsive or efficient as Gnome2/MATE.