User: Password:
|
|
Subscribe / Log in / New account

Reitter: Answering the question: "How do I develop an app for GNOME?"

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 9:22 UTC (Thu) by ovitters (subscriber, #27950)
In reply to: Reitter: Answering the question: "How do I develop an app for GNOME?" by droundy
Parent article: Reitter: Answering the question: "How do I develop an app for GNOME?"

GNOME shell does not make fast computers slow. Secondly, Javascript will be the preferred language. As such, committing the future of GNOME to it? There will still be Vala, C, Python, etc.


(Log in to post comments)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 15:03 UTC (Thu) by paulj (subscriber, #341) [Link]

GNOME shell definitely has significantly higher resource needs than the previous Metacity/Compiz environments. Worse, it seems to leak memory. It's RSS expands and expands with time, until it starts causing the machine to have to swap. At which point you have to kill gnome-shell to have it restarted and get a useable desktop back.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 15:14 UTC (Thu) by ovitters (subscriber, #27950) [Link]

I responded to making fast computers slow.

You bring up something different, higher resource usage compared to metacity/compiz. GNOME shell is based on clutter, etc. Totally different than metacity.

The higher usage vs metacity is partly because of compositing and at the moment there is a binding bug with clutter (IIRC). Not much to do with Javascript. It would have been exposed in any binding. That bug was unfortunately only fixed in unstable, not in 3.6.x. In any case, you would've seen the same in Python, etc.

Of course, you can judge a Javascript decision on whether or not that bug is fixed at the moment. But actually we also fix memory leaks in other programs. Be it C (lots), Python, etc.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 15:43 UTC (Thu) by paulj (subscriber, #341) [Link]

Well, my laptop has fast enough CPUs (pretty much any x86 CPU made in the last 5 odd years is "fast"). Unfortunately, it doesn't have that much memory (1.5GB). This was sufficient prior to GNOME shell, except that I couldn't keep as many browser tabs open as on my desktop, and it was better to minimise swapping between LibreOffice and my browser, when using the former. GNOME shell's memory usage, its tendency to expand quite quickly, has put an additional pressure on memory, such that it's regularly much slower than before, as it's using swap much more heavily than before.

If bugs relating to leaks have been fixed, and things are due to improve in future releases, that's great.

I didn't place any blame on Javascript. ;) Though, for whatever it's worth, my experience is that it can be even harder to avoid or fix leaks in GCed languages than in ones with explicit semantics for managing ownership of memory.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 11, 2013 15:25 UTC (Mon) by droundy (subscriber, #4559) [Link]

Interestingly, I didn't say it made fast computers slow, I said it made fast computers <i>seem</i> slow, which is quite a different statement. I also didn't say that javascript was to blame, more likely it was javascript developers who were to blame. But the correlation is not encouraging.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 11, 2013 15:42 UTC (Mon) by ovitters (subscriber, #27950) [Link]

Not sure how you see the correlation. Why pick javascript and not the compositing? Or maybe gtk+3.x, dconf, etc?

In practice the slowness is often combination of compositing and drivers btw (aside from just outright gnome-shell bugs :P). Use gnome-shell on another system or with another driver and you'll see a huge difference.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds