Slashdot Mirror

It appears David has been working hard over there at Novell to get this into the community quickly perhaps. With some rapid development, I hope this helps people decide next year between Vista "A" $200, "B" $350, or "C" $500 and openSUSE $0.00 + shipping.

It appears David has been working hard over there at Novell to get this into the community quickly perhaps. With some rapid development, I hope this helps people decide next year between Vista "A" $200, "B" $350, or "C" $500 and openSUSE $0.00 + shipping.

Why didn't the free software community develop anything as good as OS X?

They did. They developed GCC, which Apple uses in OS X. They devleoped Samba, which Apple uses in OS X. They developed CUPS, which Apple uses in OS X. Even if you don't use those subsystems (and you probably do) if Apple had to build all that from scratch then they wouldn't have had the resources to build the other good bits in OS X like Aqua. So all OS X users owe a great deal to the Free Software community for making OS X worth using.

Aside from our direct help, Apple still had an easier time of it than the Free Software community. The Free Software community has had to build literally everything from scratch. Apple just bought NeXtSteP!!1!1! which is older than most Slashdotters and revamped the windowing system. That's not a lot of effort compared to the Free Software community who in early 1997 didn't even have a desktop and only barely had a windowing system.

Yet despite starting from a disadvantage the Free Software community hasn't been idle. The windowing system is about to get an almighty boost from Compiz and Xgl, bringing it up to par with OS X and Vista. You might sneer at the achievements of the Free Software community, but we have been around a lot longer than the smug OS X users, and we will be around for longer still.

Although I fully support any effort Google puts into widespread usage of *nix systems, there are a couple organisations that are way ahead of you (and Google) when it comes to your three points: freedesktop.org has already been and continues to standardise the desktop frontends and backends so that your desktop environments will work great together and not even your typical Windows user would get confused by it. Then there is KDE who have made such huge advancements in your fancy-shmancy integration and synergy that I'd be more worried for Apple that they won't be the holder of the "fanciest desktop environment as perceived by the general public" award anymore. Of course, there is GNOME, and although it's become a very good desktop environment for beginners to computers or those who just want things to work, it does have many artificial limitations in how you can control it, so I recommend KDE to those who want any sort of control over their GUIs.

What do you have aginst Direct Rendering Management?

a mere 1600 DPI but that should be plenty for most

I'd be wary of buying such a mouse for use on a Linux/BSD system. I realize, though, that most gamers use Windows. It would seem that under many circumstances, there is no way to set the speed of a mouse in xorg/xfree86. Sure, you can set the acceleration, but if you happen to have, say, a shiny new Logitech Cordless MouseMan Optical (800dpi), the thing is so fast that you have to set the acceleration to be

Why is losing mouse acceleration a big deal? It means that you cannot move across the screen with a quick movement while maintaining the ability to make small movements easily. It turns out that in operating system like Mac OS X, they actually "decelerate" for very slow movements - it takes a greater distance to move one pixel. I had never noticed these things before.

