Slashdot Mirror

Things are improving, however. For graphics/sound/control, use SDL.

For desktop integration, go with the Freedesktop.org menu spec.

And for package management, there's RPM, standardized by all LSB-compliant distributions.

Indeed the Gnome Devs already have realized that Longhorn should be next targetted. In fact, they've almost rendered your second complaint null and void. Could anyone miss this story from three days ago? As noted: the Gnome devs have the underpinnings of Gnome successfully implemented over a generalized vector rendering library, which will have as a backend a hardware accelerated composition library. This integration is the second step in the FOSS answer to your second warning. The first was SVG icons, which have been fully functional since Gnome 2.4. I can't speak for KDE, but I imagine they're reacting similarly.

Apple got to the advanced desktop first. FOSS will be second. I'll be surprised if Microsoft doesn't come in a slow third. Heck, Reiser 4 will be ready with metadata delivery long before WinFS is.

Cheerleading session over.

Um, isn't that pretty much what D-Bus is?

I like the shadow effect, but maybe that is here now, and I don't know it?

For that you need the X.Org X server with the XComposite extension enabled.

This is a big step forward. Something I've waited for a long time. If it is possible to unite all those vector-graphics efforts in cairo more time can be spent on "stuff that matters".

Well, I always hoped X11 would do this step but they seem to enjoy doing politics instead of standards... On the other hand this approach has some unique advantages:

