Linked by Rayiner Hashem & Eugenia Loli-Queru on Mon 24th Nov 2003 16:24 UTC
Original OSNews Interviews Today we are very happy to publish a very interesting Q&A with major members: the founder Havoc Pennington (also of Debian, Gnome and Red Hat fame), Waldo Bastian (of SuSE & KDE fame), Keith Packard and Jim Gettys (of X/XFree86/fontconfig/w3c fame) and David Zeuthen, a new member who's taking over the ambitious HAL project. In the article, we discuss about general goals, status and issues, the role of KDE/Qt in the road to interoperability with Gnome/GTK+, HAL (with new screenshots), the new X Server aiming to replace XFree86 and we even have an exclusive preliminary screenshot of a version of Mac OS X's Exposé window management feature for this new X Server! This is one article not to be missed if you are into Unix/Linux desktop!
Order by: Score:
Gee... I remember this feature from some where.
by Nick on Mon 24th Nov 2003 16:34 UTC

"So we need a registry of types documenting the type name and the format of the data transferred under that name. That's it."

Oh yeah it has been in Windows since around Windows 1.0 or 2.0 I don't know but it has been at least 15 years.

v REALLY BAD adverts embedded in the text
by CdBee on Mon 24th Nov 2003 16:46 UTC
v REALLY BAD adverts embedded in the text
by Ben on Mon 24th Nov 2003 16:51 UTC
v RE: advertising
by Eugenia on Mon 24th Nov 2003 16:57 UTC
Fabulous article!
by MxCl on Mon 24th Nov 2003 17:07 UTC

This kind of article keeps me coming back to OSNews!

Anyway, as everyone I'm excited by the progress spawned by fd.o, especially in the regions of HAL and the new X Server.

KDE is a perhaps a little more separated from fd.o than GNOME, but I can assure readers that KDE is just as committed to producing an interoperable desktop as the other project members.

Now all we need to hope for is better vendor support for graphics hardware for the new (and old of course) X Server. From what I have read recently that's one thing the OSS movement lacks.

Re: Gee...
by Anon E. Moose on Mon 24th Nov 2003 17:07 UTC

Yeah, that's been in Windows since 2.0 (not 1.0). What difference does that make?

@Rainer Hayshem
by Kendall Bennett on Mon 24th Nov 2003 17:21 UTC

"Rayiner Hashem: What impact does the design of the new server have on performance? The new X server is different from Apple's implementation because the server still does all the drawing, while in Apple's system, the clients draw directly to the window buffers. Do you see this becoming a bottleneck, especially with complex vector graphics like those provided by Cairo? Could this actually be a performance advantage, allowing the X server to take advantage of hardware acceleration in places Apple's implementation can not?"

"Keith Packard: I don't think there's that much fundamental difference between X and the OS X window system. I'm pretty sure OS X rendering is hardware accelerated using a mechanism similar to the DRI. Without that, it would be really slow."

Maybe now you believe me that Apple's system *does* use the hardware accelerator to draw into the window buffers <grin>

Some very good points raised
by Richard Tough on Mon 24th Nov 2003 17:24 UTC

This is the best article I've read in a long time..well done Eugenia/Rayiner!
Some very good points raised, I look forward to what has in store for us in the future.

by Alex on Mon 24th Nov 2003 17:32 UTC

Havoc didn't understand anything about the autopackage project, that's really a shame, because it really is a great project.

Also, autopackage will use native .deb or.rpms if they exist.

Text to speech
by Kjartan on Mon 24th Nov 2003 17:36 UTC

You need gail, libgail-gnome, at-spi, gnome-speech, festival, and gnopernicus for this to work. Haven't tested it myself, but there you have the deps at least ;)

RE: Text to speech
by Eugenia on Mon 24th Nov 2003 17:38 UTC

I have gnopernicus and gnome-speech on my Slackware, I don't know about the rest.

@Kendall Bennett
by Rayiner Hashem on Mon 24th Nov 2003 17:47 UTC