This issue is already on the TODO list and in their bugzilla system submitted by someone else. The goal is eventually to have a much smarter system for mouse speed and acceleration, to suit all tastes. I hope it gets some attention (perhaps as an add-on to the new X11R7), as right now I went back to an older mouse that works with acceleration (but isn't optical).

My mouse is simply incredibly fast (and I can't imagine another reason than the doubled dpi from most mice) - plugging it into my Mac Mini showed it was much faster than a wired Logitech optical mouse, and the discrete settings Mac OS X offered for mouse speed proved either too slow or too fast. I think the bundled Logitech software allows for finer control of mouse movement, though.

Read for yourself: http://lists.osdl.org/pipermail/desktop_architects /2005-December/000629.html According to Nat himself there was obviously no need to close the devlopment: "For the first 10 or 12 months of development, there was no material outside contribution to Xgl." But: "We'd like to make a splash with something that is largely functional." That's maybe OK for a company and it's marketing needs, but not how open source development works. Although Novell sposored a lot of work on XGL it's not "thier" project. Everyone would have also appreciated Daves work if he'ld submitted to the open repository. I think esp. the Ximian crew behave in my opinion quite reckless und unfair. Remember all that Qt license bashing in the beginning, then all these "standards" for all desktops defined by gnome developers like tango, the fluffed gnome coup some weeks ago, Linus rant against gnome (a few days befor was that desktop meeting at OSDL in Portland, take a look at Nats blog, where just he says something like need to says something about that later in a short blog...) and the general "WE are the corporate desktop" attitude of the Gnome Marketing. And all this with a gnome that has serious problems with unmaintainable libraries which are full of double implemented technoligies and remains of wrong descions mage earlier like Corba, bonobo, ... Sun already dropped thier gnome based Java desktop, Slackware did so because of the unmaintanable librarie dependencies. So with all that background I would say developing XGL behind closed doors is not a "conspiracy" and the link to the discussion above is not a flamewar, but another Nat Friedman stupidity. And surprise, surprise, a few days after that discussion it looks like Dave accepted that this was silly thing to do and released his work on the mailing list: http://lists.freedesktop.org/archives/xorg/2006-Ja nuary/011922.html but it looks like it's to late and some people also started to work beside Dave on XGL and it seems like we most likely now will have a fork. So, Thank you, Novell, well done :(

But I feel bad about adding more and more functions to KDE and leaving the rest of the system behind

Yes, FUSE rocks. But KDE was started in 1996 - FUSE was far from being "there"

It'd be a nice thing to se FUSE replacing KIO and gnome-vfs. SADLY, the freedesktop people have decided to start Yet Another Specification which aims to unify KIO and gnome-vfs. FUSE is the right thing to do - transparent to ALL apps even those compiled years ago - but no matter how much I explained to him, they think that the "Right Way" is creating a two-namespaces filesystem namespace. When you paste your URL from konqueror or nautilus to your terminal it won't work because you need to port cat to dvfs. (yes, we'd need a bsd FUSE equivalent - but such things are already happening)

It's sad that freedesktop people are accepting whatever project as long as it unifies "something" even if it doesn't have sense. There we go, creating a technically-crappy software base for the future of open source.

first, this "names" this article speaks about is about names that are given to open source projects and not to linux! linux is the kernel and the startup/shutdown scripts... and maybe some other pieces, but that's it... besides the kernel and userspace apps (udev,...) there is nothing exclusively linux-like with this "names".

this XYZ computing (maybe this company tries to compensate something with this article... their name for example) article however raises something else speaking of usability and this things...

in X (http://www.freedesktop.org/), there exists a mime-database and a desktop-file-database. every application comes with .desktop files that provide info what this app is for. if your window manager or desktop environement is able to use this info, you do not need to remember any names of apps. for example /usr/share/applications/gimp.desktop

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Applicat ion
Name=The GIMP
GenericName[de]=Bildeditor
GenericName[en_C A]=Image Editor
[...]
Comment[de]=Bilder und Photos erstellen und bearbeiten
Comment[en_CA]=Create and edit images or photographs
[...]
Exec=gimp-remote-2.2 %U
TryExec=gimp-2.2
Icon=/usr/share/gimp/2.0/ima ges/wilber-icon.png
Terminal=false
Categories=Ap plication;Graphics;2DGraphics;RasterGraphics;
X-G NOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Pro duct=GIMP
StartupNotify=true
MimeType=image/bmp; image/g3fax;image/gif;image/jpeg;image/jpg;image/p jpeg;image/
png;image/tiff;image/x-bmp;image/x-co mpressed-xcf;image/x-fits;image/x-gray;imag
e/x-p cx;image/x-png;image/x-portable-anymap;image/x-por table-bitmap;image/x-port
able-graymap;image/x-po rtable-pixmap;image/x-psd;image/x-sgi;image/x-sun- raster;
image/x-tga;image/x-xbitmap;image/x-xcf;i mage/x-xpixmap;image/x-xwindowdump;

the Category says, in what submenu this entry should to. the GenericName specifies a name (in the locale the user works in) that explains what this is (Image Editor) and the Comment explains it more detailled. ... and guess what: the MimeType even specifies, what MIME this app can work with.

in most situations you do not need to care what app is opening a file... and if you try to open a file in a file manager that is aware of the mime-db and .desktop files, then it will offer you already all installed image editors / image viewers available... after once trying them, you know their names... voilà!

... and once you learn what the names mean, you start to like this logical naming. for example:

gimp: general image manipulation programm

this is probably the best and most logical name for such kind of application *g*

Importantly from our point of view, it will mean that you can run an experimental version of some piece of X, such as Xlib, without having to run an experimental version of everything in X.

This new x.org version is not just about autotooling the server

From http://xorg.freedesktop.org/wiki/ChangesSince68

* New EXA acceleration architecture, with experimental support in sis(4), radeon(4), i128(4) (more to come)
* Individual extensions may be enabled or disabled on the command line using the -extension flag
* Improved chipset probing for IA64
* SecureRPC enabled on Linux by default
* Updated savage(4), including dualhead and DRI support
* Updated XRX support
* Fixes to rootless mode for Cygwin and Darwin ports
* Numerous K&R-to-ANSI C conversions
* Many Darwin fixes
* Updated XvMC support, enabling generic loading of hardware-specific drivers
* Added wsfb(4) video driver for OpenBSD and NetBSD framebuffer consoles
* Numerous ATI driver updates from the GATOS project, including TV input support
* More support for enhanced visuals like 12-bit PseudoColor and 30-bit TrueColor
* Improved ProPolice support
* Updates to nv(4) driver from XFree86 and nVIDIA
* via(4) updates from the Unichrome project, including DRI support
* i810(4) updates, including i915GM/E7721/i945G support and shadowfb support
* Improved module loader support for Alpha chips
* Added mingw port for native Win32 builds
* Updated PCI scanning
* Added DMA support to radeon(4) for Render and Xv operations
* Experimental DRI support for Radeon 9500 and above
* Updated xterm to #204 from [WWW]upstream
* Added evdev(4) input driver for generic input handling on Linux
* Switched to libdl-based module loader
* Improved acceleration for sunffb(4)
* MMX blending routines for the Render extension
* sis(4) updates
* New sisusb(4) driver for USB-attached video
* Tiled framebuffer support for radeon(4)
* Initial support for running the Xorg server without root privileges
* Improved acceleration for newport(4)
* Add DragonFly BSD support
* Update bundled Freetype to 2.1.9
* r128(4) dualhead support
* mach64(4) TV-OUT support
* ATI Theater 200 video decoder support
* SGI Altix support
* Disabled antique [WWW]DPS extension
* Support for FreeBSD/powerpc
* Enhanced software Render core
* Support for more than 12 buttons in the generic mouse(4) driver
* Better support for DRI on 64-bit platforms
* Solaris support updates: enhanced mouse driver, agpgart support, experimental AMD64 support, kbd(4) support, /dev/audio keyboard bell option
* Output-only windows
* Non-rectangular mergedfb desktops
* Update bundled fontconfig to 2.3.2

Exa is a replacement for XAA, the old X Acceleration Architecture. nvidia's binary drivers do not use XAA. They cooked up their own method for accelerating their drivers, independent of what the X developers were using. Their method is superior to XAA, and it remains to be seen whether or not it's superior to Exa. If so, don't expect them to change. If not, it'll likely be a while before it's implemented. This is proprietary software, remember. It takes a lot longer.

The OSS nv driver in 7.0 does *not* have Exa support. I've tried the currently-available experimental patch, and it crashes X within a few seconds of startup on my hardware. It also breaks XAA on non-AGP cards. Note that an exa-enabled nv may or may not accelerate 2D operations as well or as fast as the proprietary nvidia driver does. Personally, as long as it's better, I'll be happy, as nvidia is terribly unstable with composite enabled.

I love how incorrect information gets marked up as "informative". *sigh*

Well, there's the new acceleration architecture called "EXA" (which I guess will replace XAA eventually)... which I think is worth mentioning.

I've been using it with a Radeon 9200 card since 7.0.0 rc2, and I haven't had any problems. I can use translucent windows with no slow down at all. Translucent windows with XAA on the same machine is horribly slow.

I can play a DVD while browsing with a 75% translucent firefox window on top of it. No problems at all. Scrolling is very smooth. This is on a Mac Mini, btw.

Only ATI r100/r200 cards seem to be supported at the moment, though...
http://xorg.freedesktop.org/wiki/ExaStatus

Or even better, use kwallet :).

That will not happen. Why would an application built over GTK+ and Gnome pick a random application from another, alternative, desktop environment, and base it's functionality on it? Let me say it again: it will NOT happen.

The workaround, however, is to have this master password thing come out as a FDO standard. Once all kwallet's everywhere use the same specs and same files, then you'll be allowed to complain about why Gaim or Firefox or any other Linux application doesn't use it.

You might need this patch, if it's a trident cyberblade graphics chip:
https://bugs.freedesktop.org/show_bug.cgi?id=3304

I think that misses the point of the AC OP: WMs like PWM and fluxbox might support "tabs", but the applications (or more importantly the GUI toolkits like Qt and Gtk+) aren't really aware of them in the way they are like for other netwm stuff, they're just hacks, handy ones nonetheless, but still. Hey, I guess the freedesktop folk will get to standardising tabs after standardising MDI (MDI SUCKS, but windows weenies migrating to linux demand it.)

i'll comment on things from my experience with linux as a primary desktop system for almost three years.

Lack of configuration is the main bonus point of Windows. You just install software and it's ready to go. While I like the configuratability (is that a word?) of Linux I find it makes small common changes slow and painful. I hate installing a big new piece of software because it (often) means digging though a multitude of text files looking for a setting while reading technically complex man pages. A lot of Windows programs have text files for configuration but you never go near them. On Linux your always in there.

but this depends on the manufacturer of that particular software (i assume you are not talking about packages that are supplied by distribution :) ).
yes, a lot of software is pretty hard to get working, especially for people who come from windows - but then there's some that is really easy to get working.

for example, mono is easy to install. nvidia kernel module (!) also is mostly just pressing [enter] repeatedly. (though you have to make some changes manually to xorg.conf, they are well documented and linux newbie could make them easily)

Common feel is another advantage. The whole cut and paste disaster on Linux is almost laughable. I know that the Gnome and KDE teams have been working together on cut and paste and drag and drop but there are still numerous places where it doesn't quite work. It might supprise you to know that I don't really care that much about the different widget kits. I run a mixed system of Gnome apps and KDE using whichever is best for the job at hand. The widgets work the same in both kits (for the most part) so I just see the difference as a skin.

copynpaste - there were problems some years ago, but lately i get kde, gnome and other apps working together, i can cop&paste text, pictures. i can manage both text and pictures with klipper. it's pretty cool :)
even now there are some problems, but they mostly are with some applications - for example, pasting from opera to openoffice.org 2.0 diacritic symbols fscks them up. it works with opera->oo.org1.1 or firefox->oo.org2.0. but these problems are not norm nowadays, they really are exceptions.
i can't comment on dragndrop, as i basically don't use it :)

visual differences - i usually do not notice that a program uses different widgets unless somebody tells me or it is really, really distinctive :)
somehow i concentrate on the task, the functionality of the program, so unless widgets get in my way, they are good for me.

