Slashdot Mirror

Also checkout Raster's site.

Can you imagine a graphics system that runs on PDAs, your computer from 1999, and your shiny new boxes? E17 is just f'ing brilliant.

Just as a matter of comparison here... With my 2003 spec laptop (P4M 1.6Ghz, 256 meg RAM, 64 Meg Nvidia 4200) running Fedora Core 3, X 6.8.2, KDE 3.4 with Composite enabled, Top tells me X is using 13% memory and 2% CPU. Of course, the alpha channel and other nifty stuff is being pushed through the GPU but it still shows the alternatives out there. It would be interesting to see Longhorn running on a 2003 spec machine in 2006.

Does next generation mean it'll support copy and paste?

To what does "it" refer? Copy and paste is largely a matter of toolkits supporting the ICCCM conventions for the PRIMARY and CLIPBOARD selection and the X clipboard conventions, and, for non-plain-text selections, supporting appropriate conventions for non-plain-text items (or creating them if they don't exist).

The parent linked to the wrong XGL. This is the Xgl that was meant in the article.

That is not the XGL that you are looking for. This is.

Not very good googling.

The answer might be: D-BUS

Well, the reigning champ of DRI compatible video cards is the Radeon FireGL 8800 which is a slightly faster version of the Radeon 8500. Some of the benchmarks of the Volari cards indicate that their performance is comparable to budget Nvidia and ATI cards. If their X drivers are as good as their Windows drivers, it's possible that top-end Volari cards are faster than the top end ATI cards when using the free software drivers. I look forward to trying one of these puppies.

As far as the VIA drivers go...I'm not sure what they released. Most of the VIA chips already work with DRI. It's great if they're releasing more code, but I'd be interested in hearing what new VIA chips or features will be supported as a result. As far as integrated video chipsets go, Intel tends to be the best with DRI.

When looking through the kernel source code there is only support for 2D. Kernel bugreport X.org bugreport

Sure, their drivers are perfect. Must be why several other people have had problems with them too.

Why ? Because GStreamer was designed *from the start* to be pluggable. The whole patent issue is one of the main reasons why GStreamer is designed the way it is. Sure, it took a lot longer to get to a point where stuff starts to Just Work, because we wanted to make sure we would be around when the shit hits the fan.

So while a lot of other projects chose to ignore the whole patent problem, and a lot of projects used the GPL as a license (which indeed is not compatible with patents), making it possible for any distro to ship them, we had the focus of making sure that the GStreamer platform is pluggable to the point where the libraries can be put in or taken out without breaking the applications. It's also one of the reasons why GStreamer, from the start, has been LGPL - because that allows distributors to ship a complete stack of GStreamer applications legally in places where software patents apply (like, say, the whole US). Fighting software patents is a great idea. Waving the problem away as if it's not there is not.

Also, with the arrival of Fluendo, a company building stuff on top of GStreamer, (and also a company I happily work for :)), people will be able to get codecs for the patented formats in a legal way, if they chose not to run the risk, or if they want to be legally safe.

What does this mean in the end ?

