Having said that, shouldering the sole blame for a bug seems pretty minor. MS releases a fix and that's that.
That's the point. It's "some blame" because there isn't much blame, not because it's only a small point of the blame. Wheras if it were a deliberate back door, MS would deserve a lot of blame.
If that is the case, it sounds to me like there are some pretty unsustainable business models out there.
Not at all. Some companies are research companies, they spend the money on R&D and make it back from having new drugs. Once they've become commoditized, that particular drug becomes the provenance of other manufacturers who don't bother with the R&D. The research company needs to be discovering new stuff, but that's their job, it's what the money goes on.
I'm looking, just as I looked when he first said it. But Gibson's evidence was completely false, and without it the bug is no different from hundreds of bugs caused by ordinary incompetence all the time.
In terms of direct hardware cost, no, but once you factor in power, cooling, networking, physical space, admin etc., yes. If they weren't, they wouldn't sell.
But Python isn't used for image processing! In the examples you give, Python is being used as a layer above C that does image processing. Python is a great language to wrap around C code for things like this, but to claim that Python is doing the processing is to mislead.
OK, you're right in these cases, but that just reflects how easy it is to wrap existing libraries. There's no reason you couldn't do it in pure python - there's just no point.
This is in stark contrast to Java. The standard Java API for image processing is JAI (Java Advanced Imaging). Although it can use C libraries if they are available it can (if these libraries or not present) also use a Java-only implementation which gives good performance.
So they've written two copies of it because Java people refuse to reuse existing libraries?
That is not serious image processing done in python. That is python using C. I used the phrase raw python. Any language can 'spoof' speed by calling out to a faster one.
I'm pretty sure a lot of the processing was direct python. And some languages make it easier to combine than others.
Re:Back door or poor design? You can't really tell
on
WMF Flaw not a Backdoor
·
· Score: 4, Insightful
When a program sends a document to a printer, the program is already running, so if you allow it to execute arbitrary code by doing so, no biggie, it's worth it if you get some useful functionality out of it. Especially in the window 3.1 days.
If you want to render something postscript-like onto a screen, why not just reuse the printer code?
I can see how it happened. The original introduction of setabortproc violated separation of code and data, but it was needed for performance - and on the kind of hardware win3.1 ran on, that was vital. I suppose it shows that you should never compromise on design for the sake of performace - but in the real world, you have to. May I also point out that if the x86 had a working way to mark memory non-execute then this wouldn't be a problem.
MS deserves some blame? Who else should we blame? The wine group? Mark? Steve Gibson? Slashdotters?
You've never had a security flaw in your code? It's an *accident*, the same as when the postman falls over and breaks your parcel. Oh wait, I forget, in America there's always someone to sue.
I can't believe that these corporations care one way or the other about people viewing porn.
That's precisely it, they don't care. It's less trouble for them to just hand the info over. Frankly I'm surprised at google resisting, but then look at all the adulation they're getting for it.
If you have the time to hand-optimize your code, it blows anything out of the water. This means it's useful for simple number crunching, but not much else - more processors are generally cheaper than more coders. It was expected that compilers would improve by the time Itanium was adopted, but that hasn't really happened. (I read here that the hurd coders were able to make their Itanium message-passing routine TEN TIMES faster by doing it in hand-coded assembly compared to what a compiler churned out)
Oh yeah, look what a big success the itanium has been. And compare with the backwards-compatible amd64. Like it or not, dumping x86 backwards compatibility is not a good move.
I don't get this geeky thing where you'll spend godawful amounts of money on hardware (and create a huge electricity bill and cooling problem to boot) but take a hissy fit about paying for a DVD or a CD you want to enjoy.
Hardware is sold for about what it cost to make. I can get a blank CD for 20p, yet I don't see music CDs being sold for anything like that.
It reminds me of software pirates who spend so much time and energy collecting software (or porn fanatics, too, I guess) but never actually enjoy what they've collected.
Don't you have a collection you never use? You can enjoy collecting things for the sake of collecting them.
There's netcat, which acts very much like cat but will either listen on a given port or output to a given host/port. Not sure whether that's what you're after.
Yes, but as we've seen, DRM doesn't have to be particularly effective to get legal protection. That's why we need a clause in the GPL to stop people being DMCA'd.
No, you're just required to claim that whatever circumvention you were bypassing is not a TPM under the DMCA. Which you would presumably be doing anyway, since otherwise you'd be violating the DMCA. The point is that you waive your ability to sue people who break the protection in a GPL program under the DMCA.
Slashdot Mirror
You misunderstand the code of the typical slashdotter:
evaluate(){
if(apple)
return good;
else if(microsoft)
return bad;
else if(google)
return good;
else if(DRM)
return bad;
else if(open source)
return good;
else if(monopoly)
return bad;
...
Lol, just read the comments here. 500 zealots falling over themselves to defend it.
That's the point. It's "some blame" because there isn't much blame, not because it's only a small point of the blame. Wheras if it were a deliberate back door, MS would deserve a lot of blame.
It's doing the same run-time cached-interpretation thing as python or anything else.
Not at all. Some companies are research companies, they spend the money on R&D and make it back from having new drugs. Once they've become commoditized, that particular drug becomes the provenance of other manufacturers who don't bother with the R&D. The research company needs to be discovering new stuff, but that's their job, it's what the money goes on.
Why does the performance of python need to be any worse than that of Java?
The Java implementation can be shipped as byte code and will then run as good performance native code on any platform.
A python script will have bytecode generated the first time and then run as high performance native code on any platform.
I'm looking, just as I looked when he first said it. But Gibson's evidence was completely false, and without it the bug is no different from hundreds of bugs caused by ordinary incompetence all the time.
That was the point...
In terms of direct hardware cost, no, but once you factor in power, cooling, networking, physical space, admin etc., yes. If they weren't, they wouldn't sell.
OK, you're right in these cases, but that just reflects how easy it is to wrap existing libraries. There's no reason you couldn't do it in pure python - there's just no point.
This is in stark contrast to Java. The standard Java API for image processing is JAI (Java Advanced Imaging). Although it can use C libraries if they are available it can (if these libraries or not present) also use a Java-only implementation which gives good performance.
So they've written two copies of it because Java people refuse to reuse existing libraries?
I'm pretty sure a lot of the processing was direct python. And some languages make it easier to combine than others.
If you want to render something postscript-like onto a screen, why not just reuse the printer code?
I can see how it happened. The original introduction of setabortproc violated separation of code and data, but it was needed for performance - and on the kind of hardware win3.1 ran on, that was vital. I suppose it shows that you should never compromise on design for the sake of performace - but in the real world, you have to. May I also point out that if the x86 had a working way to mark memory non-execute then this wouldn't be a problem.
You've never had a security flaw in your code? It's an *accident*, the same as when the postman falls over and breaks your parcel. Oh wait, I forget, in America there's always someone to sue.
I could tell in less than 50 milliseconds as well...
Tell its shit from what?
That's precisely it, they don't care. It's less trouble for them to just hand the info over. Frankly I'm surprised at google resisting, but then look at all the adulation they're getting for it.
If you have the time to hand-optimize your code, it blows anything out of the water. This means it's useful for simple number crunching, but not much else - more processors are generally cheaper than more coders. It was expected that compilers would improve by the time Itanium was adopted, but that hasn't really happened. (I read here that the hurd coders were able to make their Itanium message-passing routine TEN TIMES faster by doing it in hand-coded assembly compared to what a compiler churned out)
Oh yeah, look what a big success the itanium has been. And compare with the backwards-compatible amd64. Like it or not, dumping x86 backwards compatibility is not a good move.
Hardware is sold for about what it cost to make. I can get a blank CD for 20p, yet I don't see music CDs being sold for anything like that.
It reminds me of software pirates who spend so much time and energy collecting software (or porn fanatics, too, I guess) but never actually enjoy what they've collected.
Don't you have a collection you never use? You can enjoy collecting things for the sake of collecting them.
Noise will be irritating. Heat will destroy several hundred dollars' worth of hardware. I think heat takes a higher priority.
There's netcat, which acts very much like cat but will either listen on a given port or output to a given host/port. Not sure whether that's what you're after.
It was still necessary to recognise the piece, a non-trivial task to do automatically.
Compare this with the fact that NASA used Java for rendering Mars images, and released it as the Maestro application. Your point?
My point is that python is just as suitable for image processing as Java, and usually more productive.
The GPL just says you cannot use the DMCA against someone who breaks your DRM.
Yes, but as we've seen, DRM doesn't have to be particularly effective to get legal protection. That's why we need a clause in the GPL to stop people being DMCA'd.
No, you're just required to claim that whatever circumvention you were bypassing is not a TPM under the DMCA. Which you would presumably be doing anyway, since otherwise you'd be violating the DMCA. The point is that you waive your ability to sue people who break the protection in a GPL program under the DMCA.