then there are wrappers for qt apps to look like gnome desktop they sit in or gtk apps look like kde desktop they reside.

for different projects on collaboration you might check out some work at http://freedesktop.org/

The one thing that does bug me about the different widget sets though is the lack of one hit configuration. It's impossible (IMHO) to run a pure KDE or prue Gnome desktop.

it is possible :)
it all depends on tasks you want to do - if it's mail, web, office software - you probably can do with a single desktop environment. if you want more, combining best from each probably is a good idea.

I find it frustrating that you can't (easily) configure the Gnome L&F and KDE L&F at the same time.

agree :)
that's where those wrappers come in (this also is sorta covered in freedesktop)

Then, of course, there is OOo which is off on a world of it's own

well, >=1.1, yes. 2.0 can use both gtk and qt widgets in addition to it's own generic widget set. things change to the best ;)

and the X apps which I never quite figured out.

oh, well. you forgot tcl, wx and probably million more ;)

Updating the system is quite painful as well. I find it hard

X isn't as bad as you say. It is improving. The next release of X.org 6.9/7.0 (monolith/module based) has various improvements. The most important is the new module based structure in 7.0. This should improve not only the installation procedure but also making the code more accessible to would-be developers. The most important next step is trying to come up with a new accelerated arch based on modern day GPUs. I refer you to Jon Smirl's paper

