I hate to pick nits, but Wine is more than an implementation of the Win32 API. It also has a loader for PE executables and DLLs, and a server component which handles system state. (OK, arguably you could say that the system state is part of the API contract...)
Winelib used to be a straight Win32 API implementation, but I believe the Wine team changed that, so a Winelib application behaves more like a Win32 binary now.
Sometimes letting its developers decide that something is cool and should be made into a product is the worst decision a company can make. Sometimes it works out, and creates a new category of product that nobody imagined before. I can't really begin to guess which one this is going to be, except maybe noting that I don't want one. I also thought Netscape Navigator 1.0 was a stupid product, and that Netscape is doomed if it thinks it can make money on it.
Your assertion that the watermark doesn't introduce noise because of the error correction codes is obviously false - a digital watermark is designed to survive MP3 encoding, for example. The error correction code is lost once the data is read off of the CD. The error correction code is there to hellp the decoder reproduce the original data - noise and all.
Changing every byte randomly, as you suggest, will merely introduce a low level noise into the recording. You seem to be confusing watermarking with some steganography schemes, which change the least significant bit of a digital sample (audio or video), which indeed can be defeated in the manner you describe. Since lossy audio compression always uses vector quantization (that's the "lossy" part), the least significant bits are always lost anyway.
The only thing you're right about is that watermarking doesn't work. But it doesn't work for reasons you don't seem to understand.
It's the American national bowling championship. Bowling, as you probably know, is the American national sport (it's even a required course in most liberal arts graduate programs, at least in the midwest), so the superbowl is a very big deal here.
Sometimes it would be possible (yeah, I know you're trying to be funny, but still...) yet in my case I'm looking at a dead machine as soon as the bug manifests itself, and it may take several days for that to happen, so gdb is out of the question.
A far better approach is careful instrumentation of the code with debug output, and logging everything to a serial port, which is damn hard to do without source.
I'm afraid you're confusing two issues here: ATI also has closed source drivers. I don't have a problem with that, though, because they also document their hardware, therefore allowing the XFree86 project to write their own open source drivers. That's really all I would like to see. As it stands, nVIDIA claims that merely publishing documentation detailed enough to allow writing drivers for their hardware would be detrimental to their performance lead and market position.
Maybe now that ATI leapfrogged them they'll change their minds... Or not.
I'm really not complaining about nVIDIA's quality of engineering, their support of Linux, or even about the company's stand on documenting their hardware. I'm just not buying their stuff, because they don't give me what I need. Some people base their purchasing decisions on benchmarks and Quake frame rates. Others care more about stability and hardware documentation. As long as the former outnumber the latter by the kind of margin we're seeing now (basically, nobody cares about whether they get source for their drivers), nVIDIA really won't have a reason to reconsider their position.
As Linux starts making its way to people's desktops, though, I expect that to change. There are clear practical advantages to having driver source, and some of nVIDIA's customers (Hollywood effects houses, maybe?) may start pressuring them to do the right thing.
And, no, I don't have an AMD system of a VIA chipset, and I went as far as turning off AGP altogether (the workaround mentioned on nVIDIA's site), with no results. This is exactly the kind of problem where source availability would have been the most helpful: It's an intermittent, hardware dependant, hard to reproduce problem. If they agreed to work on this with me, I'd expect it to take months for them just to reproduce this. With this kind of bug, the time to reproduce the problem is the largest component of the time it takes to deliver a fix. If I could only instrument the driver code, have it log interesting events to a serial port, and let it run for a few weeks (it can take that long to trigger the problem), it would have been fixed by now.
Interesting. I am running a TNT. What were the symptoms in your case? I'm seeing complete lockups - The machine won't even respond to pings. Or to the power button, for that matter.
Well, I'm glad they work for you, but I'm seeing occasional system lockups that weren't there in the year or so I was running the XFree86 drivers. The only suggestion on nVidia's site was to turn off AGP support, which I did, to no avail.
I'm a competent C programmer, and I've done driver work before. I can find my way around source code, and I've tracked down problems in open source code I was using before. Not being able to debug this is driving me nuts.
So, this is what's wrong with nVidia's drivers. When they break, you can't fix them.
I haven't used them, but I'm considering buying an ATI card, and I'd rather use open source drivers, having had a very bad experience with nVidia's binary drivers.
Re:Which is exactly why it has a girls name
on
ALICE vs. ALICE
·
· Score: 2
...and be embarrassingly specific about them, too.
Fresco... A friend of mine used to rave about it. I haven't talked to the guy in almost 8 years, which should give you an idea how long this thing has been kicking around. I've been following it for years (basically checking on the web page every few months), and progress is
Yes.
I just tried it. It's set to 100%. What are you talking about?
Yes. You get the /. Geek of The Week award.
I hate to pick nits, but Wine is more than an implementation of the Win32 API. It also has a loader for PE executables and DLLs, and a server component which handles system state. (OK, arguably you could say that the system state is part of the API contract...)
Winelib used to be a straight Win32 API implementation, but I believe the Wine team changed that, so a Winelib application behaves more like a Win32 binary now.
Fail.
Where was the market demand for the Apple II?
Sometimes letting its developers decide that something is cool and should be made into a product is the worst decision a company can make. Sometimes it works out, and creates a new category of product that nobody imagined before. I can't really begin to guess which one this is going to be, except maybe noting that I don't want one. I also thought Netscape Navigator 1.0 was a stupid product, and that Netscape is doomed if it thinks it can make money on it.
I thought Michael Jordan wrote Conan the Barbarian.
See here for an interesting discussion of the SDMI challenge, for example.
Nice try. Almost completely wrong.
Your assertion that the watermark doesn't introduce noise because of the error correction codes is obviously false - a digital watermark is designed to survive MP3 encoding, for example. The error correction code is lost once the data is read off of the CD. The error correction code is there to hellp the decoder reproduce the original data - noise and all.
Changing every byte randomly, as you suggest, will merely introduce a low level noise into the recording. You seem to be confusing watermarking with some steganography schemes, which change the least significant bit of a digital sample (audio or video), which indeed can be defeated in the manner you describe. Since lossy audio compression always uses vector quantization (that's the "lossy" part), the least significant bits are always lost anyway.
The only thing you're right about is that watermarking doesn't work. But it doesn't work for reasons you don't seem to understand.
Oh, I see. And how does that relate to pro wrestling, again?
In golf, only the American League uses explosive pins. The National Golf Association doesn't use them.
How do they slam dunk, then? I'm confused now...
You're thinking of golf.
You forgot to mention the explosive pins.
And BTW: What is superbowl?
It's the American national bowling championship. Bowling, as you probably know, is the American national sport (it's even a required course in most liberal arts graduate programs, at least in the midwest), so the superbowl is a very big deal here.
Sometimes it would be possible (yeah, I know you're trying to be funny, but still...) yet in my case I'm looking at a dead machine as soon as the bug manifests itself, and it may take several days for that to happen, so gdb is out of the question.
A far better approach is careful instrumentation of the code with debug output, and logging everything to a serial port, which is damn hard to do without source.
I'm afraid you're confusing two issues here: ATI also has closed source drivers. I don't have a problem with that, though, because they also document their hardware, therefore allowing the XFree86 project to write their own open source drivers. That's really all I would like to see. As it stands, nVIDIA claims that merely publishing documentation detailed enough to allow writing drivers for their hardware would be detrimental to their performance lead and market position.
Maybe now that ATI leapfrogged them they'll change their minds... Or not.
I'm really not complaining about nVIDIA's quality of engineering, their support of Linux, or even about the company's stand on documenting their hardware. I'm just not buying their stuff, because they don't give me what I need. Some people base their purchasing decisions on benchmarks and Quake frame rates. Others care more about stability and hardware documentation. As long as the former outnumber the latter by the kind of margin we're seeing now (basically, nobody cares about whether they get source for their drivers), nVIDIA really won't have a reason to reconsider their position.
As Linux starts making its way to people's desktops, though, I expect that to change. There are clear practical advantages to having driver source, and some of nVIDIA's customers (Hollywood effects houses, maybe?) may start pressuring them to do the right thing.
And, no, I don't have an AMD system of a VIA chipset, and I went as far as turning off AGP altogether (the workaround mentioned on nVIDIA's site), with no results. This is exactly the kind of problem where source availability would have been the most helpful: It's an intermittent, hardware dependant, hard to reproduce problem. If they agreed to work on this with me, I'd expect it to take months for them just to reproduce this. With this kind of bug, the time to reproduce the problem is the largest component of the time it takes to deliver a fix. If I could only instrument the driver code, have it log interesting events to a serial port, and let it run for a few weeks (it can take that long to trigger the problem), it would have been fixed by now.
Nope - I have a Pentium III. I saw the athlon problem mentioned somewhere, but that's not it.
The card is a RIVA TNT2, and I have no idea which motherboard this is.
Interesting. I am running a TNT. What were the symptoms in your case? I'm seeing complete lockups - The machine won't even respond to pings. Or to the power button, for that matter.
Well, I'm glad they work for you, but I'm seeing occasional system lockups that weren't there in the year or so I was running the XFree86 drivers. The only suggestion on nVidia's site was to turn off AGP support, which I did, to no avail.
I'm a competent C programmer, and I've done driver work before. I can find my way around source code, and I've tracked down problems in open source code I was using before. Not being able to debug this is driving me nuts.
So, this is what's wrong with nVidia's drivers. When they break, you can't fix them.
Why? What's wrong with the Gatos drivers?
I haven't used them, but I'm considering buying an ATI card, and I'd rather use open source drivers, having had a very bad experience with nVidia's binary drivers.
...and be embarrassingly specific about them, too.
there is no reason that it shouldn't look like enlightenment once somebody with artistic talent shows up
What, surely you're not implying that someone with artistic talent ever got anywhere near enlightenment, are you?
Ok, maybe someone did, but at least in my opinion, enlightenment's themes are just plain ugly.
Fresco... A friend of mine used to rave about it. I haven't talked to the guy in almost 8 years, which should give you an idea how long this thing has been kicking around. I've been following it for years (basically checking on the web page every few months), and progress is
.
s l o w . .
Don't hold your breath.
These wounds don't heal easily. I'm saving you years of therapy, buddy!
I'm sorry to hear that. This should make up for the disappointment...