LWN: Comments on "Managing GNOME shell extensions"

Managing GNOME shell extensions

jamesh — Fri, 30 Sep 2011 07:19:10 +0000

That isn't a particularly relevant comparison. Gnome Shell already has a JS runtime initialised, so an extension would run within that runtime rather than paying those costs a second time.

Managing GNOME shell extensions

nix — Sat, 24 Sep 2011 12:21:04 +0000

Yeah, the only ways to make this work right are

1) maintain a copy of the object inside the separate VMs. This rarely works unless the object has no mutable state (e.g. results of queries).

2) maintain a reference to the object in a proxy, while the object itself remains in C space, not managed by any of the GC systems. If you want a weak link to the C-space object, so the C universe can delete it regardless of the VM's references, you need another layer: a proxy in GCed space pointing to a proxy in C space which then points to the object itself, which ensures that when the C-space object is deleted, you can reseat the C-space proxy to point to a singleton null 'deleted' object, which the VM-resident proxy objects can then use to detect said deletion.

It's far too much work to have the GC systems cooperate, but you can certainly have them stay out of each others' way (and this has been done before, often).

Why a different distribution mechanism

jspaleta — Fri, 23 Sep 2011 17:25:57 +0000

I understand why GNOME is choosing the technical measures it is making to try to make the distinction. I have nothing to comment on the technical measures GNOME is using to delineate a space between extension and the base.

But I continue to be baffled by where the line in the sand is in regard to allowable downstream customization. How much downstream changes in default UI is too much and still be GNOME? It's never been clear in the 2.x timeframe and I'm still not seeing clarity for 3.x. That lack of clarity is in direct conflict with assumptions you want to make about distributor actions. Without clarity as to what you expect distributors to refrain from doing, they will wander out of bounds again and again without meaning to act in bad faith. Because well, you haven't defined the boundaries of what good faith action is.

I'm not suggesting that you _have_ to pull out the trademark enforcement big stick. But you need some form of clear guidance. You don't even have a compliance test suite or a standing set of "thou shall not" commandments...bright line tests of any sort...which define the narrow path of correct action with regard to what is expected of a downstream vendor who wants to label the deliverable GNOME.

-jef

Why a different distribution mechanism

otaylor — Fri, 23 Sep 2011 17:13:40 +0000

Want to be clear about "allowing remote code to take control of my desktop" - what happens is that when you click on the website to install an extension, this triggers the downloading code (not in the same process as the browser plugin) to put up a dialog asking if you want to download and install an extension. So, if you consider a MIME-type helper secure, you shouldn't be too afraid of this. The advantage of a plugin, beyond slickness, is that we can do additional security checks to avoid users being tricked by arbitrary websites into installing extensions. Debian of course, is free to package the browser plugin as a separate subpackage.

Why a different distribution mechanism

otaylor — Fri, 23 Sep 2011 17:06:01 +0000

If we hosted the official GNOME modules and then a whole bunch of extensions all as tarballs to be downloaded from ftp.gnome.org and packaged, then it would be pretty hard to say with a straight face that any combination of those tarballs wasn't equally GNOME.

GNOME doesn't enforce Mozilla-style or event Fedora-style trademark restrictions on the use of the GNOME trademarks with modified versions of the GNOME software, and there never has been much enthusiasm for that in project, but we generally work with the assumption that distributions won't patch up GNOME with arbitrary upstream patches that completely rework the user interface and then claim to be shipping GNOME.

Extensions can completely rework the user interface so it's important to keep a firm distinction in everybody's mind about what's GNOME and what's an extension.

Managing GNOME shell extensions

otaylor — Fri, 23 Sep 2011 16:59:54 +0000