Jon himself left his project because the little attention it was receiving from other xorg developers. However his work was not unnoticed and him leaving actually stirred up some debate on the future of Xorg. Check the mailing lists for some interesting debate.

Anyway there is a group of developers who will continue Jon's work after the new Xorg is released. It is that right now everyone is trying to push 6.9/7.0 out the door.

Honestly, if Red Hat or some other Linux companies invested in more X coders and hired more developers to work on this project. We could have a modern desktop comparable to OS X and Vista within a year. However I doubt this will ever happen.

Funny you should mention this. The GStreamer folks currently are working on getting the infrastructure in place to replace ESD with GStreamer.

See this page for more details.

There was a story a while back about Video Whale

This is really the opposite of what the poster wants, one source on many screens rather than one screen with many sources but GStreamer would probably be a good place to start if you wanted to write something to do this.

The cool thing about all of this is that you just configure the routers/base stations and then the machines do the rest themselves wherever you plug them in (for Macs at least, Avahi needs a bit more work, and is still masked with Gentoo 2005.1). Then, when people start moving stuff around, it still configures itself. No more discussions about where the printer goes...just unplug the damn thing and move it where you want it.

Beautiful. Another thing that Apple has done right, Microsoft doesn't get and Linux needs to work on more.

The OS should have registered actions for transports and datatypes. So each "scheme" (protocol) in a URL, like "http:", "ftp:", "mailto:", "rtsp:" (omitting the ":", to be exact) has a registered app or process for transporting in that protocol. And each datatype in a URL, like ".html", ".mp3", ".xml" (omitting the "."), or its overriding Content-Type header from the server in protocols like HTTP has a registered app or process for rendering the transported data according to its MIME type. Disambiguation among registered alternates is done in the application receiving the URL request, with a default. So a desktop context menu can offer a prioritized "Open with...". Apps can handle URLs for which they have transport and/or rendering facilities, or hand off to whichever app is registered. The only complexity is that the renderer might differ whether the data is to be "read", "edited" or "executed". The app ought to be able to differentiate the mode from the context in which the URL is requested, but the OS would have to register those modes. The key is that the facility resides in the OS (or its execution environment) so every app always has it available - it's IPC.