• Distributions can finally ship a multimedia platform in a legal way; see the up-take on Totem and RhythmBox for example. Flumotion, Fluendo's streaming server with support for royalty-free codecs, is a new project and already it is gaining quite an uptake.

  Very few distros have taken the risk to ship one of the other projects, for legal reasons. (Apparently the mighty Debian ships Xine, and while on any other non-free subject lots of noise is made, this one seems to be left alone because it's a big deal).

  It is no coincidence that projects like mplayer, vlc, and xine do not get shipped by most distributions. In fact, coincidentally, Fluendo did a press release on this very issue yesterday.

• Source does not have to be "crippled" to be shippable. Other projects get their tarball mangled to remove all questionable code, causing lots of bug reports, ... Take XMMS in Fedora as an example - people complained loudly about the removal of MP3. Actually, Red Hat had the guts to make a stand and decide "we can't legally ship this, and we should stop pretending it's not a problem."
• GStreamer had some discussions with the FSF (here's the result. In a nutshell, it is vital for a complete framework (ie, all parts of its stack) to not be GPL (or GPL, with an exception clause for GStreamer - see our licensing advisory for more info). The GPL is not compatible with patents. A distro can not risk shipping a stack of libs/plugins/applications where one of these is GPL.
• "For sale" distributions will finally be able to ship proprietary plugins for these patented codecs, as well as playback applications, and DVD playback, *and it will finally be legal* on Linux.
• Apart from Sorenson (who outright refuse - or are not allowed - to license code to anyone but Apple), codec companies are turning around, taking note of Linux, and Fluendo is stepping up to make sure that those who really want these proprietary codecs can buy them.
• Here is what you can do. People need to realize that, jus

Why ? Because GStreamer was designed *from the start* to be pluggable. The whole patent issue is one of the main reasons why GStreamer is designed the way it is. Sure, it took a lot longer to get to a point where stuff starts to Just Work, because we wanted to make sure we would be around when the shit hits the fan.

So while a lot of other projects chose to ignore the whole patent problem, and a lot of projects used the GPL as a license (which indeed is not compatible with patents), making it possible for any distro to ship them, we had the focus of making sure that the GStreamer platform is pluggable to the point where the libraries can be put in or taken out without breaking the applications. It's also one of the reasons why GStreamer, from the start, has been LGPL - because that allows distributors to ship a complete stack of GStreamer applications legally in places where software patents apply (like, say, the whole US). Fighting software patents is a great idea. Waving the problem away as if it's not there is not.

Also, with the arrival of Fluendo, a company building stuff on top of GStreamer, (and also a company I happily work for :)), people will be able to get codecs for the patented formats in a legal way, if they chose not to run the risk, or if they want to be legally safe.

What does this mean in the end ?

• Distributions can finally ship a multimedia platform in a legal way; see the up-take on Totem and RhythmBox for example. Flumotion, Fluendo's streaming server with support for royalty-free codecs, is a new project and already it is gaining quite an uptake.

  Very few distros have taken the risk to ship one of the other projects, for legal reasons. (Apparently the mighty Debian ships Xine, and while on any other non-free subject lots of noise is made, this one seems to be left alone because it's a big deal).

  It is no coincidence that projects like mplayer, vlc, and xine do not get shipped by most distributions. In fact, coincidentally, Fluendo did a press release on this very issue yesterday.

• Source does not have to be "crippled" to be shippable. Other projects get their tarball mangled to remove all questionable code, causing lots of bug reports, ... Take XMMS in Fedora as an example - people complained loudly about the removal of MP3. Actually, Red Hat had the guts to make a stand and decide "we can't legally ship this, and we should stop pretending it's not a problem."
• GStreamer had some discussions with the FSF (here's the result. In a nutshell, it is vital for a complete framework (ie, all parts of its stack) to not be GPL (or GPL, with an exception clause for GStreamer - see our licensing advisory for more info). The GPL is not compatible with patents. A distro can not risk shipping a stack of libs/plugins/applications where one of these is GPL.
• "For sale" distributions will finally be able to ship proprietary plugins for these patented codecs, as well as playback applications, and DVD playback, *and it will finally be legal* on Linux.
• Apart from Sorenson (who outright refuse - or are not allowed - to license code to anyone but Apple), codec companies are turning around, taking note of Linux, and Fluendo is stepping up to make sure that those who really want these proprietary codecs can buy them.
• Here is what you can do. People need to realize that, jus

Why ? Because GStreamer was designed *from the start* to be pluggable. The whole patent issue is one of the main reasons why GStreamer is designed the way it is. Sure, it took a lot longer to get to a point where stuff starts to Just Work, because we wanted to make sure we would be around when the shit hits the fan.

So while a lot of other projects chose to ignore the whole patent problem, and a lot of projects used the GPL as a license (which indeed is not compatible with patents), making it possible for any distro to ship them, we had the focus of making sure that the GStreamer platform is pluggable to the point where the libraries can be put in or taken out without breaking the applications. It's also one of the reasons why GStreamer, from the start, has been LGPL - because that allows distributors to ship a complete stack of GStreamer applications legally in places where software patents apply (like, say, the whole US). Fighting software patents is a great idea. Waving the problem away as if it's not there is not.

Also, with the arrival of Fluendo, a company building stuff on top of GStreamer, (and also a company I happily work for :)), people will be able to get codecs for the patented formats in a legal way, if they chose not to run the risk, or if they want to be legally safe.

What does this mean in the end ?

• Distributions can finally ship a multimedia platform in a legal way; see the up-take on Totem and RhythmBox for example. Flumotion, Fluendo's streaming server with support for royalty-free codecs, is a new project and already it is gaining quite an uptake.

  Very few distros have taken the risk to ship one of the other projects, for legal reasons. (Apparently the mighty Debian ships Xine, and while on any other non-free subject lots of noise is made, this one seems to be left alone because it's a big deal).

  It is no coincidence that projects like mplayer, vlc, and xine do not get shipped by most distributions. In fact, coincidentally, Fluendo did a press release on this very issue yesterday.

• Source does not have to be "crippled" to be shippable. Other projects get their tarball mangled to remove all questionable code, causing lots of bug reports, ... Take XMMS in Fedora as an example - people complained loudly about the removal of MP3. Actually, Red Hat had the guts to make a stand and decide "we can't legally ship this, and we should stop pretending it's not a problem."
• GStreamer had some discussions with the FSF (here's the result. In a nutshell, it is vital for a complete framework (ie, all parts of its stack) to not be GPL (or GPL, with an exception clause for GStreamer - see our licensing advisory for more info). The GPL is not compatible with patents. A distro can not risk shipping a stack of libs/plugins/applications where one of these is GPL.
• "For sale" distributions will finally be able to ship proprietary plugins for these patented codecs, as well as playback applications, and DVD playback, *and it will finally be legal* on Linux.
• Apart from Sorenson (who outright refuse - or are not allowed - to license code to anyone but Apple), codec companies are turning around, taking note of Linux, and Fluendo is stepping up to make sure that those who really want these proprietary codecs can buy them.
• Here is what you can do. People need to realize that, jus

Here's the problem... The open-source/free-software movement is similar to an organic evolution/adaptation system, while the proprietary software industry is just that, like industrial/factory systems. Because of the factory like mechanics, proprietary software is easy to package and pump out. Open source goes in all different directions and it's an electronic survival of the fittest. If someone comes out with a better piece of software, people will tend to use it instead. If someone comes out with a better distro or packaging system, it's the same thing. Only thing is... since it all goes in a million different directions, there are alot of "extinct species" along the way. This is our trade-off for the freedom vs. convenience. However, if we can find a way to get the best of both worlds (LSB, FreeDesktop.org, Autopackage, and other open standards)....things could really get exciting.

I wonder if you could use GTK-QT with QT/Mac? That would certainly be cool...

Have you installed gentoo? The "installer" is a command prompt and that 12 page installation document you mention.

It might not have an installer, but it has an installation procedure, and it has the notion of an installation, so it has the notion of "as installed".

but you run into problems with for instance ATI's and Nvidia's X windows drivers not wanting to both be installed at the same time, so by default you get neither

That's a botch - the system should be able to figure out (by looking at the PCI bus) what card you have, and load only the appropriate driver, even if both are installed. That's either a Gentoo bug or, more likely, an X11 server bug (or perhaps a video driver bug).

And what are the chances of convincing the gnome team to drop metacity and gnome-terminal in favor of xfwm and xfterm?

I presume the issue with gnome-terminal vs. xfterm is that the former doesn't support real transparency but the latter does; if so, the question might be better posed as "what are the chances that a future release of gnome-terminal will support real transparency?"

At this point you'd pretty much have to come up with your own distro and with some decent hardware detection that would autmatically install hardware accellerated video drivers,

Hopefully all desktop distributions will do that in the future - perhaps that'll fall under the rubric of HAL.

turn on compositing and change the default theme if your hardware happened to support it.

"Change the default theme" in what fashion? Just "use advanced compositing features" (along the lines of the difference in Aqua's behavior with, and without, Quartz Extreme), or make more significant appearance changes (so that even a static screen would look different)? I'm not sure the latter would be the right idea - the appearance should probably be purely under the user's control.

In the case of the former, some of that might be done with theme engines and applications inquring whether accelerated composition is available, along the lines of the CoreGraphics API to inquire about Quartz Extreme (but does Terminal in OS X require an accelerated card to support transparency?).

Blackbox is not even listed as EWMH compliant yet, what is taking so long?

http://www.freedesktop.org/Standards/wm-spec

just kidding...

Trust me, Pat knows far more about Linux than you will ever know about Linux. In particular, when he says Gnome is hard to compile, you can bet your sweet ass that Gnome is nay-to-impossible to compile.

I've been using linux for only 2 years (before I was a Windows user), and with jhbuild and a mailing list I've been compiling gnome since the 2.7x days.

Perhaps with "Gnome is nay-to-impossible to compile" you meant "I lack a clue"/"I didn't try"/"I'm trolling"?

I'm telling you right now to put up or shut up: Give us here, on Slashdot, a URL of these "well-advertised build scripts". Additionally, point to where in the official GNOME docs these build scripts are referenced.

From http://www.gnome.org/start/2.10/:

Of course, our sources are always available for you to build GNOME from scratch. See the Release Notes for more information about our build scripts, GARNOME and jhbuild.

JHBuild project page. Note it's used to compile freedesktop projects too.

garnome project page

Now that you've demonstrated you don't have a fucking clue about gnome, and are just bashing the project because of some mental problems, shut up.

If someone is crazy enough to think cairo belongs in a platform as stable software, right now, then I'll just go break some more APIs just to prove them wrong.

Those are some interesting new features, quite innovative actually. However, I would be much more interested in hearing how X is being made smaller and faster. Xserver seems to be a nice continuation of Kdrive since the fork, but it is still lagging behind a full Xorg installation. Most X users are not serving up desktops to thin clients, and only need a full install for things like hardware acceleration and multihead support. I would think a small and fast X would greatly benefit desktop adoption, and if any of you have tried Kdrive on modern equipment, it more than feels snappier, it is.

Can't we all just get along? ;)

Even if you did (I use probably 50/50 QT/GTK stuff), you could use the GTK-QT Theme Engine to make it look ALL the same.

Fact of the matter is, most end user folks aren't going to bother adding a menu item or desktop icon for a program. If the package doesn't add it (which shouldn't be a problem with sane package management and fd.o standards) the user is going to stop right there.

A menu editor is mainly useful to folks who want to compile and install software from source tarballs, or to customize the way their current menu is laid out. Neither of these is a particularly big deal for end users, and just about everyone who is going to be rabid about doing it is going to have the necessary skills to do it without a dedicated menu editor.

I can understand that many people want one, but I can't see it being something that is blocking widespread GNOME acceptance or anything like that.

I'm still waiting for a reasonable alternative to the underlying X server that isn't completely unheard of in 90% of the OSS world.

I'm not sure what you mean here, do you want a different implementation of the X protocol? If so, why not try Freedesktop.org's experimental XServer? It's quite a nice fast modular server. Are you looking for something other than X11 protocol? Then why not try DirectFB? DirectFB doesn't have enough supported applications for you? Why not try Quartz, which I imagine at least 90% of the OSS world as heard of. I don't really see a lack of options there.

Jedidiah.

Yeah, it sure would be great if this was ubiquitously implemented!

Are you using incredibly archaic versions of Qt, Gtk+, and Mozilla, are are you just trolling? This problem has been largely solved for some time now. I can easily paste between GNOME, KDE, and Mozilla apps using either the "select, then middle-click" method or the "select, copy, then paste" method. Most apps I run into follow these guidelines for allowing both the traditional X11 behavior and Windows-style behavior at the same time without surprise or conflict.

Why can't we just unite like all the good apps on windows, mac os, qnx, amiga.. and everything else with a real solid dev team?

Linux is Free software, and most of the stuff running on it is usually also Free software. That has costs, and one of those costs is that people will write whatever they feel like writing. You won't be able to force people to conform. You can have things like Freedesktop.org to lay out some suggested standards, but no one is compelled to follow them. The only way to enforce consistency is to dictate that there is only one way to do things, and the only realistic way to do that is to have a single group in sole control of all the core libraries, which means they need to locked down to prevent forking parallel development, etc. If that's what you want, great. It's out there and available right now: Apple is offering it with MacOS X, Microsoft is offering it with Windows. If you want Free software with open source, you have to be willing to take the bad with the good.

Jedidiah.

This is why more people need to get involved in projects like the Linux Standard Base. If more distros would quit trying to do their own thing and work together, Linux might be able to really take off. Autopackage will help people with installation hell between distros. And hopefully, freedesktop.org's new set of UI standards will help KDE and Gnome people get along a little better too....but then again, we are talking about human beings here.

Yes, Firefox matches my KDE desktop perfectly. I think you would like GTK-QT
Are you really saying you didn't have GTK+ installed anyway? Never used the gimp? Or xscreensaver?

I'd argue that they are indeed investing credible resources (if not "pumping money") into important parts of desktop infrastructure.

Robert Love working on HAL.
Robert O'Callahan working on Mozilla.
David Reveman working on Glitz/Cairo
Etc, etc.

I'd argue that they are indeed investing credible resources (if not "pumping money") into important parts of desktop infrastructure.

Robert Love working on HAL.
Robert O'Callahan working on Mozilla.
David Reveman working on Glitz/Cairo
Etc, etc.

There was some talk of putting gstreamer in KDE 4. I'm not sure of the status of this; I have also heard that KDE is going to great a multimedia engine framework that can work better with multiple engines...

There was some talk of putting gstreamer in KDE 4. I'm not sure of the status of this; I have also heard that KDE is going to great a multimedia engine framework that can work better with multiple engines...

What happened to implementing the Shared MIME Info spec from FreeDesktop.org? As recently as 1/2005, KDE was "planning to support it for their next major release". GNOME already supports this way to focus on our data, with automatic integration with our apps, without worrying that we picked the right desktop to mediate between our apps and our data. Is the next "major" KDE release "4.0", and we have to wait a few years for MIME integration to catch up with GNOME? Or is the MIME layer already in 3.4, and this is just another action-packed OSS episode airing with hidden, inscrutable features not making it to the release notes?

Funny how it only really works that way on Linux and OSX, in my experience.

Uh, when did you start using Linux? When I first installed Mandrake three or four years ago, the sound didn't work and I couldn't connect to the internet. Later, I got to experience the joys of setting up a printer. Things only got easy on Linux within the past year or so with the advent of HAL and Project Utopia. A year ago, someone wanted me to print out a file for them off a USB memory stick. I plugged it in. Nothing happened. I tried to Google for how to use USB memory in Linux, but after about two minutes, she said "Never mind, I can get someone else to print it." That's right: Linux cost me thanks-for-printing-my-essay-for-me sex. Today I can plug in my USB drive and it will mount itself and open a window displaying its contents. If Dvorak's facts are wrong, they're only a few months wrong.

The rest of the article is still bullshit.

That's exactly how I feel. I used to use E16 back when I used GNOME 1.x, but I always felt like the E development process was a black box. Eventually I moved to GNOME 2.x (where E16 didn't work so well), and later to Xfce, and it's like it's all been very quiet.

The E community seems very closed. That's not to say they aren't welcoming of new members, just that they don't reach out. At all. They don't appear to participate in any of Freedesktop's activities, and tend to keep to themselves, plodding along. And now Rasterman is complaining that Seth and Havoc are only now talking about things that E has done for years. Maybe if Rasterman had been a bit more proactive, and joined the greater Linux desktop community, he could have shared his ideas. Maybe if E17 actually had some developer/preview releases (no, telling everyone who's interested to grab it from CVS doesn't count as having releases), the technology would be better understood by outsiders. But no, they have to sit in their little black box all day...

If, however, you're having problems cut & pasting between modern KDE and GNOME apps, then it is a bug, not a feature.

Or, to put it another way, if they don't do things this way, that's a bug, not a feature.

Quit using those old outdated apps that don't support modern copy and paste Its been standard for a few years now, both GNOME and KDE get it right. I'm sure others do too.

Its not our fault if you refuse to upgrade to something that supports the standard.

Yes, this is all using render, damage and composite, three new X extensions that do the bulk of the work on the server side.

Yes, this is all using render, damage and composite, three new X extensions that do the bulk of the work on the server side.

Actually, yes.

Adam Jackson (ajax) took a bunch of notes.

Doing effects over non-overlapping windows is possible. Doing such things as this or this or this are not.

KDE vs Gnome wars: put an end to it. I know everyone will disagree with me saying 'choice is good'. I agree... but there needs to be a standard. Without a standard alot of manpowers being distributed where it could much be better focused. Perhaps this is the downfall of Linux in general... everyones got freedom so all they choose to work on something different.

First of all, there is no "war". People are not killing people over what desktop to use. That's just a headline that bad journalists use to sell more rags.

And are you suggesting that half of the Linux community just throw away everything they've been working on for the past 5 years? It's just not realistic. (And that's not a bad thing: if you could convince that many people to give up that easily, Microsoft would have wiped out Linux by now.)

Working to use the same standards *is* realistic, and that's exactly what they're doing. So they are growing closer together. When a project isn't owned by a company, you can't just kill it overnight.

Perhaps in a couple years we'll have one Linux desktop, with standards defined by fd.o. We'll probably have Gtk+ and QT for a long time (10 years or more), but that's fine, too. (Even Apple, king of desktop consistency, has 2 major APIs. As long as they look and act the same, the user doesn't care.)

Have a common to all distro's install tool that is very easy to use (perhaps a RPM front end).

Well Synaptic is a fairly universal install frontend for all distro based software - it runs on Debian (and all debian based distros), Fedora, SuSE, Connectiva. All you have to do is install the damn thing (it comes by default with several of those distro options). As for third party packages, try Autopackage. Yes they're still finishing things off, and yes, it's going to take developers bothering to package their software with it, but the promise it offers is, I think, enough that we can expect to see it become fairly standard over the next couple of years.

KDE vs Gnome wars: put an end to it.

Um, it is. Or are you going to say all the GNOME developers have to go and work on KDE (or vice versa)? So who says who "wins"? And who really cares if there are 2 seperate desktops if they integrate increasingly well via FD.o standards?

Jedidiah

For #3 check the Freekdesktop specification.

Basically, different toolkits and DE will still exist but they aim to standarize stuff to increase interoperabiltt between DEs; from stuff like common configuration files, proper metadata support, menu files, and trash can management to more complex like drag-and-drop between tookits, control embeeding and (finally) proper clipboard functioning.

This has the potential to end a lot of nightmares for program instalation and interoperability, no matter for which desktop you write them.

Most major desktop enviroments are embracing the Freedesktop specifications: KDE and Gnome among them. XFCE 4 deserves a nod too for being one of the most FD-compliant desktops available.

No, you don't.
It's hard, but not that hard.
You can download binaries from here:
http://dri.freedesktop.org/wiki/Download#head-f3c7 94f007343b969bc570c5dd057212ece700be

They have regular binaries, that you have to install yourself, or debian packages. I did install the binaries, and am using a hardware accelerated S3 here at work. At home I can't use the integrated S3, because of the nvidia in the AGP slot.
I agree it's not easy, but it's not compiling X.org, either.

Very cool.

Although I can't say I have ported X servers to new platforms, I can tell you it is interesting to play around with the "other" X server at freedesktop.org, here. It is well worth the effort if you are stuck with an ATI card. Don't follow the install directions on the site though - use jhbuild with the "freedesktop" moduleset and the "xserver" module. This is also where the XGL server is.

Bonus points if you can get openGL working without X, and then XGL running on top ;-)

Very cool.

Although I can't say I have ported X servers to new platforms, I can tell you it is interesting to play around with the "other" X server at freedesktop.org, here. It is well worth the effort if you are stuck with an ATI card. Don't follow the install directions on the site though - use jhbuild with the "freedesktop" moduleset and the "xserver" module. This is also where the XGL server is.

Bonus points if you can get openGL working without X, and then XGL running on top ;-)

Follow http://cvs.freedesktop.org/xorg/xc/ChangeLog?rev=1 .365.2.155&only_with_tag=XORG-6_8-branch&view=mark up, check for commits with "xprint" or "print" in the description.

A patch is out there to fix this, and I'm hoping it's included in the new release. For Gentoo, the patch is available here. You can probably just patch it yourself for other OSes. It is based around the patch given in the X.org bug entry.

Forget about the X.org website, it's worthless. If you want to see what's changed in 6.8.2, turn to the release notes over at Freedesktop.org.