Actually, it's not just some implementation limitation we decided on. We simply don't know any way to have an object shared by three different garbage collection systems, work right, and not be leaked. (This is under a fairly strict definition of "work right" ... including among other things that the proxy object are persistent - that I can say in Python button.some_property = 5 and that's there even if the last Python reference to the button is dropped, then you get the object back by traversing the widget graph.)

Managing GNOME shell extensions

nix — Fri, 23 Sep 2011 16:29:08 +0000

That... doesn't seem like the sort of fundamental restriction you were implying. It seems more like a 'we can only think of one way to write a VM' problem. Off the top of my head: it is perfectly possible to do all these things via some sort of central registry which takes the single allowed reference: you'd just need to have all the VMs load some package that cooperated with such a registry. Since the VMs would have to load at least one specialized package in any case (to be of any use as an embedded language), this problem is moot. There is no need for the VMs themselves to cooperate at all. All they need is an FFI that calls out to C and the ability to load modules written in C, which virtually every VM must have if it is to be of any real use.

Managing GNOME shell extensions

ebassi — Fri, 23 Sep 2011 16:21:48 +0000

What? Yes you can. I do it all the time.What? Yes you can. I do it all the time.

you left out the important bit of my reply: GObject does not allow that. each language binding will have to keep a reference on the native C object, and get notification when the object goes away in the underlying library. GObject only allows one of those notifications because more than one would a) clash with the ABI guarantees (we don't have infinite space in the GObject structure and we cannot add fields without breaking the ABI) and b) would impose performance restrictions (suddenly, object destruction is O(n) with n being the number of "toggle" references).

so, no: GObject does not allow multiple VMs with different GCs in the same process, and that won't change in the short term.

you can get more information in this thread on desktop-devel-list.

Managing GNOME shell extensions

nix — Fri, 23 Sep 2011 11:02:05 +0000

no, you cannot mix different virtual machines with different garbage collectors within the same process.

What? Yes you can. I do it all the time. Lots and lots of processes link against both libpython and libperl, which have their own independent virtual machines with their own different GCs. There are even bridges permitting e.g. Python and Lua to talk to each other (both VMs with their own independent GCs). What you have to do is ensure that no piece of data ever ends up traversed by more than one GC, which just means designing the FFI right. (Lua's is designed right for this: I don't know about other languages.)

Managing GNOME shell extensions

ebassi — Fri, 23 Sep 2011 09:05:35 +0000

I'm sure, it's only matter of short time, until somebody implements Python or other languages support for the GNOME shell.

no, you cannot mix different virtual machines with different garbage collectors within the same process. GObject simply does not support this because it's insane.

if extensions were to be executed out of process then you would not be able to monkey patch internals, so there are various trade-offs to consider.

Why a different distribution mechanism

bronson — Fri, 23 Sep 2011 02:28:51 +0000

Sorry, I didn't realize the extent that you were picturing using code review...

> Why should an important bug fix be blocked on the same process?

You're going to hold all code until a qualified reviewer can look at it. Given the endemic shortage of qualified code reviewers, I'm pretty sure the code will be blocked on your site's own reviewers longer than they'll be blocked on some Debian/RedHat maintainer.

Managing GNOME shell extensions

bronson — Fri, 23 Sep 2011 02:07:58 +0000

I agree! This would be truly useful.

I'd hope the system would allow users to have their own dependency dbs layered on top of the system's. That way I could add (say) TenGen's MongoDB or Caffeine to my apt sources without affecting everyone on the system.

Packages would probably have to have some sort of indication that user-installable or not. It doesn't make sense to install the kernel into your home directory. Probably x.org too.

It might get weird if the user does a dist-upgrade before the machine admin. Or, if your idea of local installs automatically converting to system-wide ones works, then maybe everything just works.

Why a different distribution mechanism

bronson — Fri, 23 Sep 2011 01:53:34 +0000

I'm really glad Gnome is embracing the idea of extensions. That said, I think trying to isolate them to some web site will be an exercise in futility.

> We want to be judged on the experience we designed, for good or bad

Remember when Gnome was still shipping Spatial long after all the distros had turned it off? I was really glad the distros could bring their desktops back to reality when the Gnome project decided to get a little too experimental. A second opinion is often a good thing.

Besides, they're going package the good extensions anyway, especially if they're coming straight from Gnome git! http://git.gnome.org/browse/gnome-shell-extensions/ (link from the article)

> So why should users have to wait for someone to wrap up an extension in an RPM or DEB in order to use it?

Because it does an awesome job of weeding out the cruft. You get another pair of eyes, a lively bug tracker, and lots of fellow users all using the same system. Distros tend to be pretty fantastic. Personally, I wouldn't toss their benefits away quite so lightly.

Also, your writing implies that the extensions will have consistent high quality and be continuously maintained... That seems hard to believe. Gnome's past experience with theming sites suggests that the site will contain lots of duplication and half-finished cruft and the distros will cherry-pick the great bits.

> Why should an important bug fix be blocked on the same process?

Most security turnarounds are measured in hours or days. Not a problem.

Wait, you're going to push updates straight to the user??? Or maybe you'll send an email every time something is updated so users will have to click on install links a few times a week? Either way, it doesn't sound very desirable.

> Why shouldn't you be able to see the comments and reviews that all users have on an extension?

Very true! And the Ubuntu Software Center would be one logical place to find those comments and reviews.

Why a different distribution mechanism

nix — Fri, 23 Sep 2011 00:06:38 +0000

The second reason is that extensions are not working with a stable API, so have very specific version requirements that don't really fit into the normal assumptions packaging systems make. If a packaged extension says it works with GNOME Shell 3.2 only and not with GNOME Shell 3.4, then that will likely break the user's attempt to upgrade to the next version of their distribution. We'd rather just disable the extension and let the user find a new version when it becomes available.

Note that FF has the same behaviour, and it's why I have stopped using Firefox. "Upgrade! Lots of new stuff, oh, and security fixes!" <click> "Oops, looks like half your extensions don't work anymore. Oh, you were relying on them? Sorry!"

--- pardon me, that was inaccurate. It doesn't say "sorry".

Why a different distribution mechanism

droundy — Thu, 22 Sep 2011 23:01:47 +0000

Actually, the version requirements sounds like a strong argument in favor of using the existing distribution infrastructure. That and the security question are sufficient for me to hope that when this is released in Debian stable any integration with browsers allowing remote code to take control of my desktop will be disabled by default.

Managing GNOME shell extensions

droundy — Thu, 22 Sep 2011 22:57:20 +0000

Why not simply allow users to enable or disable extensions?

Why a different distribution mechanism

jspaleta — Thu, 22 Sep 2011 22:06:11 +0000

Everything else aside for a moment.

I don't see how extensions.gnome.org actually helps GNOME prevent OEMs and distributors from passing off customized deliverables as the authoritative/sanctioned/canonical/orthodox GNOME experience.

There's certainly nothing here which prevents distributors from rolling packaged versions of these extentions and nothing preventing them from pre-installing them as part of the advertised GNOME experience for their distribution.

Distributors and OEMs that want to ship customized GNOME will still ship customized GNOME and call it GNOME. Is there anything I'm not aware of that actually prevents an OEM or distributor from doing exactly the type of out of the box customization you don't want to see and calling it GNOME?

-jef

Managing GNOME shell extensions

jospoortvliet — Thu, 22 Sep 2011 20:25:13 +0000

What I wonder is why they don't use GHNS - http://ghns.freedesktop.org/ - or whatever the latest version is of that... It gets you wallpapers, scripts, extensions, icon themes, emoticons and all that stuff in KDE apps. Guess having a common API and not reinventing the wheel would be worthwhile?

Managing GNOME shell extensions

Corkscrew — Thu, 22 Sep 2011 19:53:12 +0000

I've always wondered why this is. Has anyone previously tried to add single-user install to the apt? What was the community response?

I realise that Debian is more aimed at big iron, but even there it could be useful. I have webspace and shell on a Debian server, and it is truly painful to do stuff like install Django from source. It would be nice to just have a command like "apt-get install --single-user django" and let magic happen.

Off the top of my head, obvious issues are:
- dependencies would have to be trackable on a per-user basis (which would also mean unprivileged users getting access to the system-wide dependency db)
- you'd need separate locations for system-wide vs per-user installation for every package (this would break some of them)
- per-user installations would have to be convertible to system-wide installations as and when the sysadmin got round to installing stuff

None of these seem insurmountable.

Why a different distribution mechanism

otaylor — Thu, 22 Sep 2011 18:39:01 +0000

There are a couple of reasons we want to provide a separate distribution mechanism:

The first reason is that we really do care about users getting a consistent out-of-the-box experience with GNOME 3. We want to be judged on the experience we designed, for good or bad. But in the end, we know that some users, and especially the sort of enthusiastic customizers who read LWN will have other ideas about what works best for them. With extensions we want to give users the chance to go ahead and deeply modify their desktop in all sorts of ways, but we're not so crazy about distributions and OEM's doing the same and presenting the result as GNOME without the user even knowing what been done. extensions.gnome.org is a purely user-focused approach to finding and installing extensions.

The second reason is that extensions are not working with a stable API, so have very specific version requirements that don't really fit into the normal assumptions packaging systems make. If a packaged extension says it works with GNOME Shell 3.2 only and not with GNOME Shell 3.4, then that will likely break the user's attempt to upgrade to the next version of their distribution. We'd rather just disable the extension and let the user find a new version when it becomes available.

But to me, probably the most important reason is simply that we can do better. If someone packages the C library, or Apache, there's a large amount of work to be done to make things work correctly with the system. But at the level where a GNOME Shell extension works, every GNOME version 3.2.1 system looks just about every other GNOME version 3.2.1 system. So why should users have to wait for someone to wrap up an extension in an RPM or DEB in order to use it? Why should an important bug fix be blocked on the same process? Why shouldn't you be able to see the comments and reviews that all users have on an extension?

GNOME shell extension security

otaylor — Thu, 22 Sep 2011 17:24:04 +0000

I think my opinion about extension signatures got a little confused here "Owen Taylor's preferred plan involves two signatures: one from each reviewer, and a separate one from the site although he noted that the manual steps could constitute a weak spot." but if you read the mail that is linked to, you'll see that two-signature plan was just a thought experiment about ways we could use signatures that actually enhanced security beyond our current plans. And one that I didn't consider immediately practical.

The current security plans consist of: a) lock the code that does installation of extensions to extensions.gnome.org b) use https to maintain the integrity of the connection between the client and extensions.gnome.org c) have a thorough review process for extensions hosted on extensions.gnome.org d) take appropriate measures for the security of the web site and of the machine it's running on. We'll certainly be evaluating ways of making things better as we go along.