This approach is already part of the FreeDesktop.org model. GNOME has already implemented it, with some bugs, while KDE has committed to implementing it. The key to the implementations is interop among all of them according to the same rules. Which was the key to the success of URLs themselves, which knitted together the Internet into the critical mass that made it the environment we know today. Then we can build whatever apps we want on that simple facility. Getting rid of the "file system" (replaced with RDBMS and views, for example) will be just one early victory built on that strategy.

In fact, since linux already implements 3d support (dri/drm) inside the kernel, you might explain us what the hell you're talking about?

Unless the DRI people are lying to me, no, that's not what DRI is. DRI is "framework for allowing direct access to graphics hardware under the X Window System". (And DRM is the "kernel module that gives direct hardware access".) Hmm, nothing about 3d support there -- just opening it up so user apps can play with the hardware directly.

Yes, it "integrates with Mesa, an open source implementation of the OpenGL API". That does not make it "3d support inside the kernel".

If you had a kernel module that allowed user programs direct access to your sound card, and could write a userspace program that implemented 3d audio for your particular sound card, would you claim that the kernel had "3d audio support inside the kernel"? This seems a truly bizarre definition. By this logic, the kernel has "support" for *everything* "inside the kernel": just su root and twiddle with /proc/kcore!

Radeon (up to 9250) is the currently best supported graphics card for X11. It has full 2d acceleration and a rather fast 3d-acceleration via DRI. All with opensource rock-stable drivers. 3D acceleration is even enabled on multihead setups if you're running Xorg. I personally refuse to use any card with proprietary drivers because of stability issues. It doesn't matter if the card is twice as fast if I can't trust my computer to not crash during work (OpenGL visualisations) sessions. See http://dri.freedesktop.org/wiki/ATIRadeon for ruther info

Personally I like choice. Yes there pretty much has to be a default desktop but distros such as SuSE, Mandriva and RedHat/Fedora have always given you the option to install others during the initial setup/installation. I for one, like this, because I don't prefer KDE or GNOME. I prefer both.

Having run KDE on Mandrake, RedHat, SuSE, Fedora and (K)ubuntu over the years, I can honestly say that the Kubuntu Krew has managed to top them all on the first try. I get virtually every KDE app that's important to me with Kubuntu. The others never seem to be able to pull that off. And I really don't like SuSE's messing with the Menu structure. I guess they never heard of the Free Desktop standards , which I know for a fact that Kubuntu, Fedora/RedHat and Ubuntu are quite familliar with.

Now if Ubuntu would just change it's policy and offer important software updates between releases (like Fedora Core does) it would absolutely positively rule as a distro.

Currently I'm running Ubuntu/Kubuntu and Fedora Core. Both are at the top of my list of fave distros. And both also suck at many things that the other doesn't.

You are right. A lot of common configuration options could easily be standardized. The Freedesktop folks are working on it. They could probably use help.

Since (Ku|U)buntu cares about both, it might behoove Shuttleworth to give these guys a lift.

You know, I find that the gtk-qt theme goes a long way to solving this. GTK applications start to look a lot more like KDE applications. It's not complete but it helps.

Perhaps this is one of the things that the good fellas at freedesktop.org could do, being a nonpartisan standards development group. If as much as possible could be made desktop-independent, that would surely be good; features could be used by applications from either side of the fence, and maybe some kind of consistency would be possible.

For instance, if one uses Tango icon themes (implementing a fd.o spec, the same icons can be found both by KDE and GNOME desktops and applications.

'Course, that's just icons, but maybe it's possible to do that with themes.

Firefox doesn't look that much like a native Gtk+ app.

You can install a GTK+ engine that uses Qt to draw widgets. I'm sure your distro has it available if it's new enough. :)

Link: http://www.freedesktop.org/Software/gtk-qt

So now they have DRM support in Linux kernel?! Eeeevil!!!

*ducks*

