For the record, NVidia's closed-source binary drivers contain IP that they've licensed from other companies and that they're not free to open source.
And they did have one of their own developers (Mark Vojkovich, look him up on the XFree86 mailinglists) do most of the work on the open source 'nv' driver that was included with XFree86 and is now part of X.org, although Mark apparently has stopped working on X for now since the whole licensing kerfuffle started.
Yes, and DDT is perfectly safe! It certainly doesn't cause cancer, or poison entire food chains and it absolutely wasn't responsible for the near extinction of both the peregrine falcon and the bald eagle.
Please.
Just because the aspartame-industry-funded research finds no serious problems with aspartame (huh, I wonder how that might be possible?) doesn't mean anything. There is still no serious data about the long-term effects of consistent sustained aspartame intake, either. So your claim is complete bullshit.
Hmmm. Keith Packard had typed it in as Kawahura, but it looks like he Hideya registered on the fd.o site as Hideya Kawahara. Hideya-san's presentation was amazing, regardless of how badly I've slaughtered his last name:)
Ok, more information now that the presentation is over.
Looking Glass uses the Damage and Composite extensions that Keith Packard's experimental X server utilizes
The "scene manager" (what Sun is calling their compositing manager) is written in Java, and Looking Glass very heavily utilizes the Java3D API
Most of the pieces of the platform are already X-licensed, and Sun's representatives claim that they will be "opening the source" to Looking Glass when they release the SDK in a few months
The presentation was mostly done by Hideya Kawahura, with some lower-level technical details provided by Deron Johnson
More info on the X Developers Conference is available at freedesktop.org
Now, I'm going to watch the presentation on Croquet.
I'm sitting at the X Developers' Conference right now watching a presentation by some of Sun's guys on Project Looking Glass and I have to admit that this is some pretty cool shit.
Also, they claim that they will be opening the source code when they finally release it.
(You can join and watch the official conference IRC channel on irc.freenode.net, in #xdevconf)
Also, there's an audio stream of the conference available; poke around on freedesktop.org as I don't have the URL handy.
It's a wonderful toolkit with a great API. It's also GPL'd, and nobody is forcing you to use it. And if Trolltech ever screws up or stops maintaining it, the license goes BSD.
One of the things that a lot of people don't realize is that you can still set the colors and such in tcsh just like in bash - only the syntax is different. Here's how I have mine set on one of the machines I log into:
set prompt = "%{^[[032;1m%}`whoami`%{^[[0m%} %c3 %B%#%b "
We had a working System Tray implementation before XEMBED existed, and we'll be using the standard version for KDE4. We think it's important to maintain binary and source compatibility, so if someone out there hacked together an X app that worked with KDE2's system tray it will still work in KDE3 (hell, IIRC some of the KDE1 apps still dock properly).
And we do support the FD.o system tray apps as well, so it's not like we're ignoring them. Rhythmbox and gaim dock just fine into my kicker.
We're also the ones who invented the friggin' icon standard in the first place, as well as working with the GNOME team on the.desktop file format. I know it's fun to bash KDE, but at least bash us for good reasons, like being written in C++ or something;)
XFree86 is on the way out - the huge debacle that is the new 1.1 source license as well as the fact that David Dawes has kicked out pretty much every single useful XFree86 developer except himself means that XFree86 4.3 is really the last XFree86 you'll ever see on an official Linux CD.
It's not crystal clear exactly what will replace it in the future; Keith Packard's X server project is interesting, but I don't know if it's necessarily the future of X servers. The Composite and Damage extensions are going to play heavily into the future, though, I think; the interesting thing is that there are a few people under the freedesktop.org umbrella working on a full hardware-accelerated backend for a next-generation X server, and they're planning for future hardware.
KDE should never have anything to do with hardware acceleration. We design software for graphical interfaces, and we do some interfaces between the software UI and the actual hardware devices, but most of us aren't kernel hackers. And our "poorly-designed" interface is getting less and less poorly-designed every day; we aren't perfect, but that isn't stopping us from getting better all the time.
Except that with the Composite and Damage extensions in the X server over at freedesktop.org, there are compositing managers out there that store buffers of each window in RAM and then render them to the screen with extra effects (see http://ktown.kde.org/~fredrik/composite/ and http://freedesktop.org/~keithp/screenshots/ for some examples).
For what it's worth - KDE has, by default, been a single-click interface since before KDE 1.0 was released.
If anybody was doing any copying, it was Microsoft. (Not that it was a terribly intuitive idea - I mean, come on...) I think it's worth pointing out, too, that double-click is more "intuitive" to people who are used to Windows simply because it's what they're used to, not because it's more intuitive. My grandmother doesn't understand why you should double-click some things and single-click others. Most people who haven't been trained on Windows are the same way. So "intuitive" is all in the eyes of the beholder.
But we did do it first, and we did it desktop-wide. RedHat, and maybe other distributions (I think Lindows too) have changed the default desktop setting to use double-click - this is something that distributors are free to do, of course. We make it easy for them to do so, as well.
Actually, last that I heard, the plan is to use a DCOP/DBUS bridge in KDE 3.3 and then a wholesale move to DBUS for KDE4. There's talk of using DBUS as a base for DCOP in KDE4, as well, for the wire implementation (and thus ditching libICE) but we'll see what happens.
That's easy to do when the libraries are already installed for you:)
Now, assuming that you didn't have half of those installed... how would you know what you needed to download in order to build libORBit? It's not easy. (I'm talking about this from a developer perspective - debian makes it as easy as 'apt-get install liborbit2' but if you're building things from source it is complete and total insanity.)
I'm not even a GNOME hacker and I can tell you you're pretty far off.
D-BUS isn't meant to replace Bonobo at all. D-BUS is a message bus architecture meant for passing messages between applications and the system - e.g. for the kernel to tell the desktop "Hey, I mounted a USB flash drive at/mnt/usb!" or "The user inserted an Audio CD". Bonobo is a cross-application component embedding system so that you can have the AbiWord viewer embedded into Evolution for inline-viewing of an attached word-processing document.
(FWIW, D-BUS is modelled heavily on DCOP, which we've had in KDE since KDE 2.0. D-BUS has both a system-bus mode and a session-bus mode, however, which DCOP does not, as DCOP is a session-bus system only. The current talk indicates that we'll be moving wholesale to D-BUS for KDE4.)
I read the Evolution developers' blogs almost daily and I have yet to see anything about an "evolution-back-end-server" - I have seen some interesting things about Groupwise integration, but that's quite a far cry from the open source software that we all know and love.
And if you think that Novell will pay for Ximian developers to program something that will take away their Groupwise market, I want some of what you're smoking.
Also, I would love to know how exactly anything in the KDE API looks even remotely like anything in the MS Win32 API. I've programmed very briefly on Win32 and much more extensively with KDE and Qt, and I can tell you that they are absolutely nothing alike. But you don't seem to know what you're talking about anyway, so I'm not exactly surprised.
1) KDE, as a project, is not Borg-like. We like to use other technologies when they work, and we use (and/or invent) better ones if the existing things don't work properly. (See CORBA.)
2) While it's nice to leverage existing technology and architecture, if you make use of too many existing projects it becomes an absolute nightmare to build everything from scratch. Even installing from binary packages is a huge pain - there are literally dozens of packages, and getting the dependency order correct is just insane. Can you tell me off the top of your head which libraries gdk-pixbuf, gtkglarea, ORBit, and libzvt depend on? I didn't think so.
3) Using all sorts of different projects means that you have different APIs for every library. One of the really nice features of having KDE based on Qt is that Qt provides a very nice, sane, predictable API for all sorts of different things - the same methods are available whenever they make sense. And since all of kdelibs is distributed as one package, and developed as one large package, the entirety of the API is much more cohesive than the ORBit API plus GTK+ plus libxml plus libsoup plus any other independently-developed libraries that you might need to include to get the functionality you need.
KDE and GNOME are evolving to serve very different markets and that's ok. I'm a KDE developer and I'm excited about everything in Project Utopia, even the GNOME-specific parts, because it gives me a chance to see what they do that I like and what they do that I dislike in their GUI and I have the opportunity to do things differently without duplicating the entirety of the Project Utopia tree. To use a very common analogy, it's much better for someone to reinvent the hubcap on the wheel than to keep reinventing the entire wheel every time.
I don't see how pipes are such a nightmare. It makes sense to allow programs to direct their input and output to eachother without needing to use an intermediate file. (And WinNT and its derivatives have pipes as well, so it's not like it's a UNIX-specific weakness.)
RPM hell is pretty much gone in any mainline distribution these days, what with apt-get, yum, emerge, urpmi, and yast's online updating. All of the major distributions have a free way for you to update your system with full dependency checking and resolution. Even Slackware's got it with swaret.
If you don't think KDevelop is a "real" IDE you might want to look again. The newest release, based on the Gideon codebase, is astounding. Code completion is only part of the good stuff included.
OpenOffice is just about the same as MS Office - I haven't seen any compelling reasons to use Microsoft's version instead, especially considering that OpenOffice runs on my OS and MS Office doesn't (at least, not natively).
The technology is pretty much in place at this point. There might still be a few straggling areas (games are a sore point at the moment, but more and more developers are releasing Linux versions these days than ever before) but on the whole, Linux on the desktop is just building momentum, and nothing is stopping it. It'll hit critical mass sooner or later, and once it does, it's game over for Microsoft. I don't really care personally when it does for the rest of the world - I'm happy with it right now.
Anyway. Good times. Use what works, as that's what you need. But you might be surprised if you try out a mainstream distro, as a lot more works these days than ever has before. And no, FreeBSD isn't even close to mainstream. I love FreeBSD5 and I'm using it (with pf) on my firewall, but I use Linux on my workstation.
Except that the whole point of the moderation is not to downmod those you disagree with (although it happens waaay too frequently) but to engage in discussion with them to prove them wrong.:)
FWIW, obviously I like programming with Qt and KDE much more, but I know that that's my opinion. I wouldn't ever downmod someone for having a different opinion than mine.
Re: the stab at GNOME - heh. Wasn't meant to be a "stab" really, just that the GNOME guys targeted Linux initially.:)
And it looks like you were actually at least partially right - I see that in revision 1.24, the index.html page logged a commit to change the 'Linux' string to 'Unix' which is funny. It's definitely from before I ever got involved in the project. (The commit date looks about right - I know I didn't start following KDE until 1998 at least.)
(Also, for the nostalgic, I copied a checkout of that laptop picture - it's now at c133.org/files/kdelaptop.gif for those of you who're interested in ancient KDE history.)
Slashdot Mirror
For the record, NVidia's closed-source binary drivers contain IP that they've licensed from other companies and that they're not free to open source.
And they did have one of their own developers (Mark Vojkovich, look him up on the XFree86 mailinglists) do most of the work on the open source 'nv' driver that was included with XFree86 and is now part of X.org, although Mark apparently has stopped working on X for now since the whole licensing kerfuffle started.
Yes, and DDT is perfectly safe! It certainly doesn't cause cancer, or poison entire food chains and it absolutely wasn't responsible for the near extinction of both the peregrine falcon and the bald eagle.
Please.
Just because the aspartame-industry-funded research finds no serious problems with aspartame (huh, I wonder how that might be possible?) doesn't mean anything. There is still no serious data about the long-term effects of consistent sustained aspartame intake, either. So your claim is complete bullshit.
Hmmm. Keith Packard had typed it in as Kawahura, but it looks like he Hideya registered on the fd.o site as Hideya Kawahara. Hideya-san's presentation was amazing, regardless of how badly I've slaughtered his last name :)
Now, I'm going to watch the presentation on Croquet.
I'm sitting at the X Developers' Conference right now watching a presentation by some of Sun's guys on Project Looking Glass and I have to admit that this is some pretty cool shit.
Also, they claim that they will be opening the source code when they finally release it.
(You can join and watch the official conference IRC channel on irc.freenode.net, in #xdevconf)
Also, there's an audio stream of the conference available; poke around on freedesktop.org as I don't have the URL handy.
Uh... Have you heard of IBM?
Or maybe RedHat?
RedHat's been in the black for quite a while now, and they keep turning a profit quarter after quarter.
So what's your beef with Qt?
It's a wonderful toolkit with a great API. It's also GPL'd, and nobody is forcing you to use it. And if Trolltech ever screws up or stops maintaining it, the license goes BSD.
Why do you want it to die?
I love tcsh.
One of the things that a lot of people don't realize is that you can still set the colors and such in tcsh just like in bash - only the syntax is different. Here's how I have mine set on one of the machines I log into:
set prompt = "%{^[[032;1m%}`whoami`%{^[[0m%} %c3 %B%#%b "
Good stuff.
Just for the record...
.desktop file format. I know it's fun to bash KDE, but at least bash us for good reasons, like being written in C++ or something ;)
We had a working System Tray implementation before XEMBED existed, and we'll be using the standard version for KDE4. We think it's important to maintain binary and source compatibility, so if someone out there hacked together an X app that worked with KDE2's system tray it will still work in KDE3 (hell, IIRC some of the KDE1 apps still dock properly).
And we do support the FD.o system tray apps as well, so it's not like we're ignoring them. Rhythmbox and gaim dock just fine into my kicker.
We're also the ones who invented the friggin' icon standard in the first place, as well as working with the GNOME team on the
You do realize that iTunes can browse your music and sort it by artist and then album, right?
IIRC, the shortcut on Mac systems is Cmd-B, and on Windows I would bet it's Ctrl+B.
Try it out.
That username rocks.
Seven years is better than never.
And if any project should just up and quit because they got something wrong when they started... sorry, but your entire attitude is just wrong.
We'll continue making KDE better. You can continue bitching.
Just so you know, your entire rant has been obsoleted by the global replacement of the word "directory" with "folder" in KDE 3.2, at least.
KDE is far from a "hopeless" project. And it's dominated by people who care about having a great desktop, not hardcore old-school UNIX diehards.
I won't comment on GNOME beyond stating that they have a very different philosophy than we do.
I hate to say it so bluntly, but I will.
You're wrong.
XFree86 is on the way out - the huge debacle that is the new 1.1 source license as well as the fact that David Dawes has kicked out pretty much every single useful XFree86 developer except himself means that XFree86 4.3 is really the last XFree86 you'll ever see on an official Linux CD.
It's not crystal clear exactly what will replace it in the future; Keith Packard's X server project is interesting, but I don't know if it's necessarily the future of X servers. The Composite and Damage extensions are going to play heavily into the future, though, I think; the interesting thing is that there are a few people under the freedesktop.org umbrella working on a full hardware-accelerated backend for a next-generation X server, and they're planning for future hardware.
KDE should never have anything to do with hardware acceleration. We design software for graphical interfaces, and we do some interfaces between the software UI and the actual hardware devices, but most of us aren't kernel hackers. And our "poorly-designed" interface is getting less and less poorly-designed every day; we aren't perfect, but that isn't stopping us from getting better all the time.
Except that with the Composite and Damage extensions in the X server over at freedesktop.org, there are compositing managers out there that store buffers of each window in RAM and then render them to the screen with extra effects (see http://ktown.kde.org/~fredrik/composite/ and http://freedesktop.org/~keithp/screenshots/ for some examples).
For what it's worth - KDE has, by default, been a single-click interface since before KDE 1.0 was released.
If anybody was doing any copying, it was Microsoft. (Not that it was a terribly intuitive idea - I mean, come on...) I think it's worth pointing out, too, that double-click is more "intuitive" to people who are used to Windows simply because it's what they're used to, not because it's more intuitive. My grandmother doesn't understand why you should double-click some things and single-click others. Most people who haven't been trained on Windows are the same way. So "intuitive" is all in the eyes of the beholder.
But we did do it first, and we did it desktop-wide. RedHat, and maybe other distributions (I think Lindows too) have changed the default desktop setting to use double-click - this is something that distributors are free to do, of course. We make it easy for them to do so, as well.
Actually, last that I heard, the plan is to use a DCOP/DBUS bridge in KDE 3.3 and then a wholesale move to DBUS for KDE4. There's talk of using DBUS as a base for DCOP in KDE4, as well, for the wire implementation (and thus ditching libICE) but we'll see what happens.
That's easy to do when the libraries are already installed for you :)
Now, assuming that you didn't have half of those installed... how would you know what you needed to download in order to build libORBit? It's not easy. (I'm talking about this from a developer perspective - debian makes it as easy as 'apt-get install liborbit2' but if you're building things from source it is complete and total insanity.)
Oh, wow.
/mnt/usb!" or "The user inserted an Audio CD". Bonobo is a cross-application component embedding system so that you can have the AbiWord viewer embedded into Evolution for inline-viewing of an attached word-processing document.
I'm not even a GNOME hacker and I can tell you you're pretty far off.
D-BUS isn't meant to replace Bonobo at all. D-BUS is a message bus architecture meant for passing messages between applications and the system - e.g. for the kernel to tell the desktop "Hey, I mounted a USB flash drive at
(FWIW, D-BUS is modelled heavily on DCOP, which we've had in KDE since KDE 2.0. D-BUS has both a system-bus mode and a session-bus mode, however, which DCOP does not, as DCOP is a session-bus system only. The current talk indicates that we'll be moving wholesale to D-BUS for KDE4.)
I read the Evolution developers' blogs almost daily and I have yet to see anything about an "evolution-back-end-server" - I have seen some interesting things about Groupwise integration, but that's quite a far cry from the open source software that we all know and love.
And if you think that Novell will pay for Ximian developers to program something that will take away their Groupwise market, I want some of what you're smoking.
Also, I would love to know how exactly anything in the KDE API looks even remotely like anything in the MS Win32 API. I've programmed very briefly on Win32 and much more extensively with KDE and Qt, and I can tell you that they are absolutely nothing alike. But you don't seem to know what you're talking about anyway, so I'm not exactly surprised.
Just a few comments.
1) KDE, as a project, is not Borg-like. We like to use other technologies when they work, and we use (and/or invent) better ones if the existing things don't work properly. (See CORBA.)
2) While it's nice to leverage existing technology and architecture, if you make use of too many existing projects it becomes an absolute nightmare to build everything from scratch. Even installing from binary packages is a huge pain - there are literally dozens of packages, and getting the dependency order correct is just insane. Can you tell me off the top of your head which libraries gdk-pixbuf, gtkglarea, ORBit, and libzvt depend on? I didn't think so.
3) Using all sorts of different projects means that you have different APIs for every library. One of the really nice features of having KDE based on Qt is that Qt provides a very nice, sane, predictable API for all sorts of different things - the same methods are available whenever they make sense. And since all of kdelibs is distributed as one package, and developed as one large package, the entirety of the API is much more cohesive than the ORBit API plus GTK+ plus libxml plus libsoup plus any other independently-developed libraries that you might need to include to get the functionality you need.
KDE and GNOME are evolving to serve very different markets and that's ok. I'm a KDE developer and I'm excited about everything in Project Utopia, even the GNOME-specific parts, because it gives me a chance to see what they do that I like and what they do that I dislike in their GUI and I have the opportunity to do things differently without duplicating the entirety of the Project Utopia tree. To use a very common analogy, it's much better for someone to reinvent the hubcap on the wheel than to keep reinventing the entire wheel every time.
I don't see how pipes are such a nightmare. It makes sense to allow programs to direct their input and output to eachother without needing to use an intermediate file. (And WinNT and its derivatives have pipes as well, so it's not like it's a UNIX-specific weakness.)
RPM hell is pretty much gone in any mainline distribution these days, what with apt-get, yum, emerge, urpmi, and yast's online updating. All of the major distributions have a free way for you to update your system with full dependency checking and resolution. Even Slackware's got it with swaret.
If you don't think KDevelop is a "real" IDE you might want to look again. The newest release, based on the Gideon codebase, is astounding. Code completion is only part of the good stuff included.
OpenOffice is just about the same as MS Office - I haven't seen any compelling reasons to use Microsoft's version instead, especially considering that OpenOffice runs on my OS and MS Office doesn't (at least, not natively).
The technology is pretty much in place at this point. There might still be a few straggling areas (games are a sore point at the moment, but more and more developers are releasing Linux versions these days than ever before) but on the whole, Linux on the desktop is just building momentum, and nothing is stopping it. It'll hit critical mass sooner or later, and once it does, it's game over for Microsoft. I don't really care personally when it does for the rest of the world - I'm happy with it right now.
Anyway. Good times. Use what works, as that's what you need. But you might be surprised if you try out a mainstream distro, as a lot more works these days than ever has before. And no, FreeBSD isn't even close to mainstream. I love FreeBSD5 and I'm using it (with pf) on my firewall, but I use Linux on my workstation.
Yes. I^HWe rock. ;)
Except that the whole point of the moderation is not to downmod those you disagree with (although it happens waaay too frequently) but to engage in discussion with them to prove them wrong. :)
FWIW, obviously I like programming with Qt and KDE much more, but I know that that's my opinion. I wouldn't ever downmod someone for having a different opinion than mine.
-clee
Re: the stab at GNOME - heh. Wasn't meant to be a "stab" really, just that the GNOME guys targeted Linux initially. :)
And it looks like you were actually at least partially right - I see that in revision 1.24, the index.html page logged a commit to change the 'Linux' string to 'Unix' which is funny. It's definitely from before I ever got involved in the project. (The commit date looks about right - I know I didn't start following KDE until 1998 at least.)
(Also, for the nostalgic, I copied a checkout of that laptop picture - it's now at c133.org/files/kdelaptop.gif for those of you who're interested in ancient KDE history.)