There you go getting on your thermodynamic high horse but screw up big time when you confuse energy requirements with some sort of cataclysmic power surge. Very silly, you're a big numbers guy with no patience.
w.r.t. solving chess, there are such things as tree pruning and of course not all states have to be stored, they are merely searched. Then of course there's the prospect of additional mathematical optimizations.
P.S. typo, that should read "GLX is fully supported.
Also remember that an application displaying on a 'remote' X server is actually running on the X server that you're sitting in front of. So when I say the textures and display lists are stored remotely they're on the graphics card you're getting video from.
Wrong, networked GLX if fully supported in correctly configured X servers. Native hardware interfaces called through the DRI (for example) do get used when running natively to interface directly to the hardware but all GL calls have related GLX networking protocol and CAN and do work over a network connection on a remote display.
Moreover when you use a remote display the OpenGL context on the remote system reports to your your application the querryable resources of that display.
Display lists and textures are stored remotely and so the application performance of well written OpenGL code can be extremely fast when you run it remotely because the hardware capabilities of the server can still get used to their fullest.
All of this is of course completely application transparent, you don't have to write a line of code, it just works.
Geeze, most laser pointers say don't look directly into the beam, this 15mW laser's warning says don't look directly at the dot it creates. Yikes, I'm thinking this isn't the safest thing to own either for your eyesight or legal liability.
They are obliged to do that if they expect a remedy. It's put up or shut up time. They keep pointing the finger and have done nothing that would place a burden of fixing the problem upon the shoulders of anyone they claim to be infringing.
3 mod points down as Flamebait? Some guy posts VERBATIM the contents of a server that is running just fine and it's flamabait to suggest it was redundant? That's complete bullshit.
Burger flippers get paid low wages because they're unskilled and anybody can replace them. Burger flippers also get paid more in the US than anywhere else and this skilled guy has to eat his own share of burgers.
He's in demand, the project is his, he knows the code. He should charge a fee appropriate for his skill level and his unique ability to get this job done. It should have nothing to do with what some unmotivated fool at McDonalds has to put up with as a salary.
Having said that $100/hour seems on the high side for a private individual billing for some tweaks to an open source project. That works out at something like $200k per year if you can bill 40 hours a week and give yourself a couple of weeks holidays.
Not spin, just reasonable analysis. There are legal remedies for this stuff and legal obligations. SGI has met it's legal obligations, SCO has done nothing but issue press releases. They have not met any of their obligations to inform anyone of a specific alleged infringement. In the face of this SGI has gone the extra mile to sanitize their code and has been very open about it.
Even if there is stuff in there this press release illustrates a case study of how it can be handled. The sky is not falling and SCO will not be able to hijack the Linux codebase.
It is telling that all this talk is the result of SCO press releases, nothing more. They have not made any legal claims of copyright infringement against SGI or Linux, only PR "spin".
SCO "says"?!!! Legally that means nothing. They have an obligation to inform others of the infringing lines of code and give opportunity for a remedy. If I say some outlandish thing would you always slpit the difference irrespective of the merits of the claim? There are some blatantly sucpicious things going on with SCO's claims and press releases. The only legal claims they have made are contract claims against IBM, all the rest is just press releases. They have made no legal claims against Linux or SGI, but are merely trying to scare the market. In the face of this YOU really don't know whom to believe? There is ample evidence already in the public domain to arrive at an informed opinion. The debelopment logs for Linux are public and available. In the face of this you are still splitting the difference?
Just what do you think developers have been doing for years writing Linux? Do you really think anyone can come along and through some hand waving simply take the fruits of their labors? The copyright work of millions of industrious hours of coding simply stolen by SCO? Or perhaps you think that Open SOurce developers just sit around and copy the code of others all day long?
It doesn't matter how substantial the infringing code is, it will be cleaned up, and Linux will move on retaining what it rightfully owns.
No it does not strengthen it. For SCO to have a copyright case that substantively affects Linux they would need much more than a few lines of code that slipped through a review process that were subsequently removed after the matter was raised.
It is highly material to the case that this was a few lines of inadvertant code among millions and that SGI has removed all it could find. Without further notification of offending lines SCO has no leg to stand on. SGI is doing the right thing legally.
This totally scuppers SCO's argument that Linux contributors are out of control and stealing their stuff.
Legally SGI is doing the right thing. They perform due dilligence and if anything slips through the cracks they remedy it. It illustrates just how flimsy SCO's copyright case is a pointer to what may actually ultimately happen when this matter is resolved.
Prepare for more crazy ramblings from SCO in the immediate future. They will undoubtedly issue a press release claiming this is an admission of wrongdoing by SGI and play up the aspect of the letter that suggest missappropriated code, but of course this is not the message to be taken from the SGI letter.
Except that flash is an overly complex implementation nightmare that is never the same on any two platforms especially when you start getting into animations.
The SMIL animation spec is ambiguous in places and tries to be all things to all men, failing badly.
Show me one SVG implementation that is adequately functional. Even Adobe's SVG implementation fails miserably on some very simple tests.
Bruce needs to take another read of HPs offer, they do not merely offer to refund the purchase price. They say they will take up the case on your behalf.
Re:64bit performance gains...
on
AMD64 Preview
·
· Score: 1
P.S. I meant "features added to the CPUs that have nothing to do with 64 bit computing", but the advocates of 64 bit computing are listing them as inate advantages of 64 bit CPUs.
Re:64bit performance gains...
on
AMD64 Preview
·
· Score: 1
32 bit not being faster than 64 bit on the same CPU is NOT the point. It's what you could have done with 32 bit & the same die area with a 1MB cache and onboard dual channel memory controller extra registers etc and NO 64 bit support with a dedicated 32 bit CPU that is the valid comparrison of the relative merits.
Re:64bit performance gains...
on
AMD64 Preview
·
· Score: 1
I tend to disagree. Yes data types > 32 bit will speed up but they do not dominate most applications. Sizeof for most common types is 32 bit or less. As for not exploiting x86, you should realize that the registers come from redefining the instruction set etc, you could do this with x86, you can add registers, and this has been done in the past. And SSE has 128 bit registers to operate on types as an indication of what's possible now by scaling performance on smaller types so if you're recompiling you can win anyway on existing x86 platforms.
This is what's rather confusing about the debate here, features added to these CPUs that have nothing to do with x86.
Re:64bit performance gains...
on
AMD64 Preview
·
· Score: 1
It is a big deal compared to existing 32 bit processors. Yes cache latency is important, but eliminating the cahe miss and therefore system memory latency is always a win., You don't stall the processor as often.
If someone does it with my code I'll consider them theives. They're welcome to write their OWN code if they think it's so easy, but taking MY SOFTWARE dissassembling it converting it to C and then calling it their own is theft. Now if they dissassemble to figure out some hardware interface that's one thing, but they'd better throw the code away and write their own stuff to that interface instead of using the copy. I don't care how difficult the copying process is, they are free to write their own.
Excellent point, you are right (although I don't know about any lack of precedent or what impact more recent laws would have on this). Anyone trying this better hope I'm not on the jury of course, because IMHO this has much more to do with copying than looking and learning.
Slashdot Mirror
There you go getting on your thermodynamic high horse but screw up big time when you confuse energy requirements with some sort of cataclysmic power surge. Very silly, you're a big numbers guy with no patience.
w.r.t. solving chess, there are such things as tree pruning and of course not all states have to be stored, they are merely searched. Then of course there's the prospect of additional mathematical optimizations.
P.S. typo, that should read "GLX is fully supported.
Also remember that an application displaying on a 'remote' X server is actually running on the X server that you're sitting in front of. So when I say the textures and display lists are stored remotely they're on the graphics card you're getting video from.
Wrong, networked GLX if fully supported in correctly configured X servers. Native hardware interfaces called through the DRI (for example) do get used when running natively to interface directly to the hardware but all GL calls have related GLX networking protocol and CAN and do work over a network connection on a remote display.
Moreover when you use a remote display the OpenGL context on the remote system reports to your your application the querryable resources of that display.
Display lists and textures are stored remotely and so the application performance of well written OpenGL code can be extremely fast when you run it remotely because the hardware capabilities of the server can still get used to their fullest.
All of this is of course completely application transparent, you don't have to write a line of code, it just works.
setenv DISPLAY is your friend.
Geeze, most laser pointers say don't look directly into the beam, this 15mW laser's warning says don't look directly at the dot it creates. Yikes, I'm thinking this isn't the safest thing to own either for your eyesight or legal liability.
They are obliged to do that if they expect a remedy. It's put up or shut up time. They keep pointing the finger and have done nothing that would place a burden of fixing the problem upon the shoulders of anyone they claim to be infringing.
Their FUD campaign is obvious.
B.F.D., that wasn't even the point of the post. Did you even follow the thread to see my point before bleating for moderators?
Geeze no wonder the slashdot crowd has a reputation as a baying mob of anonymous idiots.
3 mod points down as Flamebait? Some guy posts VERBATIM the contents of a server that is running just fine and it's flamabait to suggest it was redundant? That's complete bullshit.
Burger flippers get paid low wages because they're unskilled and anybody can replace them. Burger flippers also get paid more in the US than anywhere else and this skilled guy has to eat his own share of burgers.
He's in demand, the project is his, he knows the code. He should charge a fee appropriate for his skill level and his unique ability to get this job done. It should have nothing to do with what some unmotivated fool at McDonalds has to put up with as a salary.
Having said that $100/hour seems on the high side for a private individual billing for some tweaks to an open source project. That works out at something like $200k per year if you can bill 40 hours a week and give yourself a couple of weeks holidays.
Reguardless, the post should have been modded as redundant.
You'd think, and indeed they can. Just because some karma whore first posts the text file doesn't mean the server is even noticing the load.
Not spin, just reasonable analysis. There are legal remedies for this stuff and legal obligations. SGI has met it's legal obligations, SCO has done nothing but issue press releases. They have not met any of their obligations to inform anyone of a specific alleged infringement. In the face of this SGI has gone the extra mile to sanitize their code and has been very open about it.
Even if there is stuff in there this press release illustrates a case study of how it can be handled. The sky is not falling and SCO will not be able to hijack the Linux codebase.
It is telling that all this talk is the result of SCO press releases, nothing more. They have not made any legal claims of copyright infringement against SGI or Linux, only PR "spin".
SCO "says"?!!! Legally that means nothing. They have an obligation to inform others of the infringing lines of code and give opportunity for a remedy. If I say some outlandish thing would you always slpit the difference irrespective of the merits of the claim? There are some blatantly sucpicious things going on with SCO's claims and press releases. The only legal claims they have made are contract claims against IBM, all the rest is just press releases. They have made no legal claims against Linux or SGI, but are merely trying to scare the market. In the face of this YOU really don't know whom to believe? There is ample evidence already in the public domain to arrive at an informed opinion. The debelopment logs for Linux are public and available. In the face of this you are still splitting the difference?
Just what do you think developers have been doing for years writing Linux? Do you really think anyone can come along and through some hand waving simply take the fruits of their labors? The copyright work of millions of industrious hours of coding simply stolen by SCO? Or perhaps you think that Open SOurce developers just sit around and copy the code of others all day long?
It doesn't matter how substantial the infringing code is, it will be cleaned up, and Linux will move on retaining what it rightfully owns.
No it does not strengthen it. For SCO to have a copyright case that substantively affects Linux they would need much more than a few lines of code that slipped through a review process that were subsequently removed after the matter was raised.
It is highly material to the case that this was a few lines of inadvertant code among millions and that SGI has removed all it could find. Without further notification of offending lines SCO has no leg to stand on. SGI is doing the right thing legally.
This totally scuppers SCO's argument that Linux contributors are out of control and stealing their stuff.
Legally SGI is doing the right thing. They perform due dilligence and if anything slips through the cracks they remedy it. It illustrates just how flimsy SCO's copyright case is a pointer to what may actually ultimately happen when this matter is resolved.
Prepare for more crazy ramblings from SCO in the immediate future. They will undoubtedly issue a press release claiming this is an admission of wrongdoing by SGI and play up the aspect of the letter that suggest missappropriated code, but of course this is not the message to be taken from the SGI letter.
Dang, I meant "Except that SVG is an overly complex implementation nightmare" bah.....
Except that flash is an overly complex implementation nightmare that is never the same on any two platforms especially when you start getting into animations.
The SMIL animation spec is ambiguous in places and tries to be all things to all men, failing badly.
Show me one SVG implementation that is adequately functional. Even Adobe's SVG implementation fails miserably on some very simple tests.
Bruce needs to take another read of HPs offer, they do not merely offer to refund the purchase price. They say they will take up the case on your behalf.
P.S. I meant "features added to the CPUs that have nothing to do with 64 bit computing", but the advocates of 64 bit computing are listing them as inate advantages of 64 bit CPUs.
32 bit not being faster than 64 bit on the same CPU is NOT the point. It's what you could have done with 32 bit & the same die area with a 1MB cache and onboard dual channel memory controller extra registers etc and NO 64 bit support with a dedicated 32 bit CPU that is the valid comparrison of the relative merits.
I tend to disagree. Yes data types > 32 bit will speed up but they do not dominate most applications. Sizeof for most common types is 32 bit or less. As for not exploiting x86, you should realize that the registers come from redefining the instruction set etc, you could do this with x86, you can add registers, and this has been done in the past. And SSE has 128 bit registers to operate on types as an indication of what's possible now by scaling performance on smaller types so if you're recompiling you can win anyway on existing x86 platforms.
This is what's rather confusing about the debate here, features added to these CPUs that have nothing to do with x86.
It is a big deal compared to existing 32 bit processors. Yes cache latency is important, but eliminating the cahe miss and therefore system memory latency is always a win., You don't stall the processor as often.
1) Is NOT an inate property of a 64 bit processor. You could build a 32 bit processor with more registers.
2) is valid
3) True but almost no software I use does much 64 bit type processing.
4) You could do this with a compiler, it the instruction is slow, yu don't save die area because you need to support it in 32 bit mode.
You missed out the biggest winner, the massive cache on this processor, 1MB I believe, that's a big step up.
You put a cache that size on a 32 bit Athlon and you will see some big improvements.
I don't think it's right to say 64 bit is inherently faster, if your application needs it then yes, but for 32 bit class apps, 32 bit mode is faster.
If someone does it with my code I'll consider them theives. They're welcome to write their OWN code if they think it's so easy, but taking MY SOFTWARE dissassembling it converting it to C and then calling it their own is theft. Now if they dissassemble to figure out some hardware interface that's one thing, but they'd better throw the code away and write their own stuff to that interface instead of using the copy. I don't care how difficult the copying process is, they are free to write their own.
Excellent point, you are right (although I don't know about any lack of precedent or what impact more recent laws would have on this). Anyone trying this better hope I'm not on the jury of course, because IMHO this has much more to do with copying than looking and learning.