See my previous post. I donate my time for the benefit of my students in great huge wads all the time. I just have to choose which projects I do it for carefully: both for my own sanity, and to make sure the students themselves receive maximum benefit. My students involved in PSAS and XCB have reaped serious benefits from their free work---IMHO much more than if they'd put the same effort into the space elevator contest.

Little off-topic, but anyone with Linux, a nvidia card and x.org should test xcompmgr, it gives you hardware-accelerated translucency, ala OS-X. It looks gorgeus, and works with gnome and kde. A must have!
Disclaimer: Iam not related in any way to xcompmgr. Just a happy user.

chgros wrote:

Funny, for me one of the advantages of linux is that every executable is in /usr/bin (or /usr/local/bin), so when I want to run something I just type the command name.

Elminst wrote:

On Windows you click Start, click Programs, then click your application. [...] Until you can do this on Linux with 99.999% of programs like you can on Windows, you lose this argument.

Firstly, programs under Unix-style operating systems are not limited to the two directories you mentioned. There are, of course, /bin and /usr/X11R6/bin, but a number of larger packages are likely to get installed under /opt. This is distribution dependent, and the /opt/foo/bin directories may or may not be included in $PATH automatically - SuSE adds them (KDE and GNOME at least), which means that those that like to type in program names are happy... but not everyone likes to.

The second point is quite valid, and now that both KDE and GNOME use a common .desktop format, there's no reason why applications should not appear under the programs menu. Not only that, but you don't even need to know which desktop software is installed or in use - you just drop the .desktop file into a common directory; on SuSE, this is /usr/share/applications, but this sort of thing is documented on freedesktop.org.

-- Steve

Java2D is now OpenGL accelerated under mustang.

Glitz provides support for hardware acceleration too.

So, usage of OpenGL is increasing...

Did you ever hear about GTK-QT? This is a theme engine for GTK 2.x that makes GTK 2.x apps use the current KDE or QT style. It is geared (pun intended) towards KDE users; it provides a control panel in the KDE control center to configure this. The control module lets you choose GTK 2 themes and fonts, but it also lets you choose to use your KDE themes and fonts instead. It still has its bugs, but it works quite well. I like the fact that GTK 2 programs don't look out of place on my KDE desktop.

In my opinion, this is a great first step to unifying the look and feel of our software while still letting programmers use the libraries they want to use.

http://freedesktop.org/wiki/ predates it by quite some time. It appears that Tango's focus is more on the visual appearance, while freedesktop.org aims to provide at least a loose level of standardisation for linux desktops. The two projects definitely compliment each other nicely.

Nice, I get modded troll for pointing out the obvious. What the hell are you mods smoking? Here's a few links to projects just like this that blew hot air and wasted bandwidth by talking and not doing, just like this one.
http://freedesktop.org/ http://www.freestandards.org/news/press.php?id=215 &view=full/ http://www.desktoplinuxconsortium.org/

You're probably talking about Gtk-Qt theme engine.

I also recently had my TWiki-based wiki farm broken into, for the 3rd time in 4 years, despite trying to stay up to date at least with Debian releases. Fortunately, I had each wiki set up to run suexec as an individual user, so the damage was reasonably well contained.

Since TWiki's security problems seem intractable (giant Perl codebase that's very difficult to audit and doesn't seem to have been designed to handle security) I decided that enough is enough and followed freedesktop.org's lead in moving the whole farm to MoinMoin. MoinMoin is written in Python rather than Perl, and seems to be better thought out in terms of security, although I had to hack up the source some to get what I wanted. Some open source migration tools will be made available shortly.

I wouldn't recommend to anyone that they run a publically-viewable TWiki installation at this point.

Check this out:

http://dri.freedesktop.org/wiki/Building

This is the howto I followed to get accelerated video.

Once I had DRI enabled, I created one Xorg.conf for single head, and one Xorg.conf for dual head operation. Then I wrote some very simple shell scripts to switch between modes :

However, because I need to use the open source driver for the Radeon 7500 support (I'm not about to go through the pain of getting ATI's open source driver to run only to have to write a more PITA shell script to get acceleration for video work) AND because ATI's driver won't do dual-head between two cards, I'm stuck with the open-source driver. I can live with it until the next-generation Nvidia cards come out, or until I decide to buy a PCHDTV card, at which point I'll buy a current NVidia card. Also FYI: the Quake and Wolfenstein engines do not seem to agree with the open-source driver very well, hence my need to boot Windows.

Oh, and obviously I intended to post my previous reply as anon, too late to worry about that now. D'oh.