Actually, no I don't. I don't think that Keith Packard was stating that as known fact, but rather just offering a conjecture. Apple does have a DRI-like model, but only for OpenGL, not Quartz rendering. Quartz 2D rendering, unless something has changed drastically in Panther without Apple hyping it, is still done via the CPU. In fact, the big improvement in besides Quartz Extreme (which we know is just the compositor) 10.2 was hardware acceleration of window scrolling (essentially a bit-blit). Nowhere in Apple's literature is anything about hardware acceleration of Quartz 2D mentioned (and it really is rather complicated --- you can't, for example, use the card's regular 2D line operations because they aren't anti-aliased). In fact, their SIGGRAPH presentation confirms that 2D rendering is done via the CPU ;)

Anyway, if the new X server gives us 2D via hardware, that will put it on par with Longhorn. I especially like the 6-month estimate that Jim Gettys gave ;)

PS> One further clarification. Raster was measuring the performance of Render vs imlib for a number of compositing operations. While a simple composit was much faster via Render (thanks to NVIDIA's hardware acceleration) anything that involved scaling was much slower. My guess is that NVIDIA's acceleration only covers the simple case of non-scaled compositing. This would certainly make sense --- since the primary user of Render (Xft, which uses it to compose AA text) doesn't use any scaling features.

A few questions.
by Alex on Mon 24th Nov 2003 17:47 UTC

One question that has really been bugging me is: When will the new X server be ready for the public, estiamted time?


How long will the release cycle for KDE 3.3 be? (I really hope it is no longer than 6 months).

RE: A few questions.
by Eugenia on Mon 24th Nov 2003 17:55 UTC

1. About a year, I would bet.
2. About six-eight months after the 3.2, I would think.
No one has hard numbers yet.

Nothing wrong with RPM
by Kick The Donkey on Mon 24th Nov 2003 17:58 UTC

Havoc's statements are exactly right with RPM. Nothing wrong with file, package, or format. Its the ui and implementation that is shoddy.

by Rayiner Hashem on Mon 24th Nov 2003 17:59 UTC

@Alex. Well, KDE 3.2 will take at least until late january from the looks of it, so I'd peg KDE 4.0 at about a year from now.

the "new" X
by maceto on Mon 24th Nov 2003 18:37 UTC

Anyone up for a build and get this out to the masses. not CVS access, but some debs or rpm`s?

by Rich on Mon 24th Nov 2003 18:39 UTC

I love the talk about the new X server and the HAL project (and finally a real device manager, yay!)

Great article!

by win95_still_good on Mon 24th Nov 2003 18:56 UTC could someone explain exactly what the new x server is trying to accomplish? Ive heard performace and better graphics but im not really sure what that means

Text2Speech works
by jmf on Mon 24th Nov 2003 18:59 UTC

[rb0.7]# festival
Festival Speech Synthesis System 1.4.3:release Jan 2003
Copyright (C) University of Edinburgh, 1996-2003. All rights reserved.
For details type `(festival_warranty)'
festival> (tts "/usr/share/apps/LICENSES/GPL_V2" nil)
[... listen and enjoy ...]
SIOD ERROR: control-c interrupt
closing a file left open: /usr/share/apps/LICENSES/GPL_V2
festival> (quit)

RE: Text2Speech works
by Eugenia on Mon 24th Nov 2003 19:03 UTC

The way you present it here, this text2speech is _not_ part of the desktop usability embedded automatically on all apps (which is what the question asks), you have to give it a text file to read.
BTW, my fedora has a festival driver app, but not "festival" itself.

Re: Gee... (@Nick)
by Aaron J. Seigo on Mon 24th Nov 2003 19:13 UTC

Well, the mime type issues, even for DnD, isn't as desperate as it sounds. Both KDE and GNOME understand MIME types and have their own MIME type databases; they also tend to use generally the same mime type settings for DnD, more so internally than between the various implementations. And therein lies the problem: each desktop has its own set of mimetype definitions. So if you use apps from just one desktop, or are selective in which apps you use, you have few to no problems.

What has been lacking is a MIME type database/registry and a set of standardized types for DnD (and by extension cut 'n paste) that everyone shares. FD.o is currently working on defining those standards. This is just like how FD.o has standardized other (meta)data registries and definitions, such as the .desktop file hierarchy or icon themes. This will lead to both better interop between the UNIX desktops as well as more consistency between individual apps as we'll then have a common deffinition to point to when some app get its wrong.

The UNIX desktop is coallescing (as opposed to fragmenting). Tomorrow's versions of KDE and GNOME will work even better together than today's versions. This seems to be the opposite direction that closed source systems generally go in, isn't it.

RE: RE: Text2Speech works
by jmf on Mon 24th Nov 2003 19:22 UTC

Sorry, there is nothing like text2speech (my invention)
festival can do more than my example, not only read the file from a texte, for example :

Doing stuff
(SayText TEXT) Synthesize text, text should be surrounded by double quotes
(tts FILENAME nil) Say contexts of file, FILENAME should be surrounded by double quotes
(voice_rab_diphone) Select voice (Britsh Male)
(voice_ked_diphone) Select voice (American Male)
festival> (SayText "Great interview from OSNews"

I can't comment how it is embedded in Gnome, KDE or wether it is present on Fedora (I use none of them)

I just presented the basic tool which does the work.

Yes Aaron
by Rahul Sundaram on Mon 24th Nov 2003 19:26 UTC


Yes. You are right. Gnome and KDE are converging. one significant area that I find no roadmap for converging is kparts/bonobo. I am happy that fd.o is a work being accepted by free desktops without much ego clashes. End user must be able to use KDE or Gnome apps without worrying about any interoperability problems. That is the goal we are working towards.


RE : Text to speech
by Tyr on Mon 24th Nov 2003 19:26 UTC

You need gail, libgail-gnome, at-spi, gnome-speech, festival, and gnopernicus for this to work. Haven't tested it myself, but there you have the deps at least ;)

I just got it to work on my FreeBSD 4.9 box. I needed to install on top of my relatively standard install :

festival-1.4.1_1, festlex-oald-1.4.1, festvox-kal16-1.4.0, and I upgraded to libaudiofile-0.2.4

possibly some other ports were installed along with this, didn't keep a log.
Also after installation I needed to modify /usr/local/share/festival/lib/init.scm to select the correct audio routines (commenting out options for windows and linux) - this avoids those SIOD ERROR messages.

v GNOME _still_ isn't integrated
by Anonymous on Mon 24th Nov 2003 19:26 UTC
RE: Anon E. Moose
by Nick on Mon 24th Nov 2003 19:29 UTC

All that I am saying is that Linux claims to be ahead on the inovation front, but yet the simplist things that Windows has had for 15 years seem to escape Linux.

Great article
by Aaron J. Seigo on Mon 24th Nov 2003 19:29 UTC

Today I remembered why I keep osnews on my bookmark bar: the interviews with people in the trenches. Thanks to both the interviewers and the interviewed for a great read and a great expose of what's up in Open Source desktop world. =)

It really seems we've turned a pretty important corner: up 'til now we've been largely playing catch-up and "clone the leader". With enough work done to have created a viable desktop, we're now able to stop and do some introspection. It's visible in this article how the community is consciously addressing the issues of interop and consistency while also probing into new areas of functionality and capability. This bodes well and makes for exciting times.

Wow nice artilce
by None on Mon 24th Nov 2003 19:32 UTC

This is SO much better than anything I've seen in a long time on OSNews. After seeing "review" after review of what writers do and don't like about every distribution its really nice to see something on such a wide variety of important topics. It's also nice because its just not one person droning on subjectively. Really a nice article and doesn't make me think the site should have been named More factual technology articles and less opinionated ones are the way to go.

file types
by scogan on Mon 24th Nov 2003 19:36 UTC

So, mime-types then? What exactly is wrong with using mime.types like everything else? And these folks are supposed to lead us to linux desktop nirvana?

v Only on OSNews...
by Anonymous on Mon 24th Nov 2003 19:38 UTC
On packaging
by Mike Hearn on Mon 24th Nov 2003 19:39 UTC

First of all, thanks to Eugenia and Rayiner for a great read. Let's take a look at where autopackage was mentioned.

The argument that RPM is sufficient is worth examining. The theory goes that you can have a single RPM that works on all distros. That's sometimes true, and in those cases, great. Of course it won't integrate quite as nicely on Debian or Gentoo but tools such as alien do exist and using them is not such a hardship.

The problems come when it's not possible to have a single RPM. Typically that's because:

* The metadata used by the distributions is different.
* Different glibc versions are used.
* Files and libraries need to be put/registered in different places

(2) is kind of a red herring, there's nothing inherant in RPM that makes this a problem, but the RPM build tools don't really warn you about it or make it easy to avoid. Maybe in future apbuild will be more widely used, and this will become less of an issue (it will always be a compromise).

(1) and (3) can cause problems. RPM cannot have multiple sets of metadata, the format and tools don't allow it and extending them to do so would be problematic. If distro A calls the Python runtime "python" and distro B calls it "python2" then you have a thorny problem.

Let's not even go into the issues of Epochs and such.

(3) is not often so much of an issue, but it can be sometimes and RPM doesn't make dealing with it easy. You could move them/munge them in post-install scripts, but then the file ownership metadata is wrong and so on.

These things cause the RPM culture to be one of "one RPM for one version of one distro". Part of the hope is that a new installer framework will start with a new culture - one of binary portability. While it's true that RPM works fine on Solaris, how many Solaris RPMs have you seen on the net? I haven't seen any. I'm not interested in making a new package manager with a new format, I'm interested in making installers that work "anywhere" (restricted to linux/gnu).

There are other advantages to using autopackage I guess, none of them seriously important. You can mix source and binary installs more easily. I think the specfile format is nicer. I'm not interested in getting into a pissing match over features though, it's not worth the effort.

The final thing to note is that autopackage is an installer framework, not a package manager. Yes, at the moment you have the whole "package remove" command thing going... in future I'd like to eliminate that stuff and go 100% with RPM/DPKG/portage integration. It's technically possible to have "rpm -e whatever" work fine with stuff not installed by RPM, so we might as well remain consistant and do it.

It's been years and we still have RPMs being built and rebuilt constantly, with millions of different files for different distros - if it's possible to unify that so the job only has to be done once, is that not worth a shot? I think it is. Maybe one day Havoc will agree with me ;)

by Rayiner Hashem on Mon 24th Nov 2003 19:39 UTC

Its not a matter of just using mime types, but agreeing on what mime types to assign to different data.

RE: file types
by scogan on Mon 24th Nov 2003 19:40 UTC

and in response to Aaron J. Seigo: mime types are registered with IANA ( There is already a standard.

@ Nick
by dpi on Mon 24th Nov 2003 19:42 UTC


"All that I am saying is that Linux claims to be ahead on the innovation front, but yet the simplist things that Windows has had for 15 years seem to escape Linux."

We can't all be first, right? ;) Linux != XFree86.

Great interview
by Sagres on Mon 24th Nov 2003 19:44 UTC

But perhaps you could have roughed up the HAL guy a bit more, there were some things like when you ask him how portable is the HAL over other kernels and he says it's OS agnostic but doesn't really give any details. Also if it's required to have a kernel interface how are they going to port it to closed source or/and non-unix OSes?
Also if you're going to ask them to compare against quartz you could also have asked them about fresco and directfb.
Another thing that comes to mind would be asking the gnome and kde guys when are they going to make their software independent from the graphics lib (for X haters of us ;-)
But anyway, great interview, keep up the good work.

Yay, composition engines
by BlackCat on Mon 24th Nov 2003 19:50 UTC

Great article. It's great to see that such an all-star programming cast has rallied around

I just bought an video card with 128MB video RAM, so bring on the composition engine ;) What's really neat is that it's still the same ole' X, so if you want to use your grandfather's XFree86 3.3.6 you can, and all applications will work. But if you've got the hardware, go with the X Server. Wouldn't it be ironic if by the time Longhorn hits the street composition engines would be considered old hat, "that's so 2004, even Debian has had one for years" ;)

Great Interview
by Markus on Mon 24th Nov 2003 20:06 UTC

This is one the very best articles I've read on OS News. Well done ;-)

by Aaron J. Seigo on Mon 24th Nov 2003 20:17 UTC

I'm perfectly aware of the IANA MIME type registry. KDE has a few MIME types of their own registered there. This isn't a problem of saying "OK, if it is a MS Word file we agree to use
application/msword and expect the file to have a .doc extension." It goes much deeper.

For instance: when we aren't dealing with a file, but a chunk of data, what mimetypes do we use? e.g. If I drag and drop an image that is also a clickable link what MIME types should be used, and in which order should they be presented? If I drop it on a graphics app, it should probably display the image for editting. But if I drop it on a web browser, perhaps it should should load the URL in the link. In this case, both a link and an image MIME type should (IMHO, anyways =) be provided in the DnD information and that behaviour should be standardized. Furthermore, should all DnD'd graphics have both a raw bitmap type available (which all apps should be able to use, theoretically) as well as the actual graphic format it's stored in (e.g. image/jpeg or image/png)? The questions aren't that hard, but the answers need to be standardized so that we don't have multiple answers that may all be slightly different and therefore a block to interop (which is the current situation).

Another example: when I have a MS Word document, which application should be launched? mime.types doesn't provide that information (and shouldn't). Currently if I want to open it in KWord I need to define that in each desktop environment I wish to use separately. That's absurd. Or, when I use Open Office Writer and it looks to the MIME type associations for what to do with a PDF file (for instance), it certainly doesn't look at the same information contained in my KDE settings. Ditto for Mozilla. Internally each is (generally) consistent, and they (generally) use the same IANA-defined MIME types (except for data types not registered with IANA), but between the various systems they aren't consistent. IANA can't fix that; mime.types won't address it; ergo the FD.o MIME type standardization.

