You are making rationalisations about RF interference by making an analogy to water sinking boats? Your post is a prime example of the fallacy of arguing by analogy - or "argumentum ad vehiculum" as I like to call it, because of how often the analogies relate to cars. The actual NYT article, which the somewhat-stupid, dogmatically anti-regulation blog linked to, even mentions that RF interference does not work additively this way.
Another option was a rotatable lever on the steering wheel. However, foot pedal operated throttles were already in use by at least 1923 - I've driven an Austin 7 of that year with such.
Yes, something like SecureBoot possibly could be a piece of a system that guarantees the operation of code - though, it need not be either (e.g. the hardware could come with a formal proof or model, and a checker could verify the loaded code follows the proof - not caring where it comes from).
However, SecureBoot is not that system, nor does SecureBoot of itself get you any closer to that system.
E.g. how many systems get their boot path compromised, without the exploitation of any software bugs? That's basically never the case with malware. If you can compromise a system, you can find a way to have some apparently innocuous data file exploit a bug in some code that interprets it to inject code (JPEG parsers, Flash, JavaScript, etc.. take your pick, the list is endless - they're all buggy, cause we don't know how to write bug-free code), and then take-over the machine - that will work for the initial exploit and it will work to re-exploit the machine after reboots. SecureBoot just doesn't do anything to stop this, and these are scenarios which exploits already regularly use.
SecureBoot doesn't stop the bad guys. It will only stop the less-technical, more ordinary users from using their computers the way they want.
No, it can not. SecureBoot verifies the code image was the one that was intended, *prior* to that code being run. SecureBoot can say nothing about what happens when that code runs. In particular, SecureBoot will not protect you from the code being modified or replaced once it is running, by design or (the typical case for security compromises) through the bugs that are rife in any non-trivial body of code. To make guarantees about the correct operation of code and be able to verify it is free of bugs that would allow the code to be replaced would require formal verification. That's a near impossible task generally.
"even if malware loaded into memory into runtime" - so you recognise this can happen, yet still can claim SecureBoot protects against it? A reboot doesn't protect, because the system can just be compromised again (e.g. by some apparently innocuous application, or even a data file that gets interpreted automatically by an application that has a bug, thus allowing code injection and further exploitation of kernels bugs - as there have been in, e.g., Javascript and Flash interpreters).
SecureBoot does not fix the problem that end-users want it to. However, SecureBoot certainly walks us down a path where large corporates could make life difficult for end-users. MS might not be able to make SecureBoot mandatory for now, for legacy compatability reasons, but do not doubt they will when they can. SecureBoot is already *mandatory* on ARM systems, in order to be supported by MS Windows there.
What people really want is that their running code is verified to be running the way it is supposed to be. This requires formal proofs of code operation - which is notoriously difficult (and impossible to do generally with arbitrary software). SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor. SecureBoot can however make the lives of ordinary users difficult. For now, we have the ability to use our own trust anchor, or none at all. Microsoft can't yet afford to block users from running all the non-SecureBoot OSes - as these include older Windows releases.
It's sad that so many Linux distributions and foundations are going along with this.
It's not in the GPL. Again, the copyright holder isn't bound by the GPL. The copyright holder, by definition in law, is or are the person(s) holding the right to dictate the terms by which _others_ may copy the work.
If the the copyright holders say that half the code is available GPL, and the other half isn't, and that that's fine, then that's fine. (They need to word it a bit better than that if they want others to actually be able to distribute under the GPL, in particular they need to state they're granting an exception to the GPL so that others may distribute the GPL half of their software while making use of their proprietary half, but they're the copyright holders, they can do this).
The only time a copyright holder would be constrained is if there were multiple copyright holders and they didn't all agree. However, when the copyright holders agree, they can pretty much do what they want.
No. If I'm the author of software, I can decide to GPL some of it and keep other parts proprietary. I own it, I can do this. No one else can do this however.
The copyright holder of the code is exempt from the GPL. They have no need for a licence via the GPL, because they own it - anything they do with it is legal, at least under copyright law. Copyright only constrains *others*.
The GPL doesn't force you to give the software away. You can sell it. Indeed, RMS himself used to **sell** tapes of GPL software to fund the FSF. RedHat make *billions* on per-seat licensing of GPL software. Nor does GPL software force you, as an author, to GPL all the software. As the author you are completely free to draw the line as you wish between which bits of your software are GPL and which proprietary. You just grant yourself an exception.
What the GPL *does* do, which a BSD licence does not, is protect you from anyone who tries to take your source and then make their own proprietary modificaitions. If you released your code as GPL you can now sue them, and get damages. If you released as BSD, you can't - they are free to make closed modifications to your code (as Apple have done with FreeBSD).
You're at odds with RMS, congratulations, but you're also falling quite a bit short in your understanding of the licences you do and don't have issues with.
Actually, the USA imprisons *more* people - in *absolute* terms - than China, despite China having several multiples the population. The USA leads the world both in terms of absolute prison population and per-capita incarceration rates. Thus, if you want to measure liberty and freedom in their most literal senses, the USA is the worst country in the world. The average Chinese person has a far better chance of NOT being locked up by their government than the average American. (On the other hand the average Chinese person has a much higher chance of being executed).
That's not true. Just recently in the UK a murderer had 1 charge completely thrown out because the arresting officer didn't read him his rights. The murdered confessed and had led the officer right to the body, all ruled inadmissible because the detective decided not to interrupt the murdered while he was confessing. (Luckily there was another murder which he could be convicted on).
BBC News is pretty simplistic too. It's good for getting a broad overview, but if there's any story you're interested in you'll almost certainly have to go somewhere else if you want to get actual detail. Channel 4 news are better at detail, but sometimes prone to over editorialising.
You appear to be correct, judging by the information in the patch (e.g. see the LWN link posted by someone else, later in these comments). (commenting mostly because I accidently modded you as 'troll' when I'd meant to click 'informative' and this is the only way to undo that).
The scientology story censored comment story you mention. In CmdrTaco's post on the story, he links to the censored comment, saying its text was replaced. However, that link is broken. This makes me wonder if there's some deeper problem with links in old/. stories?
Of course there are. The statistics most people do is 2-variable, but statistics generalises perfectly well to multiple variables. The quality of a study may need a subjective assessment, but you can assign it a value and it becomes another dimension to your data, then find out how it correlates with other dimensions in your data. Some of the stuff I do on finding hidden structure in large, complex graphs/networks uses techniques that also are used in multi-variate statistical analyses.
I agree there may be a need to filter for medical treatment studies. I agree pharmaceuticals have manipulated the public record (from which meta-studies must draw) with poor studies. However, they have also manipulated the public record by _withholding_ studies from the public record. (By co-incidence I'm reading Ben Goldacre's "Bad Pharma" at the moment, which takes issue with that withholding trick and its distorting effect - very interesting book so far).
One of the problems with judging helmet efficacy of course is that it is *very* hard to do well controlled studies. intrinsically, if we want statistics that measure real-world efficacy of helmets, we're going to have to work with extremely noisy signals. The best way to deal with noise is to use as much data as possible (and control for the differences in methodologies).
BTW: The limited-time period trick has been used by studies that found helmets had a large positive effect too.;)
I'm using bias in a non-pejorative, technical, statistical sense. Clearly either: a) There is some underlying bias why studies where helmets were less effective were also less likely to meet Thompson's Cochrane review standards OR b) There is a bias in the Cochrane review OR c) There is a "biased" co-incidence (random chance that creates a pattern that looks like bias).
FWIW, I have both studies open. They both have good discussions on this. I think we'd both be better off just reading them and deciding from that. I'm sticking to my belief that bias is best dealt with by gathering and aggregating more data and using mathematical tools to deal with any differences in methodology and results, rather than using more subjective "quality" criteria to exclude data-points.
One thing, the Elvik meta-study a different data-set to the Thompson Cochrane Collab. paper, which is interesting. The Elvik paper is updating a 2001 meta-study, Attewell, with new data-points. The Cochrane paper uses some of the same, and additional ones. There are primary-papers in the Attewell study though which the Thompson paper did not find at all - even though it found the Attewell meta-study. Similarly there are primary-papers in the Thompson paper, which pre-date Attewell significantly, but which Attewell does not mention. This makes me think the search strategy in both those meta-studies might have been sub-optimal - unless there's some important factor I've missed. If I havn't missed anything, it'd be interesting to see a meta-study with search criteria that caught at least all the primary works in those meta-studies.
Also worth noting is that several of the studies excluded from the Thompson paper were published in Accident Analysis & Prevention, as was the Attewell meta-study.
Oh, I'm not arguing for apples-oranges comparisons. There are objective, mathematical methods to deal with multi-variate results, rather than just excluding ones you don't like.
I don't have expertise in or much knowledge of the medical world, but my mathematical knowledge is not comfortable with "less is more" wrt statistical analysis. The answer to noise is to aggregate over more data, not have humans apply their judgement as to which signals are and are not representative. That path is certain to result in misleading conclusions at times, even with the best intentions from the best experts.
And it remains curious that those studies that the Cochrane study felt it had to be excluded have such an effect on the result. Whether it was that studies that show less benefit and/or increased other injuries in helmets are biased towards less rigorous methodology, or whether it was selection bias by the Cochrane study authors, I don't know. However, the Elvik study strongly suggests there appears to be some kind of bias *somewhere* in the previous work (the primary research and/or the meta-study).
I don't doubt him. Still, we don't know which of the two meta-studies is more representative of reality. I'm going to stick to my general view though that these questions are best answered by aggregating more data, rather than less. I look forward to future meta-studies revising the results of these two with even more data, when it becomes available.
Slashdot Mirror
You are making rationalisations about RF interference by making an analogy to water sinking boats? Your post is a prime example of the fallacy of arguing by analogy - or "argumentum ad vehiculum" as I like to call it, because of how often the analogies relate to cars. The actual NYT article, which the somewhat-stupid, dogmatically anti-regulation blog linked to, even mentions that RF interference does not work additively this way.
Another option was a rotatable lever on the steering wheel. However, foot pedal operated throttles were already in use by at least 1923 - I've driven an Austin 7 of that year with such.
Yes, something like SecureBoot possibly could be a piece of a system that guarantees the operation of code - though, it need not be either (e.g. the hardware could come with a formal proof or model, and a checker could verify the loaded code follows the proof - not caring where it comes from).
However, SecureBoot is not that system, nor does SecureBoot of itself get you any closer to that system.
E.g. how many systems get their boot path compromised, without the exploitation of any software bugs? That's basically never the case with malware. If you can compromise a system, you can find a way to have some apparently innocuous data file exploit a bug in some code that interprets it to inject code (JPEG parsers, Flash, JavaScript, etc.. take your pick, the list is endless - they're all buggy, cause we don't know how to write bug-free code), and then take-over the machine - that will work for the initial exploit and it will work to re-exploit the machine after reboots. SecureBoot just doesn't do anything to stop this, and these are scenarios which exploits already regularly use.
SecureBoot doesn't stop the bad guys. It will only stop the less-technical, more ordinary users from using their computers the way they want.
No, it can not. SecureBoot verifies the code image was the one that was intended, *prior* to that code being run. SecureBoot can say nothing about what happens when that code runs. In particular, SecureBoot will not protect you from the code being modified or replaced once it is running, by design or (the typical case for security compromises) through the bugs that are rife in any non-trivial body of code. To make guarantees about the correct operation of code and be able to verify it is free of bugs that would allow the code to be replaced would require formal verification. That's a near impossible task generally.
"even if malware loaded into memory into runtime" - so you recognise this can happen, yet still can claim SecureBoot protects against it? A reboot doesn't protect, because the system can just be compromised again (e.g. by some apparently innocuous application, or even a data file that gets interpreted automatically by an application that has a bug, thus allowing code injection and further exploitation of kernels bugs - as there have been in, e.g., Javascript and Flash interpreters).
SecureBoot does not fix the problem that end-users want it to. However, SecureBoot certainly walks us down a path where large corporates could make life difficult for end-users. MS might not be able to make SecureBoot mandatory for now, for legacy compatability reasons, but do not doubt they will when they can. SecureBoot is already *mandatory* on ARM systems, in order to be supported by MS Windows there.
What people really want is that their running code is verified to be running the way it is supposed to be. This requires formal proofs of code operation - which is notoriously difficult (and impossible to do generally with arbitrary software). SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor. SecureBoot can however make the lives of ordinary users difficult. For now, we have the ability to use our own trust anchor, or none at all. Microsoft can't yet afford to block users from running all the non-SecureBoot OSes - as these include older Windows releases.
It's sad that so many Linux distributions and foundations are going along with this.
It's not in the GPL. Again, the copyright holder isn't bound by the GPL. The copyright holder, by definition in law, is or are the person(s) holding the right to dictate the terms by which _others_ may copy the work.
If the the copyright holders say that half the code is available GPL, and the other half isn't, and that that's fine, then that's fine. (They need to word it a bit better than that if they want others to actually be able to distribute under the GPL, in particular they need to state they're granting an exception to the GPL so that others may distribute the GPL half of their software while making use of their proprietary half, but they're the copyright holders, they can do this).
The only time a copyright holder would be constrained is if there were multiple copyright holders and they didn't all agree. However, when the copyright holders agree, they can pretty much do what they want.
No. If I'm the author of software, I can decide to GPL some of it and keep other parts proprietary. I own it, I can do this. No one else can do this however.
The copyright holder of the code is exempt from the GPL. They have no need for a licence via the GPL, because they own it - anything they do with it is legal, at least under copyright law. Copyright only constrains *others*.
Yes, correct, it prevents the distribution of. Private modifications are fine either way.
The GPL doesn't force you to give the software away. You can sell it. Indeed, RMS himself used to **sell** tapes of GPL software to fund the FSF. RedHat make *billions* on per-seat licensing of GPL software. Nor does GPL software force you, as an author, to GPL all the software. As the author you are completely free to draw the line as you wish between which bits of your software are GPL and which proprietary. You just grant yourself an exception.
What the GPL *does* do, which a BSD licence does not, is protect you from anyone who tries to take your source and then make their own proprietary modificaitions. If you released your code as GPL you can now sue them, and get damages. If you released as BSD, you can't - they are free to make closed modifications to your code (as Apple have done with FreeBSD).
You're at odds with RMS, congratulations, but you're also falling quite a bit short in your understanding of the licences you do and don't have issues with.
Actually, the USA imprisons *more* people - in *absolute* terms - than China, despite China having several multiples the population. The USA leads the world both in terms of absolute prison population and per-capita incarceration rates. Thus, if you want to measure liberty and freedom in their most literal senses, the USA is the worst country in the world. The average Chinese person has a far better chance of NOT being locked up by their government than the average American. (On the other hand the average Chinese person has a much higher chance of being executed).
That's not true. Just recently in the UK a murderer had 1 charge completely thrown out because the arresting officer didn't read him his rights. The murdered confessed and had led the officer right to the body, all ruled inadmissible because the detective decided not to interrupt the murdered while he was confessing. (Luckily there was another murder which he could be convicted on).
StrongARM? Didn't intel sell that to Marvel years ago?
BBC News is pretty simplistic too. It's good for getting a broad overview, but if there's any story you're interested in you'll almost certainly have to go somewhere else if you want to get actual detail. Channel 4 news are better at detail, but sometimes prone to over editorialising.
You appear to be correct, judging by the information in the patch (e.g. see the LWN link posted by someone else, later in these comments). (commenting mostly because I accidently modded you as 'troll' when I'd meant to click 'informative' and this is the only way to undo that).
Single speed mountain biking? You must have thunder thighs :). Nice pink helmet too. ;)
Hi,
The scientology story censored comment story you mention. In CmdrTaco's post on the story, he links to the censored comment, saying its text was replaced. However, that link is broken. This makes me wonder if there's some deeper problem with links in old /. stories?
Oh control for by adding dimensions to the data as necessary to deal with that - not dropping the data!
Of course there are. The statistics most people do is 2-variable, but statistics generalises perfectly well to multiple variables. The quality of a study may need a subjective assessment, but you can assign it a value and it becomes another dimension to your data, then find out how it correlates with other dimensions in your data. Some of the stuff I do on finding hidden structure in large, complex graphs/networks uses techniques that also are used in multi-variate statistical analyses.
I agree there may be a need to filter for medical treatment studies. I agree pharmaceuticals have manipulated the public record (from which meta-studies must draw) with poor studies. However, they have also manipulated the public record by _withholding_ studies from the public record. (By co-incidence I'm reading Ben Goldacre's "Bad Pharma" at the moment, which takes issue with that withholding trick and its distorting effect - very interesting book so far).
One of the problems with judging helmet efficacy of course is that it is *very* hard to do well controlled studies. intrinsically, if we want statistics that measure real-world efficacy of helmets, we're going to have to work with extremely noisy signals. The best way to deal with noise is to use as much data as possible (and control for the differences in methodologies).
BTW: The limited-time period trick has been used by studies that found helmets had a large positive effect too. ;)
I'm using bias in a non-pejorative, technical, statistical sense. Clearly either: a) There is some underlying bias why studies where helmets were less effective were also less likely to meet Thompson's Cochrane review standards OR b) There is a bias in the Cochrane review OR c) There is a "biased" co-incidence (random chance that creates a pattern that looks like bias).
FWIW, I have both studies open. They both have good discussions on this. I think we'd both be better off just reading them and deciding from that. I'm sticking to my belief that bias is best dealt with by gathering and aggregating more data and using mathematical tools to deal with any differences in methodology and results, rather than using more subjective "quality" criteria to exclude data-points.
One thing, the Elvik meta-study a different data-set to the Thompson Cochrane Collab. paper, which is interesting. The Elvik paper is updating a 2001 meta-study, Attewell, with new data-points. The Cochrane paper uses some of the same, and additional ones. There are primary-papers in the Attewell study though which the Thompson paper did not find at all - even though it found the Attewell meta-study. Similarly there are primary-papers in the Thompson paper, which pre-date Attewell significantly, but which Attewell does not mention. This makes me think the search strategy in both those meta-studies might have been sub-optimal - unless there's some important factor I've missed. If I havn't missed anything, it'd be interesting to see a meta-study with search criteria that caught at least all the primary works in those meta-studies.
Also worth noting is that several of the studies excluded from the Thompson paper were published in Accident Analysis & Prevention, as was the Attewell meta-study.
Oh, I'm not arguing for apples-oranges comparisons. There are objective, mathematical methods to deal with multi-variate results, rather than just excluding ones you don't like.
I don't have expertise in or much knowledge of the medical world, but my mathematical knowledge is not comfortable with "less is more" wrt statistical analysis. The answer to noise is to aggregate over more data, not have humans apply their judgement as to which signals are and are not representative. That path is certain to result in misleading conclusions at times, even with the best intentions from the best experts.
Gah, correction: A result aligned bias that is, so more likely to be systematic, less likely to be random co-incidence.
A systematic, result aligned bias that is, not just random.
And it remains curious that those studies that the Cochrane study felt it had to be excluded have such an effect on the result. Whether it was that studies that show less benefit and/or increased other injuries in helmets are biased towards less rigorous methodology, or whether it was selection bias by the Cochrane study authors, I don't know. However, the Elvik study strongly suggests there appears to be some kind of bias *somewhere* in the previous work (the primary research and/or the meta-study).
I don't doubt him. Still, we don't know which of the two meta-studies is more representative of reality. I'm going to stick to my general view though that these questions are best answered by aggregating more data, rather than less. I look forward to future meta-studies revising the results of these two with even more data, when it becomes available.