Wouldn't have been more easy for Evolution, Gaim and other programs to share a single addressbook?!
Er, maybe, but:
a) Gaim doesn't have an addressbook. It has a buddy list. That's a very different thing. Some buddies won't even have email addresses associated with them (which I guess is the key they're using).
b) Gaim and Evolution were developed separately. Gaim won't be using any shared addressbook until it's a neutral standard, I'd guess, with multiple implementations (KAddressbook/Evo) working together.
c) Integration of what EXISTS and WORKS NOW is infinitely easier than inventing a completely new address book standard, getting Evolution to use it, Gaim to integrate with it etc. This can be done (in fact *is* being done right now, I'm watching it happen) in a matter of hours, not months or years.
This fixes the problem in the short term, but what happens when you uninstall the app or library on which your package depends?
You separate the concept of "supports" and "depends". For instance, if package A depends on package B, you scan the system for the presence of package B using a script, and if found and the install was succesful, make a note in the package database that B supports A. Now if you uninstall B, you can see that something would break.
Not using the database for dependency checking does not mean you don't have a database.
There's nothing about your system that can't be tracked down by a little intelligent scriptwork. If package managers worked like that, then you'd be able to ignore them on occasion or even break small pieces and the rest wouldn't come tumbling down.
Right. In fact an easier way to look for a library is to scan the linker cache. Look, I'll show you:
/sbin/ldconfig -p | grep libfoo.
In fact, the code we use in autopackage is a little more involved:
This works because (unfortunately) if a library is not in the linker cache, it won't be usable by the system anyway so nothing is lost by not checking the filing system directly in this case. For python we do exactly what you suggest
Is anybody working on this? Is anybody interested in working on this?
In short, yes. You aren't the first one to think of this. In fact the approach goes back to the days of autoconf, but as far as I know my project is the first attempt to apply this to binary packages on Linux. See autopackage.org for details. It's essentially a lot of infrastructure and support code for packages, combined with a library of tests for common packages. Eventually we hope the library developers will maintain the "skeleton files" themselves.
1) Macromedia creation tools - maybe wine can do the trick, but not likely.
In fact Wine can run Dreamweaver MX and Flash MX today. WineHQ doesn't do it perfectly but it's close, basically it needs somebody who owns these apps and who cares to sit down and maintain them on Wine. CrossOver is well on its way to supporting the entire Macromedia stable.
For people who really do need these apps, rather those who simply like posing with them, this shouldn't be an issue for much longer.
2) DirectX/game support - not going to happen until the userbase is there, and even then, it's iffy - when was the last time you saw a good game for PC? not terribly frequent, are they? nearly everyone's developing for Xbox now.
Erm, there are bazillions of games for Windows. To say everybody is developing for the Xbox is a gross distortion of the truth. And besides, we DO support DirectX again via Wine.
3) adobe products - some work, but just barely, though wine. not an option. gimp is not an option, because it doesn't compare. neither are all the other tools - they've got nowhere near the feature list (which is invalueable in something like premiere or ps).
I'd guess for 80% of people who use Photoshop today, the Gimp is just fine. Typically these are people for whom Paintbrush isn't good enough, or who have 'aquired' a copy from a friend etc. They can do just fine with the gimp.
But for the 20% who can't, that's still fine, because Wine (well, CrossOver) runs Photoshop nearly perfectly - if it runs well enough for the Hollywood studios, it runs well enough for you.
The rest of your post is mostly baseless and the points raised have been dealt with time and time again. Use Google power.
The trouble with this is control. This sort of consistency would mean developers willingly going with someone else's design principles and UI guidelines
That's already happening to some extent with the Gnome HIG. Even non-GNOME apps like Gaim, The Gimp and autopackage are following it, at least to some extent. The guidelines are sound, clearly specified and there's experience and a large body of already-compliant code.
There are typically many types of apps that aren't HIG compliant of course, like non-GTK apps, proprietary software and so on. However, I really do think people worry about this too much - Windows has never had a strong/visible HIG and apps for it are often a total mess yet it seems to be doing OK.
Hmm, no, many distributors like RPM. It's a simple and convenient way to ship a few gigs of software on CDs with your distro and remain sane. I think you mean, users think RPM sucks, and this is where we can start discussing.
Your idea for a GUI to source tarballs has already been done, basically. There are programs like KConfigure that do it all for you, but they don't make installing from source any easier. Why not?
Source tarballs don't contain dependency information. Or rather they do, but only in the form of configure checks, which are useless for actually resolving dependencies.
Source tarballs are source code. That means installing the software takes ages, eats disk space and RAM, and so on.
You typically end up with unstripped binaries.
Some source tarballs cannot be uninstalled.
This approach is useless for binary-only packages like (say) games.
The only real way forward out of this mess is to develop a portable binary packaging scheme that allows you to install packages on many different distros WITH dependency resolution. And of course, better developer education - dependencies have a cost. Depending on CVS HEAD of a library in a release is just a big nono. Keeping dependencies fairly mainstream, or better, optional, takes practice and a bit of forethought but can be done (see Wine for an extreme example of this approach).
PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.
What about Slackware? GNOME works OK there, thanks to Dropline. Basically bad packaging/installs say nothing about the desktop and everything about the distro.
I have to nail down which wm to use, and also whether I want to run xfce with gnome-panel, or something like that.
If you change either of those things, you're no longer running Gnome. Gnome has 1 WM, metacity, and one desktop manager. XFCE is a desktop environment in its own right, feel free to mix and match but don't think you're running gnome afterwards.
Nobody is obliged to give anybody an instant user community. But neither are you obliged to give RedHat your money.
This is a meaningless statement, the two sentances aren't connected.
The main thing that distinguishes Microsoft from other companies is those intangibles: user community, name recognition, etc.
No, I'd argue that it's primarily controlling Windows, and having piles of cash that distinguishes them.
f you want a company like Microsoft to have control of Linux, send your money to some commercial Linux vendor.
You haven't linked being "commercial" with being like Microsoft, you haven't even tried. When, and only when, you can show that Red Hat are using Microsoft-style tactics to try and control Linux will you not seem like a paranoid delusional.
If you want Linux to continue to exist as a system whose design reflects the needs of its users, support projects like Debian.
There's a reason I (and many others) don't use Debian, which is that it doesn't reflect my needs, not even close.
Er, I'm not sure what your point is. So Debian and Gentoo have bad GNOME packages? Try Red Hat/Fedora, works fine there. How about Garnome on SuSE - worked fine for me. It's possible to screw up KDE packages just as much as anything else.
I'm having trouble configuring a lot of things in GNOME right now. Like how to see KDE apps in the menu?
Works here (again, on Red Hat 9). Of course KDE apps don't actually use the agreed upon menu system yet, that's coming in KDE 3.2, so until then it's really a bug in KDE and not in GNOME.
And it seems that you can't have different desktop wallpapers on different virtual desktops? Nor can you have a randomly changing wallpaper based on a whole bunch of images in a single directory (like in KDE)
Right, those features aren't in Gnome. You can get external programs to do wallpaper switching etc, but I agree, it'd be nice to have it built in.
GNOME on the other hand never seems to work for me, and as far as usability goes, whey the hell do they have that second menubar on the top of the screen and another on the bottom? Getting GNOME set up the way one would like out of the box is a nightmare.
Well, all the usability tests done show that this layout works quite well. In fact, I always rearrange the default Red Hat setup back to the default as I prefer it. The Sun desktop system got quite poor usability marks, and when they looked into why, it turned out partly to be that they changed the default panel setup to be more like KDE/Windows/BlueCurve.
Er, well clearly if you fork the product you don't immediately get a user community to go with it. Likewise, nobody is obliged to give you servers. The bug db data is the only real valid one there IMHO, and I expect if people wanted it badly enough the bugzilla dbs would be made available (if they aren't already). I think this is entirely a non-issue.
Well, there is one that FreeBSD + PPC with AGP, sound, USB 2, and firewire.
Let's ignore the fact that FreeBSD, to which Apple owes so much, doesn't even run on PowerPC.
It's called Apple Macintosh with OS X.
The original poster was talking about an IBM made machine, running Linux. The only possible connection to Macs are that they'd use the same processor - how tenuous can you get?
+1 Insightful for making a dumb link to something entirely offtopic is so stupid.
If you pay for a RedHat or SuSE subscription, you end up helping create an infrastructure in which you will not have a choice but to pay them in the future.
Sounds like bollocks to me. Please support this assertion. Why would paying Red Hat for support lock you in to them in future?
In The Inmates are Running the Asylum, Cooper argues that the easiest application install of all is implemented by a web-browser, and that no application install needs to be harder than that.
I agree. The long term UI plan for autopackage is clicking directly on icons in the web browser. You can of course drag the icon to your panel or menu as well, if you wish to make a permenant link. This isn't impossible to implement though it is fairly hard.
Any well-written application should be able to determine reasonable defaults based on context. Therefore, on general principles, there is no need for an interactive installation process.
Well, autopackage supports user interaction, however it forces the package developer to specify sane defaults. I'm not 100% sure this is the right way to go, but there are some things that just make a lot more sense to do in the installer (like choosing 'components' and such).
The string 'dead' does not appear anywhere in the article
Don't be so inflexible. In the article there is this string:
That magpie attitude, according to Microsoft, is mutual. Red Hat's decision to end support for its free software and the Novell-SuSE link-up have put the last nail in the coffin of the free-software model, the Redmond behemoth believes -- even going so far as to speculate that the move from free to paid-for open-source software is a validation of Microsoft's way of doing business and the only way the open-source movement can survive.
So they paraphrased. Maybe Microsoft said that, maybe they didn't, but the article basically did.
Apples and oranges. On Win32 and Mac OS X, there is a single standard native toolkit, and it is well understand that to make a native app, that's what you use.
I wish. That'd make my job a lot easier. In fact on Win32 there are multiple versions of the same toolkit. Browse through MSDN some time, and notice how half the controls have special features or replacements that are only available on certain versions or if IE >= whatever is installed.
Toolbars are a good example of that. What is native? The toolbar common control? The ReBar? How about the new style you see in Office and Visual Studio (can't recall if it's even available as a public api yet). Is that native?
Things aren't as clear cut as you make them out to be.
Why does this just never happen in Windows (even OOo doesn't exhibit these awful characteristics in Windows - yes, this is a rhetorical question, I understand the technical reasons and they all indicate major flaws in the X architecture to me)?
I take it you've not used Windows in the last few years then. Take a look at the menus and toolbars in Wordpad, Visual Studio, Office 2003, Windows Media Player and Encarta.
What? They're all different? How dare those people not use the builtin toolkits - what are they thinking?
I think that really you don't understand the Windows architecture (which is really quite similar to X except for no network transparency and a kernelized WM), otherwise you'd realise that multiple conflicting toolkits happen all the time there.
This is even true of MacOS X. There are some well known incidents where it was shown that different apps in the MacOS X base distribution reinvented the same widget multiple times over.
Re:Work on nasty glibc bugs?
on
WineConf 2004
·
· Score: 1
Writing a C library is no trivial thing. Glibc is easily one of the best out there today, dumping it would be insane and besides, what else would we use? Not going to happen.
In this case Wine was doing some seriously bad things with threading, poking internal structures and overriding the threading subsystem etc - when threading on Linux came up for an overhaul surprise surprise Wine broke. It's mostly fixed now, I think. The end result is a lot more sane and robust though.
That's not "addressing the problem", that's giving a ridiculous workaround. Worse, it shows that IE can architecturally do it just fine - DX Transformations have been shipped with Windows for years. It cannot be hard to simply make the AlphaImageLoader the default filter for PNG images. If it's more than 60 minutes work then the IE codebase is so utterly screwed it's not surprising the product is static.
But they won't do it? Why not? Probably internal politics or perhaps that part of the code is so fragile they don't dare touch it (there are parts of Windows that nobody has really even looked at since the 80s). Who knows. The point is that it blows, and is a good demonstration of why the IE team should be ashamed to admit who they are.
Precisely. If I were Szulik, and wanted to abandon my entire consumer market, I would at least abandon it to someone in the family.
Firstly, Szulik isn't abandoning the consumer market because Linux doesn't have a consumer market. We're not "consumers" in the typical sense of the word. We are geeks and developers. Joe Public will use Linux one day, but that day isn't today.
Secondly, MacOS X is not a "part of the family", not even close. It is a competitor to Linux, just as much as Windows is. Why should Szulik recommend just yet another proprietary operating system? Because it has some UNIX commands? So does Solaris, so does Windows even.
Far better for people to stay on Windows IMHO where their apps can be emulated, their processors and hardware are well understood, and they can actually use it for business realistically.
People are bashing Red Hat like there's no tomorrow but to be honest, they are persistantly sane and reasonable. Desktop Linux isn't ready for the desktop, I see this every day when my XP using friends come into my room and try and use my computer. It's not bizarre or uber-leet, it's pretty much stock RH9, and it just isn't there yet despite RH9 being one of the most advanced desktop Linux distros around today. Whether it's MSN compatability, dodgy sound mixing, mounting disks or whatever, there are still a lot of details to take care of yet.
My most common use of copy and paste is copying a URL out of a terminal and into a browser. So, I drag over the URL in the terminal, which does not support Ctrl-C, Ctrl-V pasting.
Ummm, the simple solution here would be to use a terminal that supports CC/CV pasting? Gnome Terminal does, and I use it all the time, for the exact reason you've articulated.
The X clipboard does need some more standardised media types, but most of the problems people see with it are buggy or broken apps these days...
I am not an expert but I'll answer as well as I can.
What are the memory implications of this ?
The reason keithp is going to be buffering each node in the window tree is for memory reasons - buffering entire toplevel windows is far too expensive. It involves two extensions, aXe and XDAMAGE to work correctly. I believe XDAMAGE is partly useful for reducing the work needed to implement eyecandy effects, but it's all new to me too so I'm prolly wrong.
Secondly, MacOS X gets around the memory requirements partly through heavy use of video RAM and partly through compressing and decompressing toplevel windows on the fly (as far as I know). I wouldn't be surprised if the new X team take a similar route.
Finally, I don't think OpenGL will feature in this. OpenGL is a neat 3D API but not so great at 2D work - we seem to be heading towards using XRender as our low-level 2D API with Cairo providing a Quartz style drawing system on top. That doesn't imply speed loss - both OpenGL and XRender are abstractions over the hardware acceleration engines of the card, so there's no reason why XRender based apps could not get the sort of speeds we associate with 3D HW accel (even if today it doesn't reach those speeds). The advantage of going the Xrender route is that it's much easier to mix and match the old style and new style rendering (note how OpenGL requires you to set it up for a particular rect but XRender can just be used as a standard drawing op).
Like I said, no expert, keithp is the canonical source for this, but that's what I've gathered from reading and listening.
the frustration of trying to get Linux working with much more modern hardware (like my NForce2 board) just made me get fed up with the whole idea..... hardware integration is obviously perfect - stuff just works
Send $2000 to my address via PayPal and I will ship you a machine with modern hardware that works perfectly out-the-box with Linux.
Actually, don't do that - my point is that you're comparing apples (hardware+software) and oranges (just software). Apple have a distinct advantage in this area, in that nobody installs OS X on their souped up built-from-the-bits machine or cupboard box, so it's a lot easier to get hardware integration running OK.
Slashdot Mirror
Er, maybe, but :
a) Gaim doesn't have an addressbook. It has a buddy list. That's a very different thing. Some buddies won't even have email addresses associated with them (which I guess is the key they're using).
b) Gaim and Evolution were developed separately. Gaim won't be using any shared addressbook until it's a neutral standard, I'd guess, with multiple implementations (KAddressbook/Evo) working together.
c) Integration of what EXISTS and WORKS NOW is infinitely easier than inventing a completely new address book standard, getting Evolution to use it, Gaim to integrate with it etc. This can be done (in fact *is* being done right now, I'm watching it happen) in a matter of hours, not months or years.
You separate the concept of "supports" and "depends". For instance, if package A depends on package B, you scan the system for the presence of package B using a script, and if found and the install was succesful, make a note in the package database that B supports A. Now if you uninstall B, you can see that something would break.
Not using the database for dependency checking does not mean you don't have a database.
Right. In fact an easier way to look for a library is to scan the linker cache. Look, I'll show you:
In fact, the code we use in autopackage is a little more involved:
This works because (unfortunately) if a library is not in the linker cache, it won't be usable by the system anyway so nothing is lost by not checking the filing system directly in this case. For python we do exactly what you suggest
In short, yes. You aren't the first one to think of this. In fact the approach goes back to the days of autoconf, but as far as I know my project is the first attempt to apply this to binary packages on Linux. See autopackage.org for details. It's essentially a lot of infrastructure and support code for packages, combined with a library of tests for common packages. Eventually we hope the library developers will maintain the "skeleton files" themselves.
In fact Wine can run Dreamweaver MX and Flash MX today. WineHQ doesn't do it perfectly but it's close, basically it needs somebody who owns these apps and who cares to sit down and maintain them on Wine. CrossOver is well on its way to supporting the entire Macromedia stable.
For people who really do need these apps, rather those who simply like posing with them, this shouldn't be an issue for much longer.
2) DirectX/game support - not going to happen until the userbase is there, and even then, it's iffy - when was the last time you saw a good game for PC? not terribly frequent, are they? nearly everyone's developing for Xbox now.
Erm, there are bazillions of games for Windows. To say everybody is developing for the Xbox is a gross distortion of the truth. And besides, we DO support DirectX again via Wine.
3) adobe products - some work, but just barely, though wine. not an option. gimp is not an option, because it doesn't compare. neither are all the other tools - they've got nowhere near the feature list (which is invalueable in something like premiere or ps).
I'd guess for 80% of people who use Photoshop today, the Gimp is just fine. Typically these are people for whom Paintbrush isn't good enough, or who have 'aquired' a copy from a friend etc. They can do just fine with the gimp.
But for the 20% who can't, that's still fine, because Wine (well, CrossOver) runs Photoshop nearly perfectly - if it runs well enough for the Hollywood studios, it runs well enough for you.
The rest of your post is mostly baseless and the points raised have been dealt with time and time again. Use Google power.
That's already happening to some extent with the Gnome HIG. Even non-GNOME apps like Gaim, The Gimp and autopackage are following it, at least to some extent. The guidelines are sound, clearly specified and there's experience and a large body of already-compliant code.
There are typically many types of apps that aren't HIG compliant of course, like non-GTK apps, proprietary software and so on. However, I really do think people worry about this too much - Windows has never had a strong/visible HIG and apps for it are often a total mess yet it seems to be doing OK.
Hmm, no, many distributors like RPM. It's a simple and convenient way to ship a few gigs of software on CDs with your distro and remain sane. I think you mean, users think RPM sucks, and this is where we can start discussing.
Your idea for a GUI to source tarballs has already been done, basically. There are programs like KConfigure that do it all for you, but they don't make installing from source any easier. Why not?
The only real way forward out of this mess is to develop a portable binary packaging scheme that allows you to install packages on many different distros WITH dependency resolution. And of course, better developer education - dependencies have a cost. Depending on CVS HEAD of a library in a release is just a big nono. Keeping dependencies fairly mainstream, or better, optional, takes practice and a bit of forethought but can be done (see Wine for an extreme example of this approach).
PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.
You're welcome to help out. The project in my sig is one such approach - we're currently working on dependency resolution from a network.
I have to nail down which wm to use, and also whether I want to run xfce with gnome-panel, or something like that.
If you change either of those things, you're no longer running Gnome. Gnome has 1 WM, metacity, and one desktop manager. XFCE is a desktop environment in its own right, feel free to mix and match but don't think you're running gnome afterwards.
This is a meaningless statement, the two sentances aren't connected.
The main thing that distinguishes Microsoft from other companies is those intangibles: user community, name recognition, etc.
No, I'd argue that it's primarily controlling Windows, and having piles of cash that distinguishes them.
f you want a company like Microsoft to have control of Linux, send your money to some commercial Linux vendor.
You haven't linked being "commercial" with being like Microsoft, you haven't even tried. When, and only when, you can show that Red Hat are using Microsoft-style tactics to try and control Linux will you not seem like a paranoid delusional.
If you want Linux to continue to exist as a system whose design reflects the needs of its users, support projects like Debian.
There's a reason I (and many others) don't use Debian, which is that it doesn't reflect my needs, not even close.
I'm having trouble configuring a lot of things in GNOME right now. Like how to see KDE apps in the menu?
Works here (again, on Red Hat 9). Of course KDE apps don't actually use the agreed upon menu system yet, that's coming in KDE 3.2, so until then it's really a bug in KDE and not in GNOME.
And it seems that you can't have different desktop wallpapers on different virtual desktops? Nor can you have a randomly changing wallpaper based on a whole bunch of images in a single directory (like in KDE)
Right, those features aren't in Gnome. You can get external programs to do wallpaper switching etc, but I agree, it'd be nice to have it built in.
Well, all the usability tests done show that this layout works quite well. In fact, I always rearrange the default Red Hat setup back to the default as I prefer it. The Sun desktop system got quite poor usability marks, and when they looked into why, it turned out partly to be that they changed the default panel setup to be more like KDE/Windows/BlueCurve.
Er, well clearly if you fork the product you don't immediately get a user community to go with it. Likewise, nobody is obliged to give you servers. The bug db data is the only real valid one there IMHO, and I expect if people wanted it badly enough the bugzilla dbs would be made available (if they aren't already). I think this is entirely a non-issue.
How do Red Hat "own" RH Linux? It's all under free software licenses. If you don't like how they operate, you are free to fork it - just like Debian.
Let's ignore the fact that FreeBSD, to which Apple owes so much, doesn't even run on PowerPC.
It's called Apple Macintosh with OS X.
The original poster was talking about an IBM made machine, running Linux. The only possible connection to Macs are that they'd use the same processor - how tenuous can you get?
+1 Insightful for making a dumb link to something entirely offtopic is so stupid.
Sounds like bollocks to me. Please support this assertion. Why would paying Red Hat for support lock you in to them in future?
I agree. The long term UI plan for autopackage is clicking directly on icons in the web browser. You can of course drag the icon to your panel or menu as well, if you wish to make a permenant link. This isn't impossible to implement though it is fairly hard.
Any well-written application should be able to determine reasonable defaults based on context. Therefore, on general principles, there is no need for an interactive installation process.
Well, autopackage supports user interaction, however it forces the package developer to specify sane defaults. I'm not 100% sure this is the right way to go, but there are some things that just make a lot more sense to do in the installer (like choosing 'components' and such).
Don't be so inflexible. In the article there is this string:
That magpie attitude, according to Microsoft, is mutual. Red Hat's decision to end support for its free software and the Novell-SuSE link-up have put the last nail in the coffin of the free-software model, the Redmond behemoth believes -- even going so far as to speculate that the move from free to paid-for open-source software is a validation of Microsoft's way of doing business and the only way the open-source movement can survive.
So they paraphrased. Maybe Microsoft said that, maybe they didn't, but the article basically did.
I wish. That'd make my job a lot easier. In fact on Win32 there are multiple versions of the same toolkit. Browse through MSDN some time, and notice how half the controls have special features or replacements that are only available on certain versions or if IE >= whatever is installed.
Toolbars are a good example of that. What is native? The toolbar common control? The ReBar? How about the new style you see in Office and Visual Studio (can't recall if it's even available as a public api yet). Is that native?
Things aren't as clear cut as you make them out to be.
I take it you've not used Windows in the last few years then. Take a look at the menus and toolbars in Wordpad, Visual Studio, Office 2003, Windows Media Player and Encarta.
What? They're all different? How dare those people not use the builtin toolkits - what are they thinking?
I think that really you don't understand the Windows architecture (which is really quite similar to X except for no network transparency and a kernelized WM), otherwise you'd realise that multiple conflicting toolkits happen all the time there.
This is even true of MacOS X. There are some well known incidents where it was shown that different apps in the MacOS X base distribution reinvented the same widget multiple times over.
In this case Wine was doing some seriously bad things with threading, poking internal structures and overriding the threading subsystem etc - when threading on Linux came up for an overhaul surprise surprise Wine broke. It's mostly fixed now, I think. The end result is a lot more sane and robust though.
But they won't do it? Why not? Probably internal politics or perhaps that part of the code is so fragile they don't dare touch it (there are parts of Windows that nobody has really even looked at since the 80s). Who knows. The point is that it blows, and is a good demonstration of why the IE team should be ashamed to admit who they are.
Firstly, Szulik isn't abandoning the consumer market because Linux doesn't have a consumer market. We're not "consumers" in the typical sense of the word. We are geeks and developers. Joe Public will use Linux one day, but that day isn't today.
Secondly, MacOS X is not a "part of the family", not even close. It is a competitor to Linux, just as much as Windows is. Why should Szulik recommend just yet another proprietary operating system? Because it has some UNIX commands? So does Solaris, so does Windows even.
Far better for people to stay on Windows IMHO where their apps can be emulated, their processors and hardware are well understood, and they can actually use it for business realistically.
People are bashing Red Hat like there's no tomorrow but to be honest, they are persistantly sane and reasonable. Desktop Linux isn't ready for the desktop, I see this every day when my XP using friends come into my room and try and use my computer. It's not bizarre or uber-leet, it's pretty much stock RH9, and it just isn't there yet despite RH9 being one of the most advanced desktop Linux distros around today. Whether it's MSN compatability, dodgy sound mixing, mounting disks or whatever, there are still a lot of details to take care of yet.
The hotkey is Shift-Control-C for that exact reason
Ummm, the simple solution here would be to use a terminal that supports CC/CV pasting? Gnome Terminal does, and I use it all the time, for the exact reason you've articulated.
The X clipboard does need some more standardised media types, but most of the problems people see with it are buggy or broken apps these days...
What are the memory implications of this ?
The reason keithp is going to be buffering each node in the window tree is for memory reasons - buffering entire toplevel windows is far too expensive. It involves two extensions, aXe and XDAMAGE to work correctly. I believe XDAMAGE is partly useful for reducing the work needed to implement eyecandy effects, but it's all new to me too so I'm prolly wrong.
Secondly, MacOS X gets around the memory requirements partly through heavy use of video RAM and partly through compressing and decompressing toplevel windows on the fly (as far as I know). I wouldn't be surprised if the new X team take a similar route.
Finally, I don't think OpenGL will feature in this. OpenGL is a neat 3D API but not so great at 2D work - we seem to be heading towards using XRender as our low-level 2D API with Cairo providing a Quartz style drawing system on top. That doesn't imply speed loss - both OpenGL and XRender are abstractions over the hardware acceleration engines of the card, so there's no reason why XRender based apps could not get the sort of speeds we associate with 3D HW accel (even if today it doesn't reach those speeds). The advantage of going the Xrender route is that it's much easier to mix and match the old style and new style rendering (note how OpenGL requires you to set it up for a particular rect but XRender can just be used as a standard drawing op).
Like I said, no expert, keithp is the canonical source for this, but that's what I've gathered from reading and listening.
Send $2000 to my address via PayPal and I will ship you a machine with modern hardware that works perfectly out-the-box with Linux.
Actually, don't do that - my point is that you're comparing apples (hardware+software) and oranges (just software). Apple have a distinct advantage in this area, in that nobody installs OS X on their souped up built-from-the-bits machine or cupboard box, so it's a lot easier to get hardware integration running OK.