Consider this to be an official offer of bounty. Hack goatse.cx, post fluffy bunnies and a public key. I, for one, will contribute to whoever pulls it off. GO FOR IT!
-- Michael Chermside
PS: This offer is not actually intended to violate any laws.
Downloading copyrighted material without permission of the owner is a CRIME. [... ]
Yes. So is driving faster than 65. What's your point?
And that's EXACTLY why we must implement STRICT ENFORCEMENT of speed limit laws! Modern technology should be used to prevent this ILLEGAL activity! All car owners should be required (at their expense) to purchase a special ENCRYPTED AUTOMOBILE ID TRANSPONDER, which would generate little electronic signals capable of being detected. That way, people who speed can receive the fines that they deserve. In fact, if we implement this system immediately, here in the US we'll even be able to afford W's TAX CUT, since the revenue from fines will quickly reach the 10s of billions.
Well, here's MY attempt to defend the whitespace-based syntax.
Would you allow a junior programmer joining your team to write code like this?
int someFunc(int x) {
if( x < MIN_VALUE ) {
return x;}
else { int i, v, new_x=0; for( i=0; i<x; i++ ) {
&n bsp;v = process(i);
new_x += v;
}
return new_x;}
}
I certainly wouldn't. In c (or c++, or java, or whatever language that snippet was written in), whitespace is significant, but it is significant ONLY to the human reading the code, not to the compiler.
If I could, I'd ask the compiler (or the source-code-control checkin program) to require that the indentation match the braces. That would prevent stupid stuff like the above, and also prevent the more insidious errors like this:
int someFunc(int x) {
if( x < MIN_VALUE ) {
re turn x;
} else {
in t i, v, new_x=0;
fo r( i=0; i<x; i++ )
&n bsp;v = process(i);
&n bsp;new_x += v;
re turn new_x;
}
}
where my failure to use {} around the for() clause has created an error (ie, new_x += vshould be inside the loop, and you can TELL that from the indentation).
So in python, you get exactly this feature. The language verifies that the ACTUAL block structure of the compiled code equals the INTENDED block structure as indicated by the programmer:
def someFunc(int x):
if x < MIN_VALUE:
re turn x
else:
ne w_x=0
i= 0
wh ile i < x:
&n bsp;v = process(i)
&n bsp;new_x += v
re turn new_x
In my opinion, the python code will hold up BETTER than over long life spans than c-style code, at least if you consider only the effects of whitespace-based block structure. I say this because the use of indentation to indicate block structure is older and more widespread than the use of braces for that purpose -- compare Algol, Lisp, APL, and nearly everything else except early (column-sensitive) Fortran and assembler.
Of course you ALSO said that you liked having the braces, because it makes it easier for you to read. Fortunately, braces ARE allowed in python! The following example demonstrates their use.;-)
def someFunc(int x): #{
if x < MIN_VALUE: #{
re turn x
#}
else: #{
ne w_x=0
i= 0
wh ile i < x: #{
&n bsp;v = process(i)
&n bsp;new_x += v
#}
re turn new_x
#}
#}
Your point is well taken, as a general point. But in regard to this specific case (O'Reilly) I suspect you're off the mark. Unless one of the employees in this software division posts to say otherwise (hey, feel free to speak up... you wouldn't want to miss the opportunity to be instantly modded +5, Relevent;-) ), I will continue to assume that the process was not simply a top manager announcing that the division was to be eliminated, but that it involved much more in the way of give-and-take, discussion, and consideration for the employees.
After all, as the article said:
Unfortunately, there were no new appropriate positions for nine people from the software group, so they will be laid off. That''s the hardest part of the decision by far, as those folks have done great work. We're supporting them in their effort to find new employment, we thank them, and we wish them well.
A few things that would be REALLY valuable in the past (if you could convince anyone to go along with you):
The printing press. Simple enough I could probably invent it with the help of a couple good furniture makers, but VERY powerful.
Basic health knowledge. The existance of germs, and what to do about them (soap!).
A here are few gems of knowledge that wouldn't give any immediate benefit, but might set science ahead by hundreds or thousands of years: Chemical elements exist and their mass is stable. All species evolved from others; we have a set of "instructions", two copies per person.
They are happening? Where? The whole kidney theft thing is an urban legend. Nor will doctors make any less attempt to resitate due to possible organ donation. And you can't sell your organs, even if you want to. See an organ donor site for more information.
For a more serious look at what we might be doing WRONG in the area of genetic engineering, see Scientific American's review of Body Bazar. Among other things, it addresses your question: "Who are YOU to tell me what I can and can't do with my own genes?" -- apparently in US law, you DON'T own your own genes.
I guess I don't really believe that the kind of abuses that cloning could encourage ARE in fact occuring on any widespread basis. And there are much more important things to worry about.
I hear lots of people getting all upset over the idea of human cloning. And nearly all of them are completely misdirected.
We've all seen B-budget sci-fi movies in which the mad scientist uses his cloning machine to make a duplicate of Fred of Sally and the evil clone then replaces the "real" human. But REAL cloning doesn't make a "duplicate" of a human, just another person with the same genes. That's all.
There are terrible things that we could do with cloning... growing clones and treating them as non-humans for instance (used for organ transplants, etc). But those are violations of human rights, and could happen just as easily without clones (suppose we started using 3rd-worlders for spare parts for Americans... it'd be just as bad). Cloning itself is not the source of the problem.
And as proof, I submit that human clones already exist among us! Really. On rare occasions, a fertilized egg will be split in half, and both halfs will implant in the uterus and grow. The result is two humans who are perfect clones of each other -- they're called "identical twins".
Identical twins don't think share the same mind or memories. They don't try to secretly replace each other. They don't provide a sort of immortality. And they certainly don't lack a soul. Artificial twins would be EVEN MORE DIFFERENT, because they wouldn't be the exact same age, and (often) raised in the exact same family.
So please, avoid the fearmongering. Cloning itself -- even human cloning -- is not a terribly force in the world. It could still be misused, but if anything, spreading un-true fears and rumors INCREASES the chance that it will be abused.
Also you might want to check out the Electronic Frontier Foundation an organization similar in some ways to the ACLU but focused more on issues related to technology and freedom.
If either the ACLU or the EFF wants to take up your case, let me know... I'll give an increased donation to either organization for assisting in a case like this one.
IF (and I emphasize *if*) they really find it necessary to do this, then there is a right and a wrong way to go about it.
The wrong way to go about it is to create an exclusive list of "Members Only" participants and allow only those members to see all security weaknesses until a fix has been completed by the vendor and is ready for immediate distribution. As we all know, there is no way that a cracker would ever be able to gain access to these restricted members-only alerts. And there is every reason to believe that even non-members would continue to freely and willingly contribute alerts to a list to which they had no access, so we need have no fear that security weaknesses would go unmentioned.
The right way to go about this is to continue to use a public list for nearly all bugs found. But a few are particularly bad problems -- either flaws which are terribly easy to exploit, or which are extremely widely distributed and therefore manifest a severe vulnerability. Distributing these only to a restricted list of highly-trusted individuals makes a lot of sense, as long as we adhere strictly to a simple list of restrictions. The primary one is that this shorter list is intended to give the white-hats a head start, not to keep security flaws secret. That means that alerts on the restricted list are AUTOMATICALLY released to the general public after a short time period. And that holds regardless of whether or not the problem has been fixed... in fact, it will serve as a strong incentive to accelerate the production of a solution. The second restriction I propose is that no vendors qualify for "special treatment" -- the same rules apply to them all.
logicnazi has a really good point here... someone please moderate her up! Specifically, a cost-benefit analysis is the RIGHT way to convince businesses -- save the religious arguments for convincing/. readers. And the argument she makes is sound.
I fully agree. Why not? *THIS* seems to me to be exactly why slander was considered a crime in the first place! Now, I believe that there should be a simple dispute resolution procedure... if you don't try to resolve things through the procedure, then you can't sue for slander. But if you TRY the procedure, and get nothing but a run-around, then you ought to be allowed to sue.
The Greyhound station in Chicago is about 4 blocks from the Amtrack station. Yeah... I know... it was a retorical question, but since I work 2-3 blocks from each, I thought I'd mention it.
> Read the article. This was not the kind of buffer
> overflow that could be fixed with a library.
> Indeed, a language that did bounds checking on
> arrays (and completely didn't support pointers)
> could have avoided this problem, but I'm not sure
> that it would.
I read the article. I agree that it's not just stcpy onto a stack buffer... on the surface. But this IS just the kind of trivial error that basic programming techniques should avoid -- simply never trust input without validating it first. I agree that a "safe" language such as Java would protect from this, but "safe" libraries would help also!
Well, if they attempt to patent the idea of ranking a page by counting the number of Web pages that link to that page, then I will scream and shout a great deal. That qualifies as "obvious" [to experts in the field] to my mind.
But I'd be surprised if that's what the patent covers, since that's NOT what Google uses. In fact, they have a very complicated formula, which they are continually tuning. It weighs those links according to how important/authoritative each of THEM is... and the means for building this rankind is by no means trivial.
To recap: If the patent attempts to cover the obvious, I'll flame away with the best of them. If it seems to be a legitimate "invention"... something which was neither simple nor obvious... then I'll hold off. Abuse (later on) of the patent might re-qualify them for flamage, but in my mind there's nothing wrong with patents themselves.
Starting it as a Wiki seems like a good idea (and easy to get off the ground)... so long as we leave room for changing the content, presentation, and even the medium later by EXPLICITLY stating that contributors are placing their contribution under some kind of free (libre) liscense. (Public domain would be pretty good as far as I'm concerned!)
I am not a mathematician (IANAM?), but I would really welcome the existence of a site like this, and I would work to help make it happen. As a matter of fact, it just so happens that last week I started putting some mathematically inclined musings on WardsWiki (but I don't think that's the place for THIS project). So if someone else is planning to work on replacing Mathworld, please contact me, and I'll help out! mike.chermside@destiny.com
I'd be glad to discuss this at greater length offline (mike.chermside@destiny.com), but I think I can defend chazR's position.
Here are a few quick points:
C is a language which was designed for building an operating system. It is highly specialized for that job. Here are some resulting oddities:
Numeric types of different sizes.
The sizes of the numeric types vary from machine to machine.
operators like >> and <<<
C is a very old language. Language design has improved ENORMOUSLY since it was invented. Here are a few features that more modern languages have:
Constants.
Strings.
Lists, Maps, and other super-common data structures built in.
Object orientation.
Units, aka packages.
Garbage collection.
Exceptions.
Built-in threading primatives.
C is a risky language. It it easy to make mistakes, and it encourages bad programming style.
Here are some examples:
= vs == (nuff said)
Functions that return a "special code" to indicate errors (eg: -1 => EOF)
Use of global variables.
Use of global functions.
Separation of data structures and code.
I should also mention some of C's good points:
Simple, straightforward language.
Possible to write very efficient code.
Vast librarys of existing code.
Widely known and used.
World's Most Portable Language!
Please don't read this wrong... LOTS of EXCELLENT code is written in C. And I wouldn't dream of getting rid of C... it is, for instance, a great language for compilers to OUTPUT. But if I had a choice, I'd rather not program in it.
Slashdot Mirror
Consider this to be an official offer of bounty. Hack goatse.cx, post fluffy bunnies and a public key. I, for one, will contribute to whoever pulls it off. GO FOR IT!
-- Michael Chermside
PS: This offer is not actually intended to violate any laws.
-- Michael Chermside
Would you allow a junior programmer joining your team to write code like this?
I certainly wouldn't. In c (or c++, or java, or whatever language that snippet was written in), whitespace is significant, but it is significant ONLY to the human reading the code, not to the compiler.
If I could, I'd ask the compiler (or the source-code-control checkin program) to require that the indentation match the braces. That would prevent stupid stuff like the above, and also prevent the more insidious errors like this:
where my failure to use {} around the for() clause has created an error (ie, new_x += v should be inside the loop, and you can TELL that from the indentation).So in python, you get exactly this feature. The language verifies that the ACTUAL block structure of the compiled code equals the INTENDED block structure as indicated by the programmer:
In my opinion, the python code will hold up BETTER than over long life spans than c-style code, at least if you consider only the effects of whitespace-based block structure. I say this because the use of indentation to indicate block structure is older and more widespread than the use of braces for that purpose -- compare Algol, Lisp, APL, and nearly everything else except early (column-sensitive) Fortran and assembler.
Of course you ALSO said that you liked having the braces, because it makes it easier for you to read. Fortunately, braces ARE allowed in python! The following example demonstrates their use. ;-)
-- Michael Chermside
One word: Freenet.
They already did. It'll clean off ALL your dirty windows and replace them with a pure, blue screen (of death).
-- Michael Chermside
See this story on kuro5hin if you don't know what I mean.
Please.
And if you think I'm right, or you disagree and want to defend yourself, please write me.
-- Michael Chermside
After all, as the article said:
-- Michael Chermside
> least 30%.
Over what time period?
-- Michael Chermside
The printing press. Simple enough I could probably invent it with the help of a couple good furniture makers, but VERY powerful.
Basic health knowledge. The existance of germs, and what to do about them (soap!).
A here are few gems of knowledge that wouldn't give any immediate benefit, but might set science ahead by hundreds or thousands of years: Chemical elements exist and their mass is stable. All species evolved from others; we have a set of "instructions", two copies per person.
Anyone else want to chime in?
For a more serious look at what we might be doing WRONG in the area of genetic engineering, see Scientific American's review of Body Bazar. Among other things, it addresses your question: "Who are YOU to tell me what I can and can't do with my own genes?" -- apparently in US law, you DON'T own your own genes.
I guess I don't really believe that the kind of abuses that cloning could encourage ARE in fact occuring on any widespread basis. And there are much more important things to worry about.
-- Michael Chermside
We've all seen B-budget sci-fi movies in which the mad scientist uses his cloning machine to make a duplicate of Fred of Sally and the evil clone then replaces the "real" human. But REAL cloning doesn't make a "duplicate" of a human, just another person with the same genes. That's all.
There are terrible things that we could do with cloning... growing clones and treating them as non-humans for instance (used for organ transplants, etc). But those are violations of human rights, and could happen just as easily without clones (suppose we started using 3rd-worlders for spare parts for Americans... it'd be just as bad). Cloning itself is not the source of the problem.
And as proof, I submit that human clones already exist among us! Really. On rare occasions, a fertilized egg will be split in half, and both halfs will implant in the uterus and grow. The result is two humans who are perfect clones of each other -- they're called "identical twins".
Identical twins don't think share the same mind or memories. They don't try to secretly replace each other. They don't provide a sort of immortality. And they certainly don't lack a soul. Artificial twins would be EVEN MORE DIFFERENT, because they wouldn't be the exact same age, and (often) raised in the exact same family.
So please, avoid the fearmongering. Cloning itself -- even human cloning -- is not a terribly force in the world. It could still be misused, but if anything, spreading un-true fears and rumors INCREASES the chance that it will be abused.
-- Michael Chermside <mike.chermside@destiny.com>
If either the ACLU or the EFF wants to take up your case, let me know... I'll give an increased donation to either organization for assisting in a case like this one.
-- Michael Chermside
-- Michael Chermside
The wrong way to go about it is to create an exclusive list of "Members Only" participants and allow only those members to see all security weaknesses until a fix has been completed by the vendor and is ready for immediate distribution. As we all know, there is no way that a cracker would ever be able to gain access to these restricted members-only alerts. And there is every reason to believe that even non-members would continue to freely and willingly contribute alerts to a list to which they had no access, so we need have no fear that security weaknesses would go unmentioned.
The right way to go about this is to continue to use a public list for nearly all bugs found. But a few are particularly bad problems -- either flaws which are terribly easy to exploit, or which are extremely widely distributed and therefore manifest a severe vulnerability. Distributing these only to a restricted list of highly-trusted individuals makes a lot of sense, as long as we adhere strictly to a simple list of restrictions. The primary one is that this shorter list is intended to give the white-hats a head start, not to keep security flaws secret. That means that alerts on the restricted list are AUTOMATICALLY released to the general public after a short time period. And that holds regardless of whether or not the problem has been fixed... in fact, it will serve as a strong incentive to accelerate the production of a solution. The second restriction I propose is that no vendors qualify for "special treatment" -- the same rules apply to them all.
-- Michael Chermside
-- Michael Chermside
-- Michael Chermside
-- Michael Chermside
-- Michael Chermside
> overflow that could be fixed with a library.
> Indeed, a language that did bounds checking on
> arrays (and completely didn't support pointers)
> could have avoided this problem, but I'm not sure
> that it would.
I read the article. I agree that it's not just stcpy onto a stack buffer... on the surface. But this IS just the kind of trivial error that basic programming techniques should avoid -- simply never trust input without validating it first. I agree that a "safe" language such as Java would protect from this, but "safe" libraries would help also!
-- Michael Chermside
Except that I don't think he WAS so contributing. I don't think the minor in this case committed a crime.
-- Michael Chermside
But if they're going out of business... try me. I might change my mind.
-- Michael Chermside
But I'd be surprised if that's what the patent covers, since that's NOT what Google uses. In fact, they have a very complicated formula, which they are continually tuning. It weighs those links according to how important/authoritative each of THEM is... and the means for building this rankind is by no means trivial.
To recap: If the patent attempts to cover the obvious, I'll flame away with the best of them. If it seems to be a legitimate "invention"... something which was neither simple nor obvious... then I'll hold off. Abuse (later on) of the patent might re-qualify them for flamage, but in my mind there's nothing wrong with patents themselves.
-- Michael Chermside
I am not a mathematician (IANAM?), but I would really welcome the existence of a site like this, and I would work to help make it happen. As a matter of fact, it just so happens that last week I started putting some mathematically inclined musings on WardsWiki (but I don't think that's the place for THIS project). So if someone else is planning to work on replacing Mathworld, please contact me, and I'll help out! mike.chermside@destiny.com
-- Michael Chermside
Here are a few quick points:
I should also mention some of C's good points:
Please don't read this wrong... LOTS of EXCELLENT code is written in C. And I wouldn't dream of getting rid of C... it is, for instance, a great language for compilers to OUTPUT. But if I had a choice, I'd rather not program in it.
-- Michael Chermside