Gnome 2.0 Alpha 1 Released

Dave H writes "The first pre-release of the GNOME 2 platform is now available! Find it at you can grab it from FTP.gnome.org It is of course a technology preview; note that it can't be installed alongside GNOME 1.x." There's some more information information posted on LinuxToday.

Comments

New ORB.

[sarkeizen]

Anyone know if there's intent to implement some kind of simplified IPC? Similar to DCOP? I'm a CORBA developer and even I think that CORBA presents a fair ammount of work to perform some relatively simple things.

BTW: Great Job on the multilingual!, as someone who likes to have his desktop in traditional chinese this is a big deal for me.

Re:A bit of thought on the evolution of the GNOME.

[Jamie Zawinski]

Eazel and Ximian are the most productive GNOME companies,

By "most productive", did you mean "only"?

Is it because the GNOMErs only know how to code in C, and not in C++. There are several good books and web sites on C++ programming, you know.

I promise you that those of us who refuse to use C++ do not do so out of ignorance. Quite the opposite, in fact: I don't use C++ precisely because I know more about it than you.

Re:Another thought...

[David Greene]

Insightful? I've never questioned the drug-using habits of moderators before, but there's a first time for everything. :)

"But hardware != software", I hear some cry. Well, sorry to break it to you, but software is simply a simulation of hardware. There is nothing that you can do in software that you can't do in hardware. Faster.

While it's true that hardware and software are essentially the same thing (a favorite rant of mine, BTW), it's not true that hardware is necessarily "better" than software, even in the speed department.

Picture this - a graphics card that has a pure hardware implementation of XFree86 4.1, Gnome 2, and (just for the hell of it) KDE 2.2 as well. Nothing on the computer, the graphics is done entirely in silicon.

If we look at this proposal from a perspective of practicality, it clearly falls down. Hardware is incredibly difficult to debug and change. That is the beauty of software. The fact that complex computer architectures are implemented in terms of software (microcode) only points to this flexibility.

To address your speed claims, I point you to HP's Dynamo project. Dynamo is a dynamic translator for PA-RISC binaries. It is a software system that translates PA-RISC instructions to PA-RISC instructions at run-time. That doesn't seem to make much sense until you realize that the translation includes optimizations that can only be done at run-time. Binaries actually run faster under Dynamo than in native execution mode. By putting in a layer of software, HP was able to increase system speed.

One cannot do this in hardware because metal and silicon is fixed and FPGA's are too slow. Yes, people are researching reconfigurabler hardware, but that is for very specialized applications like DSP's, applications that are already used to boost graphics performance today.

A final observation: hardware gets much of its speed from parallelism. A ripple-carry adder runs much more slowly than a carry-lookahead adder. While certainly running at the speed of light (yeah, yeah, give or take) helps, parallelism (pipelining, O-O-O execution) is what got us the machine speeds we see today.

Parallelism is really, really hard to extract at the instruction level. Theoretically, it's there, but damned if I know how to get at it. Certainly lots of graphics routines have loads of parallelism. But guess what? We already have hardware to exploit it!

This would free up much of the computer's RAM, unload much of the heavier cycle devourers, and produce one of the fastest GUIs on the planet.

Modern GUI's really don't need to be much faster than they are now. We all like high framerates in our pretty games, but those are very specific applications. In fact, good hardware solutions already exist for them. I don't see RAM consumption as a problem, considering that X runs just fine on the iPAQ with room to spare. I have no idea what software you are running, but the CPU usage of graphics code is not even close to the largest consumer of cycles on my machine.

We already have good graphics hardware. Moving the X/GNOME/KDE control into hardware would gain almost nothing.

#define PROGRESS productive_end_user

[Ukab the Great]

Real progress in an end-user, GUI-based, for-the-masses desktop computing environment is not about:

• How many cool toys you have
• How slick the thing looks
• What language you use (those OO C is a pain in the ass to code in)
• How many graphics buzzwords like AA or DRI you support
• How little memory you use
• How technically elegant you make it

Real progress can be defined as whether the secretary, farmer, mechanic, CEO, or whoever else who isn't a card-carrying geek was able to be more productive and feel better about using than computer than they were with the last version. Anyone,GNOME, KDE, or otherwise, who does not understand this does not understand the desktop. If you do not understand the desktop, you will at best produce a successful user-hostile abomination such as Microsoft did and survive entirely by the politics of corporate IT or at worst get your butt slammed across the entire computing industry.