• Platform independence: runs on win32 and linux, awaiting os x...
• Can work without X11...especially interesting in not-so-full-powered-configurations (directly via OpenGL)
• Independent... People at freedesktop seem to do the trick very well (they didn't get between the lines -- yet)

Interesting is, that there are also java-bindings that work together with SWT which is an interesting step (mono is already on board -- see previous comments)

So hopefully the time of ugly graphics in platform-independent OpenSource-Software is finally over... (just watch OpenOffice -- uaaahh)

Well, a last wish: If Qt guys come aboard, this means KDE is in which on the other hand means that gnome and KDE join on the same backend... just dreaming...

Have a browse around Direct Rendering Open Source Project for details of video cards with open source 3D drivers.

You are correct. We shouldn't waste our time trying to make everything the same. However, a lot of work has been put into having the same interfaces across the different desktops. Check out freedesktop.org for more information. It really does make sense to at least have standards between the interfaces, but one of the primary drawing points of Linux (at least as I see it) is the flexibility and choices available.

If only one ICQ client was worth using to you, how would you feel if that one client wasn't available because it wasn't "the standard Linux ICQ client"?

And ICQ has been pretty dead for pretty long. When did you last try Linux?

Oh, and, uh, cough, cough, SDL. Simple Dynamic Library. Does everything DirectX does, uses OpenGL as a background.

If you want to write a book for DirectLinux, which teaches people to use SDL, go ahead. But it'd be better to call it something like "SDL for Dummies".

Linux has games. UT, UT2003, UT2004, Doom 1, 2, and 3, Neverwinter Nights, Quake 1, 2, and 3, Rise of the Triad, Duke Nukem 3D... Go read this and come back when you've got enough info to justify such a long rant.

Linux distros aren't all that different to the application developer. I run Gentoo Linux as my distro. About 5 apps were developed specifically for it, and most of them were easily ported from other, more popular distros like Fedora and Debian. It takes about 5 minutes to port an app to another distro, 15 at most.

And I wouldn't want a "Standard Linux". Competition is healthy, and I'd rather be able to choose Gentoo Linux than be forced into, say, "Standard Linux" running on a Win2k kernel. But hey, you're free to create a new one, or go check out the free desktop project. Or maybe you should go "****" yourself.

Its called code reuse. Not done well, mind you, but MANY MANY linux distributions have the EXACT same problem.

Use all the same core libraries, but have teams work on pluggable GUI components that suit their taste.

It's fully possible to accommodate diverse ideas without having two huge, separate, disconnected communities.

As for stability, I've found dozens of bugs in Kmail and Konqueror. Most don't cause a crash, but they are still annoyingly incorrect operation.

Actually, the latest version of gtk-qt is pretty damn good. I think it has the potential to become a "standard" for KDE users once all the little bugs are worked out.

So far, Linux has made inroads in replacing old UNIX servers, just as BSD has

They both also succeeded replacing Windows-based server whose administrator got fed up with microsoft's products.
We see more Windows-to-Linux thant Linux-to-Windows server migration.
Linux and BSD are also used a lot in academics.
And Linux IS used on Dekstop even if it isn't as visible as it's other uses.

We're still using XFree86

... X.org, as pointed by other slashdotters...

which just recently gained the ability to change its own screen resolution without requiring a configuration file edit and restar

[CTRL] [ALT] [+] and [CTRL] [ALT] [-] since I installed my first distribution.
(You should have paid more attention to the manual).
Meanwhile, you had to use some hack to avoid rebooting Windows 95 in order the effect to take place...

. Desktop environments like KDE and GNOME are more interesting in adding more buttons and sidebars rather than implementing a universal API library for development

Then FreeDesktop.org doesn't exist, I think...

including binary installation/uninstallation

It's not desktop's purpose to implement installations. (Just like it's not DirectX's job either).

I think it's the exact opposite.
Almost all linux distributions have a package managment system (YaST, apt-get, emerge, drakrpm, yum ...)
Unless you want to use new version of a sfotware that isn't available yet in your distribution, you got a SINGLE place to uninstall unneeded packages, install new softwares that are optimised for YOUR distribution, and you can easily get updates for them.

Compare to windows where you have your Installation CD, Windows Update, separate installer that you must download from separate website for each software you want.
You must track updates alone for every single software you installed (do you remembre that small plug-in you installed 6 months ago in WinAmp and for which there's now a patch against a buffer overflow ?)

I really think PC providers (like Dell, HP, ...) should watch and learn. They could win a lot of clients if they had a single point for software acquisition/update like this...

a universal graphics/sound library for games

There's not only one, but a few of them.
Notable one :
- OpenGL : So good for 3D graphics that it's also used under Windows for games like thoses from ID software.
- SDL : 2D GFX/Audio library that is also used by windows programms (like emulators).

and clear interface design that doesn't borrow from Windows while complaining about it. KDE currently implements an integrated file browser/net browser, start menu, taskbar, and more. All popular Windows features

Most of the base of the design is borrowed from older Unices which where available long time before Windows.
KDE got most of them from the begining.

Even the parts that are inspired by Windows are much more configurable than windows.

Mono, currently the most promising prospect for a true future desktop Linux, is an implementation of Microsoft technologies.

1. Mono is not the only V

You might want to look at the Freedesktop Base Directory Spec. It defines the use of $XDG_CONFIG_HOME (default: ~/.config/) and $XDG_CACHE_HOME (default: ~/.cache/) as a root for applications to store their configuration data and temporary cached data, respectively. I would think that the app itself should ask you where you want to save data files and whatnot.

Few apps implement the spec, but hopefully that will change soon.

D3DX is regularily updated, GLU hasn't been updated in years

OpenGL 2.0 was released 7 September 2004.

The TODO list for the DRI driver has it mentioned in the Big Projects section.

1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."

if you feel you'd like to use ambiguous, case-insensitive filenames, you should be using a UI which handles that re-mapping for you. i want my tools to know that file abcde is different from file ABCDE. Please don't "fix" that feature!

2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.

But don't make this a part of UNIX, please! Sometimes you need to dig into a file's guts with a different tool than the one "associated" with that file type. Any sort of tight binding would be anathema to the flexibility and power that UNIX represents.

3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.

Here's an example from GNOME's Human Interface Guidelines. If you find a gnome app that doesn't meet that spec, you should file a bug against it (or fix it, if you have the skills/tools to do so!). For KDE, you might want to read relevant sections from their User Interface Guidelines as well.

Let's clean up the UI so that people who want a Windows- or Mac-style interface can have it, yes! but please don't take that as a shortcoming of UNIX. If it's a problem, it's a problem of the GUI layers that have been built on top of it. But whatever you do, please please please don't sacrifice the flexibility and power that undergirds the whole system!

theres no groundwork to allow Unix to surf the pervasive wave. instead there's only huge ancient walls which people have been waving their hands at for decades. the wall hasnt noticed. unix is a perfect multi-user base, except one flaw.

X needs a way to allow applications (wm's) to discern the source of input. Built off this core, window managers or X itself can hack solutions to craft "multiple cursors". (Ultimately the window manager is going to have to get deeply involved with this policy; I think the best solution is to simlpy expose the source of input and have the window manager hold state for each input-source and manipulate the single corepointer, "faking" multiple pointers. this prevents X from having to deal with drawing&policy (which is the wm's domain)). Currently the best interaction you can get is to mux together your inputs into one keyboard/mouse pair.

The multiple pointers in X problem has been around for a while, but no ones been able to crack it. X was simply never meant to have more than one cursor, never meant to assuming anything past a single keyboard and mouse.

The one plight of this solution is that every X input event would have to pass through the window manager, which I imagine is expensive.

synergy allows you to share input devices between computers (even cross platform) but the next logical step is missing.

All we need is some way to see the physical source of each input event.

There's no bigger achilles heel.
Myren

How does this compare to GStreamer?

"Actually, man, it will. Starting April 13. 2029."

http://www.freedesktop.org/~keithp/screenshots/
You are either dumb or you are lying. Probably the latter.

Composite will make things seem smoother, because of the way things get drawn in off-screen memory before being blitted on screen.

Composite doesn't really have much to do with drop shadows, per se. It allows windows to be moved off screen and for a compositing agent to draw them onto the screen as it likes.

Most (all?) drop shadow implementations currently use the RENDER extension to draw the shadows. All drivers (except the NVidia binary ones) implement RENDER acceleration through the XAA (X Acceleration Architecture) hooks. Currently XAA only really accelerates RENDER if you're compositing text (so xterm with AA fonts is faster). There aren't any hooks for "Blend this region onto the screen" yet -- it has been rumoured that those will be added soon.

Note that the Xserver with KDrive DDX does have hooks for doing blending and compositing onto the screen, and thus can draw drop shadows (amongst other things) fast on supported cards... It doesn't support GLX (or a bunch of other useful things like XvMC) though.

--ralpht

"freedesktop.org is a free software project to work on interoperability and shared technology for desktop environments for the X Window System. The most famous X desktops are GNOME and KDE but any developers working on Linux/UNIX GUI technology are welcome to participate. Find more X related software projects here."

This group has published several standards with this goal in mind.

Check out coLinux.

Installation is currently somewhat painful if you don't want to use a provided system image, but progress is definately being made.

Colinux + Xming (or your favorite X server for win32) = Windows and Linux applications running seamlessly side by side, with very little performance loss compared to running Linux natively.

(Don't let the last update of May on the front page fool you, check the snapshots for more recent updates, documentation also updated on the wiki site more often than anywhere else.)

coLinux can be installed as a system service that starts at boot. Put Xming in startup also, and on the Linux side add whatever you want to startup to contact the Xming session and go.

There's no fundamental reason why someone couldn't make a nice package that sets everything up automatically, it's just that so far as I'm aware, nobody has yet done any targetted application setup this way that I am aware of.

Cheers,

You just need to start GIMP with the --no-splash command-line option to suppress the splash screen. Or better yet, edit gimp.desktop so it works when GIMP is started from the menu. Since GIMP supports startup notification, your desktop can do whatever it wants to do to inform you about the startup.

gstreamer has all the bits, you just need to string it together.

I think that no matter how cool applications that use the Englightenment Foundation Libraries look, it will be a long time before we start to see many that actually use them. If you ask me, having an application that looks beautiful sharing desktop space with an app that doesn't look so good is just bad style. Imagine the last time you saw an old app with Motif widgets sitting next to a more modern application. Add Java apps into the mix and it looks like a complete mish-mash. Blech!

If free software is to compete with modern OS's like MacOS and Windows, it will need to have applications that don't aesthetically clash. E17 is no solution unless all programs are magically rewritten to use the EFL's.

Would it be possible to design GTK and QT themes that use the Enlightenment Foundation Libraries to draw widgets? Sort of like what gtk-qt does?

Give it a try and you'll understand. I used to use Fluxbox a lot, but being only a WM it's rather limited in what it can and can't do. I then moved to KDE, whose interface i loved but was dog-ass slow. From there i moved to GNOME, which was still dog-ass slow, and while it's interface is not as polished as KDEs, it looks (for me) a whole lot better.

Now i'm settled with XFCE 4, and i have to say is the first time i've ever been really comfortable with an *NIX desktop enviroment. Think of it as being somewhere between a WM and a DE: it borrows the best from both worlds. XFCE looks much like GNOME, being GTK based, but it just *flies*. In fact, i'm pretty sure that if your system runs Fluxbox well it will also run XFCE well.

The latest XFCE release is major in the sense they've started to polish the weak spots in the design - there's now a nice session manager, better configuration options, more eye candy :) and sleeker interface overall. Desktop icons are being developed for those who asked for it aswell. It's also one of the more Free Desktop-compliants DE available. It does what it's supposed to do, with zero bloat. In fact, i think the GNOME crew should take a few hints from XFCE.

The only way to accomplish what you are proposing (running apps with gtk/qt flawlessly) involves an extra layer of code.

Yeah, specifically this code. : )

