It has been one of the most shameful situations to come out of the British science community.
The "study" was massively flawed, and the paper has been discredited and removed from publication.
I'm sorry, I can't let that go. It didn't "come out of the British science community". In fact, if the British science community had been allowed to do its job, the study (actually just a set of case histories or "anecdotes") would have sunk into obscurity and never have been heard of except for the footnote of a mediocre doctor losing his licence over unethical practices.
The shameful situation was caused entirely by the British media which prefers sensationalism to scientific honesty. Certain journalists should be serving prison sentences for putting the public in danger for the pursuit of a story. What I find really hard to stomach is the fact that the media has totally failed to acknowledge its part in the whole sorry affair, instead scapegoating Andrew Wakefield (who deserves it, to be honest) whilst conveniently ignoring their own complicity.
2) If the odds of getting measles is less than 1 in 1000
They aren't. In a society like the one I grew up in (70's UK) without measles immunisation, more or less everybody got measles.
But unlike Rick Perry, I am opposed to FORCED vaccination by the government.
The measles vaccine is not 100% effective on individuals. It relies, to an extent on herd immunity, which is to say, it works by lowering the probability that the virus will transfer from one person to the next to the point where it will die out before it can spread.
It is your duty to society to be vaccinated and to get your children vaccinated.
The thing is that "part of the language" means a very specific thing: It means it's part of the syntax and of the language definition. The Java SE API implementation is not part of the language, it is, however, part of the Java SE implementation and its API and semantics are tightly specified, so you can pretty much guarantee it's there on any implementation.
Pull your head out of your ass - I stated at least one of those studies was covered here.
That's not a citation. A lot of stuff goes through Slashdot, so saying it covered a study about Java once doesn't help much.
So clearly you're too stupid to understand annecdote is not data and too stupid to be bothered to search/. - exactly as I would be required to do.
You made the claim, you provide the evidence.
And since I'm not stupid, I don't have a need to do your research to validate what was previously reported. Holy shit people are stupid.
Stupidity is being asked to provide citations for studies you claim exist, going off on a rant instead of providing them and not realising that your actions look like evasion possibly because the said studies are a figment of your imagination (at least that's what everybody else is thinking).
the only commercialisation allowed by the GPL is that it's ok to offer a warranty (and charge for it) or to charge for the distribution (sending a CD). that's all.
That's for the source code, you can charge as much as you like for the compiled binary.
there's absolutely no mention of differences between commercial or non-commercial redistributors.
correct answer: yes, a redistributor can just point to the original source if they distribute binaries which were compiled without modifications to that original GPL'd source code. it's actually a very good way for the redistributor to keep costs down.
As others have said, you need to read section 3 which deals with distribution of binaries. Suffice it to say, you are wrong.
Can a redistributor just point to the original source under the GPL if they don't modify it? I assume they can)
No. They can't.
Section 3 of the GPL v2 says they must either provide the source when they provide the binary or provide a written offer to give people the source if asked at the cost of distribution or, for non commercial distribution only point to the written offer they received from upstream.
That's not good enough. The terms of the GPL v 2 section 3 make it explicit that the distributor (mobile phone manufacturer) has to make the source code available. They can't just say "get it from that other web site over there". So to be compliant, HTC (for example) needs to make available the source for the exact version of the kernel that is installed on your phone.
Actually, that's not 2 b, that's 3 b and you don't need to do that, you can do 3 a instead which is
Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange
Which London is that? It's clearly not London, UK, because in that city, the queue of cars, buses and lorries (as we Brits call them) is caused by other cars, buses and lorries. The bikes actually move faster than the cars in peak periods.
You really need to go again then. Try not to do what I did which was visit on the hottest day of the year which made the temperature in the Colossus room almost unbearable. But it was worth it.
Your filter on the while loop should test for live kids. As things stand, if you drop one with your first shot, such that it remains on the lawn, you will end up wasting an infinite amount of ammunition.
That's very interesting but it's also rubbish or at least not as bad as Dennis Ritchie makes out. What would be added?
1. a new data type "string" perhaps. At the syntactic level it would behave like all the other data types (integer types, floating point types, struct/union types)
2. A handful of operators for manipulating strings. For the most part these would be existing operators overloaded (in much the same way as the arithmetic operators are overloaded between integer and floating point types) e.g. string concatenation could be +, extracting single characters would be [], the length could use sizeof. Extracting substrings would need a new operator.
Casting strings to and from other types might be tricky, but could just be banned for the most part.
So in terms of parsing, one new type among the many is needed and one new operator. Code generation would require new bits, of course, but no more so than the code generation for manipulating floating point numbers.
You can't insert nil into an Objective-C collection. You are thinking of NSNull.
nil is effectively the same as C's NULL but the message dispatch system catches the case where the receiver is nil and effectively turns the dispatch into a no-op (except for setting the return value to 0).
An arbitrary limit equal to the virtual machine size of the computer that was originally targeted.
The advantages that I see for counted length are: - it makes copying easier - you know beforehand how much space to allocate, and how much to copy. - it makes certain cases of strcmp() faster - if the length doesn't match, you can assume the strings are different. - It makes reverse searches faster. - You can put binary in a string.
- It all but eliminates the possibility of buffer overruns for strings.
But that must be weighed against the disadvantages, like not being able to take advantage of CPUs zero test conditions, but instead having to maintain a counter which eats up a valuable register.
But lots of CPUs have an instruction a bit like "decrement register and jump if not zero" which can be used for length+data strings.
Or not being well suited for piped text or multiple threads; you can't just spew the text into an already nulled area, and it will be valid as it comes in;
With modern character encodings, you can't guarantee that whatever string format you use. Couple that with the fact that streamed data tends to be read and written in blocks with a length parameter anyway, and the whole advantage is gone. This is why almost all modern languages have some variation on length + data for their strings and utilities for manipulating raw byte buffers.
Getting a free strlen() is NOT an advantage, by the way. In fact, that became a liability when UTF-8 arrived. With a library strlen() function, all you had to do was update the library, but when the compiler was hardcoded to just return the byte count, that wasn't an option.
Except that strlen() has always and still does count the number of C chars before the null byte. This is enshrined in the C99 standard. UTF-8 has not changed the implementation of strlen(). Also, gcc and probably many other compilers will normally optimise things like strlen() to a few lines of assembler rather than a call to libc, so you'd have to recompile anyway if it does change.
Sure, one could go to UTF-16 instead, but then there's a lot of wasted space.
All in all, having worked with both systems, I find more advantages with null-termination.
There's also a third system for text - linked lists. It doesn't have the disadvantage of an artificial string length limit, and allows for easy cuts and pastes, and even COW speedups, but requires far more advanced (and thus slower) routines and housekeeping, and has many of the same disadvantages as byte-counted text.. Some text processors have used this as a native string format, due to the specific advantages.
I'd still take NULL-terminated for most purposes.
Most modern languages have a proper string type and I would always take that over null terminated char sequences. You can bet that Java's internal implementation of String uses length+data.
Furthermore, if they chose a one-byte length, as the article so casually suggests as the correct solution (like Pascal), it would have had the insane limit of 255-byte strings, with no compatible way to have a string any longer. (Though a size_t length would make more sense.)
Actually, they were suggesting a two byte length, hence the one byte of overhead because a length + data string does not need a terminator. Two bytes would have been adequate on a PDP 11 because addresses were only 16 bit.
For some reason my "disable advertising" button has got turned off, but that means I get to see the huge banner ad and the even huger ad on the right hand side, which both say in huge letters:
Incidentally, I notice that at some point after screwing with the iTunes window buttons for absolutely no reason, they've reverted them back to be like every other window that's not the App Store. So apparently Apple is slowly learning their own lessons about interface consistency.
Not quite: try pressing the green "make the window as big as it needs to be to display all the content" button.
Apple is one of the worst offenders at breaking its own UI guidelines. iTunes is a fail, the App Store is a fail, Quick Time X is a huge fail. I haven't got it but I gather Aperture is also a fail.
My only complaint would be if it's not 1000 meters and 2 miles.
As long as it's right, it doesn't matter if it's inconsistent.
Complain away. I measured it with Google Earth's measuring tool. It's actually 1.6km long and 0.48km high. Both measurements are out by a factor of two.
The reduction in risk in HIV and other sexually transmitted diseases is pretty small if it exists at all. This compares very poorly with condoms which reduce the risk by ninety something percent and which protect both you and your partner.
As for cancer, you can reduce your risk of testicular cancer by 100% simply by amputating your testicles, but you're not going to do that, are you.
The main issue with circumcision as far as I am concerned is that it is an elective procedure usually performed on an individual who is unable to give their informed consent. If people want to remove their own foreskins, it's no skin off my nose, just don't do it to other people.
Slashdot Mirror
It has been one of the most shameful situations to come out of the British science community.
The "study" was massively flawed, and the paper has been discredited and removed from publication.
I'm sorry, I can't let that go. It didn't "come out of the British science community". In fact, if the British science community had been allowed to do its job, the study (actually just a set of case histories or "anecdotes") would have sunk into obscurity and never have been heard of except for the footnote of a mediocre doctor losing his licence over unethical practices.
The shameful situation was caused entirely by the British media which prefers sensationalism to scientific honesty. Certain journalists should be serving prison sentences for putting the public in danger for the pursuit of a story. What I find really hard to stomach is the fact that the media has totally failed to acknowledge its part in the whole sorry affair, instead scapegoating Andrew Wakefield (who deserves it, to be honest) whilst conveniently ignoring their own complicity.
2) If the odds of getting measles is less than 1 in 1000
They aren't. In a society like the one I grew up in (70's UK) without measles immunisation, more or less everybody got measles.
But unlike Rick Perry, I am opposed to FORCED vaccination by the government.
The measles vaccine is not 100% effective on individuals. It relies, to an extent on herd immunity, which is to say, it works by lowering the probability that the virus will transfer from one person to the next to the point where it will die out before it can spread.
It is your duty to society to be vaccinated and to get your children vaccinated.
The difference is that the massive collection of classes in java are built in the language itself.
No they are not. They are in jar files like every other Java library.
You don't happen to bump on a Java deployment without them.
That's true. Oh, wait, no, it isn't
The thing is that "part of the language" means a very specific thing: It means it's part of the syntax and of the language definition. The Java SE API implementation is not part of the language, it is, however, part of the Java SE implementation and its API and semantics are tightly specified, so you can pretty much guarantee it's there on any implementation.
Microsoft C does not claim to be C99 compliant and it probably never will be. They more or less gave up at C89 to concentrate on C++
Citations for the studies please.
Pull your head out of your ass - I stated at least one of those studies was covered here.
That's not a citation. A lot of stuff goes through Slashdot, so saying it covered a study about Java once doesn't help much.
So clearly you're too stupid to understand annecdote is not data and too stupid to be bothered to search /. - exactly as I would be required to do.
You made the claim, you provide the evidence.
And since I'm not stupid, I don't have a need to do your research to validate what was previously reported. Holy shit people are stupid.
Stupidity is being asked to provide citations for studies you claim exist, going off on a rant instead of providing them and not realising that your actions look like evasion possibly because the said studies are a figment of your imagination (at least that's what everybody else is thinking).
I've got a stylus for my iPad. I'm not saying it's perfect, but it makes handwriting possible and drawing practical.
the only commercialisation allowed by the GPL is that it's ok to offer a warranty (and charge for it) or to charge for the distribution (sending a CD). that's all.
That's for the source code, you can charge as much as you like for the compiled binary.
there's absolutely no mention of differences between commercial or non-commercial redistributors.
correct answer: yes, a redistributor can just point to the original source if they distribute binaries which were compiled without modifications to that original GPL'd source code. it's actually a very good way for the redistributor to keep costs down.
As others have said, you need to read section 3 which deals with distribution of binaries. Suffice it to say, you are wrong.
Can a redistributor just point to the original source under the GPL if they don't modify it? I assume they can)
No. They can't.
Section 3 of the GPL v2 says they must either provide the source when they provide the binary or provide a written offer to give people the source if asked at the cost of distribution or, for non commercial distribution only point to the written offer they received from upstream.
That's not good enough. The terms of the GPL v 2 section 3 make it explicit that the distributor (mobile phone manufacturer) has to make the source code available. They can't just say "get it from that other web site over there". So to be compliant, HTC (for example) needs to make available the source for the exact version of the kernel that is installed on your phone.
Actually, that's not 2 b, that's 3 b and you don't need to do that, you can do 3 a instead which is
Which London is that? It's clearly not London, UK, because in that city, the queue of cars, buses and lorries (as we Brits call them) is caused by other cars, buses and lorries. The bikes actually move faster than the cars in peak periods.
Xcode 4.1 has that ability.
Protesting isn't illegal in the UK. Setting fire to other people's property is.
You really need to go again then. Try not to do what I did which was visit on the hottest day of the year which made the temperature in the Colossus room almost unbearable. But it was worth it.
Your filter on the while loop should test for live kids. As things stand, if you drop one with your first shot, such that it remains on the lawn, you will end up wasting an infinite amount of ammunition.
That's very interesting but it's also rubbish or at least not as bad as Dennis Ritchie makes out. What would be added?
1. a new data type "string" perhaps. At the syntactic level it would behave like all the other data types (integer types, floating point types, struct/union types)
2. A handful of operators for manipulating strings. For the most part these would be existing operators overloaded (in much the same way as the arithmetic operators are overloaded between integer and floating point types) e.g. string concatenation could be +, extracting single characters would be [], the length could use sizeof. Extracting substrings would need a new operator.
Casting strings to and from other types might be tricky, but could just be banned for the most part.
So in terms of parsing, one new type among the many is needed and one new operator. Code generation would require new bits, of course, but no more so than the code generation for manipulating floating point numbers.
You can't insert nil into an Objective-C collection. You are thinking of NSNull.
nil is effectively the same as C's NULL but the message dispatch system catches the case where the receiver is nil and effectively turns the dispatch into a no-op (except for setting the return value to 0).
That's still an arbitrary limit.
An arbitrary limit equal to the virtual machine size of the computer that was originally targeted.
The advantages that I see for counted length are:
- it makes copying easier - you know beforehand how much space to allocate, and how much to copy.
- it makes certain cases of strcmp() faster - if the length doesn't match, you can assume the strings are different.
- It makes reverse searches faster.
- You can put binary in a string.
- It all but eliminates the possibility of buffer overruns for strings.
But that must be weighed against the disadvantages, like not being able to take advantage of CPUs zero test conditions, but instead having to maintain a counter which eats up a valuable register.
But lots of CPUs have an instruction a bit like "decrement register and jump if not zero" which can be used for length+data strings.
Or not being well suited for piped text or multiple threads; you can't just spew the text into an already nulled area, and it will be valid as it comes in;
With modern character encodings, you can't guarantee that whatever string format you use. Couple that with the fact that streamed data tends to be read and written in blocks with a length parameter anyway, and the whole advantage is gone. This is why almost all modern languages have some variation on length + data for their strings and utilities for manipulating raw byte buffers.
Getting a free strlen() is NOT an advantage, by the way. In fact, that became a liability when UTF-8 arrived. With a library strlen() function, all you had to do was update the library, but when the compiler was hardcoded to just return the byte count, that wasn't an option.
Except that strlen() has always and still does count the number of C chars before the null byte. This is enshrined in the C99 standard. UTF-8 has not changed the implementation of strlen(). Also, gcc and probably many other compilers will normally optimise things like strlen() to a few lines of assembler rather than a call to libc, so you'd have to recompile anyway if it does change.
Sure, one could go to UTF-16 instead, but then there's a lot of wasted space.
All in all, having worked with both systems, I find more advantages with null-termination.
There's also a third system for text - linked lists. It doesn't have the disadvantage of an artificial string length limit, and allows for easy cuts and pastes, and even COW speedups, but requires far more advanced (and thus slower) routines and housekeeping, and has many of the same disadvantages as byte-counted text.. Some text processors have used this as a native string format, due to the specific advantages.
I'd still take NULL-terminated for most purposes.
Most modern languages have a proper string type and I would always take that over null terminated char sequences. You can bet that Java's internal implementation of String uses length+data.
Furthermore, if they chose a one-byte length, as the article so casually suggests as the correct solution (like Pascal), it would have had the insane limit of 255-byte strings, with no compatible way to have a string any longer. (Though a size_t length would make more sense.)
Actually, they were suggesting a two byte length, hence the one byte of overhead because a length + data string does not need a terminator. Two bytes would have been adequate on a PDP 11 because addresses were only 16 bit.
For some reason my "disable advertising" button has got turned off, but that means I get to see the huge banner ad and the even huger ad on the right hand side, which both say in huge letters:
Download Google Chrome Now
Incidentally, I notice that at some point after screwing with the iTunes window buttons for absolutely no reason, they've reverted them back to be like every other window that's not the App Store. So apparently Apple is slowly learning their own lessons about interface consistency.
Not quite: try pressing the green "make the window as big as it needs to be to display all the content" button.
Apple is one of the worst offenders at breaking its own UI guidelines. iTunes is a fail, the App Store is a fail, Quick Time X is a huge fail. I haven't got it but I gather Aperture is also a fail.
First paragraph is golden. If the code was at one time released open source, then you can totally fork it.
What if he can't prove he had the right to release it as Open Source in the first place?
Who says North is up?
My only complaint would be if it's not 1000 meters and 2 miles.
As long as it's right, it doesn't matter if it's inconsistent.
Complain away. I measured it with Google Earth's measuring tool. It's actually 1.6km long and 0.48km high. Both measurements are out by a factor of two.
The reduction in risk in HIV and other sexually transmitted diseases is pretty small if it exists at all. This compares very poorly with condoms which reduce the risk by ninety something percent and which protect both you and your partner.
As for cancer, you can reduce your risk of testicular cancer by 100% simply by amputating your testicles, but you're not going to do that, are you.
The main issue with circumcision as far as I am concerned is that it is an elective procedure usually performed on an individual who is unable to give their informed consent. If people want to remove their own foreskins, it's no skin off my nose, just don't do it to other people.