Of course this is handled in the.Net world rather nicely, and you don't even need to worry about some developer that can't bother to read the documentation to figure out which interface is obsolete. (Which is apparently a very big problem in the linux driver development).
.Net is userspace, and the linked document is not concerned with userspace. The userspace visible kernel APIs have been stable since before Linux 1.0, as the document points out.
In Linux, obsolete internal kernel interfaces are removed when they become obsolete, and anything using the obsolete interface is ported to the new interface by the authors of the new interface. I'm sure you'll agree that it's difficult to accidentally use an interface that no longer exists.
Now, for a proprietary kernel that needs to retain binary compatibility with every driver ever developed for it, simply because the old drivers cannot or will not be fixed, it becomes exceedingly easy to accidentally use an obsolete interface that's hanging around just to support some cruft from the mid 90s.
They should be for all Intel cards, and packaged together with X.org. As a point of reference, more than a year ago (when XGL was new), I tried out the Korrora Livecd on my friend's laptop with an Intel 855GM (or maybe 852GM, I don't remember now), and it ran all the fancy 3D effects quite well.
You could also check the Ubuntu forums, you might be hitting a problem similar to this.
You're probably using really old drivers or you have DRI (read: 3D acceleration) disabled. Current Intel drivers support all Intel cards quite well, also see my previous post on this issue.
Intel graphics cards have historically been bad options for OpenGL and 3D apps in Linux.
That is most definitely not the case now. Intel cards are certainly not speed demons, but they work quite well as they have good open source drivers written by Intel themselves. Intel employs several of the main X.org hackers, including Keith Packard. Also see this announcement.
I would recommend an Intel graphics card over an Nvidia or ATI for a Linux machine unless you plan on playing demanding games like Quake 4 or Doom 3 (for which I'd suggest an Nvidia). I would never recommend an ATI card that requires the use of fgrlx (that's any X1000 or X2000 series card at the moment).
So, 40 years ago, could you tell me with 100% certainty that you would still be able to run all of said software today? No, of course you couldn't. Therein lies the problem.
It doesn't matter if one proprietary software vendor is reliable, they *all* must be, which will never happen.
Wine's D3D 9 implementation is quickly approaching feature completeness. Wine also has a SoCer to start an initial D3D 10 implementation, as to when the D3D 10 implementation will be useful (sufficiently complete, and something to use it on) is anyone's guess, but most of it should be fairly similar to D3D 9.
Alky is most definitely vapourware. If you've followed their history they've launched and disappeared again several times now. Their goals may seem impressive, but they have yet to produce any working code.
In Alky's initial "open source" phase (about a year ago), they claimed they wouldn't use any Wine code for specious reasons that would only convince the uninformed, while failing to understand all of the problems associated with what they were trying to do (in place binary translation across arbitrary architectures and OSes without any source access). They failed to answer questions about how they would solve problems such as IPC, especially since they claimed they wouldn't use a "wineserver"-like process. After a month or so of copying Wine headers into Alky verbatim and without attribution, they shut down their web site and kickbanned everyone from their IRC channel.
Alky resurfaced again a few months later with a closed source twist and the claim of being able to convert the Prey demo to run directly on Linux. I have yet to hear anyone who's had success with this said "converter". I stopped following the project at this point, but I doubt they'll produce any useful code any time soon.
OpenGL already supports geometry shaders and has for quite awhile. Unless I'm missing something, that's the only new feature worth mentioning in D3D 10.
Yes, there ARE differences which, I must say, is one of the most challenging and fun parts of web design.
You are incredibly masochistic, and I don't agree with you. Challenging, yes, but fun, most definitely not. I prefer to actually do useful things rather than have to throw in loads upon loads of hacks to trick IE 6 into rendering a page somewhat reasonably. Making something work the same in Konqueror, Firefox and Opera is trivial in comparison.
Now, of course, everyone has to use the latest technology in webpage design. In other words, the most incompatible technology. What looks lovely in IE looks aweful in Firefox and even worse in Opera. Ok, ok, maybe not aweful. But not JUST the same way. So you'd have to do the page two or three times to make it compatible with every browser. But that, in turn, would cost more money.
If you plan to use any web technology created this millennium, and you want it to work properly in IE 6, prepare to tear your hair out repeatedly. Speaking from experience, supporting Konqueror, Firefox and Opera simultaneously is substantially easier than supporting IE 6 at all.
From a developer's perspective, I prefer Gnome's methodology. I'd rather things be done 'right', in that orthogonal, reusable, generic fashion. Maybe it lacks some of the features, but that's the price I pay...
Your statement contradicts itself. You state that you don't like lots of dependences for a program, but you expect developers to create highly reusable libraries? What's the point of creating them if you don't want anybody to use them? I'd rather a developer link against libwheel rather than reinvent it, then spend all the saved time on solving problems that aren't already solved. Code reuse applies equally to both libraries and programs.
GTK has more of the killer Linux apps like Gaim, Open Office, Mozilla, etc.
OpenOffice doesn't use GTK any more than it uses Qt. OpenOffice uses it's own custom written widget set, though it can optionally integrate somewhat with Qt at least by using Qt icons, etc.
I think you should also consider that the anticipation of doing something is often better than the actual doing of something. When you find out you have, say, 3 months to live, you can no longer anticipate to do a lot of things, and that makes your last 3 months of living rather miserable, if you ask me.
I guess what I'm really saying here is that my plans for the rest of my life are far more important to me than anything I could do in a final 3 months, regardless of any knowledge of my imminent demise.
If you are literally living your life as if you might die in a handful of months, congratulations.
I didn't say that, nor would it be necessary for me to feel the way I do. I think the feeling of impending doom and the realization that any of my plans involving more than a couple months are now useless would outweigh any short term benefits, such as driving around an expensive car for a few months (as the poster above mentioned).
Would you truly prefer to drive $expensive_car with the knowledge that you're going to die quite soon vs the ignorant bliss?
I think the parent's point was that the cluster management system could simply batch out two individual (single threaded) processes to each node (for a total of 16 processes over 8 nodes), rather than just a single process per node. This may or may not work, depending on how the processes communicate over the network, but it is certainly a substantially easier task than writing a multi-threaded distributed program in most any case.
Slashdot Mirror
.Net is userspace, and the linked document is not concerned with userspace. The userspace visible kernel APIs have been stable since before Linux 1.0, as the document points out.
In Linux, obsolete internal kernel interfaces are removed when they become obsolete, and anything using the obsolete interface is ported to the new interface by the authors of the new interface. I'm sure you'll agree that it's difficult to accidentally use an interface that no longer exists.
Now, for a proprietary kernel that needs to retain binary compatibility with every driver ever developed for it, simply because the old drivers cannot or will not be fixed, it becomes exceedingly easy to accidentally use an obsolete interface that's hanging around just to support some cruft from the mid 90s.
You think you want a stable kernel ABI, but you really don't.
They should be for all Intel cards, and packaged together with X.org. As a point of reference, more than a year ago (when XGL was new), I tried out the Korrora Livecd on my friend's laptop with an Intel 855GM (or maybe 852GM, I don't remember now), and it ran all the fancy 3D effects quite well.
You could also check the Ubuntu forums, you might be hitting a problem similar to this.
The new Intel drivers should come stock with X.org, as they're integrated with it.
As for DRI, if
says Yes, then you're good to go.You're probably using really old drivers or you have DRI (read: 3D acceleration) disabled. Current Intel drivers support all Intel cards quite well, also see my previous post on this issue.
That is most definitely not the case now. Intel cards are certainly not speed demons, but they work quite well as they have good open source drivers written by Intel themselves. Intel employs several of the main X.org hackers, including Keith Packard. Also see this announcement.
I would recommend an Intel graphics card over an Nvidia or ATI for a Linux machine unless you plan on playing demanding games like Quake 4 or Doom 3 (for which I'd suggest an Nvidia). I would never recommend an ATI card that requires the use of fgrlx (that's any X1000 or X2000 series card at the moment).
So, 40 years ago, could you tell me with 100% certainty that you would still be able to run all of said software today? No, of course you couldn't. Therein lies the problem.
It doesn't matter if one proprietary software vendor is reliable, they *all* must be, which will never happen.
Do you have any sources to back up your claim? It doesn't work for me:
var a = "foo"; alert(a);alert(a);
Both Firefox and Konqueror complain of script errors in the latter page.
Proprietary software is not practical, especially in the long term. The best tool for the job must also be practical.
I laughed out loud at this point and only read the rest of the page for amusement. I don't think you understand what you're talking about.
Ah, but those aren't OSes, of course. They just occasionaly manage to (poorly) imitate some features that one would expect to find in an OS.
Wine's D3D 9 implementation is quickly approaching feature completeness. Wine also has a SoCer to start an initial D3D 10 implementation, as to when the D3D 10 implementation will be useful (sufficiently complete, and something to use it on) is anyone's guess, but most of it should be fairly similar to D3D 9.
Alky is most definitely vapourware. If you've followed their history they've launched and disappeared again several times now. Their goals may seem impressive, but they have yet to produce any working code.
In Alky's initial "open source" phase (about a year ago), they claimed they wouldn't use any Wine code for specious reasons that would only convince the uninformed, while failing to understand all of the problems associated with what they were trying to do (in place binary translation across arbitrary architectures and OSes without any source access). They failed to answer questions about how they would solve problems such as IPC, especially since they claimed they wouldn't use a "wineserver"-like process. After a month or so of copying Wine headers into Alky verbatim and without attribution, they shut down their web site and kickbanned everyone from their IRC channel.
Alky resurfaced again a few months later with a closed source twist and the claim of being able to convert the Prey demo to run directly on Linux. I have yet to hear anyone who's had success with this said "converter". I stopped following the project at this point, but I doubt they'll produce any useful code any time soon.
OpenGL already supports geometry shaders and has for quite awhile. Unless I'm missing something, that's the only new feature worth mentioning in D3D 10.
You are incredibly masochistic, and I don't agree with you. Challenging, yes, but fun, most definitely not. I prefer to actually do useful things rather than have to throw in loads upon loads of hacks to trick IE 6 into rendering a page somewhat reasonably. Making something work the same in Konqueror, Firefox and Opera is trivial in comparison.
If you plan to use any web technology created this millennium, and you want it to work properly in IE 6, prepare to tear your hair out repeatedly. Speaking from experience, supporting Konqueror, Firefox and Opera simultaneously is substantially easier than supporting IE 6 at all.
Bugs don't count as functionality.
I vaguely remember something like this as well. Of course, I never actually saw one or it's results in person, though.
I'm tempted to say it was just a hoax.
Soon the binary only regulatory daemon won't be necessary, see http://intellinuxwireless.org/.
No, unfortunately not.
Your statement contradicts itself. You state that you don't like lots of dependences for a program, but you expect developers to create highly reusable libraries? What's the point of creating them if you don't want anybody to use them? I'd rather a developer link against libwheel rather than reinvent it, then spend all the saved time on solving problems that aren't already solved. Code reuse applies equally to both libraries and programs.
OpenOffice doesn't use GTK any more than it uses Qt. OpenOffice uses it's own custom written widget set, though it can optionally integrate somewhat with Qt at least by using Qt icons, etc.
You know that both Opera and EditPad are proprietary software, not open source, right?
I think you should also consider that the anticipation of doing something is often better than the actual doing of something. When you find out you have, say, 3 months to live, you can no longer anticipate to do a lot of things, and that makes your last 3 months of living rather miserable, if you ask me.
I guess what I'm really saying here is that my plans for the rest of my life are far more important to me than anything I could do in a final 3 months, regardless of any knowledge of my imminent demise.
I didn't say that, nor would it be necessary for me to feel the way I do. I think the feeling of impending doom and the realization that any of my plans involving more than a couple months are now useless would outweigh any short term benefits, such as driving around an expensive car for a few months (as the poster above mentioned).
Would you truly prefer to drive $expensive_car with the knowledge that you're going to die quite soon vs the ignorant bliss?
Indeed. Personally, I'd rather not know unless there's something I can do to prevent it. In this case, it seems like that's not the case.
I think the parent's point was that the cluster management system could simply batch out two individual (single threaded) processes to each node (for a total of 16 processes over 8 nodes), rather than just a single process per node. This may or may not work, depending on how the processes communicate over the network, but it is certainly a substantially easier task than writing a multi-threaded distributed program in most any case.