As it exists now, there is no authentication. Therefore, impersonation is trivial. If for no other reasons than social engineering potential, that's a serious security problem in my book. Yes, you mention adding authentication to ICQ, but the fact remains that that hasn't happened, and based on past experience that's not likely to happen.
I still think, however that the base ICQ protocol is far better than anything brought forward by anyone else.
They take half your income because you work there. If you move to another country, your birth country won't be able to collect taxes from you.
That's not true in his case. The United States and Libya are the two countries in the world for which you still owe taxes regardless of what country you live and work in. This means that Amercians living and working overseas have often to pay taxes twice -- once to the US and once to their country of residence.
While I am happy to see the protocol documentation released, just because Microsoft is documenting the protocol as it exists now does not mean that they will continue to do so.
Time and time and time again, they have released documentation for a standard, only to latter add functionality that they do not document. Their undocumented extensions to their published SMB/CIFS standards are one good example of this.
My point is this: don't rely on the Microsoft protocol if you don't want to get the rug yanked out from under your feet later. You might be able to keep up by reverse-engineering, as Samba has, or live with the small subset of functionality that was documented, but do you really want to have to do either?
If you do use this protocol at all, use it only as a "bridge" for compatibility with MS clients. Don't make it your primary protocol. That way, if they make undocumented changes later, they end up cutting off their users from the world at large, rather than cutting off your users from Microsoft's world.
> Actually, there is a good reason -- speed. It > has to make this calculation lots of times.
&& and || short-circuit in C, and if you're really paranoid about performance, you can do a bit of explicit strength-reduction:
!( y & 3 ) && ( ( y % 100 ) || !( y % 400 ) )
This will be as fast as your existing code for the majority of cases, or possibly faster if your compiler doesn't do this bit of strength-reduction itself.
Yes, you'll see an extra division/compare for years divisible by four, but the initial divison/compare will have been replaced by an inexpensive binary AND for all cases. Years divisible by 100 (i.e. 2000) will also incur an additonal division/compare beyond that. (wish there was a convenient way to write this so that on ia32 the third test would reduce to anding EAX with 3 again, reusing the result of the last operation, rather than doing a second division) However, again, such years are certainly not the majority of cases.
I dunno; I would be suprised if this calculation were a bottleneck in the log analysis; to my mind it'd be more likely to be I/O-bound. When I get home, I'll try benchmarking your tool with and without this modification.
according to the BIG Bang theory, the universe was once as small as a pea. All that matter in so little space = enormous gravity. And I do mean _ENORMOUS_. But then, it exploded. Gravity didn't do shit all to prevent it. I guess it was on a coffee break...
Gravity literally didn't exist prior to the big bang (or for a short period afterwards), nor did mass.
What makes a black hole is not a certain amount of mass, just a certain amount of mass concentrated within a certain area. There's a certain critical density, you see.
Assuming you could pack the matter tightly enough, you could make a black hole massing only a few grams or less. In fact, for practical reasons, a laboratory-created black hole probably wouldn't have much more mass than that. ---
I mean... really. There are really only two things you need to know here, both of which you more or less HAVE to know in the first place to be worth much as an admin:
what/dev file goes with what drive
dd at its simplest is just dd if=input file of=output file
Once you know these two things (the first of which, especially, you ought to know), it is trivial to make the following inferences:
Gee... I want to get an image of the disk/dev/hdb4 in file blah...
dd if=/dev/hdb4 of=blah
Okay, now I want to write that image to/dev/hdc3...
dd if=blah of=/dev/hdc3
Hell, if that's too complicated for you, you can just use cp to and from the raw device.
Either of those commands is massively faster than starting up a shell script or interactive program and answering questions. So much for your precious time savings.
You, sir, should never, ever be a system administrator. Your unwillingness to learn or even think will ultimately mean catastrophe for your employer. I'm serious about that. You will get yourself in SERIOUS trouble if you don't really understand what you're doing.
Quite literallly 90% of the serious problems you encounter as an administrator will not be the sort that any programmer could ever have taken into account for you and written a friendly "OK" button to fix.
I can write a program that will mangle code a bit, but produce a program that does the same thing. I've just bypassed the GPL.
Nope, you've just used that program to create a derivative work, which still falls under the original license.
There's a program that translates code into plain English. You can use this on crypto source, take it out of the US, and translate it back into source. That would bypass the GPL too, since it reduces the code to raw algorithms.
Legally, that too is a derivative work. While it may then be in a form that is acceptable for export, it is still a derivative work.
I cannot purchase the rights to dialog. The original author is unknown. But it has a GPL at the top. Looks like I just need to rewrite it myself.
Hrm; that's an interesting situation. Is the license even valid when there is no copyright information? (probably, but it's worth looking into). This is a valid point, except it is not a problem specific to the GPL.
This problem also extends to large GPL'd products. If you own the licensed on xxx.c and xxx.h and roblimo owns abc123.c, def456.c, and cmdrtaco owns 987654321.c, and you won't sell to me, I'm screwed.
You get the exact same situation when you deal with software under other licenses with a number of copyright holders. You can just purchase license to roblimo's and cmdrtaco's code, and reimplement xxx.h and xxx.c yourself. That's still considerably less work than rewriting from scratch.
This, too, is not a problem specific to the GPL. For instance, Netscape had to rip out large chunks of Mozilla before releasing the source, because not all the different copyright holders would agree to the relicensing.
These problems are handled by X and BSD licenses...
The X and BSD licenses take the expediency of explicitly granting open-ended permission to relicense, avoiding the necessity of negotiating with the copyright holder. That's not a bad thing in and of itself, unless you like your code being enhanced and used in a proprietary fashion without any compensation to you or the other users/contributors, who had been giving to each other freely.
There's a difference between giving freely and and letting yourself be taken advantage of.
...and no duplication of effort is required.
This is assuming that everyone who uses the BSD/X-licensed code relicenses it in a compatible manner. That is not always the case.
To provide a counter-example to your assertion, let's say entity X takes your software package Y, and releases an enhanced version under license Z (which you cannot personally accept). If you want the new features under an acceptable license, you'll still have to reimplement them yourself. It's even harder if license Z means a completely propreitary licensing arrangement, such that you have to reverse-engineer the features they added. Thus, BSD/X licenses may (indirectly) result in duplication of effort, too.
Every license has its own set of problems and potential pitfalls.
Hummingbird makes an NFS client for Windows. I don't think they'll be much help for Linux's rather... problematic... NFS implementation, except maybe cooperating with it a little better. ---
Anyone who has read the GPL can tell you it is even more encumbered than any commercial license. At least with a commercial product, I can purchase rights to redistribute the program without source.
This is possible with GPLed software as well. The GPL does not (and indeed cannot) tie the hands of the copyright holder(s) with respect to licensing.
Just like any other software, it is entirely possible for you (as an individual or as a representative of a corporate entity) to negotiate alternate licensing arrangements with the copyright holders, which may or may not involve a transfer of funds. This is true regardless of the license attached to specific releases of the code.
The Berkeley and X licenses are in essence no different in this regard; they simply grant that permission to relicense implicitly.
I wish SGI the best of luck, but I'm really not sure it's enough to keep them afloat. Linux is by no means a magic bullet.
*sigh*
I really do hope I'm wrong about their ability to survive, though. It may be stupid, but the way most people (particularly management) would see Linux's inability to save a dying company as a general indictment of its commercial viability.
If SGI godes under, this could become "Let's all ditch this Linux thing before it drags us down like it did SGI!".
Maybe I'm just being morbid.
On second thought, all SGI needs to do is bring back the Cube. That'd make everything ok again. ---
DOOM clone is in Excel 95. You might be amused by the flight simulator in Excel 97, although it is admittedly somewhat less interesting.
Here's how to get to it:
(courtesy of eeggs.com:) 1. On a new Worksheet, Press F5 2. Type X97:L97 and hit enter 3. Press the tab key 4. Hold Ctrl-Shift 5. Click on the Chart Wizard toolbar button 6. Use mouse to fly around - Right button forward/ Left button reverse
Drop by eeggs.com to find some of the other, less "official"-looking (read: likely non-sanctioned) eggs. ---
In other words, it doesn't. You mention Solaris -- does it support Solaris/SPARC? What about AIX? What about Digital Unix/Alpha? What about IRIX/MIPS? Specifically what non-Intel architectures _are_ supported?
The Unix world is not all Intel Unix clones. Far from it. Get some perspective.
I bet it's more likely that one of the thousands of anonymous Microsoft employees puts a Trojan in Windows 2000 than that Linus and/or Alan put one in a kernel.
That's a sobering thought...
In an environment where people can be fired for inserting easter eggs et al in the product, you still see pinball games, flight simulators and even entire DOOM CLONES in Microsoft software. And these people are just screwing around for fun... what happens when you get someone with an agenda working on these projects? Say, a psychopath or a terrorist?
How well do companies like Microsoft screen their employees?
X is not necessary, but there's some functionality already there (or being developed for Xfree86) that I don't know if exists for console mode apps.
Yes, that's exactly the thrust of my first comment -- some of this stuff SHOULD be possible independently of X.
For example, there's GLX, if you want a remote app to be accelerated in your hardware.
GLX, in particular, probably is one of those things that belongs in X. I'm not desparate for network transparent console video. However, I would like to be able to have otherwise well-rounded video support outside of X. For a lot of specialized applications, X is just too big, but there aren't any good alternatives for accelerated graphics right now. (no, writing your own drivers in userspace a la svgalib is not a good alternative)
Also, multiple apps using the same rendering hardware.... There's already 3D support in console for 3dfx cards (I think Quake x can run accelerated under SVGALib + Glide, I'm not sure on this).
This is exactly the problem. You can't reliably share the graphics hardware right now without going through X. That needs to change. As far as SVGALib + Glide, that was precisely what I was referring to when I said "each app banging on the hardware directly is NOT a modern or a safe way of operating." (granted, it's not as bad if you have/dev/3dfx set up, but that's _hardly_ a generalist approach)
There's also the GGI project, but it's been ages since I last read about it.
KGI is a GGI subproject.
But X provides some other things than "full-screen accelerated games".
Sure, but sometimes people don't NEED those other things. Also keep in mind that there are some application types besides games that require fullscreen accelerated graphics.
The whole point to "Embrace and Extend" is that you are adding proprietary extensions to an open specification. An open source program can not by definition "Embrace and Extend" since are the changes are in the open. I can get XF86 and compile it on any UNIX or OS/2, so this is not an issue.
Hrm; yes, I should have used quotes around "embrace and extend". It really isn't the most applicable term. I'm just concerned about a loss of portability of X applications that rely on the new extensions, in much the same manner as a lot of Linux programmers don't bother to make their code [easily] portable to other Unices. (although that is arguably a problem because other Unices are often rather broken in some areas:P)
The anti-aliased text extension has the potential to be the worst culprit -- it introduces an entirely new API for drawing text, and supporting older X servers would mean writing all of your code that dealt with drawing text twice. (although hopefully you'd have abstracted it somewhat so that only meant one source module). Maybe we'll be lucky and that'll get handled by GTK and Qt. It may not really be that much of an issue after all.
For the sake of argument, though, can you really compile XFree86 for any Unix? Can I, say, replace the vendor's X server with XFree86 on my HP-UX workstation here? What about other non-Intel non-Linux/*BSD systems?
In general with X, you do pay a fairly large price due to the network transparency issue; however XSHM and especially XDGA do alot to resolve this. Theoretically, DGA in full screen mode is as fast as windows, though I can't back this up with numbers.
Well, I was really talking about applications in general, not just games. Most apps don't need or want to be beating on the framebuffer directly. XSHM can be applicable at times (imlib), but I don't really see how XDGA helps there...
For applications, anyway, drawing on a bitmap or a framebuffer is not always a good substitute for using the (potentially) accellerated drawing primitives either, is it? I don't think X is that fundamentally broken.
Also, just out of curiousity, how many non-XFree86 servers support XDGA?
Just had a thought... are DRI, DGA, the proposed anti-aliased font extension and so forth in XFree86 part of, or planned to be part of a current or future X11 spec? I've noticed that a lot of these things do not seem to be supported by non-XFree86 servers... we're not inadvertantly embracing and extending X11 here, are we? ---
> Is this driver issue or simply X is slower than > Win GUI subsystem ?
Well, in general with X you do pay a fairly large price for marshalling/demarshalling commands for relatively low-level drawing primitives, even for local stuff. Yes, there's the SHM extension, but that's only if you want/need to implement your own drawing primitives and scribble on the bitmap. And you lose network transparency if you rely on that.
The Win32 GDI (as far as I know) is basically a matter of local method invocation, with possible marshalling/demarshalling over a network connection going on behind the scenes in cases like Windows Terminal Server, but otherwise it's all local. ---
Slashdot Mirror
not that serious. It's IM for chrissakes
As it exists now, there is no authentication. Therefore, impersonation is trivial. If for no other reasons than social engineering potential, that's a serious security problem in my book. Yes, you mention adding authentication to ICQ, but the fact remains that that hasn't happened, and based on past experience that's not likely to happen.
I still think, however that the base ICQ protocol is far better than anything brought forward by anyone else.
Are you familiar with Caliban?
---
They take half your income because you work there. If you move to another country, your birth country won't be able to collect taxes from you.
That's not true in his case. The United States and Libya are the two countries in the world for which you still owe taxes regardless of what country you live and work in. This means that Amercians living and working overseas have often to pay taxes twice -- once to the US and once to their country of residence.
No, I don't think it's quite fair either.
---
While I am happy to see the protocol documentation released, just because Microsoft is documenting the protocol as it exists now does not mean that they will continue to do so.
Time and time and time again, they have released documentation for a standard, only to latter add functionality that they do not document. Their undocumented extensions to their published SMB/CIFS standards are one good example of this.
My point is this: don't rely on the Microsoft protocol if you don't want to get the rug yanked out from under your feet later. You might be able to keep up by reverse-engineering, as Samba has, or live with the small subset of functionality that was documented, but do you really want to have to do either?
If you do use this protocol at all, use it only as a "bridge" for compatibility with MS clients. Don't make it your primary protocol. That way, if they make undocumented changes later, they end up cutting off their users from the world at large, rather than cutting off your users from Microsoft's world.
---
Take a look at some of the ICQ exploits published sometime.
---
> Actually, there is a good reason -- speed. It
> has to make this calculation lots of times.
&& and || short-circuit in C, and if you're really paranoid about performance, you can do a bit of explicit strength-reduction:
!( y & 3 ) && ( ( y % 100 ) || !( y % 400 ) )
This will be as fast as your existing code for the majority of cases, or possibly faster if your compiler doesn't do this bit of strength-reduction itself.
Yes, you'll see an extra division/compare for years divisible by four, but the initial divison/compare will have been replaced by an inexpensive binary AND for all cases. Years divisible by 100 (i.e. 2000) will also incur an additonal division/compare beyond that. (wish there was a convenient way to write this so that on ia32 the third test would reduce to anding EAX with 3 again, reusing the result of the last operation, rather than doing a second division) However, again, such years are certainly not the majority of cases.
I dunno; I would be suprised if this calculation were a bottleneck in the log analysis; to my mind it'd be more likely to be I/O-bound. When I get home, I'll try benchmarking your tool with and without this modification.
---
according to the BIG Bang theory, the universe was once as small as a pea. All that matter in so little space = enormous gravity. And I do mean _ENORMOUS_. But then, it exploded. Gravity didn't do shit all to prevent it. I guess it was on a coffee break...
Gravity literally didn't exist prior to the big bang (or for a short period afterwards), nor did mass.
---
for us 'merkins
---
What makes a black hole is not a certain amount of mass, just a certain amount of mass concentrated within a certain area. There's a certain critical density, you see.
Assuming you could pack the matter tightly enough, you could make a black hole massing only a few grams or less. In fact, for practical reasons, a laboratory-created black hole probably wouldn't have much more mass than that.
---
I mean ... really. There are really only two things you need to know here, both of which you more or less HAVE to know in the first place to be worth much as an admin:
Once you know these two things (the first of which, especially, you ought to know), it is trivial to make the following inferences:
Gee... I want to get an image of the disk /dev/hdb4 in file blah...
dd if=/dev/hdb4 of=blah
Okay, now I want to write that image to /dev/hdc3...
dd if=blah of=/dev/hdc3
Hell, if that's too complicated for you, you can just use cp to and from the raw device.
Either of those commands is massively faster than starting up a shell script or interactive program and answering questions. So much for your precious time savings.
You, sir, should never, ever be a system administrator. Your unwillingness to learn or even think will ultimately mean catastrophe for your employer. I'm serious about that. You will get yourself in SERIOUS trouble if you don't really understand what you're doing.
Quite literallly 90% of the serious problems you encounter as an administrator will not be the sort that any programmer could ever have taken into account for you and written a friendly "OK" button to fix.
---
This Alix is a bit young for RMS anyway.
---
I mean, it's just a line of code, and there's nothing wrong with it operating more correctly. Just fix it already and make everyone happy.
And hey, you never know when someone might have some odd reason for post-dating their logs 100 years in the future...
---
So the GPL doesn't protect algorithms, just code.
Correct. This is true of all licenses.
I can write a program that will mangle code a bit, but produce a program that does the same thing. I've just bypassed the GPL.
Nope, you've just used that program to create a derivative work, which still falls under the original license.
There's a program that translates code into plain English. You can use this on crypto source, take it out of the US, and translate it back into source. That would bypass the GPL too, since it reduces the code to raw algorithms.
Legally, that too is a derivative work. While it may then be in a form that is acceptable for export, it is still a derivative work.
---
I cannot purchase the rights to dialog. The original author is unknown. But it has a GPL at the top. Looks like I just need to rewrite it myself.
Hrm; that's an interesting situation. Is the license even valid when there is no copyright information? (probably, but it's worth looking into). This is a valid point, except it is not a problem specific to the GPL.
This problem also extends to large GPL'd products. If you own the licensed on xxx.c and xxx.h and roblimo owns abc123.c, def456.c, and cmdrtaco owns 987654321.c, and you won't sell to me, I'm screwed.
You get the exact same situation when you deal with software under other licenses with a number of copyright holders. You can just purchase license to roblimo's and cmdrtaco's code, and reimplement xxx.h and xxx.c yourself. That's still considerably less work than rewriting from scratch.
This, too, is not a problem specific to the GPL. For instance, Netscape had to rip out large chunks of Mozilla before releasing the source, because not all the different copyright holders would agree to the relicensing.
These problems are handled by X and BSD licenses...
The X and BSD licenses take the expediency of explicitly granting open-ended permission to relicense, avoiding the necessity of negotiating with the copyright holder. That's not a bad thing in and of itself, unless you like your code being enhanced and used in a proprietary fashion without any compensation to you or the other users/contributors, who had been giving to each other freely.
There's a difference between giving freely and and letting yourself be taken advantage of.
This is assuming that everyone who uses the BSD/X-licensed code relicenses it in a compatible manner. That is not always the case.
To provide a counter-example to your assertion, let's say entity X takes your software package Y, and releases an enhanced version under license Z (which you cannot personally accept). If you want the new features under an acceptable license, you'll still have to reimplement them yourself. It's even harder if license Z means a completely propreitary licensing arrangement, such that you have to reverse-engineer the features they added. Thus, BSD/X licenses may (indirectly) result in duplication of effort, too.
Every license has its own set of problems and potential pitfalls.
---
Hummingbird makes an NFS client for Windows. I don't think they'll be much help for Linux's rather ... problematic ... NFS implementation, except maybe cooperating with it a little better.
---
Anyone who has read the GPL can tell you it is even more encumbered than any commercial license. At least with a commercial product, I can purchase rights to redistribute the program without source.
This is possible with GPLed software as well. The GPL does not (and indeed cannot) tie the hands of the copyright holder(s) with respect to licensing.
Just like any other software, it is entirely possible for you (as an individual or as a representative of a corporate entity) to negotiate alternate licensing arrangements with the copyright holders, which may or may not involve a transfer of funds. This is true regardless of the license attached to specific releases of the code.
The Berkeley and X licenses are in essence no different in this regard; they simply grant that permission to relicense implicitly.
---
dear me... I even used preview...
:%s/godes/goes/
---
I wish SGI the best of luck, but I'm really not sure it's enough to keep them afloat. Linux is by no means a magic bullet.
*sigh*
I really do hope I'm wrong about their ability to survive, though. It may be stupid, but the way most people (particularly management) would see Linux's inability to save a dying company as a general indictment of its commercial viability.
If SGI godes under, this could become "Let's all ditch this Linux thing before it drags us down like it did SGI!".
Maybe I'm just being morbid.
On second thought, all SGI needs to do is bring back the Cube. That'd make everything ok again.
---
DOOM clone is in Excel 95. You might be amused by the flight simulator in Excel 97, although it is admittedly somewhat less interesting.
Here's how to get to it:
(courtesy of eeggs.com:)
1. On a new Worksheet, Press F5
2. Type X97:L97 and hit enter
3. Press the tab key
4. Hold Ctrl-Shift
5. Click on the Chart Wizard toolbar button
6. Use mouse to fly around - Right button forward/ Left button reverse
Drop by eeggs.com to find some of the other, less "official"-looking (read: likely non-sanctioned) eggs.
---
In other words, it doesn't. You mention Solaris -- does it support Solaris/SPARC? What about AIX? What about Digital Unix/Alpha? What about IRIX/MIPS? Specifically what non-Intel architectures _are_ supported?
The Unix world is not all Intel Unix clones. Far from it. Get some perspective.
---
I bet it's more likely that one of the thousands of anonymous Microsoft employees puts a Trojan in Windows 2000 than that Linus and/or Alan put one in a kernel.
That's a sobering thought...
In an environment where people can be fired for inserting easter eggs et al in the product, you still see pinball games, flight simulators and even entire DOOM CLONES in Microsoft software. And these people are just screwing around for fun... what happens when you get someone with an agenda working on these projects? Say, a psychopath or a terrorist?
How well do companies like Microsoft screen their employees?
---
X is not necessary, but there's some functionality already there (or being developed for Xfree86) that I don't know if exists for console mode apps.
Yes, that's exactly the thrust of my first comment -- some of this stuff SHOULD be possible independently of X.
For example, there's GLX, if you want a remote app to be accelerated in your hardware.
GLX, in particular, probably is one of those things that belongs in X. I'm not desparate for network transparent console video. However, I would like to be able to have otherwise well-rounded video support outside of X. For a lot of specialized applications, X is just too big, but there aren't any good alternatives for accelerated graphics right now. (no, writing your own drivers in userspace a la svgalib is not a good alternative)
Also, multiple apps using the same rendering hardware .... There's already 3D support in console for 3dfx cards (I think Quake x can run accelerated under SVGALib + Glide, I'm not sure on this).
This is exactly the problem. You can't reliably share the graphics hardware right now without going through X. That needs to change. As far as SVGALib + Glide, that was precisely what I was referring to when I said "each app banging on the hardware directly is NOT a modern or a safe way of operating." (granted, it's not as bad if you have /dev/3dfx set up, but that's _hardly_ a generalist approach)
There's also the GGI project, but it's been ages since I last read about it.
KGI is a GGI subproject.
But X provides some other things than "full-screen accelerated games".
Sure, but sometimes people don't NEED those other things. Also keep in mind that there are some application types besides games that require fullscreen accelerated graphics.
---
The whole point to "Embrace and Extend" is that you are adding proprietary extensions to an open specification. An open source program can not by definition "Embrace and Extend" since are the changes are in the open. I can get XF86 and compile it on any UNIX or OS/2, so this is not an issue.
Hrm; yes, I should have used quotes around "embrace and extend". It really isn't the most applicable term. I'm just concerned about a loss of portability of X applications that rely on the new extensions, in much the same manner as a lot of Linux programmers don't bother to make their code [easily] portable to other Unices. (although that is arguably a problem because other Unices are often rather broken in some areas :P)
The anti-aliased text extension has the potential to be the worst culprit -- it introduces an entirely new API for drawing text, and supporting older X servers would mean writing all of your code that dealt with drawing text twice. (although hopefully you'd have abstracted it somewhat so that only meant one source module). Maybe we'll be lucky and that'll get handled by GTK and Qt. It may not really be that much of an issue after all.
For the sake of argument, though, can you really compile XFree86 for any Unix? Can I, say, replace the vendor's X server with XFree86 on my HP-UX workstation here? What about other non-Intel non-Linux/*BSD systems?
---
In general with X, you do pay a fairly large price due to the network transparency issue; however XSHM and especially XDGA do alot to resolve this. Theoretically, DGA in full screen mode is as fast as windows, though I can't back this up with numbers.
Well, I was really talking about applications in general, not just games. Most apps don't need or want to be beating on the framebuffer directly. XSHM can be applicable at times (imlib), but I don't really see how XDGA helps there...
For applications, anyway, drawing on a bitmap or a framebuffer is not always a good substitute for using the (potentially) accellerated drawing primitives either, is it? I don't think X is that fundamentally broken.
Also, just out of curiousity, how many non-XFree86 servers support XDGA?
---
Just had a thought... are DRI, DGA, the proposed anti-aliased font extension and so forth in XFree86 part of, or planned to be part of a current or future X11 spec? I've noticed that a lot of these things do not seem to be supported by non-XFree86 servers ... we're not inadvertantly embracing and extending X11 here, are we?
---
> Is this driver issue or simply X is slower than
> Win GUI subsystem ?
Well, in general with X you do pay a fairly large price for marshalling/demarshalling commands for relatively low-level drawing primitives, even for local stuff. Yes, there's the SHM extension, but that's only if you want/need to implement your own drawing primitives and scribble on the bitmap. And you lose network transparency if you rely on that.
The Win32 GDI (as far as I know) is basically a matter of local method invocation, with possible marshalling/demarshalling over a network connection going on behind the scenes in cases like Windows Terminal Server, but otherwise it's all local.
---