It's certainly a good start, but like you implied, it's a kludge. The real hope is that lots of other projects will join its parent group, and they finally start that severe revision, or even perhaps just deprecate one in favor of the other (I philosophically prefer GTK, but it seems Qt is winning, so oh well). Even better, maybe we can even sort out all the other toolkits, and eliminate redundant ones.

Look into X.org, they might not be ready for what you see... but you can always start working on your own.

As you can see, it's freedesktop.org where all the really great stuff is happening (and they're working with X.org, so that's good too). In fact, I wasn't just brainstorming some idea I made up on the spot; I've been interested in freedesktop.org for some time, and was trying to evangelize the idea of standardizing the technologies behind "the Linux Desktop" and getting some ubiquitous tools (such as this -- although I was thinking more along the lines of picking one format (such as plist) and deprecating all the others instead of trying to accomodate all of them).

Speaking of which, that's the one problem I see that's endemic to even the "unification" efforts: they're always about trying to support all the different legacy methods, instead of working on a replacement. Just look at gtk-qt and Config4GNU that I already linked to, as well as the package management article from yesterday -- always with the piling on extra layers. Sooner or later we're going to have to refactor our code instead of just adding to it, or else we'll be buried in cruft. I personally think we ought to start now.

The only way to accomplish what you are proposing (running apps with gtk/qt flawlessly) involves an extra layer of code.

