You can't restrain information that doesn't want to be restrained. Has never worked, doesn't work, will never work. (Yes, you can delay it a little. But nothing more.)
What alternative does Symantec have? If they start rejecting exploits, someone else will start a forum where all exploits are allowed. I prefer to have all this information in a place where I can be sure that the relevant people read it.
Of course, those who posting an exploit without giving the vendor (whether that is MS or an free software project) sufficient time to prepare a patch, that would be irresponsible. But when someone else is committed to doing so, there is nothing you can do.
I think in a way we are forced back to that old game in our childhood. It's not about whether I have a good enough water pistol, it needs to better than those of my friends!
Software developers have to focus, and once their software is fast enough for 80% of the people using it, they won't spend any more time on improving performance. (That's not criticism, I think that is just the way it is. And those who think it's just Microsoft's fault here, please show me the 486-100MHz that is happily running KDE 3.0 or Mozilla.)
Hence, as a user, you need to have a CPU in the top 80% to have your software run fast enough. If you want have it really smooth and fast, you need to be even better, probably twice as fast.
Now how much do you have to spend for a CPU so that you are twice as fast as the bottom 20% in use for the next 3 years?
I think for most software it's a self-sustaining race. But hey, I don't mind, I am taking part in the development of a Go (the japanese board game) program, and we do need the performance!
While I agree with almost all of your post -- BK metadata like changeset comments just isn't s.th. that should be kept in a proprietary format --, with this one you are actually wrong:
Also, patch submissions that do not come in via BK are treated worse than patches that come in via BK - Linus and friends may say they aren't, or they aren't intentionally, but they are - again matters of convenience and infrastructure working against Non-BK users.
Linus has even stated that he prefers e-mail patches, because they are as easy to integrate (just piped into BK) and are usually better commented...
Either you ignore the patents or you stop coding. There is no other solution. You can't be a patent lawyer and a coder at the same time.
Jean-Loup Gailly, the author of gzip, tried to be both. He writes:
I have probably spent more time studying data compression patents than actually implementing data compression algorithms. I maintain a list of several hundred patents on lossless data compression algorithms, and I made sure that gzip isn't covered by any of them. In particular, the --fast option of gzip is not as fast it could, precisely to avoid a patented technique.
He also notes that the US patent office not only accepts "obvious" patents, but also obviously wrong patents -- see his analysis of two complete non-sense patents on data compression.
Slashdot Mirror
You can't restrain information that doesn't want to be restrained. Has never worked, doesn't work, will never work. (Yes, you can delay it a little. But nothing more.)
What alternative does Symantec have? If they start rejecting exploits, someone else will start a forum where all exploits are allowed. I prefer to have all this information in a place where I can be sure that the relevant people read it.
Of course, those who posting an exploit without giving the vendor (whether that is MS or an free software project) sufficient time to prepare a patch, that would be irresponsible. But when someone else is committed to doing so, there is nothing you can do.
Software developers have to focus, and once their software is fast enough for 80% of the people using it, they won't spend any more time on improving performance. (That's not criticism, I think that is just the way it is. And those who think it's just Microsoft's fault here, please show me the 486-100MHz that is happily running KDE 3.0 or Mozilla.)
Hence, as a user, you need to have a CPU in the top 80% to have your software run fast enough. If you want have it really smooth and fast, you need to be even better, probably twice as fast.
Now how much do you have to spend for a CPU so that you are twice as fast as the bottom 20% in use for the next 3 years? I think for most software it's a self-sustaining race. But hey, I don't mind, I am taking part in the development of a Go (the japanese board game) program, and we do need the performance!
- Also, patch submissions that do not come in via BK are treated worse than patches that come in via BK - Linus and friends may say they aren't, or they aren't intentionally, but they are - again matters of convenience and infrastructure working against Non-BK users.
Linus has even stated that he prefers e-mail patches, because they are as easy to integrate (just piped into BK) and are usually better commented...Jean-Loup Gailly, the author of gzip, tried to be both. He writes:
I have probably spent more time studying data compression patents than actually implementing data compression algorithms. I maintain a list of several hundred patents on lossless data compression algorithms, and I made sure that gzip isn't covered by any of them. In particular, the --fast option of gzip is not as fast it could, precisely to avoid a patented technique.
(from the gzip faq)
He also notes that the US patent office not only accepts "obvious" patents, but also obviously wrong patents -- see his analysis of two complete non-sense patents on data compression.