Slashdot Mirror
Coding The Future Linux Desktop [updated]
the.jedi writes "With the release of GTK+ 2.4, and Gnome 2.6 due out some time next week, it seems of some the Gnome developers are looking at how they'll be coding Gnome and the rest of the Linux desktop. Havoc Pennington of Planet Gnome has written a short blog pondering and analyzing the available options as coders move towards high-level languages like java and C#. He gives a good overview and assessment of technologies like mono, OO.org's UNO framework, as well as other ways of tying new languages to the existing code base. An extremely interesting read for desktop linux hackers everywhere."
Update: 03/17 14:44 GMT by T : Speaking of the future of Gnome, aeneas writes with a list of Gnome 2.6 release parties around the world (linked from gnome.org/start/2.5).
Did you guys switch the polarity on the temporal transducer again? It's *LIKE* a re-post, but not.
Here ya' go, from yesterday.
"Lawyers are for sucks."
- Doug McKenzie
I'm not favoring XUL, but if I read ok, the article mention sthat XUL only has bindings to javascript. These are maybe the best implmented, but ti has also bindings (or being worked on) for perl, python and ruby.
Michel
Yes, C/C++ has it's issues, but how about it's performance advantages over bytecode languages like C# and Java? It could be a way do distinguish Linux desktops from the Microsoft world, by running natively compiled applications. Look at either OpenOffice or Mozilla. They are consistently two of the slowest to launch apps on my Linux system
And both OOo and Moz are native-compiled. I don't get where you're going with that.
Maybe we need a high performance network enabled version of Gtk.
The problem is not on Gtk. Gtk makes use of a double buffer to avoid flickering. That's not bad, but it brings an X Window design decission to the surface.
When using X over a network, it always transfers ALL the screen to the clients, even the static parts.
The addition of the XDamage extension to X servers allows the X protocol to transfer _only_ the screen changes over the network. Less transferred data, less network use, more speed.
I can't wait for the Freedesktop X server to be production quality.
Also, a couple years ago, I experimented with gnome's corba implementation, Orbit. It was pretty darn lightweight and fast. Since then, Orbit has made so much progress, maybe I should have a look at it again, and see how hard it'd be to add support for that to crosstool, so Corba could be an easy option for people using crosstool-generated toolchains.
to gnome being a project that you could code for in any language?
Err...it hasn't changed a bit. They added support for one more language, to the other ones out there. A lot of people that bitterly hate C# went nuts over it, and have been happily misquoting Miguel and thinking that the sky is falling.
If you don't like to use C#...hey, don't use it! Use C, or C++, or perl, or Java, or whatever language you like to code GNOME apps in. If you like Lisp languages, look at cl-gtk or clg.
May we never see th
Both of which are written in C++.
A big part of the slowness of gtk2 is font rendering. Motif uses (or used?) XDrawString(), so text was done entirely by the server. On the downside, the quality of the text rendering was very poor.
gtk2 draws all text with pango. Pango is a high-quality unicode text renderer with an Xft2 backend. If you have an old X server, this can be pretty slow. If you have a recent XRender extension, it's almost as fast as the old XDrawString().
Owen Taylor did add an optimisation to render text more quickly for text which gtk knows is being drawn over a plain background, this helps old X servers a lot, provided you're not using a pixmap-based theme.
At 8mb on my system (that includes the java class library) that's pretty light. For comparison .NET on Windows weighs in at about 30mb and the Mono RPM (compressed) is about 8mb as well, so it's certainly competitive.
I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in .NET; what makes HP think that GTKmm or QT isn't good enough? Don't believe the hype dude; the MS marketing machine has been blowing a lot of smoke up a lot of asses.
Yup.
Java/C# are snazzy for:
* Custom application development
* Lightweight distributed and networked systems.
* (Java at least) Cross-platform GUI apps.
* Vertical market software development.
C/C+ are snazzy for:
* Libraries
* Horizontal market applications
Until Microsoft goes out and rewrites MS SQL Server, MSIE, and Microsoft Word in C# (not going to happen, for good reasons), I don't see any reason why there should be any interest in doing the same with the core GNOME apps.
The same goes for Sun and Java. When Sun decides that Java would make a really great language for Open Office and successfully writes an efficient Java-based Office release, then it might be worthwhile considering Java for said use.
Until then, I'd suggest rnning out and actually *using* one of the desktop apps that people have written with Java. Hey...they're slow, RAM-hungry, and annoying to run on systems with different JVMs.
There have been a zillion less efficient languages proposed to replace C (and later C++) over the years. All of them failed to replace C/C++ as a general application programming language. Efficiency matters. The fact that Microsoft is pusshing a high level language and Sun is pushing a high level language (at other people -- notice failure of Wordperfect Java port for an example of why Java/C# are not good choices for horizontal market apps) does not mean that *this* year is the time to move to a high level language. I don't think anyone here wants GNOME or KDE to have a *bigger* RAM footprint, which Java would do.
May we never see th
1) Mozilla and OO are written in C++ not Java or C#
2) Java on a modern hotspot JVM can outperform the equivalent C++ code for stuff that isn't IO limited (ie number crunching stuff)
3) GCJ compiles Java to native code anyway.
I'm not sure I see your point.
GNOME has historically been ideologically aligned with GNU, but otherwise GNU doesn't play any role in GNOME's development. There is no gnu.org people working on it AFAIK, and they have no more say if Mono should be used than Joe Random developer. In fact, I'm Joe GNOME developer, got full CVS rights etc, and I certainly don't consider or even want myself associated with GNU in any way. For the record, I fully support Mono and will agree to its inclusion if it ever comes up to the vote.
We are not hostile at all to DotGNU.
We think we have a better implementation so we keep going forward with that. I don't think we're even competing since DotGNU seems to have different targets than us: for example the reason we built a JIT from the start is because we want Mono to be an efficient developer platform that enables people to move away from unsafe and difficult to use langauges: this of course would be not compatible with an interpreter design which is slow. By all means continue with the DotGNU implementation, improve it and try to build on its strengths, but don't just call us hostile only because we have a different implementation from yours.
No need for either.
XUL already exists. XAML is a XUL feel-alike, like C# is to Java.
Pah. It always takes Microsoft to bring already-existing ideas into the spotlight.
Nasty type errors are really rare, though. Normally, you've either done something stupid and the code doesn't run at all (and you have to test everything at least once), or the types are right.
Of course, some languages can be really helpful with their type checking. Haskell often gives some insight into the nature of some code by giving it a more general type. But I find Java tells you nothing you didn't already know.
Python has a few other problems. It's (a) slow even with tools like Psyco.
I've looked at the output of some code from psyco and it looked just like C (provided you stick to C-compatible types, of course). Python tends to off-load critical loops into C libraries (map(), etc). Java tends to be much slower, perhaps because most of its standard library is interpreted?
Modern C++ compilers also have access to profiling information. Moreover, they then can optimize over the true average rather that what happens on the first few times that code is encountered (which may not be that typical).
The Tao of math: The numbers you can count are not the real numbers.
Actually, the grandparent is correct. Just look to common industry practises for the evidence you need: no one writes desktop apps in C any more. C++ is the de facto standard, for many reasons. And it will be replaced by one (or several) of the managed code languages.
It all comes down to time: development time, and maintenance time. C is a costly language, and companies don't want to pay for it.
Programming is hard. It's an unnatural thing for the human mind to do.
:).
:).
Not in Python - it's as natural as eating or sex
The more code can be automatically verified and checked, the better IMHO.
That's why there should be tests that excercise your code. Static typing helps catch some trivial bugs, but it only goes so far.
It's (a) slow even with tools like Psyco a
I think this is the reason it's not considered for OO.org scale programs. Desktop programs need to be very snappy, and Python takes a hit here. Less so because of the size or scalability. google for Chandler @ OSAF.
has a wierd non-C like syntax which is a bit offputting for people who are used to C++/Java/C# style languages.
The syntax is not "weird". Actually it's much more natural than in C family languages. And someone who can't get used to a new kind of syntax of such simplicity is probably quite stupid and should not be programming anyway (note that I'm emphatically *not* referring to you here, so ease up on the flamethrower
Save your wrists today - switch to Dvorak
But even so, this information might not be useful.
For example, GCC compiles per file. It doesn't compile the project as a whole, so it can't perform cross-module optimisations.
Another example, how do you efficiently optimise a library statically? Not only that, but the behaviour of the application might depend upon, for example, a read-in piece of text (to determine, for example, if it logged or not). A sophisticated JIT can then generate more optimised code than a C++ compiler over time.
There are loads of cases where a JIT can outperform a static compiler. That's not to say that static compilers don't have a large number of strengths, or can't be modified to overcome a large number of these weaknesses (whole program compilation is already pretty much there for gcj, adding it to the gcc in total might not be that difficult, likewise a runtime profiler could rely on static hints for places that might be good to optimise, akin to dynamo). But at the moment, JITs don't necessarily lose out.
It turns out most S.W.F client code relies too much on poking around "behind the scenes" way of pinvoke badness and the like that there needs to be a real Win32 implementation behind it.
.NET was so they could cast off the shackles of Win32 backwards-compatability, for good and bad reasons both)
(which is also why Microsoft is backing off of S.W.F themselves; the whole point of them going with
That said, mono is in fact working on a S.W.F implementation in conjunction with Wine.
DNA just wants to be free...
This seems like a natural fit for developing desktop applications that don't feel like they're running under a VM, yet they are still garbage collected.
Yes, because IceWM and WMaker are written in a unicode-supported toolkit that trades a little bloat for i18n purposes..
Oh wait, they aren't! Metacity is the one that's written to be run anywhere in the world.
Honestly, if there was another GTK+ 2 window manager with all the Gnome hooks built into it to compare it to, then you'd have a platform to stand on.
Otherwise, you may as well be saying 'd00d WTF!!! why is Doom III so much slower than Wolfenstein 3D???? id is t3h sloppy coding!!11!'
Having lived on K6-2 with redhat 6.2 for years I recently tried Fedora on a P3 600. Optimization notwithstanding the desktop is awfully slow. I'll stick with gnome 1.0 and gtk-1.2 for now, thanks.
That's quite an facile editorial but you can't expect better from normal users. My screenshot looks better than yours. Evolution is better than KMail, GNOME looks more polished than KDE and so on. I do use XChat, Abiword, Rhythmbox.... ...usually you get stuff like these from normal users. And this is ok since you can't blame them for stuff they simply don't know about or don't have a slighest knowledge about.
Such editorials are hard to take serious since they are build up on basicly NO deeper knowledge of the matter. Most people I met so far are full of prejudices and seek for excuses or explaination why they prefer the one over the other while in reality they have no slightest clue on what parameters they compare the things.
If people do like the gance ICONS over the functionality then it's quite ok but that's absolutely NO framework to do such comparisons.
I do come from the GNOME architecture and spent the last 5 years on it. I also spent a lot of time (nearly 1 year now if I sum everything up) on KDE 3.x architecture including the latest KDE 3.2 (please note I still do use GNOME and I am up to CVS 2.6 release myself).
Although calling myself a GNOME vetaran I am also not shy to criticise GNOME and I do this in the public as well. Ok I got told from a couple of people if I don't like GNOME that I simply should switch and so on. But these are usually people who have a tunnelview and do not want to see or understand the problems around GNOME.
Speaking as a developer with nearly 23years of programming skills on my back I can tell you that GNOME may look polished on the first view but on the second view it isn't.
Technically GNOME is quite a messy architecture with a lot of unfinished, half polished and half working stuff inside. Given here are examples like broken gnome-vfs, half implementations of things (GStreamer still half implemented into GNOME (if you can call it an implementation at all)) rapid changes of things that make it hard for developers to catch up and a never ending bughunting. While it is questionable if some stuff can simply be fixed with patches while it's more required to publicly talk about the Framework itself.
Sure GNOME will become better but the time developers spent fixing all the stuff is the time that speaks for KDE to really improve it with needed features. We here on GNOME are only walking in the circle but don't have a real progress in true usability (not that farce people talk to one person and then to the next). Real usability here is using the features provided by the architecture that is when I as scientists want to do UML stuff that I seriously find an application written for that framework that can do it. When I eye over to the KDE architecture then as strange it sounds I do find more of these needed tools than I can find on GNOME. This can be continued in many areas where I find more scientific Software to do my work and Software that works reliable and not crash or misbehave or behave unexpected.
Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.
We still have many issues on GNOME which are Framework related. We now got the new Fileselector but yet they still act differently in each app. Some still have the old Fileselector, some the new Fileselector, some appearance of new Fileselectors are differently than in other apps that use the new Fileselector code and so on. When people talk about polish and consistency, then I like to ask what kind of consistency and polish is this ? We still have a couple of different ways to open Window in GNOME.
- GTK-Application-Window,
- BonoboUI Window,
- GnomeUI Window,
Then a lot of stuff inside GNOME are hardcoded UI's, some are using *.glade files (not to mention that GLADE the interface buil
I'll try to address some of the issues Havoc presented. Of course, I'm a Mono developer, so I'm biased, but hopefully people can see my arguments are more on the technical side than advocacy.
No rewrites please: this is a very important point: we can't just throw away the current code: we need incremental changes to not disrupt stability and compatibility. I'll just note that using Mono (and C#), interoperability with existing C code is much easier than with Java because of P/Invoke.
Calling managed code from C/C++: Havoc says it's hard, but Mono provides an easy to use interface to do that. Mono is designed to be embedded in existing applications, not just as a runtime for standalone completely managed programs. Also, it would be easy to create a shared library and header files to access managed methods seamlessly: they can be automatically generated thanks to the use of Reflection and the Mono embedding API.
I'm not sure a "simple native component system bridge" would solve the issues, mostly because simple systems are always found later to be incomplete, they get changed and become big, but with all the design warts needed to make a simple design work for not-so-simple constraints.
A minimal Mono system is currently about 2 MB on disk, but no effort yet has been put into reducing it (and I think it's entirely possible, we have been busy implementing features and leaving aside space optimizations). Of course, since the default build of the core assembly has lots of features, much of the reduction in size could be achieved by trimming features that other systems don't have:-). Even without trimming, most people will concour that 2 megabytes of disk space for a shared component is small enough in a desktop setting (and applications compiled to IL code are usually much smaller than comparable C apps anyway).
Community should decide: of course, I agree. Anything that is pushed down our throats by somebody else is not going to work for the free software and open source communities. The solution will need to be choosen because it actually solves issues the developers and the users see. Java had several years to try to attract developers from our community and it had some success in some niche areas (not for desktop applications, though). Mono has just started, but from the comments of the developers that actually used it to write new applications or port existing ones from C, it looks like we are on a good adoption path (even though we didn't release a 1.0 version yet, we are still working on debugging support and documentation is sparse).
Havoc fears the adoption of Mono or Java for the desktop would alienate people and cause forks. I don't think that will happen with Mono, because Gnome will continue to have a diversity of developers who'll prefer using the C libraries directly: Mono allows to keep and interoperate with existing code very easily and we want the migration to happen incrementally, so at first only end-user applications would be written in managed code, while the foundation would still be in C (at least, enough of the foundation to have people happyly writing their own apps in c or with the existing bindings). At that point, when a managed execution environment has proven itself to both developers and users (hopefully) we could start discussing about using it for the foundation, too, if that makes sense. I think Mono is positioned better here to allow this incremental shift of both development and espectations towards a managed runtime.
Problems with a .Net clone: Havoc claims that MS controls the platform
because, even if the core is unencumbered, some assemblies are tied to MS
technologies and there is non standards body or community momentum to build
alternative solutions for a complete platform. Well, considering that until
a couple of months ago there were 5 people developing mono, we have achieved a lot,
not only in the implementation of the runtime, but also, thanks to the large
commun
i will have to bite. and to make a case for Java / desktop.
:)
to get that out of the way: yes, java memory use is ridiculous, and Sun needs to do something about it. 16M overhead for _any_ app is not going to cut it. memory use is on top of the list for requests for enhancement, so i expect significant movement there soon.
I'll say _you_, then, haven't spent days debugging a Java memory leak.
i have. yes, the garbage collector does not free you of all worries. and especially with the listener model you will run into gc issues quick. unless you use WeakReference and simply _never_ have that problem (WeakReferences are references that do not prevent garbage collection - it's a way to make Java behave like C, exept that you don't have to dealloc - the garbage collector takes care of that for you)
using WeakReference where appropriate, you can have the cake and eat it, too.
Sun should really emphasize this more in the docs. But i wonder what the alternative is? No garbage collector? Surely, that's worse.
4. It also has horrible startup time - i think that has to do with RAM usage. it takes a while to fill 25M... so if the RAM problem goes away, this one will go away, too.
5 Swing is slow... Not true. Swing (caveat: on windows!) is hardware accelerated. E.g. it takes advantage of the graphics card, just like native apps do. That it hand-paints everything is java mythology. It was true a long time ago. [caveat: i think it might still be true on non-windows platforms]
6. It also requires quite a bit of clue to use well....
Point taken.
Swing is a relatively weak framework, some call it over-engineered, i just think it was done by people with little experience in designing GUI frameworks. On the upside, it does have a lot of things built-in.
Bottom line is, Swing is a memory hog, and the architecture (or at least the tutorials) could be better, but it is fast, and it works very well.
Both memory usage and startup time are not inherent to Java/Swing, and i am convinced that both can be improved and will be improved in the near future (1.5).
Not to mention it's cross-platform
The latter means that all apps i write for my company will also run on Linux. Even though that is not a requirement for any of them (and i certainly would not get any resources allocated to do a port).
It's called moc, the meta object compiler.
You had me at "dicks fuck assholes".
Perhaps D (which isn't open source) shows how to ground a language more in the existing C world. The D language appears to offer the strengths of Java/C# rooted more firmly in a C-based environment.
http://www.digitalmars.com/d/