Yeah, specifically this code. : )

It's certainly a good start, but like you implied, it's a kludge. The real hope is that lots of other projects will join its parent group, and they finally start that severe revision, or even perhaps just deprecate one in favor of the other (I philosophically prefer GTK, but it seems Qt is winning, so oh well). Even better, maybe we can even sort out all the other toolkits, and eliminate redundant ones.

Look into X.org, they might not be ready for what you see... but you can always start working on your own.

As you can see, it's freedesktop.org where all the really great stuff is happening (and they're working with X.org, so that's good too). In fact, I wasn't just brainstorming some idea I made up on the spot; I've been interested in freedesktop.org for some time, and was trying to evangelize the idea of standardizing the technologies behind "the Linux Desktop" and getting some ubiquitous tools (such as this -- although I was thinking more along the lines of picking one format (such as plist) and deprecating all the others instead of trying to accomodate all of them).

Speaking of which, that's the one problem I see that's endemic to even the "unification" efforts: they're always about trying to support all the different legacy methods, instead of working on a replacement. Just look at gtk-qt and Config4GNU that I already linked to, as well as the package management article from yesterday -- always with the piling on extra layers. Sooner or later we're going to have to refactor our code instead of just adding to it, or else we'll be buried in cruft. I personally think we ought to start now.

The only way to accomplish what you are proposing (running apps with gtk/qt flawlessly) involves an extra layer of code.

Yeah, specifically this code. : )

It's certainly a good start, but like you implied, it's a kludge. The real hope is that lots of other projects will join its parent group, and they finally start that severe revision, or even perhaps just deprecate one in favor of the other (I philosophically prefer GTK, but it seems Qt is winning, so oh well). Even better, maybe we can even sort out all the other toolkits, and eliminate redundant ones.

Look into X.org, they might not be ready for what you see... but you can always start working on your own.

As you can see, it's freedesktop.org where all the really great stuff is happening (and they're working with X.org, so that's good too). In fact, I wasn't just brainstorming some idea I made up on the spot; I've been interested in freedesktop.org for some time, and was trying to evangelize the idea of standardizing the technologies behind "the Linux Desktop" and getting some ubiquitous tools (such as this -- although I was thinking more along the lines of picking one format (such as plist) and deprecating all the others instead of trying to accomodate all of them).