Managing GNOME shell extensions

vonbrand — Thu, 22 Sep 2011 13:40:29 +0000

Gnome runs at least on most unixy systems, i.e., Linux (and a slew of different packaging systems, not all the world is Debian), the BSDs (again, with their own packaging) and AFAIU it is the standard environment on the Solarises or at least their open descendants (yet another weird packaging system, or even several). Integrating extensions into each and every one is a inmense amount of work, and they are resource-strapped as is.

Managing GNOME shell extensions

epa — Thu, 22 Sep 2011 10:06:13 +0000

Why wouldn't I just get these with the rest of the binary packages in my linux distribution?

Sadly no major Linux distribution provides a way to install software by and for one user. It has to be installed centrally. But desktop extensions, like web browser extensions, are something that individual users need to download and install without affecting other users or needing the root password.

The better answer would be to fix the package mechanism so that one person can 'yum install frozen-bubble', it goes in his or her home directory, and does not affect anyone else; but that's a much bigger problem to solve.

Managing GNOME shell extensions

debacle — Thu, 22 Sep 2011 09:00:41 +0000

> Why wouldn't I just get these with the rest of the binary packages in my linux distribution?

Just speculating, but it's probably the same as with Firefox plugins. If somebody cares to package them, they get packaged. E.g. I never use any Firefox plugins that are not provided via apt-get.