Odd, I believe X to be one of the greatest strength of Unix ; yes, its used in other OSes besides Linux - does the presence of X in Solaris, FreeBSD, OpenBSD, Irix, and so on make them impossible to use? Millions of X users beg to differ.

To fix something, you need to quantify its brokenness first, something you have not done well at:

X is not supposed to look good, nor is it supposed to be ugly, or have any sort of 'look' at all. Perhaps you are thinking of window managers, desktop environments or similar. Many of which are reasonably attractive, caveat emptor.

Nor do I believe X is slow. What are you comparing it to? I get superior OpenGL performance under X in linux compared to the same hardware running windows with the equivalent version video drivers. X must be doing something right, but it could well be the linux kernel doing a lot better than the windows one at managing the hardware, admittedly.

Complaints about compiling code, fighting with drivers, software dependancies, and so on are not really weakness in X, merely a lack of experience in handling code. But not to worry, most *nix distributions are nice enough to ship binary builds of X that are both fast and include all the nice font rendering and antialiasing you might ever care for. Of course, you have the freedom to compile the lot by hand if you really want to, but it is by no means necessary. If your distribution of choice is not being cooperative, then investigate better alternatives.

Granted, nothing is ever 100% easy, but you sound like you are picking the hardest way forward and hence getting unneccessarily frustrated. If X was broken, then like everything else under linux ( driver support, schedulers, scalability, journaled filesystems etc all of which are better now than they have ever been and are still improving ), it _would_ be fixed.

Linux fighting DRM
Don't think so. It's been in the kernel since 2.6.12.
$ uname -r
2.6.13n
$ zcat /proc/config.gz | grep DRM
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not s

Err... you are mixing up unrelated things... this is DIRECT RENDERING MANAGER (DRM)... Not digital rights management...

The sections of the GPL you quote do indeed establish that programs that make use of GPLed code fall under the GPL, and thus must follow its terms. But this: "...and the compulsion to provide source code to anyone who asks free of charge plus any reasonable copying and/or distribution fees..." just isn't true and isn't supported by the quoted material. The GPL does compel you to distribute the source code to anyone who receives the binary on which it is based. See the GPL FAQ for details.

"Nobody likes having their source code used as if it was simply public domain. How would you like to have your source code used by anyone in anyway they want without having to give you anything in return?" Uh, I've been giving my work on e.g. Nickle, XCB, and PSAS away for over 20 years. I actually like it pretty well.

"Have you actually read the GPL or any other OSI approved licenses?" Read them, taught them, talked them over with lawyers including FSF's Eben Moglen. Let me recommend Larry Rosen's Open Source Licensing: Software Freedom and Intellectual Property Law as a resource to you as you explore the world of open source licensing further.

afaik, the X Windows System is not frozen in time as you seem to think. Far from it, cool and exciting modular technologies either building up on it or adding value are coming. Check it out:

http://www.freedesktop.org/
http://xorg.freedesktop.org/wiki/
http://www.freedesktop.org/wiki/Software_2fXserver
http://cairographics.org/introduction

