Brian: Brian Nitz wrote: > Bob Doolittle wrote: >> Shawn Walker wrote: >>> Peter Tribble wrote: >>>> I would concur. Once you've got into GNOME it's not too bad. >>>> But am I the only one to think that's really not good enough? >>>> After all, I remember a SPARCstation 2, and that *was* zippy. >>>> I, for one, want that zip back. >>> The funny thing about light-weight environments is that as their >>> userbase increases, so does their feature set, and inevitably people >>> wish for the 'good old days'. >>> >>> Rather then abandoning GNOME, I think the right answer is to find >>> ways ways to improve it, as inevitably, when current 'light-weight' >>> solutions began adding the extensive accessibility, >>> internationalization, and other that GNOME has (and is required in >>> many cases) you will inevitably lose some of that 'zip'. >>> >>> And I say this as a user of GNOME since 1.4.x (or earlier; been too >>> long to remember).... >> >> All good comments (and I say this as a Linux 0.9 user long before >> GNOME or CDE ever showed up :) ). >> However, we tried to push the "light" agenda at the Gran Canaria >> Desktop Summit recently and the GNOME leaders just didn't seem >> particularly interested. Who knows, maybe some of it got through, only >> time will tell but it doesn't look promising at the moment. > I missed the desktop summit, at what level did we push this? If we > presented anything on this, can you provide link?
This has been discussed at different levels over the past months. There has been a lot of discussion on public GNOME mailing lists, for example. At the GCDS summit, it was also discussed at the GNOME Foundation Advisory Board meeting. The problem is that GNOME Shell and the new window manager (mutter) are closely tied to clutter, which requires OpenGL. It would be very difficult to decouple these programs from OpenGL and it would be a further challenge to get it to perform well. While it is technically possible to make a new Sun Ray that supports OpenGL, this approach would also have numerous issues. Adding such support would likely require adding new hardware (and cost) to a Sun Ray deployment. Such a solution would also likely have performance issues, especially in high-latency environments. Really, it seems to make more sense to provide light alternatives to GNOME shell and mutter, rather than trying to find ways to make components designed to work with OpenGL work well on Sun Ray. > I was at OSCON09 and > even though it isn't as desktop focused, I did learn that the moblin > project is working on some of the performance issues we've seen. For > example, they noticed 350 gconf lookups during metacity start and the > fact that each required a DNS lookup. So DNS caching made a noticeable > improvement in desktop startup. (though I wonder if metacity really > needs 350 config settings!) Between netbooks, Nokea and other mobile > device gnome users, Sun Ray and Linux thin client projects, you'd think > we will eventually have enough sway to discourage Gnome projects from > allowing some of these more egregious performance killers. As you say, it should be a real benefit that more mobile and small devices are using the GNOME stack. I think we can expect that a lot of energy will be focused on making GNOME perform better on devices like Sun Ray. > One of the troll dead ends on the original thread mentioned the relative > lack of OpenSolaris desktop market share. It would help us if we could > point to even a rough order of magnitude on the number of GNOME on thin > client deployments on Solaris because I'll bet it exceeds the number of > 'opensolaris on laptop' distributions which, unfortunately seems to be > our focus. One problem with GNOME on Sun Ray is that SRSS currently only supports Solaris 10, and GNOME 2.6 has a number of issues (it is a very old version of GNOME that lacks a lot of modern features people expect from GNOME, lack of usable a11y, etc.). Hopefully, when the next OpenSolaris long-term-support release comes out and supports Sun Ray, these barriers to using GNOME with Sun Ray will go away. >> It's the "shiny object" syndrome - it affects developers too I'm >> afraid. It's a real problem in the FOS Community. It's always easier >> to get people to work on a shiny new feature instead of tightening up >> code or reducing memory consumption or network bandwidth. After all, >> hardware just keeps getting faster, so "why bother" is the usual >> argument. > Good point, for the same reason it is difficult to get a commitment to > resources for improving performance until it gets so bad that it results > in a Sun or customer escalation and then it's usually much more > expensive to fix. By time we scale up enough to see these bugs, the > community has moved on and we end up spending more of our time and money > patching legacy code that the maintainer isn't very interested in anymore. > > I hope we can continue to push gnome light both here and in the > community, but for it to really sell at a GUADEC/Summit, we have to > provide benchmarks, some patches and more benchmarks to show what can be > done to make GNOME more scalable and this requires more resource > commitment on our side. Unfortunately, "GNOME light" probably means using alternative programs to GNOME shell and mutter. Therefore, whatever solution we use for a "light desktop" will likely be more complicated that just "fixing" or providing patches for these new OpenGL-enabled GNOME 3.0 components. >> But IMO we seem to be able to out-pace increases in hardware speed >> with code bloat, and it doesn't serve the users (or the environment) >> when they keep having to chuck out their old hardware and buy new just >> to keep up. We're all so used to upgrading gear now we hardly think >> about it - it's just expected. It'd be fantastic to have an >> opportunity to reverse that trend a bit. >> >> -Bob > If you made it past the troll section of the original thread, eventually > you'll find some sound ideas in encouraging Gnome developers towards > more sustainable 3 layer multiplatform approach and other good practices > such as those which l10n has adhered to. After all, good code is much > easier to port to any platform. > > On our side, I think we should, at the very least, come up with a more > coherent approach to working with Gnome's X86 fat client isms and > linux'isms in GNOME code so we won't sound like a bunch of old luddites > who hate any change. For example: > > Issue: Window manager's hard dependency on OpenGL > Why is this a problem?: Thin clients don't have 3d accel hardware. > Workaround suggestions: > Q:Why not add OpenGL primitives to clients? A:Requires more power and > complexity on the hardware side of the clients... > Q:Why not make it a soft dependency? > A: ? Since clutter treats all components of the desktop as actors on a 3D stage, it would be a huge amount of work to provide a backend that avoided exposing OpenGL to the clients. It would also likely perform badly, and possibly require additional hardware. Considering the design of GNOME Shell and mutter are to tie the desktop to OpenGL, it makes more sense to seek alternative components that have a more lightweight assumption. It probably makes more sense to just continue providing the GNOME 2.x gnome-session, metacity, gnome-panel and applets for users with lightweight needs. Or, perhaps to use a desktop more clearly designed for lightweight use, such as LXDE. I anticipate that the old GNOME 2.x gnome-session, metacity, gnome-panel and applets will live on in the GNOME 3.x timeframe for exactly these reasons. Lots of users, not just Sun Ray, will insist that GNOME keeps working on their hardware, and this is the most straightforward way to continue providing support for those users. > Issue: Hard dependency on Policy kit > Q:Why is this a problem? > ... I do not believe any modules that Sun cares about shipping has such a hard dependency. With the obvious exception of HAL, which currently does use its own private PolicyKit. I am not aware of any serious problems that are caused by PolicyKit not being more widely available in OpenSolaris. > We could work with the gnome bug team and use Bugzilla for these kinds > of issues. Ideally we would work with FreeBSD/NetBSD/Moblin and other > non-linux non-fat environments so we could tag some issues as broken on > multiple platforms. Note that the OpenGL issue is not a problem for most mobile devices that are considering using GNOME. In fact, the GNOME mobile community is really driving a lot of the OpenGL integrations. This is because the GNOME desktop is only being considered for mobile devices that are in the "Smart Phone" class of devices (e.g. phones which will compete with the iPhone), which (like the iPhone) support OpenGL. Brian