> On another note, javascript appears to be the only way to do any type of desk extension?

I'm sure, it's only matter of short time, until somebody implements Python or other languages support for the GNOME shell. The idea, that people have to use the one scripting languages already failed with Guile.

Managing GNOME shell extensions

kragilkragil2 — Thu, 22 Sep 2011 08:17:08 +0000

I didn't say that JS was any good, just that there are more resources directed at making it better and that it is _already_running_ and needed in Gnome3. Perl, Python (unless you use some rinter applet), Java etc are not.
So my wish is still just JS extentions nothing else (maybe C and Vala). Everything else is not needed and lets the user experience on resource limited devices deteriorate faster than you get upset when somebody says anything against your favorite scripting language.

Managing GNOME shell extensions

nim-nim — Thu, 22 Sep 2011 07:49:44 +0000

It's indeed sad to see all this energy deployed into reinventing a software deployment system, for a desktop which is only used on Linux systems, all of which already have their own proven deployment mechanism (called system packages).

It will only lead to more clashes with distributions, and more frustrated users. At least mozilla had the excuse they deploy on proprietary systems where the deployment mechanisms are not open to all.

And it will become even more ridiculous when step2 of the systemd plan goes into effect, and the desktop session gets deeply integrated at the system level. We'll get a schizophrenic desktop which in one hand pretends to have nothing to do with the rest of the system (justifying the need to set up its own deployment channel) and in the other pokes deep inside init and the kernel.

