At heart, he's a developer. He'd rather be coding or debugging than getting involved in legal debate. And that's a good thing for us. I'd much rather him spend an hour working on Linux than disputing some clause of some license. It's just a more productive use of his time.
None of us, even Debian developers, enjoy dealing with legal issues. We do it because not doing so is short-sighted. IMHO, Linus often fails to understand the full scope of a non-technical problem, and when challenged, he uses "I'm apolitical" as an excuse to remain ignorant.
Linus is a decent programmer and a mediocre project manager. He's not a visionary, and I think his relevance has peaked or will soon do so. For the FSF, on the other hand, it's only the beginning. Linus is probably disappointed because the FSF won't cater to him or change its goals to suit his needs (see his complaint about the FSF not giving him early access to the first draft of GPLv3), but frankly I couldn't care less if the FSF just ignored him altogether.
I wasn't comparing it to Windows. I like Windows even less.
Oh... Yeah, Linux is crap, then.
Hey, that's what I've got! So how do I enable the hardware mixing?
It's been a while since I had one of those cards (my brother has it now, and he lives in a different city). You shouldn't need to do anything. IIRC, the driver will simply let more than one process open the sound device at a time, rather than returning EBUSY.
To be fair, the registry isn't nearly as prone to outright corruption when you're running it on NTFS 5 than it was in Win9x with FAT.
Of course, like you say, it's such a monstrosity... you can't actually walk through it and notice a problem like you can with config files.
The registry wasn't a bad idea (it's basically a standardized config file format with more efficient read/write and mutual exclusion), but the way Microsoft used it (HKEY_CLASSES_ROOT, anyone?) made it a mess.
Linux when it works is perfect. Linux when it doesn't is just weird and fucked up.
I find it's the opposite. When Linux doesn't work, I might be able to fix it, or at least see why it's not working. With Windows, it's a black box. I can try to reboot and uninstall/reinstall various drivers, service packs, DLLs, etc., and if I'm lucky, I'll come up with a procedure that mysteriously works more often than others. Actual solutions are often nowhere to be found.
Now my home Ubuntu computer has decided (again!) that flash doesn't need sound.
It's probably because (proprietary) Flash doesn't support ALSA, and ALSA is how you get software mixing. It's probably trying to get exclusive access to the sound card, and failing due to something else already using the sound card.
The simplest solution to that is to buy an SB Live! (emu10k1), or some other card that has hardware mixing support.
In general, I find that I have way fewer problems if I just buy the hardware to suit the software I want to run, rather than the other way around. It's a bit of an expense when you first start using free Unix-like operating systems, but it saves you a ton of grief in the long run.
3D acceleration doesn't work for nvidia and most recent ati cards out of the box, because binary only modules are banned on Debian, and install media won't include non-free section. You can get support by including non-free section in your repository and downloading the approopriate package.
It does work almost out-of-the-box on Debian, though. (Or, I guess technically, it will work in the next release. It works in etch.) Want the ATI drivers? Run "module-assistant auto-install fglrx" (or the short form: "m-a a-i fglrx").
Of course, if you're not running on x86, or you're running a bleeding-edge kernel, or a special X server, it might not work (those are the breaks with binary-only drivers), but when it will work, Debian does a great job of streamlining the process.
I think you're right. However, if D-Link actually made the written offer for source code, and you notified them that you wanted the source code in exchange for the reasonable cost of physical distribution (thus accepting the offer), and they refused, then they would not be violating copyright law (because they would have complied with the GPL). However, they would be in breach of their contract with you. Furthermore, if they then tried to use "it wasn't an offer" as a defense against your claim, I imagine the copyright holder could hold them liable for copyright infringement.
It always amuses me how people try to wriggle their way out of the requirements of the GPL (which are quite reasonable, IMHO), and then expect to be able to distribute GPL-covered code anyway. It doesn't work, but people still try. The case of Slade and the QuakeLives project, though it didn't go to court, is still an entertaining read.
Converting the controller to accept POST only (no GET) or adding a signature / nonce to the form would fix it.
It would have to be a nonce, and probably one that's tied to a particular user, and can't be generated by third parties for that user. Otherwise, I can just copy the form to my website, modify it, and use some Javascript to auto-submit it.
Yeah, you can't expect anyone competent to "sign off" on code you've written (though I imagine that there are plenty of incompetent people who are willing to do it). What you can do is ask them to break your code, as long as you agree to terms that state that "the fact that I can't break it does not imply that someone else won't be able to".
Another important thing to note is that preventing XSS is not as simple as it seems. In fact, preventing it may be just plain impossible if we don't want to prevent people from doing things like showing videos and Flash, with the OBJECT tag. There are apparently huge security holes in allowing it, but if you don't, then you have a world without music or video. If anyone has tips on securing this, please reply to this and let us all know. I was thinking that it might be necessary to allow only certain URLs but that seems too draconian if there's any way to avoid it.
I haven't tried this, but how about registering a separate domain for that content, and using an IFRAME (or whatever works) to bring in the media? Don't put any privileged scripts on that domain.
Before you laugh, even computing greats have made similar mistakes. RMS, of Emacs, GNU and GPL fame, used to rail against people using passwords on their accounts. He had no password on his account on the MIT AI ITS machine, which was accessible through the ARPANet. Theoretically, a lot of bad things could have happened to him, but they didn't because yesterday's ARPANet users had respect for him and people like him.
In other words, it wasn't a mistake; He just had a better understanding of the threat than you did, apparently.
Look closer. This particular vulnerability doesn't use any special JavaScript or anything else; It's a simple redirect. The only way to fix it would be for Google to change something (such as by adding a referer check) in its preferences module, or for you to special-case this particular attack in your browser.
What we have is total morons passing themselves off as web developers, just like we have thousands of "web designers" who don't know the meaning of the word "design".
"Web design" is for aesthetics and graphics people, like "interior design". Of course you run into problems when you have a web designer doing development work!
As for "No web developer has written XSS vulnerable code since 2002", I refer you to The Daily WTF.
Slashdot Mirror
None of us, even Debian developers, enjoy dealing with legal issues. We do it because not doing so is short-sighted. IMHO, Linus often fails to understand the full scope of a non-technical problem, and when challenged, he uses "I'm apolitical" as an excuse to remain ignorant.
Linus is a decent programmer and a mediocre project manager. He's not a visionary, and I think his relevance has peaked or will soon do so. For the FSF, on the other hand, it's only the beginning. Linus is probably disappointed because the FSF won't cater to him or change its goals to suit his needs (see his complaint about the FSF not giving him early access to the first draft of GPLv3), but frankly I couldn't care less if the FSF just ignored him altogether.
I'll be using it, and judging by the amount of "GPL 2 or later" software out there, so will a lot of other people.
News flash: The FSF is not democratic. It never was, and I'm thankful for it.
My people! From RMS, I bring you these eighteen... (crash!) um... twelve sections of the GPL version two!
Reminds me of portapotty.
Hmm. How about "portapoddy"? (-:
Personally, I think this is good. The more media attention the broken patent system gets, the more likely we are to get some changes.
Oh... Yeah, Linux is crap, then.
It's been a while since I had one of those cards (my brother has it now, and he lives in a different city). You shouldn't need to do anything. IIRC, the driver will simply let more than one process open the sound device at a time, rather than returning EBUSY.
We're talking about hydroelectric power, right?
Controversial? I thought everyone agreed that SCO didn't have a case.
To be fair, the registry isn't nearly as prone to outright corruption when you're running it on NTFS 5 than it was in Win9x with FAT.
Of course, like you say, it's such a monstrosity... you can't actually walk through it and notice a problem like you can with config files.
The registry wasn't a bad idea (it's basically a standardized config file format with more efficient read/write and mutual exclusion), but the way Microsoft used it (HKEY_CLASSES_ROOT, anyone?) made it a mess.
I find it's the opposite. When Linux doesn't work, I might be able to fix it, or at least see why it's not working. With Windows, it's a black box. I can try to reboot and uninstall/reinstall various drivers, service packs, DLLs, etc., and if I'm lucky, I'll come up with a procedure that mysteriously works more often than others. Actual solutions are often nowhere to be found.
It's probably because (proprietary) Flash doesn't support ALSA, and ALSA is how you get software mixing. It's probably trying to get exclusive access to the sound card, and failing due to something else already using the sound card.
The simplest solution to that is to buy an SB Live! (emu10k1), or some other card that has hardware mixing support.
In general, I find that I have way fewer problems if I just buy the hardware to suit the software I want to run, rather than the other way around. It's a bit of an expense when you first start using free Unix-like operating systems, but it saves you a ton of grief in the long run.
It does work almost out-of-the-box on Debian, though. (Or, I guess technically, it will work in the next release. It works in etch.) Want the ATI drivers? Run "module-assistant auto-install fglrx" (or the short form: "m-a a-i fglrx").
Of course, if you're not running on x86, or you're running a bleeding-edge kernel, or a special X server, it might not work (those are the breaks with binary-only drivers), but when it will work, Debian does a great job of streamlining the process.
I think you're right. However, if D-Link actually made the written offer for source code, and you notified them that you wanted the source code in exchange for the reasonable cost of physical distribution (thus accepting the offer), and they refused, then they would not be violating copyright law (because they would have complied with the GPL). However, they would be in breach of their contract with you. Furthermore, if they then tried to use "it wasn't an offer" as a defense against your claim, I imagine the copyright holder could hold them liable for copyright infringement.
It always amuses me how people try to wriggle their way out of the requirements of the GPL (which are quite reasonable, IMHO), and then expect to be able to distribute GPL-covered code anyway. It doesn't work, but people still try. The case of Slade and the QuakeLives project, though it didn't go to court, is still an entertaining read.
Try any case of contract law.
Why wouldn't a referer check be enough?
It would have to be a nonce, and probably one that's tied to a particular user, and can't be generated by third parties for that user. Otherwise, I can just copy the form to my website, modify it, and use some Javascript to auto-submit it.
All batteries are toxic, and you generate a lot less waste by reusing rechargeable batteries than by constantly disposing of non-rechargeables.
Anyway, this was a joke about exploding batteries, which you apparently missed.
Oops. Never mind. I thought you replied to a different post.
Eh? Do the same thing then, but instead of hosting the video, just stick the OBJECT tags on the unprivileged domain.
Yeah, you can't expect anyone competent to "sign off" on code you've written (though I imagine that there are plenty of incompetent people who are willing to do it). What you can do is ask them to break your code, as long as you agree to terms that state that "the fact that I can't break it does not imply that someone else won't be able to".
I haven't tried this, but how about registering a separate domain for that content, and using an IFRAME (or whatever works) to bring in the media? Don't put any privileged scripts on that domain.
In other words, it wasn't a mistake; He just had a better understanding of the threat than you did, apparently.
Look closer. This particular vulnerability doesn't use any special JavaScript or anything else; It's a simple redirect. The only way to fix it would be for Google to change something (such as by adding a referer check) in its preferences module, or for you to special-case this particular attack in your browser.
Hmm. What a dilemma. I care about the environment, but should I risk using rechargeable batteries in this thing?
"Web design" is for aesthetics and graphics people, like "interior design". Of course you run into problems when you have a web designer doing development work!
As for "No web developer has written XSS vulnerable code since 2002", I refer you to The Daily WTF.
I do not think this is the best place to ask your question HEIL HITLER!