by Nymia on Mon 24th Nov 2003 20:47 UTC

Nice article. Good work Eug and Ray.

I hope it becomes a trend.

Hear, hear
by Great Cthulhu aka Archie Steel on Mon 24th Nov 2003 20:58 UTC

I want to add my voice to those congratulating OSNews for this fine piece of journalism.

re: Hear, hear
by chazwurth on Mon 24th Nov 2003 21:13 UTC

Me too.

Great job, and thanks for a fantastic article.

by Jean-Marc Liotier on Mon 24th Nov 2003 21:45 UTC

Excellent interview with extremely interesting technical insights... I want more !

v Mod down
by bob on Mon 24th Nov 2003 21:57 UTC
File associations
by AnonaMoose on Mon 24th Nov 2003 22:16 UTC


Hmmmm this has always seemed rather hard in a Linux distro, i mean i click on a HTML page in Mandrake 9.0 and get a HTML editor ! I don`t quite know why they did this when 99% of the time you would want to view it and not edit the thing *sigh*
Then the fun begins, you want to change the association well good luck as I`ve yet to make it work (maybe this has become more refined now i`ll buy a new distro soon)
It`s little things like thiis that we should be fixing aswell as big things like X.

@Anon E Moose
Well it`s good to see my relatives are interested in this too :p

Just my two cents, thank you all for your time.

by Kar120c on Mon 24th Nov 2003 22:16 UTC

"All that I am saying is that Linux claims to be ahead on the inovation front,"

If the kernel's talking to you and making boasts about itself, I think its won the claim to inovation. If you're talking about 'people' making that claim, no shit. I don't care what platform it it, people spouting off about how innovative they are almost inevitably overestimating both themselves and whatever they're talking about, no matter if we're speaking of windows, linux, or almost any other field in the world. I don't think I've seen anything in the computing field that I'd actually call innovative on any operating system since Clippy burst onto the scene.

Re: Nick
by Anonymous on Mon 24th Nov 2003 22:31 UTC

"All that I am saying is that Linux claims to be ahead on the inovation front,"

Linux never claimed to be innovative. They're just working on what they think they should. They've never bragged about "OMG look at us we're so innovative!!!"
This in contrast to Microsoft, who does claim to be innovative but really isn't.

"but yet the simplist things that Windows has had for 15 years seem to escape Linux."

And in other news, the simplist things that Unix has had for 15 years seem to escape Windows.

All I can say is: so what? What matters is that it's here NOW. Whining about how Windows has had it for x years won't change a thing.

v The most interesting thing about this interview is ...
by scsimodo on Mon 24th Nov 2003 22:34 UTC
Is this going to be a fork of XFree86?
by Gogs on Mon 24th Nov 2003 23:05 UTC

I seem to recall a while ago that there was a very public falling out between Keith P and the XFree86 team. I'm curious as to whether the changes/improvements to X being discussed here will be merged back into the main X tree, or if it will become a completely separate release.....


RE: Is this going to be a fork of XFree86?
by Eugenia on Mon 24th Nov 2003 23:07 UTC

It will be a seperate release, but not a fork. The core of the new X Server (the server is called XWin I think, the core is called Kdrive) is rewritten by Keith and other major parts are also re-written, so they are not forked off XFree86. In fact, there are some new parts now, that XFree86 doesn't have at all. Other parts of XFree86 though, like drivers, some exteensions etc, will be forked off indeed.

@IS this going to be a fork
by Rayiner Hashem on Mon 24th Nov 2003 23:08 UTC

Appears to be a complete rewrite actually. All this new stuff is based on kdrive, Keith Packards own X server. I don't know what the plans for folding it back into XF86 are. All of this is still very experimental.

RE: Is this going to be a fork of XFree86?
by Gogs on Mon 24th Nov 2003 23:17 UTC

Any idea about how fonts are going to be handled i.e. will there have to be a rewrite of freetype qt gtk+ as well, or will kdrive be backwards compatible?

Now, lets organize and get to work
by Eric on Mon 24th Nov 2003 23:47 UTC

Lets see who can build the new Linux UI first.

1) Fonts will almost certainly be handled through Xft2 + the Render extension. There is no point rewriting freetype --- its damn good already.

2) There will be no rewriting of Qt or GTK+. If that was the case, this new server would never make it. KDrive is just another X server, it speaks the same X protocol, so all X apps will be compatible with it. However, toolkits will need to be modified to take better advantage of the new server's functionality. For example, it would be nice to have GTK+ and Qt render through Cairo natively. According to the interview answers, some additional coordination will probably also be necessary to fix the opaque resize problem.

/. and Gentoo
by dpi on Mon 24th Nov 2003 23:59 UTC

This article in linked at /.
Contains a few (imo) interesting comments.

If you're running Gentoo and would like to run/test check this out

by jonathanbearak on Tue 25th Nov 2003 00:23 UTC

At the bottom of the interview with Havoc Pennington, Eugenia notes that screenreader is greyed out in Fedora. I am running Fedora, and saw the same thing. It says that gnopernicus must be installed. Therefore,
yum install gnopernicus
and text-to-speech works.
While it's cool, it's also annoying as hell -- talks too much, you could say. Does anyone know of another way to access the underlying text-to-speech software? It would be incredibly useful if I could paste text into a textbox and press read. (Like Simpletext on MacOS 7+.)

RE: text-to-speech
by Eugenia on Tue 25th Nov 2003 00:36 UTC

This is why I mentioned Mac OS X. Because the way OSX does it is far better than text2speech on a seperate app. The speech itself can be triggered from the app itself. For example, on the TextEdit, you can select a piece of text, right click on it, and select "start speaking". It feels more integrated to the OS, and doesn't make people with usability problems feel forgotten and forced to use a third party app.

very good
by andi on Tue 25th Nov 2003 00:39 UTC

article, very interesting in-deth informations.

shocking for me noticing that os-x doesnt use 2d-hardware acc! why is apple throwing away the speed-gain ?

Re: Great interview
by Deb Ian on Tue 25th Nov 2003 00:58 UTC

> Another thing that comes to mind would be asking the gnome
> and kde guys when are they going to make their software
> independent from the graphics lib (for X haters of us ;-)


That was the sound of the point of the article going over your head.

Text-Speech, Screen reader, etc
by Anonymous on Tue 25th Nov 2003 01:03 UTC

Eugina you need to "gok" package for the screen reader functionality to work. You distro should be able to resolve its dependencies for you. Good luck.

RE: Text-Speech, Screen reader, etc--Correction.
by Anonymous on Tue 25th Nov 2003 01:27 UTC

Ah silly me, I just realized you need gnome-speech, gnome-mag and gnopernicus. Sorry if this has already been mentioned.

Good job
by Fredrik on Tue 25th Nov 2003 01:49 UTC

Great article.

About the XServer/XFree86/Kdrive confusion:

Kdrive was initially a heavily modified version of XFree86 to allow it to run on low-memory devices such as handhelds. It uses as little memory as possible by performing a lot of calculations at runtime instead of storing it in memory. Due to the high load latencies (relative to clock speed) of modern hardware, this actually becomes a speed optimization in some cases. It has less code duplication with the kernel (although there's still work to do in that area, but it needs sync with the kernel guys). The internals are also cleaned up and it's supposed to be easier to work with and modify.
For these reasons, Keith Packard chose to base his new efforts on Kdrive rather than just copying the source tree from At some point it was renamed to Xserver (not XWin, that is a just a website as the title at says. And it looks pretty dead now, but fd.o is hosted there).
Xserver doesn't support everything XFree86 does. Most of these features are useless anyway (like PIE, Ximage and a bunch of other obsolete stuff). The driver modules are gone too (Xserver is more like Xfree86 3.x with separate servers for each card). That's not too bad since the graphics driver infrastructure in linux is in great need of an overhaul anyway.
X bloatedness was overrated to begin with, but with the new Xserver + the new X C bindings things will get even leaner.
Another nice fact is that the "unsnappines" of X is being solved, on two different fronts using two different approaches and we will end up with the benefits of both.
As XDirectFB shows, reducing the number of expose events significantly improves the feel of the desktop. Xserver will have that, and combined with the kernel CPU scheduling efforts by Andrew Morton, Nick Piggin, Con Calivas and others things will get supersnappy and ultrafast. Like running TWM on a supercomputer. ;)

Am i the only one that thinks that Keith Packard looks like Steve Ballmer (minus the sweaty armpits and the monkey dance) ?? ;)

RE: Good job
by ACK!! on Tue 25th Nov 2003 01:56 UTC

That is an incredible summation. Thank you very much.

Does the Xserver conform to standard X guidelines?

This is interesting because if not it might be difficult for the standard commercial unix folks trying to get some of the gnome stuff to compile around specific linux hooks and such.

It sounds very interesting and I really hope they get the card support rocking and distros start switching.

Speed is king.

by Rayiner Hashem on Tue 25th Nov 2003 02:12 UTC

Apple does use hardware acceleration, but in very limited cases. It uses bit-blit acceleration for stuff like scrolling, so the CPU isn't stuck moving large blocks of pixels around. They also use OpenGL, of course, to composit those transparent windows together.

However, they don't appear to use acceleration for stuff like line or polygon drawing. Current hardware has a sharp divide between 2D and 3D components. The 2D components traditionally used by Windows, MacOS, and X, don't support anti-aliasing or alpha blending (transparency), or gradients or anything like that. Since OS X uses very high-quality vector graphics, with everything anti-aliased and transparent and whatnot, it can't use the existing 2D acceleration, except for the aformentioned bit-blit functionality.

That's why everyone's going 3D, because even the cheapest 3D hardware supports that functionality. Unfortunately, taking advantage of that hardware is complex. Consumer level graphics cards are game oriented --- they often make quality compromises (unacceptable for high-quality 2D), and aren't designed to handle more than one rendering application at a time. Overall, its just a hard problem to solve.

by SashaCohenRocks on Tue 25th Nov 2003 02:24 UTC

Longhorn is 3 years away, and I really do hope that the OSS community can throw out something just as good, UI wise.

Video RAM and gaming
by Spark on Tue 25th Nov 2003 02:40 UTC

First of all, great article!

How about gaming though. If some of the video RAM is taken, will this reduce the available video RAM when running a game? Or will it just automatically swap out the unused stuff when necessary until the game is closed and the window contents are required again? I also wonder where it would swap it to and how much of a performance penalty this would be if it happend during a game. ;)

by Incognito on Tue 25th Nov 2003 03:05 UTC

I hope Keith and can figure out what Mike is trying to accomplish with Autopackage. It seem obvious from Keiths comments that he doesn't get it. Installing packages was the first wall I hit when I first tried out linux. If we want people to take Linux seriously as a desktop system something like Autopackage is sorely needed. My hats off to Mike Hearn and all the contributers for all their great work. Keep It Coming!

by Incognito on Tue 25th Nov 2003 03:06 UTC

Err it was Havoc who commented on autopackage not Keith. My bad!

by Rich on Tue 25th Nov 2003 03:19 UTC

>> Am i the only one that thinks that Keith Packard looks like Steve Ballmer (minus the sweaty armpits and the monkey dance) ?? ;)

You mean Jim Gettys?

Yeah, that's what I thought! ;)

v why wait??
by Anonymous on Tue 25th Nov 2003 03:22 UTC
by John Blink on Tue 25th Nov 2003 03:53 UTC

I think GNOME and KDE should focus on kdrive more and more, make it difficult for even UNIX's not to use it.

I am hoping this will become the best desktop and high performance workstation solution.

My reason is simple, make and irrelevant.

RE: John Blink
by ACK!! on Tue 25th Nov 2003 04:12 UTC

make and irrelevant.

Especially the X folks but I feel you on the Xfree thing too. People however emphasize X windows too much and ignore that everything from the application to the window manager back to the widget class itself can make things feel slow in the X world.

That is not ignoring the problems with Xfree86 at all. I just hope we do not get too wrapped up in this whole thing only to realize very small eye candy style gains and be left in a hardware support mode worse than before.

Ok, that being said I think we can only hope commercial *Nixes jump but you have to realize the whole network model is actually a part of X that is used in the corporate *Nix world.

The old stuff that people always complain of as cruft is commonly used out there in the old school corporate Unix world and has to be supported before the big boys will play ball.

With my display exported logged into a box over the lan I commonly brought up gui admin tools like Netbackup gui or the Veritas system tools.

@Rayiner Hashem
by Anonymous on Tue 25th Nov 2003 08:30 UTC

That's why everyone's going 3D, because even the cheapest 3D hardware supports that functionality. Unfortunately, taking advantage of that hardware is complex. Consumer level graphics cards are game oriented --- they often make quality compromises (unacceptable for high-quality 2D), and aren't designed to handle more than one rendering application at a time. Overall, its just a hard problem to solve.

Any idea if any of the major PC 3D vendors have any plans to support virtualized GPUs the way SGI did? This would seem to solve the multiple apps rendering issue...unless I'm thinking of something entirely different.

by Rayiner Hashem on Tue 25th Nov 2003 08:55 UTC

Yep, it would, but I have heard absolutely nothing about this. The nice thing, though, is that its more a matter of what software developers want rather than what hardware developers plan. If 3D accelerated desktops take of (with Longhorn), hardware manufactuers will put in support. The only catch is that we'd have to wait 'till 2006, and this seems like it will be ready before then!

by Peter on Tue 25th Nov 2003 11:50 UTC
> I love the talk about the new X server and the HAL project (and finally a real device manager, yay!)

me too, i agree! ;)

RE: virtualized GPUs ???
by John Blink on Tue 25th Nov 2003 13:16 UTC

virtualized GPUs ?

RE: Autopackage
by Reg on Tue 25th Nov 2003 14:13 UTC

I am really getting tired of people bitching about linux software installation.

The average windows users have a way of messing up their win* installation by installing/uninstalling a bunch of crap. More than half of these softwares never really get uninstalled, and Win* uninstallers most of time leaves files and entries about the software in the registry.

With that said I am sure rpm/deb could be improved on:

Standardize labeling, versioning and dependency conventions for software. Some packagers label, organize, and place varied dependencies for the exact same piece of softwares they package.
Check out freshrpms, atrpms, and ximian to name a few.

1. We could adopt java packages name space convention to solve this problem.
org.gnome.* or org.kde.*

The label version and dependency (internal) must come
from the developers/organization that create/provide the softwares.

Lets solve the real problem here!!
no standards.

@John Blink
by Rayiner Hashem on Tue 25th Nov 2003 16:08 UTC

SGI systems have virtualized their GPUs for awhile now. Basically, a virtual GPU means that the real graphics hardware is fully abstracted from the application, and the OS has full control over managing the HW. Just as Windows and Linux have virtual memory and a virtual CPU (preemptive multitasking), IRIX machines have a virtual GPU. You can throw more graphics pipes into the virtual GPU pool, and automatically get increased performance. Also, the abstract nature of the interface makes it easy to share the GPU among many concurrently rendering applications, just as preemptive multitasking makes it easy to share the CPU among concurrent applications.

I really like this
by Martin Häcker on Tue 25th Nov 2003 19:21 UTC

Congratulations to OSNews for this excellent article!

While I do think that some of the quesitons could have been a bit different, I really liked this article!

To make it short: This is why I really like to read OsNews! Keep it up!

cu Martin

RE: @Rayiner Hashem
by John Blink on Tue 25th Nov 2003 22:05 UTC

Thanks for the info Rayiner.

It makes me wonder if nVIDIA or ATI have this function for their non average consumer GPU's.

Re: autopackage
by Mike Hearn on Wed 26th Nov 2003 13:50 UTC

Standards: tried it, didn't work out too well. There was little appetite for such a thing. While Red Hat were enthusastic, Debian were cautious and Gentoo were also enthusiastic until internal politiking ended it, getting standards for package metadata was compared to me in private to "asking for world peace". There are archives on the net if you want all the gory details.

The autopackage approach doesn't require everybody to suddenly relabel millions of packages, good though that would be. Modern dependency trees are huge and standardising them all is very hard indeed. Maybe somebody else can do this, I don't know. If they can then best of luck to them.