Managing GNOME shell extensions

niner — Thu, 22 Sep 2011 07:46:43 +0000

Comparing the top output of the example.js from nodejs.org to an equivalent implementation in Perl using HTTP::Server::Simple:
VIRT RES SHR TIME+ COMMAND
614m 9512 4416 0:00.05 node example.js
28932 6408 2660 0:00.04 perl example.pl

node.js not only uses 1 1/2 times the amount of memory compared to perl, it also needed more CPU time for startup and handling a single request returning "Hello world"

So much for lean and fast compared to bloated Perl runtime crap.

Managing GNOME shell extensions

kragilkragil2 — Thu, 22 Sep 2011 05:58:52 +0000

Hopefully it doesn't. I use Gnome3 on a tiny 9 inch netbook and I hate running simple little tools that use memory like the integrity of the universe depends on them. Limiting the choices developers have will make sure that all extentions are just JS and everything will stay lean, mean and without bloat. I don't care if I have to wait for extentions a few years longer or if I will never get them. If they are really important they will be done in JS othewise I don't want to be bothered with them. If there are crappy Python, Perl, Ruby, Java (insert bloated runtime crap here) extensions there will be less incentive to develop them in JS, which is already there and fairly lean and fast. Millions are invested every year to make JS fast and efficient (compared to the 5 bucks that were spend the last decade to make CPython or Perl fast..(not counting Unladen Swallow etc.))

The Gnome developers intent Gnome3 to be used on resource limited devices and limiting developers to use the tools that are best for user experience is the best way to success(see iPhone).
Gnome3 focus hopefully is more on user experience than on developer experience. In the long run users are much more important. Even developers will cope with crap if the user experience is great.
It's FOSS so you could do whatever, but I hope the Gnome devs have the foresight to not encourage slow bloat.

Managing GNOME shell extensions

pabs — Thu, 22 Sep 2011 02:38:39 +0000

Yeah, it seems a bit weird to do the whole GObject introspection thing and then not take advantage of that to allow shell extensions in any language. Hopefully this gets fixed in the future.

Managing GNOME shell extensions

alogghe — Thu, 22 Sep 2011 01:14:43 +0000

I'm confused.

Why wouldn't I just get these with the rest of the binary packages in my linux distribution?

Why invent a whole software distribution method and the attendant security issues for some gnome-shell extensions?

I'm looking forward to some of these extensions addressing some of my issues with gnome-shell before I go to gnome3 but this seems like a distraction from stabilizing and maturing the actual extensions.

On another note, javascript appears to be the only way to do any type of desk extension?

In the old desktop I could create an applet in multiple languages that was swallowed by the dock. Now it all seems to have to be written in javascript. Seems like I get to just throw away the python code I have.

It seems like the only path would be to write a javascript dbus bit for the display and then hollow out the pygtk software (python gtk is also in a state of flux) to just provide a dbus service?