Speaking of which, that's the one problem I see that's endemic to even the "unification" efforts: they're always about trying to support all the different legacy methods, instead of working on a replacement. Just look at gtk-qt and Config4GNU that I already linked to, as well as the package management article from yesterday -- always with the piling on extra layers. Sooner or later we're going to have to refactor our code instead of just adding to it, or else we'll be buried in cruft. I personally think we ought to start now.

The only way to accomplish what you are proposing (running apps with gtk/qt flawlessly) involves an extra layer of code.

Yeah, specifically this code. : )

It's certainly a good start, but like you implied, it's a kludge. The real hope is that lots of other projects will join its parent group, and they finally start that severe revision, or even perhaps just deprecate one in favor of the other (I philosophically prefer GTK, but it seems Qt is winning, so oh well). Even better, maybe we can even sort out all the other toolkits, and eliminate redundant ones.

Look into X.org, they might not be ready for what you see... but you can always start working on your own.

As you can see, it's freedesktop.org where all the really great stuff is happening (and they're working with X.org, so that's good too). In fact, I wasn't just brainstorming some idea I made up on the spot; I've been interested in freedesktop.org for some time, and was trying to evangelize the idea of standardizing the technologies behind "the Linux Desktop" and getting some ubiquitous tools (such as this -- although I was thinking more along the lines of picking one format (such as plist) and deprecating all the others instead of trying to accomodate all of them).

Speaking of which, that's the one problem I see that's endemic to even the "unification" efforts: they're always about trying to support all the different legacy methods, instead of working on a replacement. Just look at gtk-qt and Config4GNU that I already linked to, as well as the package management article from yesterday -- always with the piling on extra layers. Sooner or later we're going to have to refactor our code instead of just adding to it, or else we'll be buried in cruft. I personally think we ought to start now.

The only way to accomplish what you are proposing (running apps with gtk/qt flawlessly) involves an extra layer of code.

Yeah, specifically this code. : )

It's certainly a good start, but like you implied, it's a kludge. The real hope is that lots of other projects will join its parent group, and they finally start that severe revision, or even perhaps just deprecate one in favor of the other (I philosophically prefer GTK, but it seems Qt is winning, so oh well). Even better, maybe we can even sort out all the other toolkits, and eliminate redundant ones.

Look into X.org, they might not be ready for what you see... but you can always start working on your own.

As you can see, it's freedesktop.org where all the really great stuff is happening (and they're working with X.org, so that's good too). In fact, I wasn't just brainstorming some idea I made up on the spot; I've been interested in freedesktop.org for some time, and was trying to evangelize the idea of standardizing the technologies behind "the Linux Desktop" and getting some ubiquitous tools (such as this -- although I was thinking more along the lines of picking one format (such as plist) and deprecating all the others instead of trying to accomodate all of them).

Speaking of which, that's the one problem I see that's endemic to even the "unification" efforts: they're always about trying to support all the different legacy methods, instead of working on a replacement. Just look at gtk-qt and Config4GNU that I already linked to, as well as the package management article from yesterday -- always with the piling on extra layers. Sooner or later we're going to have to refactor our code instead of just adding to it, or else we'll be buried in cruft. I personally think we ought to start now.

I have pretty much the same system as you.

• Dell 8200
• NVidia 5700 LE
• Santa Cruz Audio
• Yamaha DB-XG50 synthesizer
• Parallel zip drive
• Epson Stylus Color 880

Pretty much everything worked out of the box for me on going from Fedora Core 2 to Fedora Core 3. The only breakage were things I expected to break.

• NTFS broke (and hung boot) until I upgraded the NTFS rpm
• Used the old NV driver until I built the NVidia driver
• Yamaha daughterboard doesn't work - a known ALSA issue

From an install point of view, some other software broke that in retrospect should have. I had to recompile my version of PHP since libcurl was upgraded. I had to recompile mod_perl-1.99.17 for my version of Apache. I had to move all of the GNU Java out of the way so that my Java applications would run. The GUI parts of mono broke since Gnome has been upgraded. And finally, mysql broke because Fedora Core 3 reinstalled the last version of mysql supplied by Redhat.

There are a lot of good things about the new release. Probably the most important from my viewpoint is that switching between KDE and Gnome no longer borks the menus. I think Gnome has fimally moved over to the free desktop specifications. While not perfect, I can now switch between desktops without too much menu breakage. I haven't tried editing the Gnome menu yet.

