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.
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.
I just ran across a GNOME problem not just ten minutes ago. I want to build Dia because argouml is insufficient and Rose sucks.
Dia is under GNOME/stable. gdk-pixbuf is under GNOME/unstable. Anyone see the problem here? Who in their right mind can call Dia "stable" when it relies on an "unstable" library?
A Government Is a Body of People, Usually Notably Ungoverned
IMHO, what's needed is a GUI that'll do for X what RISC architectures did for processors. Produce a MUCH simpler underlying architecture, using layers to provide more and more complex functionality.
But isn't this exactly what X is? The X server is just a very dumb program that only knows how to draw lines, boxes, circles, and fonts. Everything else (i.e., the complexity) is layered on top of this through toolkits and window managers.
A GNOME program uses the simple GTK toolkit to provide the GUI. GTK uses Xlib which uses X. The complexity is layered.
Furthermore, neither the application nor the toolkit needs to worry about how the window is managed; this is taken care of by the window manager program. The window manager interacts with the user and moves, resizes, and iconifies windows. Layered complexity once again.
Which raises the question: Why is slashdot posting ALPHA releases? all this will lead to is a couple months from now people will comment "Yeah I tried Gnome 3 and it sucked."
m00.
By "most productive", did you mean "only"?
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.
I don't mean to bitch, I really like gnome and look forward to switching back from KDE. The terminal is nicer, GIMP is cool, Galeon is the best web browser i've ever used, and Open Office looks promising (I know I can use these with KDE but I don't like having both GTK and QT loaded, I have better uses for my RAM). But right now KDE works, so that's what I'll use. But I'll give 2.0 alpha a shot... and when gnome works again, It'll be my primary desktop.
Good luck to those working on gnome... and expect some bug reports from me soon!
Well... at least you have anti-aliased fonts and bidirectional font-support.
Well, there is still one important issue left with KDE. The Qt library is released under a GPL license as opposed to the LGPL license for GTK+. This prohibits developers of commercial (non-GPL) applications from using the Qt library and therefore developing for KDE without paying royalties to TrollTech.
This might not be an issue for the OpenSource community, but it sure is an issue for all the companies that have to make a living. This is why companies like SUN, HP etc. has chosen GNOME as their next desktop.
Just my two bits "01" - It's a fact, like it or not.
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.
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!
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.
in interviews, on web sites, etc., it seems like KDE and gnome developers constantly point out how they each admire the other's project, they get together, drink beer when geography allows, etc.
where do you see this so-called hate?
Are you sure it's between developers, or just people who latch onto one or the other and find defnding it / attacking the "other" (as if there aren't plenty of other ways to run a *nix box besides with one of those) necessary to their identity?
This is clearly false. Qt-free is very much GPL'd. I don't know what commercial implications you are talking about. There is absolutely nothing in the Qt license to prevent it from being ported to Windows. The only commercial implication I can think of is that the application compiled against it must be licensed under the GPL. But that doesn't seem to be a concern for you.
Maybe you should try reading the fine manual. You can *very* easily disable this behavior.
First:
Preferences --> Advanced
Then:
Preferences --> Windows & Desktop
and uncheck "Use Nautilus to draw the desktop"
Now, that wasn't so hard, was it? Don't knock a great piece of software (even though I rarely use filemanagers) just because you didn't read the docs.
Given the difficulties we have getting software to work correctly, do you honestly think hardware would be easier? Or even just as easy? Today's hardware only works because the specs are orders of magnitude simpler than even a mildly complex software system.
So you want to use an HDL for this along with a synthesis tool? For synthesis to work, one has to either design a fairly simple piece of hardware or write relatively low-level HDL. In the worst case the designer will essentially write out the netlist. Not to mention the inefficiencies introduced by synthesis. Full-custom design is usually much more efficient, but also much harder to do.
>Think about that for a second. I have a *Lisp* >system that takes less disk space than 12M. That is >a huge, huge, amount of code. Sure, it is less than >the drivers, but considering that X does very >little, it is positively *enormous*.
Ok, but first of all this is stuff used by X clients, not the X server. These are things like libX11 and libXt, essential apis for X clients. Then you have the fact that alot of these apis have been pretty much depreciated for modern X programs. Gnome doesn't use Xintrinsics or the athena widgets. If you're running mostly gnome programs libXt and libXaw almost never loaded. Then there are things sitting around in there like libPEX. Don't even try to say you've used a PEX based program in the past 4 years. All in all, you're probably only going to use libX11, libICE, libSM, libXm and if you're using pretty antialiased fonts libXft and libXrender. Thats about four megs.
- 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.