Hacker News Reader

Comment by fuoqi | Hacker News Reader

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.

View on HN

> 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.

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.

That is what made me jump to XFCE.

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.

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-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

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.

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.

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"

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.

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?

>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.

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.

> 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)

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.

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.

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.

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.

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.

I wouldn't say it has no purpose existing, but it is the path less trodden so you'll run into more issues.

What? There's lots of Node-independent code in NPM.

I doubt there is lots of JS code in NPM which is independent of either Node or browser APIs when including transitive dependencies. But that is besides the point. I said no NPM as in no access to NPM. Not just no node APIs. Let's say you install a library from npm using either npm or yarn. Its downloaded into the node_modules directory. how would you require it as an es6 module?

Another poor design from the GNOME team. How is the JS code in the gnome extension distributed? It is embedded in .so files! so much for hackability. (I learned this when upon a fresh Ubuntu install I run into bug in my gnome shell version which was a one liner fix but I couldn't find the file in the backtrace.)

I haven't tried this with any node modules but you should be able to set imports.searchPath to include your node_modules folder, at least for testing: https://gitlab.gnome.org/GNOME/gjs/-/blob/master/doc/Modules...

Since there is no inbuilt support for Node APIs this will probably only work with modules that have no dependencies and are built into a single file. ES6 module support is WIP and ongoing: https://gitlab.gnome.org/GNOME/gjs/-/issues/328

I wouldn't touch a desktop environment with a 10 foot pole if it used node or npm.

Reply on news.ycombinator.com