yes any person of age can read the information (if they're literate), but can they really understand it, and do they know which sources are accurate and which are not?
When these people go to the voting booth and vote on issues like health care, national defense, social security, and the justice system, they need to make the same kinds of evaluations of expert opinions, and they decide over the life and death of hundreds of thousands of other people every year. If we entrust people with that responsibility at the voting booth, they should face the same responsibility within their own family or have to live with the consequences.
are at risk of dying because people decide not to have their kids vaccinated because of some junk written at salon.com.
The cause isn't salon.com, it's the lack of critical thinking by the parents. If you want to address that, improve the education system.
Trying to eliminate undesirable actions based on bad information is hopeless; the Chinese and Soviets tried it and failed, and they had a lot more control than you do.
I'm sure they can still sue the doctor, even if we beg them to reconsider at the time and document our disagreement with their refusal of the vaccine.
Of course, they can sue you. Any of your patients can sue you at any time. The question is whether they would win, and I find that doubtful if you did your job.
Apple has lots of these kinds of patents themselves, and they have tried to enforce them in the past. It seems hypocritical if Apple-fans complain about such lawsuits when Apple is the target.
As for the UI itself, it's a common arrangement of multiple selectors you see often in OS X. But those kinds of selectors and UIs didn't originate in OS X, they originated 30 years ago in Smalltalk, were copied by NeXT, and then finally by OS X.
These distros are clearly not ready to take on OS X, which will soon be the primary x86 alternative to Windows XP not only because of OS X's dedicated and outspoken user base but because of its slick looks and ease of use."
Gnome, KDE, and Mozilla have dozens of themes that satisfy every imaginable taste in user interfaces: simple, fun, slick, calm, elegant--you name it, they have it as a theme. Apple's one-size-fits-all approach is depressingly limited in comparison.
As for claims that the Macintosh has greater ease of use, show us some actual studies demonstrating that.
this is a vast improvement over centrally generated FEC blocks with authenticated checksums, which is not an improvement over bittorrent.
Re-read the paper again. Their own data, poor as it is, contradicts your statement. Even if we take their data at face value, it would show that centrally generated FEC is a big improvement over BitTorrent, while network coding is at best a minor improvement over centrally generated FEC.
So there is an objective test for autism? Last I checked, the diagnosis was fairly subjective. That leaves a door wide open for experimenter bias.
Come on, don't be so naive: such studies don't involve people driving around diagnosing patients. These kinds of epidemiological studies are based on patient records. The diagnoses were made years ago by qualified doctors who knew nothing then about the hypothesis being tested today.
"Four current studies are taking place to rule out the proposed link between autism and thimerosal" Sounds like the conclusion of the study had already been decided.
No, that's the accepted way of doing statistics in the medical sciences: you formulate a hypothesis and you test it.
I didn't say it wasn't. I said that people had already published FEC P2P systems and that the Avalanche paper failed to demonstrate that Avalanche is any better.
The advantage of Avalanche over other FEC methods is that the server doesn't have to do all the coding. Hence the term `network coding'.
So far, it is merely an unsubstantiated claim that that is an "advantage".
As I recall, the paper claimed a 20-30% speedup compared to plain P2P protocols. But there are other, known ways of speeding up plain P2P protocols. Since people haven't even bothered with those in real P2P implementation, it seems implausible that Microsoft's protocol translates into a practical advantage anybody cares about.
Actually, even as a research paper, the paper falls rather short. There has been prior work on P2P using forward error correction (FEC). FEC also means that you don't have to get every single chunk, but that you can reconstruct missing chunks from data you already have.
The authors should have demonstrated that their approach is better than FEC-based P2P protocols, but instead, they only compared it to simple P2P protocols. So, their protocol may actually not be better than the state of the art at all, and may actually be harder to implement in practice.
I agree he has the right to write articles on the issue regardless of his qualifications
Well, I'm glad that you do. It's not what the grandparent post said.
it's a free world. I do, however, think that he should fairly represent the current state of research, or at least acknowledge that the point is undecided,
Sure, but that's a very different statement from the original one; now you are criticizing the article on content, not authorship.
Most browsers recognize that different web sites should render at different levels of security, and allow the user to prohibit certain features based on the site you are at.
Firefox doesn't and Mozilla doesn't. IE does, and it's a stupid feature because most users won't configure it in a useful way.
If a site is potentially hazardous, I can choose -not- to browse to it.
If you have to worry about whether you can view a site because it might be hazardous, you are using a bad browser.
There is currently no general way to verify the source of an email.
Sure there is: digital signatures. And most email messages are validated by social context ("oh, this is the sales proposal I was expecting from John").
Not sure I follow; are you implying that issues of safe rendering can be determined accurately from email headers?
No, I'm saying that the primary source of information about the origins of a mail message are the headers, and their content and display is unaffected by the format of the body of the message. Therefore, for your argument, it makes no difference whether the body is rendered in HTML or ASCII.
Yes they do. With many flaws found, and more almost every week.
There are also lots of flaws found in ASCII-based applications. The fact that Microsoft can't seem to reliably program a reasonably secure HTML rendering engine shouldn't keep people from using HTML in email, just like the fact that Microsoft can't seem to reliably program a reasonably secure handler for ASCII shouldn't keep us from using ASCII.
Sandboxing an HTML renderer is easy, which only leaves phishing and social engineering attacks. Those, however, rely on rendering tricks. But legitimate human-to-human HTML email does not require frames or pixel-accurate positioning or pop-ups. So, it can be rendered in ways that makes it safe against phishing and other attacks
First of all, I should say that I don't believe the hypothesis to be true based on the data presented.
However, while observer bias is an issue in many studies, it probably wasn't one here: it did not involve an experiment in which experimenters could have shown bias; the hypothesis ("thimerosal causes autism") wasn't even known or stated during data collection.
I agree with you that the data and results are "fishy". But you are asking the wrong question. Kennedy doesn't have to be a "qualified researcher" in order to publish something in Salon.com, even something with scientific content. Salon.com is not a scientific journal, it's an on-line magazine for journals and writers, and Kennedy qualifies as one of those. Furthermore, anybody who has not been living under a rock for the last several decades will know his background and status.
As a scientists, I hope the day will never come in which only "qualified researchers" can publish on controversial issues. Voting age citizens are supposed to be able to comprehend, judge, and evaluate information for themselves.
HTML is too rich to implement most of the capabilities safely in an email client.
Whether you look at web pages from an untrusted source or whether you look at an email from an untrusted source makes no difference from a security point of view.
here are tricks you can pull with spoofing urls, and framesets, and there will -probably- be some identified next year that no one would think of now.
The header information is not in HTML; it is as vulnerable with HTML messages as without.
And HTML rendering engines have lots of features for dealing with malicious HTML already.
I don't like email senders dictating what tools I use on my end to read their email. I shouldn't have to turn my mail client into a browser to read email,
You dictate that your recipients use ASCII, don't you?
HTML is just an encoding. It's an encoding that has become ubiquitous, just like ASCII. It's an encoding you can view even on a vt100 terminal. It's an encoding that has been standardized.
I don't get HTML email, actually, because its automatically stripped at the MTA, same for all of my users, and I've never heard a single complaint yet.
OK, well, then it's your problem to figure out what the garbled output of your HTML-to-text converter actually says.
to strip out all HTML from email. I don't want my webpages on port 25,
And what is wrong with sending formatted text as email? Maybe all the HTML email you get is spam, but people actually use HTML email for real work (messages including tables, images, etc.). HTML email sure beats Microsoft Word attachments, which is what people would be using otherwise.
With a decent mail reader, this is not a problem either, since they disable remote images and render HTML in a way that prevents phishing attacks.
If we could replace most Word attachments with HTML mail messages, the world would be a lot better off.
The link is misleading because it tries to dispell myths that few people seem to have. If you look at the portrayal of post-nuclear war environments in recent film and fiction, radiation and fallout are generally not the biggest issues, but destruction of infrastructure, manufacturing capacity, public health services, and government are.
Nevertheless, while nuclear fallout and radiation would not be the main problems a post-nuclear war society would face, that doesn't mean that they are harmless. Fallout and radiation are serious problems, with long-term effects on the environment.
it's essential that these databases be open
on
Open Source Molecules
·
· Score: 5, Interesting
Data mining is becoming more and more important for science. But you can't do data mining if the data is locked up and requires cumbersome and costly subscriptions to access.
Chemical, biological, and other scientific databases need to be open, free, and freely redistributable for science and technology to continue to make rapid progress.
Storytelling almost always involves implausible, unrealizable, or impossible ideas: premonitions, improbable crimes, implausible conincidences, unrealistic human behavior, supernatural phenomena, etc.
Science fiction is no different from that, it just happens to use technological symbolism and metaphor. And it uses technological symbolism because it represents ideas like "progress" and "rationality" in the context of a story. Whether the symbols are physically realizable makes no more difference to whether it is a good story than the physical realizability of a Midsummer Night's Dream or King Lear.
Geeks like SciFi not because the technology it represents is necessarily realistic (although it is fun to speculate about that), but because it is about a technological approach to human problems, as well as the tension between technology and humanity.
There are several other manufacturers of B/W paper, including Agfa and Ilford. Go search oh bhphotovideo.com and you get dozens of resuls from half a dozen manufacturers for fiber-based paper alone. If anything, Kodak left the market because they were the least competitive.
(How a self-proclaimed "pro photographer" can be so unfamiliar with the market as to think that Kodak was the only manufacturer of B/W paper left is hard to understand.)
awk, sh, join, cut, paste, perl, grep, xargs, sort, and lots of other programs can manipulate data streams in exactly that format. And many UNIX tools are designed to generate data in that format: ls, df, ps, etc. Log files, daemons, and many kinds of data are also in that format.
More recent command line tools and file formats, unfortunately, deviate from that traditional format, sometimes because their authors just didn't understand and sometimes because they come from Windows.
Serialize the data structure (in some human readable form to stay true to UNIX tradition) and pass that down the pipe, from one process to another.
That's what UNIX applications do: they transmit streams of records. Each record is separated from the next by record separator (usually one or two newlines), and the fields within each record are separated by a user-definable field separator.
Slashdot Mirror
yes any person of age can read the information (if they're literate), but can they really understand it, and do they know which sources are accurate and which are not?
When these people go to the voting booth and vote on issues like health care, national defense, social security, and the justice system, they need to make the same kinds of evaluations of expert opinions, and they decide over the life and death of hundreds of thousands of other people every year. If we entrust people with that responsibility at the voting booth, they should face the same responsibility within their own family or have to live with the consequences.
are at risk of dying because people decide not to have their kids vaccinated because of some junk written at salon.com.
The cause isn't salon.com, it's the lack of critical thinking by the parents. If you want to address that, improve the education system.
Trying to eliminate undesirable actions based on bad information is hopeless; the Chinese and Soviets tried it and failed, and they had a lot more control than you do.
I'm sure they can still sue the doctor, even if we beg them to reconsider at the time and document our disagreement with their refusal of the vaccine.
Of course, they can sue you. Any of your patients can sue you at any time. The question is whether they would win, and I find that doubtful if you did your job.
Apple has lots of these kinds of patents themselves, and they have tried to enforce them in the past. It seems hypocritical if Apple-fans complain about such lawsuits when Apple is the target.
As for the UI itself, it's a common arrangement of multiple selectors you see often in OS X. But those kinds of selectors and UIs didn't originate in OS X, they originated 30 years ago in Smalltalk, were copied by NeXT, and then finally by OS X.
These distros are clearly not ready to take on OS X, which will soon be the primary x86 alternative to Windows XP not only because of OS X's dedicated and outspoken user base but because of its slick looks and ease of use."
Gnome, KDE, and Mozilla have dozens of themes that satisfy every imaginable taste in user interfaces: simple, fun, slick, calm, elegant--you name it, they have it as a theme. Apple's one-size-fits-all approach is depressingly limited in comparison.
As for claims that the Macintosh has greater ease of use, show us some actual studies demonstrating that.
this is a vast improvement over centrally generated FEC blocks with authenticated checksums, which is not an improvement over bittorrent.
Re-read the paper again. Their own data, poor as it is, contradicts your statement. Even if we take their data at face value, it would show that centrally generated FEC is a big improvement over BitTorrent, while network coding is at best a minor improvement over centrally generated FEC.
So there is an objective test for autism? Last I checked, the diagnosis was fairly subjective. That leaves a door wide open for experimenter bias.
Come on, don't be so naive: such studies don't involve people driving around diagnosing patients. These kinds of epidemiological studies are based on patient records. The diagnoses were made years ago by qualified doctors who knew nothing then about the hypothesis being tested today.
"Four current studies are taking place to rule out the proposed link between autism and thimerosal" Sounds like the conclusion of the study had already been decided.
No, that's the accepted way of doing statistics in the medical sciences: you formulate a hypothesis and you test it.
Actually, Avalanche is a FEC method.
I didn't say it wasn't. I said that people had already published FEC P2P systems and that the Avalanche paper failed to demonstrate that Avalanche is any better.
The advantage of Avalanche over other FEC methods is that the server doesn't have to do all the coding. Hence the term `network coding'.
So far, it is merely an unsubstantiated claim that that is an "advantage".
As I recall, the paper claimed a 20-30% speedup compared to plain P2P protocols. But there are other, known ways of speeding up plain P2P protocols. Since people haven't even bothered with those in real P2P implementation, it seems implausible that Microsoft's protocol translates into a practical advantage anybody cares about.
Actually, even as a research paper, the paper falls rather short. There has been prior work on P2P using forward error correction (FEC). FEC also means that you don't have to get every single chunk, but that you can reconstruct missing chunks from data you already have.
The authors should have demonstrated that their approach is better than FEC-based P2P protocols, but instead, they only compared it to simple P2P protocols. So, their protocol may actually not be better than the state of the art at all, and may actually be harder to implement in practice.
I agree he has the right to write articles on the issue regardless of his qualifications
Well, I'm glad that you do. It's not what the grandparent post said.
it's a free world. I do, however, think that he should fairly represent the current state of research, or at least acknowledge that the point is undecided,
Sure, but that's a very different statement from the original one; now you are criticizing the article on content, not authorship.
Most browsers recognize that different web sites should render at different levels of security, and allow the user to prohibit certain features based on the site you are at.
Firefox doesn't and Mozilla doesn't. IE does, and it's a stupid feature because most users won't configure it in a useful way.
If a site is potentially hazardous, I can choose -not- to browse to it.
If you have to worry about whether you can view a site because it might be hazardous, you are using a bad browser.
There is currently no general way to verify the source of an email.
Sure there is: digital signatures. And most email messages are validated by social context ("oh, this is the sales proposal I was expecting from John").
Not sure I follow; are you implying that issues of safe rendering can be determined accurately from email headers?
No, I'm saying that the primary source of information about the origins of a mail message are the headers, and their content and display is unaffected by the format of the body of the message. Therefore, for your argument, it makes no difference whether the body is rendered in HTML or ASCII.
Yes they do. With many flaws found, and more almost every week.
There are also lots of flaws found in ASCII-based applications. The fact that Microsoft can't seem to reliably program a reasonably secure HTML rendering engine shouldn't keep people from using HTML in email, just like the fact that Microsoft can't seem to reliably program a reasonably secure handler for ASCII shouldn't keep us from using ASCII.
Sandboxing an HTML renderer is easy, which only leaves phishing and social engineering attacks. Those, however, rely on rendering tricks. But legitimate human-to-human HTML email does not require frames or pixel-accurate positioning or pop-ups. So, it can be rendered in ways that makes it safe against phishing and other attacks
First of all, I should say that I don't believe the hypothesis to be true based on the data presented.
However, while observer bias is an issue in many studies, it probably wasn't one here: it did not involve an experiment in which experimenters could have shown bias; the hypothesis ("thimerosal causes autism") wasn't even known or stated during data collection.
I agree with you that the data and results are "fishy". But you are asking the wrong question. Kennedy doesn't have to be a "qualified researcher" in order to publish something in Salon.com, even something with scientific content. Salon.com is not a scientific journal, it's an on-line magazine for journals and writers, and Kennedy qualifies as one of those. Furthermore, anybody who has not been living under a rock for the last several decades will know his background and status.
As a scientists, I hope the day will never come in which only "qualified researchers" can publish on controversial issues. Voting age citizens are supposed to be able to comprehend, judge, and evaluate information for themselves.
HTML is too rich to implement most of the capabilities safely in an email client.
Whether you look at web pages from an untrusted source or whether you look at an email from an untrusted source makes no difference from a security point of view.
here are tricks you can pull with spoofing urls, and framesets, and there will -probably- be some identified next year that no one would think of now.
The header information is not in HTML; it is as vulnerable with HTML messages as without.
And HTML rendering engines have lots of features for dealing with malicious HTML already.
I don't like email senders dictating what tools I use on my end to read their email. I shouldn't have to turn my mail client into a browser to read email,
You dictate that your recipients use ASCII, don't you?
HTML is just an encoding. It's an encoding that has become ubiquitous, just like ASCII. It's an encoding you can view even on a vt100 terminal. It's an encoding that has been standardized.
I don't get HTML email, actually, because its automatically stripped at the MTA, same for all of my users, and I've never heard a single complaint yet.
OK, well, then it's your problem to figure out what the garbled output of your HTML-to-text converter actually says.
See the problem here?
Yes: you.
to strip out all HTML from email. I don't want my webpages on port 25,
And what is wrong with sending formatted text as email? Maybe all the HTML email you get is spam, but people actually use HTML email for real work (messages including tables, images, etc.). HTML email sure beats Microsoft Word attachments, which is what people would be using otherwise.
With a decent mail reader, this is not a problem either, since they disable remote images and render HTML in a way that prevents phishing attacks.
If we could replace most Word attachments with HTML mail messages, the world would be a lot better off.
You really don't need all that old, bulky, expensive hardware: software emulators embody all the essential features of that old hardware.
The link is misleading because it tries to dispell myths that few people seem to have. If you look at the portrayal of post-nuclear war environments in recent film and fiction, radiation and fallout are generally not the biggest issues, but destruction of infrastructure, manufacturing capacity, public health services, and government are.
Nevertheless, while nuclear fallout and radiation would not be the main problems a post-nuclear war society would face, that doesn't mean that they are harmless. Fallout and radiation are serious problems, with long-term effects on the environment.
Data mining is becoming more and more important for science. But you can't do data mining if the data is locked up and requires cumbersome and costly subscriptions to access.
Chemical, biological, and other scientific databases need to be open, free, and freely redistributable for science and technology to continue to make rapid progress.
Storytelling almost always involves implausible, unrealizable, or impossible ideas: premonitions, improbable crimes, implausible conincidences, unrealistic human behavior, supernatural phenomena, etc.
Science fiction is no different from that, it just happens to use technological symbolism and metaphor. And it uses technological symbolism because it represents ideas like "progress" and "rationality" in the context of a story. Whether the symbols are physically realizable makes no more difference to whether it is a good story than the physical realizability of a Midsummer Night's Dream or King Lear.
Geeks like SciFi not because the technology it represents is necessarily realistic (although it is fun to speculate about that), but because it is about a technological approach to human problems, as well as the tension between technology and humanity.
Yeah, I'd remember the short cryptic names better, so the short names are absolutely better.
You might well remember the short names better. Until somebody does the experiment, we don't know.
Deal with it.
Stop presenting your preconceived notions as facts. You probably also believe the earth is flat because, hey, it's so obvious to you.
There are several other manufacturers of B/W paper, including Agfa and Ilford. Go search oh bhphotovideo.com and you get dozens of resuls from half a dozen manufacturers for fiber-based paper alone. If anything, Kodak left the market because they were the least competitive.
(How a self-proclaimed "pro photographer" can be so unfamiliar with the market as to think that Kodak was the only manufacturer of B/W paper left is hard to understand.)
awk, sh, join, cut, paste, perl, grep, xargs, sort, and lots of other programs can manipulate data streams in exactly that format. And many UNIX tools are designed to generate data in that format: ls, df, ps, etc. Log files, daemons, and many kinds of data are also in that format.
More recent command line tools and file formats, unfortunately, deviate from that traditional format, sometimes because their authors just didn't understand and sometimes because they come from Windows.
Short, cryptic names hinder usablity by greatly increasing the learning curve.
Just because you think so doesn't make it true.
Serialize the data structure (in some human readable form to stay true to UNIX tradition) and pass that down the pipe, from one process to another.
That's what UNIX applications do: they transmit streams of records. Each record is separated from the next by record separator (usually one or two newlines), and the fields within each record are separated by a user-definable field separator.
It's well defined and it works.
Instead of building scrips through Perl or Python or whatever you use this is going to be centered around building "scripts" in .NET.
Yes, and that's exactly why bash is beter. If you want something "between" Perl and bash, use Tcl/Tk.