Most of the issues involved have to do with third party packages and not the Fedora Core 3 core. I build my own Apache. I install a lot of my own Perl packages. I install Java directly from Sun. The NVidia mess (not using udev) has been noted, and is pretty easy to fix.

Evolution 2.0.x is a mess. It's ugly, offers no summary view, no RSS, and no weather. In short, there's no reason to use it over any other mail client unless you have to go against an Exchange server. The lack of a summary view is particularly annoying in that I no longer can see at a glance what tasks I have, what the temperature is, how many mail messages I have not read, and of course what new stuff has been posted on Slashdot.

Fortuneately there are Firefox extentions that give me the RSS feeds and weather. Habari Xenu does the RSS feeds, and WeatherFox does the weather. Check out both from Firefox Extensions

One last nit. I've noticed that running Gnome applications under KDE carries my old Gnome wallpaper along with it. It's not visible in KDE, but when I log out the old wallpaper flashes on the screen. I wonder how much memory that costs me.

In short, a nice release, pretty painless upgrade, and a comfortable distribution of linux.

multiple applications that are hacked together to form one solution.

Most windows apps, even the ones out of redmond, have well kinda the same UI, but with a weird mishmash of funcationalty and styling.

Dockable menus, or non-dockable menus?
does crtl+insert work in this edit box, can I copy that text?
Try changing you background to something other that white, or deleting a default font and seeing how windows apps cope then windows is just as crap.

Oh, and take a look here .

What do I think should be done, well, standards need to be written and addeared to, a light xml parser needs to be put into stdc libraries allconfiguration files need to be moved to XML using dtd's (yuck) or xsd's to document and validate the format that those XML files must be in,
no more /etc/init.d/mydeamon restart to find out that there's a typo in the config file, since you can validate it against the dtd/xsd first.

Command line apps also need standards, is that -v -V --version -version, is that -help --help -help something.
is the help myapp -xyzABC or is the help
myapp
-x --xsomething here is a description of what the flag does.

is that quit, exit, crtl+c, escape ahh...

Linux, GNU et all need a kick up the arse, standards need to be written, and everything needs to be harmonized.

Isn't that exactly what http://freedesktop.org/ is all about?

ctrl-c & ctrl-v work in every app on my desktop

...and ctrl-x probably works in a lot of them as well.

And, given that Qt switched in Qt 3 to the closest thing to a standard way of handling the PRIMARY and CLIPBOARD selections in X, and that a number of other toolkits, including GTK+, have always done that, it would probably work even between applications using different toolkits in most if not all cases.

I.e., bitching about copy-and-paste in X11 is getting a bit old, at least for complaints about it not working at all, even for text. Perhaps for non-text formats there needs to be a bit more work in the toolkits and applications, but, as I remember, the selections mechanism in the ICCCM does have a mechanism to register data types and to have a recipient of data find out the types in which data in a selection is available, so they can choose the "best" type (e.g., it might be available as rich text or plain text, so that a word processor would fetch the rich-text version but a terminal window would fetch the plain-text version).

I'm not so sure about the bleeding-edge hardware problem you mention. I'm typing this on a Sony Vaio X505, which was supported perfectly out-of-the-box by Fedora Core 2 with recent updates. (With the exception of the wireless card, which needed one kernel-module RPM from a third-party repository.) With things such as laptop mode and SonyPI, for which the equivalent (to my knowledge) doesn't exist on Windows, Linux gives me a *clearly better* user experience with this particular laptop.

Anyway, my point is: Laptops have notorously been a problem with Linux in the past, but it seems to have gotten much better during the past year or two. And the other major area where people tend to want bleeding-edge hardware, namely 3d graphics, now sees the two major vendors putting out quality Linux drivers. Linus suggests in the interview that things are moving slowly, but in my experience as an end user things have gotten rapidly much better lately, especially on topics such as hardware support. And with developments such as HAL, that rapid improvement is set to continue.

working link to XCB

As for usability, note that 33 of those screenshots appear to be from the installer, which looks like it could have been taken from Debian (not sure on this). The remaining 109 appear to be from GNOME. Those could be duplicated on any Linux system having GNOME installed, including mine.

I think what you are looking for with respect to usability standards is available here: http://www.freedesktop.org/.

working link to XCB

S

While the desktops are updated, the updates aren't dynamic

This wouldn't be a problem if it can be modified to use the freedesktop.org X Composite Extension and X Damage Extension.