Cairo, a 2D vector-based GUI backend. GTK2.8 is already built on cairo. BTW, GTK ( along with Mozilla's XUL ) also pionneered the on-the-fly translation of an xml-based document describing a GUI into a running GUI, via libglade.

I don't think the next generation of either KDE or GNOME will be taking a beating from either M$ or Apple.

As for graphics acceleration, that's outside the reach of most open-source projects, since the main hardware manufacturers do not undisclose the specifications and only provide proprietary closed-source drivers... the usual solution is to use OpenGL.

afaik, the X Windows System is not frozen in time as you seem to think. Far from it, cool and exciting modular technologies either building up on it or adding value are coming. Check it out:

http://www.freedesktop.org/
http://xorg.freedesktop.org/wiki/
http://www.freedesktop.org/wiki/Software_2fXserver
http://cairographics.org/introduction

Cairo, a 2D vector-based GUI backend. GTK2.8 is already built on cairo. BTW, GTK ( along with Mozilla's XUL ) also pionneered the on-the-fly translation of an xml-based document describing a GUI into a running GUI, via libglade.

I don't think the next generation of either KDE or GNOME will be taking a beating from either M$ or Apple.

As for graphics acceleration, that's outside the reach of most open-source projects, since the main hardware manufacturers do not undisclose the specifications and only provide proprietary closed-source drivers... the usual solution is to use OpenGL.

afaik, the X Windows System is not frozen in time as you seem to think. Far from it, cool and exciting modular technologies either building up on it or adding value are coming. Check it out:

http://www.freedesktop.org/
http://xorg.freedesktop.org/wiki/
http://www.freedesktop.org/wiki/Software_2fXserver
http://cairographics.org/introduction

Cairo, a 2D vector-based GUI backend. GTK2.8 is already built on cairo. BTW, GTK ( along with Mozilla's XUL ) also pionneered the on-the-fly translation of an xml-based document describing a GUI into a running GUI, via libglade.

I don't think the next generation of either KDE or GNOME will be taking a beating from either M$ or Apple.

As for graphics acceleration, that's outside the reach of most open-source projects, since the main hardware manufacturers do not undisclose the specifications and only provide proprietary closed-source drivers... the usual solution is to use OpenGL.

Well compile it statically as every lib used by this app will be compiled in so you won't need to track any dependencies.

Then put this compile in f.e. /opt/myapp.

Then wrap this in RPM package - that will do for all RPM based. For Debian do Deb file and you are done with it:

1. Static compile
2. Build RPM from it (simple script)
3. Build Deb from it (simple script)

You can do this on one system, in totally automated manner - just script it.

But also it highly depends on kind of your software and what the installer needs to do:

1. add some symlinks?
2. register as service?
3. add to menu?
4. register MIME type?

Etc. etc.

1. Is quite easy - just contain the symlinks (f.e. /opt/myapp/bin/myapp -> /usr/bin/myapp) in package and they will get installed.

2. This is tricky - you need to issue proper command on post instalation script - this is shitty because different distros have different init/service styles. So here is a lot to do/test.

3. and 4. are now standardized as FreeDesktop, just include *.desktop file along with corresponding icon and *.xml file for MIME config in your package - these files need to go to the proper dir thou. But it is specified by standard and can be overriden by env variable (but usually is not - what for?):

http://www.freedesktop.org/wiki/Standards_2fmenu_2 dspec
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec

When you will use those standards it will work seamlesly on any distro that supports them (all mentioned by you do).

Well compile it statically as every lib used by this app will be compiled in so you won't need to track any dependencies.

Then put this compile in f.e. /opt/myapp.

Then wrap this in RPM package - that will do for all RPM based. For Debian do Deb file and you are done with it:

1. Static compile
2. Build RPM from it (simple script)
3. Build Deb from it (simple script)

You can do this on one system, in totally automated manner - just script it.

But also it highly depends on kind of your software and what the installer needs to do:

1. add some symlinks?
2. register as service?
3. add to menu?
4. register MIME type?

Etc. etc.

1. Is quite easy - just contain the symlinks (f.e. /opt/myapp/bin/myapp -> /usr/bin/myapp) in package and they will get installed.

2. This is tricky - you need to issue proper command on post instalation script - this is shitty because different distros have different init/service styles. So here is a lot to do/test.

3. and 4. are now standardized as FreeDesktop, just include *.desktop file along with corresponding icon and *.xml file for MIME config in your package - these files need to go to the proper dir thou. But it is specified by standard and can be overriden by env variable (but usually is not - what for?):

http://www.freedesktop.org/wiki/Standards_2fmenu_2 dspec
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec

When you will use those standards it will work seamlesly on any distro that supports them (all mentioned by you do).

Well compile it statically as every lib used by this app will be compiled in so you won't need to track any dependencies.

Then put this compile in f.e. /opt/myapp.

Then wrap this in RPM package - that will do for all RPM based. For Debian do Deb file and you are done with it:

1. Static compile
2. Build RPM from it (simple script)
3. Build Deb from it (simple script)

You can do this on one system, in totally automated manner - just script it.

But also it highly depends on kind of your software and what the installer needs to do:

1. add some symlinks?
2. register as service?
3. add to menu?
4. register MIME type?

Etc. etc.

1. Is quite easy - just contain the symlinks (f.e. /opt/myapp/bin/myapp -> /usr/bin/myapp) in package and they will get installed.

2. This is tricky - you need to issue proper command on post instalation script - this is shitty because different distros have different init/service styles. So here is a lot to do/test.

3. and 4. are now standardized as FreeDesktop, just include *.desktop file along with corresponding icon and *.xml file for MIME config in your package - these files need to go to the proper dir thou. But it is specified by standard and can be overriden by env variable (but usually is not - what for?):

http://www.freedesktop.org/wiki/Standards_2fmenu_2 dspec
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec

When you will use those standards it will work seamlesly on any distro that supports them (all mentioned by you do).

Haven't heard of gtk-qt, have you? It draws GTK+ widgets with whatever Qt theme you're using... it's what I use, and it makes all GTK2 programs look like Qt programs. It's also pretty damn fast.