Half of my applications integrate with KDE, and half integrate GNOME. (Actually, a few integrate with nothing).

I pray every night that FreeDesktop will eventually save us from Multi-DE hell. Hopefully my prayers have been heard.

Try the GTK-Qt Theme Engine; with it, widgets in the GIMP (and GTK apps in general) look exactly the same as widgets in any other Qt app ;).

Only some of the xapps are in TLA -- most are in CVS. There are some projects using tla (most notably debrix), just as there are some projects using CVS and SVN. Officially, we're agnostic.

They forget those of us who have never heard of it before.

And those of us who have heard of it, but have no idea if its a good thing or not.

I noticed freedesktop.org has started using it to some degree. But like I say, I have no idea if thats a good thing. It is slightly inconvenient in that I have to go read yet some more docs to use it. :(

Also: wonder if this type of exploit had anything to do with the new patches in X 6.8.1: libXpm libraries http://freedesktop.org/bin/view/XOrg/Home#About_th e_X11R6_8_1_Release

The 2.7 series has been tracked in Debian experimental for a while, so 2.8 packages should be along shortly. I'd wait for that, it saves a lot of trouble. Alternately, you could try jhbuild.

A basic unit of currency in the Linux world is the distribution, as you have discovered. A distribution is essentially just a collection of packages which are, in turn, just compiled versions of (mostly) upstream sources. The thing that makes a distro what it is are the customizations made to the package sources and occasionally packages unique to the distro. All the big distros (ie the ones that matter) are fully open source though so technology which shows up in one pretty quickly migrates upstream somewhere, and then back down again to the other distributions.

That leaves the customizations made, and what exact packages are included by default. This is where problems start to appear.

The traditional solution taken to things that don't really fit into any obvious upstream project is for each distribution to roll their own code. In the past this has happened with menus, hardware detection/pluggability, GUI configuration tools, bootup scripts, and installers. There are others I probably forgot.

In the case of menus, KDE and GNOME used different systems so distributions, not wanting to do a million different files in each package for each individual desktop and window manager each came up with their own solution. Debian has some custom system that Mandrake then adopted as well, SuSE only really supported KDE anyway, Red Hat 8 introduced this thing called "vFolders" which was an aborted attempt at a desktop-neutral standard and was one of the first things specced out at freedesktop.org. Later vFolders was shown to have serious problems and was abandoned but not before being integrated upstream into GNOME (but not KDE!). Red Hat abandoned vFolders in Fedora Core 2 but upstream GNOME did not do the same. So now we're still at this point where while everybody has agreed on a standard, it's not actually implemented uniformly at all.

D'oh. What a mess. This sort of thing has been repeated over and over, whenever something didn't really fit into any upstream project. As time goes by more and more is being sucked upstream into projects like freedesktop.org ... hardware detection is now being handled by HAL (though there is some internal resistance from SuSE who have a .... surprise .... custom solution called suseplugger), network config scripts are destined for replacement by NetworkManager if Red Hat have their way, etc etc.

So ... the random hacks different distros use to tie these disparate pieces of code together are gradually disappearing. This is good. It does, however, leave the second problem:

What packages are included? This is a bigger issue than you may think. There really is no such thing as the "Linux platform". There are small, mostly stable subsets like GNOME and KDE but this is the exception rather than the norm. Specialised libraries like pcre, OpenSSL, libpng and so on which aren't affiliated with any central project policies tend to break backwards compatibility all the time - often it could have been avoided. Each time this happens, you need a new parallel installable package that other packages can depend upon.

Typically, distributions are recompiled entirely on each new revision. So let's say that libfoo breaks backwards compatibility. The new version is included in the new distribution version, all the packages are recompiled or patched to use it, and now the old version isn't included any more.

This has the unfortunate side effect that you cannot make any assumptions about what features are available on any given Linux system beyond some really basic base libraries like libc, Xlibs etc.

Worse, even projects like GNOME and GTK+ often refuse to avoid breaking applications if they deem them "buggy" or "broken", which tends to have a very wide definition. So, the net result

the video-whale project [gstreamer.freedesktop.org]

somebody else already mentioned using X with the Xinerana extension for this, but if you have any spare PCs lying around, you can throw Gstreamer into the mix, and build a gigantic video-wall, without the PCI-limitation.
here's the howto