The Arpanet came before the net and demanded that all computers that connect to it do so with the same hardware and software.
I was really disappointed to read this in the article. First, it wasn't true. There were a lot of such restrictions in the early implementations, but by the time that TCP was spec'd, there were already cases of interconnected hardware and software from different vendors. TCP was a (pretty good) attempt to codify what had been learned about how to do this.
But more important is the point that such single-source restrictions were exactly why ARPA started funding what became the Internet. It was, to a great extent, a response to ongoing problems with electronic gadgets that couldn't talk to each other. The military (and ARPA was a military research agency) wanted this problem solved. What good were all those fancy-schmancy electronic thingies if they couldn't exchange data?
If you look up the early docs from the ARPAnet, you'll see pretty pictures all over the place showing large numbers of electronic gadgets, obviously from a lot of different manufacturers, with lines between them showing the comm links. It's obvious that interconnecting hardware and software from different vendors was a major goal right from the start.
There have been a number of comments on why ARPA gave their development money to universities rather than to commercial vendors. A number of military types were open about this from the start: They had learned that military contractors simply couldn't be forced to work together. Most attempts to get them to cooperate with data comm were pretty much dismal failures. They were competitors, after all. They would pretend to be cooperating, while doing everything they could to fix things so their competitors couldn't cooperate. This is still a problem, of course, and probably always will be. Commercial vendors sabotaging standards is a very familiar process.
So ARPA took the approach of funding an independent gang of academic hackers. Give them equipment and money to pay students to hack away. Fund a few overseers to attempt to coordinate this herd of cats. When they seem to have something working, buy them some fun new hardware and challenge them to incorporate it with the old stuff. Try not to let them get lazy and develop a monoculture of equipment from a single vendor. Watch what they do, and carry off anything they produce that seems useful.
But the intent from the start was to make all electronic gadgets talk sensibly to each other. If the early setups didn't achieve this, it was simply a case of "We're not there yet". The intent was to get there.
I have to expand the Wired article so that it covers most of my screen to make a single line of text visible without scrolling. You'd think that a geek publication like Wired would know better.
I'm getting sick of being forced to resize my browser window for nearly every new page.
Hey, Firebird guys, can you privide an option to disable the width= attribute on all tags? The height= attribute might go, too. Thanks in advance...
I don't think I agree. Whether to map two character codes to the same character is a "policy" decision that has no business in the OS kernel. An OS should implement mechanism, not policy.
When you see an OS that forces such things on apps (e.g., OSX), you know that the designers were not good engineers, and didn't understand the difference between policy and mechanism.
Such decisions properly belong in run-time libraries. That way, they aren't forced on all programs, and they can be changed when they're wrong.
One good example is "internationalization", which among other things deals with the character sets of various languages. There are a lot of policy decisions to be made there that have absolutely no business being hard-coded into the OS.
There are cases in the current 8859-* encodings where an upper/lower-case pair in one encoding aren't even letters in another encoding. You don't want to have to reboot to change the mappings for your national alphabet. This is especially true when the language changes in different parts of a document.
Putting case munging into the OS only makes sense if you are building a single-language system. This is true for much US-made software, where much of the computer industry has open contempt for any language other than English. But for the rest of the world, putting case-folding code into the OS is a guaranteed linguistic disaster just waiting to happen.
I've already seen suggestions that this alone is grounds to reject OSX in some parts of the world. And the English-only bias in the Windows file system is one of the ongoing frustrations outside the US, where you often can't even use your native alphabet in an 8+3-char file name.
I propose a rule... unless you own a company that's worth at least $100M, you should keep your suggestions about what MS should do to yourself. It's pointless,...
Right you are. Microsoft has never needed feedback from mere [l]users, and doesn't need it now. Only important people (and "important" is defined as having no need to ever touch a keyboard because your people take care of that) should ever be listened to when designing new products to be used by unimportant people.
The rest of us should just buy whatever the marketing department decides we need, and we should be grateful to them for providing such benificence.
The Internet name had been used for this existing network for years before Gore ever got involved.
Well, yes and no. The case of the first letter is significant here. The term "internet" was used in the ARPAnet community by the late 70's. But the term "Internet" was consciously introduced in the early 80's with a more precise meaning.
There were a lot of early writings that attempted to make a distinction. An "internet" was more or less what we now call a LAN or an "intranet", a collection of machines using one or more types of comm hardware, with IP used to make them all play nice together. There were (and still are) many "internets". Each may consist of a number of different (hardware) networks, but at the IP level, they can be treated as a single network. The IP protocol intercedes for the software to make the hardware networks interoperate.
The "Internet" was conceived as a top-level internet that connected all of them as a single world-wide network. This was significant not because it needed new technology, but because it was to be a permanent part of the world's communications, not under the control of any single agency or government. The significant innovation here was the idea of a permanent comm system with distributed, cooperating management.
People in academia had talked about this, of course. But by the early 80's, it really hadn't been done. There was a world-wide ARPAnet, yes, and lots of little internets in different organizations. But their interconnections were partial and transitory. I well remember the frustrations of trying to send email from within one company or school to someone in another. At that time, the UUCP email system was often much more reliable, because its store-and-forward approach didn't depend on routing and permanent connections. Even today, with much of the Internet using transient dialup connections, email depends on a store-and-forward scheme, and most home machines and portables can't put things on the web, because they don't have permanent connections. So the Internet with a capital 'I' still hasn't really been fully implemented.
Al Gore rightly deserves a lot of credit for funding development of "the Internet", which happened in the 80's. He can't take much credit for "internet" development, which happened mostly in the 70's.
Of course, if you use an OS that doesn't make case distinctions, you might not understand the difference.
Well, just making it free was not enough. It was important that it was both free AND simple.
Good point. An interesting take that I've seen on this is that what was done with the new HTTP protocol could have been done using FTP, except for one thing: security. HTTP didn't have any, and that made it usable.
To do the same thing with FTP, the client needed to know an id and password. So before you could follow a link to a site, you'd have to first contact them and get the id and password. So a 1-second operation with HTTP would take several days with FTP.
Yes, I know about anonymous FTP. In the late 1980's, this was almost never configured by default. You had to config it yourself, and hardly anyone (even true geeks) could figure out how to do that successfully.
One of the brilliant innovations with web servers was the idea that the server would only deliver files from within its directory heirarchy, and couldn't be tricked into following ".." links. So you could tell people a simple rule: If you want a file to be public, you put it into one of the web server's directories. Anything outside those directories is invisible on the web. Simple, understandable, and fairly idiot proof. The only tricky bit was symlinks, and those are easy to find (or disable in httpd.conf).
The addition of CGI scripts added a qualification to this rule, but that only affected programmers, and they could be expected to understand the issue.
It's just one example of a more general rule that I've seen proposed: Low-level transport mechanisms (IP, highways, etc) shouldn't implement security. They should do only transport, and leave the security to the "content" level. Transport mechanisms that implement security are invariably difficult to use and are restricted to small, specialized uses. And when their security turns out to have a hole, it can't be fixed, due to the difficulty of getting at the low levels, and the near impossibility of getting all commercial systems upgraded together.
But the most elegant explanation of the web's simplicity is:
: telnet foo.bar.com 25 GET/some/file.txt
Remember to hit the Return key twice.
(And yes, I do know about the "HTTP/X.Y" field. I even use it sometimes.;-)
If on line text is any indication ...
on
XForms Essentials
·
· Score: 2, Interesting
No purchase is necessary; you can read the full text online, though I will admit that even I did end up getting the hard copy eventually. The book is small, and paper still has something over HTML, even when viewed on an Apple PowerBook.
I looked at the online text with my PowerBook, too, partly because I have four browsers there. If the result indicates anything about the project, I'd say they aren't quite ready for prime time yet.
All four of them displayed the various <div> chunks so that their text overlapped, though in different ways. This was probably in part because, to fit them all on my 17" screen together, I had to make them rather narrow. But I do this routinely, because I always need several windows on the screen at once, and text that's formatted in 100-char lines isn't all that easy to read. (At least the doc doesn't force the page width with a width= attribute.;-)
Internet Explorer was the worst. This was mostly because the backgrounds were all solid, so that overlaps made the covered-up text invisible. The boxed text often had horizontal lines through the text, due to bad line breaking.
Safari was very similar to IE, but the formatting and line breaks were somewhat better. There were still headers messed up by horizontal lines.
Mozilla and Firebird were the best, and nearly identical. This was mostly because the background of everything except the upper-left doubly-boxed text were transparent, so you could at least read nearly all the text. The headers had even more horizontal lines through the text than IE or Safari.
I might test it on my linux box, which has even more browsers. Or maybe I won't bother. I am tempted to take a look with my PDA/cellphone. That's always an amusing test.
Anyway, this is what should be fairly straightforward text with a few images and hyperlinks. If it comes out on the screen so badly with these common browsers, what are the chances of XForm stuff being displayed sensibly? I can see a lot of problems getting all the common browsers to handle XForm data sensibly. Do they have a scheme for preventing the usual Microsoft variant implementation?
Such as the question whether someone having the means for their gravestone to last 300 years would have had better access to healthcare?
Indeed. It's a special case of her general observation that the surviving graveyards are not a random sample of earlier populations.
But then, there is the conventional reply to that, the old observation that until 1900 or so, residents of North America would have been (slightly) better off going to the local native medicine man than to a white doctor. It was only around then that "Western" medicine reached the point that it was significantly better than no treatment at all.
Another related suggestion is that such graveyards would typically be filled with local long-term residents, i.e., mostly property owners. Having a permanent structure to call "home" implies better protection from the elements than the average person might have had.
All of this is seriously lacking in statistically significant data. This should lead to a certain skepticism over claims that human life expectancy has really changed, for the better or for the worse.
But it does remind me that I've seen some tongue-in-cheek "serious" discussions of the concept. The most fun part is defining the "standard human". A brief study shows that, among other things, the standard human would have one breast and one testicle...
You might as well include a link to the T.W.I.N.K.I.E.S. project, or an "Ate My Balls" site.
Hey, you're right! I'd forgotten about those. It might be worth a visit to see if there are any good online collections on those topics.
The dhmo.org site has done a masterful job of collecting all the "information" on the DHMO story. Such things could be considered a valuable addition to our cultural memory.
It's interesting that [the rate of cancer] started to decline in 1991. I wonder what happened then???
A number of things. One of the more interesting here in the US was the ban on EDB (ethylene dibromide) back in 1983. This was a bit of a political fuss at the time, with farmers and commentators using the argument that "scientists hadn't been able to measure the danger" of this compound.
This has turned into a useful textbook example of "spin". I heard an article from NPR (National Public Radio) in which they talked about being curious about the claim, so they tracked down some of the scientists who had attempted to do such measurements. It turned out that they had done the usual tests to measure the concentration that killed 50% of their test animals. They failed. At one part per trillion, the lowest level that they could reliably produce, they lost nearly 100% of the animals. Autopsies showed that the critters died of multiple cancers. They commented that EDB was possibly the most powerful carcinogen yet discovered.
This wasn't exactly new news in 1983. Information on the biological efects of EDB date back to the early 1950's. There's a report online from 1974 that was obviously a preliminary study, of only 93 rats and 94 mice, some treated for only 12 days. The death rate of around 80% in this tiny study was a red flag that triggered further studies. It took another decade before a ban went into effect.
The farmers (or at least the farm-supply companies) really wanted to continue using EDB. Their PR depended on the fact that people would hear "scientists have been unable to measure the danger level" as meaning "EDB is so safe that...", when the proper interpretation was "EDB is so dangerous that...".
Decreasing this one compound in our food supply could well explain the slight decrease in overall cancer rate in the past decade. EDB is rather persistent in the environment, and underground water in a lot of farming areas was contaminated with it. But by the 90's, the concentration was starting to drop, and it's believed to be much lower now.
This story seems to be known in medical and statistical circles. It's generally unknown to the public. I never heard any hint of this part of the story from the mass media, where the story was generally presented as "controversial". The right-wing talk-radio types really publicised this as an example of heavy-handed government over-regulation of The Market. I've wondered occasionally whether the growing rabidity of their opposition to NPR had anything to do with stories like this.
Anyway, if you want a good example of how you can phrase things so that people make exactly the wrong inference, you might remember "scientists have been unable to measure the danger level".
This might be an opportune time to mention the campaign to Do Something about the growing danger posed by dihydrogen monoxide in the environment and in our very bodies.
One of my favorite bits is the reference to "award-winning U.S. scientist Nathan Zohner" who showed that "scientist Nathan Zohner concluded that roughly 86 percent of the population supports a ban on dihydrogen monoxide." This is true.
If you're a/. reader, you should be familiar with this story.
... is that life expectancy has increased tremendously over the past hundred years,
And, of course, this is one of the primary examples in intro statistics courses to explain why you need to know more than just such a sound-bite claim. It turns out that "life expectancy" is generally defined as the mean age at death, and almost all the change has been in eliminating causes of death before age 5. Life expectancy at ages 20 and up haven't changed all that much, despite all the medical advances. There has been a small improvement in advanced countries, mostly due to the elimination of some infectious diseases. OTOH, in some parts of the world, life expectancy past childhood has decreased in the past few decades.
My wife, whose specialy in grad school was medical economics & statistics, likes to invite people to take a stroll through graveyards around here (New England) and note the ages at death. She actually did this for a class, and found that for people who lived past 50, the mean age of death was the same 100, 200 and 300 years ago as it is today. The difference is that there are now very few child graves.
She also had a bit of fun in class by pointing out all the problems with her own "study", such as the question of what portion of the population was buried in graves that still exist. Such problems are rife in every such statistical claim.
For that matter, how does it work with my own email program?
One of the things I couldn't tell from the article was whether the hashing protocol would be published openly. Or would I have to purchase and install proprietary Microsoft software to do it (and whatever else is secretly included in the binary). Would I be sued under the DMCA if I try to reverse engeneer it?
Or maybe my machine just wouldn't be able to send email to anyone using Microsoft software? You'd think that wouldn't be a great loss, but I do have a few friends that use services like hotmail.com, and it'd be annoying to not be able to exchange email with them.
Well, strictly speaking, you're right. Most primates get a small amount of their protein by eating small animals, mostly insects. But this doesn't make them predators. In general, primates get most of their calories from plants, and have few if any adaptations for predation. They're more properly classified as omnivores.
Similarly, cattle and other grazing animals inevitably eat a small quantity of insect, snails, etc that are mixed in with the herbs. But this doesn't make a cow into a predator.
In addition to humans and chimps, there are a number of other primates that actively hunt prey. Baboons come to mind. There's also the fish-eating monkey in southern Asia. All four of these species get a significant amount of protein and calories by eating small animals. But most primate species get maybe 1% of their calories by predation, so they don't really qualify as predators.
I'd guess any wolf that began to have symptoms of such a serious disease would simply starve to death in fairly short order
True. And there's lots of literature supporting the idea that predators and scavengers tend to have very good defenses against the diseases that affect their prey. Part of the defenses are powerful digestive systems that leave few cells intact and chop up most proteins and DNA into small pieces. They also have some of the best immune systems on the planet.
The explanation is fairly simple. If you're a predator or scavenger, you often eat food that was weakened or killed by disease. This puts strong selective pressure on your species in favor of defenses against those diseases.
I've read a couple of articles on the semi-exception that the top predator on the planet (Homo sap) seems to be a partial exception. This is generally explained as an artifact of our recent conversion to predation. We do have some predator adaptations, but we haven't had time to evolve them fully.
There is a bit of debate about this, though. For example, studies of wild chimp populations haved turned up data showing that they actually do get a significant part of their protein by eating small animals. So our predatory ancestry probably goes back at least 5 million years. But still, we are primates, and it wasn't all that long ago that our ancestors were vegetarians.
I think it's ironic that the two things I had to patch most often this year were OpenSSH and OpenSSL.
Well, I'd think that this is a Good Sign. The term "secure" doesn't really mean that no holes exist. That's hardly likely. What it really means is that no holes are known. Or, a hole was just discovered, and we're working furiously to fix it.
The fact that these patches came out really mean that the OpenSS[HL] crowd is 1) actively looking for problems, and 2) fixing them rapidly. In particular, they don't hide the problems behind a shield of secrecy, and they don't collect patches into sets to be released when the PR people decide it's appropriate.
If their patches taper off, it will be time to take a skeptical look, to make sure that people are still actively attacking the OpenSS* code and trying to poke holes. If this process stops, we should worry. If people are still studying and attacking the code, but failing to find holes, we'll know we're in good shape.
But we aren't quite there yet. So the patches are a Good Thing.
> We have over 1000 linux machines at my company and our biggest problem is finding the space to deploy more
Get yourself a mainframe. One cabinet, thousands of linux images.
In my country we have a saying about that. It's called "putting all your eggs in one basket.";-)
This isn't just a joke. From the start of the "desktop computer revolution", the mainframe folks always made an efficiency argument. The purchasing of desktop machines continued. The main explanation was always "We have to get our work done. History shows that we can't rely on the mainframe and the DP department."
The mainframe supporters would invariably point to a record of 99.999% uptime. This would be countered with "Yeah, you were up all last week. But our important job kept dying for incomprehensible reasons, and your people couldn't or wouldn't fix the problems. So from our viewpoint, you were down the whole week. We spent the week moving our jobs to our new desktop machines, and we don't have to beg you for support any more. Bye, bye."
Actually, I forgot to include the appropriate header, so it's only one error!
Good point.
It reminds me of a project some years back that used a compiler that was notorious for going insane when it found the simplest typo, and getting all the error messages wrong from then on. We had an unofficial contest to see who could get the most error messages from a single-char error. I won hands down and ended the contest when I submitted a batch program with a missing comma, which ran through a whole box of paper printing the same error message out over and over and over and over and...
What people really loved was the fact that none of the operations staff caught the error and killed the job before the printer ran out of paper. We kept the stack of paper around as an exhibit for several years.
Nowadays compilers always seem to count the errors and give up when they reach some N. This takes all the fun out of it.
Yeah, and we might also add that in some circumstances, a bubble sort is a very good way to sort data. There's a lot of data around that is normally sorted into just one (usually time) order, and which is also produced in an order very close to that. For such data, "efficient" sorts are usually very inefficient, and a bubble sort can beat them easily.
Most theoretical work on sorting has assumed randomly-sorted input data. That's an important case, sure. But there are many situations where it's not a valid assumption. And a sort that's good on random data is not necessarily very good on non-random data.
...they quantified it by dividing verified defects by lines of code.
If I write a script to go through my C and perl code, and make sure that there's a newline before and after every brace, that will approximately double the lines of code, and will thus cut my error rate in half.
This isn't a joke; I've done this on a couple of projects where they measured output by lines of code, just to illustrate the real impact of such measures.
OTOH, if I deleted the comments from my code, that would approximately double my error rate, so I guess I won't do that.
I'm also reminded of a project that I worked on a while back in which nearly every routine had some sort of error, sometimes several, and I didn't fix any of them. This would look really bad, I know. But you can probably guess what my task was. I was writing a test suite for a compiler. Most of the tests were to verify that the compiler would catch a particular kind of error. So of course my code contained that error, and the test script verified that the result was the proper error message.
This is one of the fundamental problems with nearly every definition I've ever seen of "quality code". They usually don't measure the suitability of the code for the task. If your task is to measure a system's response to failures, you code will of course intentionally produce those errors in order to determine the system's responses. So what is an error in other situations is exactly correct code. Counting errors detected without asking what the task was gives you exactly the wrong results in such a case.
I'm not sure I'd want my name associated with a project that didn't include this sort of test code in the basic distribution. If there are problems with an installation, I want to know about them before the users start using the stuff. And I want to know in a manner that will pinpoint the problems, not from the usual bug report that typically describes some symptom that is only remotely related to the actual problem. So nearly everything that I work on has a component with a high error rate, run under the control of a script that verifies the correctness of thee error messages. If the installation doesn't handle the errors correctly, the users are given output that will tell me what the problem is.
I'd only be impressed by a study that handles such a test suite correctly. One that counts such "errors" is worse than useless; it actively discourages useful test suites.
(Actually, just before reading this/. article, the task I was working on was adding some more tests to a test suite for a package that I'm porting to a number of different systems.)
If they're gonna conquer Texas for its oil, they'd better do it soon. In 200 years, there ain't gonna be any left.
More likely that in 200 years, the Texans will be selling oil to Indians despite the fact that they don't have any to sell. Companies like Haliburton, Harken and Arbusto will still exist then...
Well, yes and no. For example, you might expect the typical manager or politicion to say "I'll never look at the source". But that's not what they say. When you tell them that open software is better because they can study the source, they automatically translate this to "I can hire technical people to study the source". Even a politician or PHB is smart enough to understand that you don't need everyone studying the source; you just need a few of your own people who aren't in the pay of the Other Side.
The reason people trust GNU/Linux more than Windows is because it has a record of better security than Windows.
Yes, of course, but a lot of the reason for this is the ease with which people can work on it independently, without needing permission from the owner. And the GPL encourages (;-) them to share their discoveries and bug fixes with the rest of us, while proprietary software encourages the vendor to file suit if you go public with security holes that you've discovered.
All this is basically just a corollary to the ability to examine the code, and change it if a problem is found.
Slashdot Mirror
The Arpanet came before the net and demanded that all computers that connect to it do so with the same hardware and software.
I was really disappointed to read this in the article. First, it wasn't true. There were a lot of such restrictions in the early implementations, but by the time that TCP was spec'd, there were already cases of interconnected hardware and software from different vendors. TCP was a (pretty good) attempt to codify what had been learned about how to do this.
But more important is the point that such single-source restrictions were exactly why ARPA started funding what became the Internet. It was, to a great extent, a response to ongoing problems with electronic gadgets that couldn't talk to each other. The military (and ARPA was a military research agency) wanted this problem solved. What good were all those fancy-schmancy electronic thingies if they couldn't exchange data?
If you look up the early docs from the ARPAnet, you'll see pretty pictures all over the place showing large numbers of electronic gadgets, obviously from a lot of different manufacturers, with lines between them showing the comm links. It's obvious that interconnecting hardware and software from different vendors was a major goal right from the start.
There have been a number of comments on why ARPA gave their development money to universities rather than to commercial vendors. A number of military types were open about this from the start: They had learned that military contractors simply couldn't be forced to work together. Most attempts to get them to cooperate with data comm were pretty much dismal failures. They were competitors, after all. They would pretend to be cooperating, while doing everything they could to fix things so their competitors couldn't cooperate. This is still a problem, of course, and probably always will be. Commercial vendors sabotaging standards is a very familiar process.
So ARPA took the approach of funding an independent gang of academic hackers. Give them equipment and money to pay students to hack away. Fund a few overseers to attempt to coordinate this herd of cats. When they seem to have something working, buy them some fun new hardware and challenge them to incorporate it with the old stuff. Try not to let them get lazy and develop a monoculture of equipment from a single vendor. Watch what they do, and carry off anything they produce that seems useful.
But the intent from the start was to make all electronic gadgets talk sensibly to each other. If the early setups didn't achieve this, it was simply a case of "We're not there yet". The intent was to get there.
I have to expand the Wired article so that it covers most of my screen to make a single line of text visible without scrolling. You'd think that a geek publication like Wired would know better.
...
I'm getting sick of being forced to resize my browser window for nearly every new page.
Hey, Firebird guys, can you privide an option to disable the width= attribute on all tags? The height= attribute might go, too. Thanks in advance
I don't think I agree. Whether to map two character codes to the same character is a "policy" decision that has no business in the OS kernel. An OS should implement mechanism, not policy.
When you see an OS that forces such things on apps (e.g., OSX), you know that the designers were not good engineers, and didn't understand the difference between policy and mechanism.
Such decisions properly belong in run-time libraries. That way, they aren't forced on all programs, and they can be changed when they're wrong.
One good example is "internationalization", which among other things deals with the character sets of various languages. There are a lot of policy decisions to be made there that have absolutely no business being hard-coded into the OS.
There are cases in the current 8859-* encodings where an upper/lower-case pair in one encoding aren't even letters in another encoding. You don't want to have to reboot to change the mappings for your national alphabet. This is especially true when the language changes in different parts of a document.
Putting case munging into the OS only makes sense if you are building a single-language system. This is true for much US-made software, where much of the computer industry has open contempt for any language other than English. But for the rest of the world, putting case-folding code into the OS is a guaranteed linguistic disaster just waiting to happen.
I've already seen suggestions that this alone is grounds to reject OSX in some parts of the world. And the English-only bias in the Windows file system is one of the ongoing frustrations outside the US, where you often can't even use your native alphabet in an 8+3-char file name.
I propose a rule... unless you own a company that's worth at least $100M, you should keep your suggestions about what MS should do to yourself. It's pointless, ...
Right you are. Microsoft has never needed feedback from mere [l]users, and doesn't need it now. Only important people (and "important" is defined as having no need to ever touch a keyboard because your people take care of that) should ever be listened to when designing new products to be used by unimportant people.
The rest of us should just buy whatever the marketing department decides we need, and we should be grateful to them for providing such benificence.
The Internet name had been used for this existing network for years before Gore ever got involved.
Well, yes and no. The case of the first letter is significant here. The term "internet" was used in the ARPAnet community by the late 70's. But the term "Internet" was consciously introduced in the early 80's with a more precise meaning.
There were a lot of early writings that attempted to make a distinction. An "internet" was more or less what we now call a LAN or an "intranet", a collection of machines using one or more types of comm hardware, with IP used to make them all play nice together. There were (and still are) many "internets". Each may consist of a number of different (hardware) networks, but at the IP level, they can be treated as a single network. The IP protocol intercedes for the software to make the hardware networks interoperate.
The "Internet" was conceived as a top-level internet that connected all of them as a single world-wide network. This was significant not because it needed new technology, but because it was to be a permanent part of the world's communications, not under the control of any single agency or government. The significant innovation here was the idea of a permanent comm system with distributed, cooperating management.
People in academia had talked about this, of course. But by the early 80's, it really hadn't been done. There was a world-wide ARPAnet, yes, and lots of little internets in different organizations. But their interconnections were partial and transitory. I well remember the frustrations of trying to send email from within one company or school to someone in another. At that time, the UUCP email system was often much more reliable, because its store-and-forward approach didn't depend on routing and permanent connections. Even today, with much of the Internet using transient dialup connections, email depends on a store-and-forward scheme, and most home machines and portables can't put things on the web, because they don't have permanent connections. So the Internet with a capital 'I' still hasn't really been fully implemented.
Al Gore rightly deserves a lot of credit for funding development of "the Internet", which happened in the 80's. He can't take much credit for "internet" development, which happened mostly in the 70's.
Of course, if you use an OS that doesn't make case distinctions, you might not understand the difference.
Well, just making it free was not enough. It was important that it was both free AND simple.
/some/file.txt
;-)
Good point. An interesting take that I've seen on this is that what was done with the new HTTP protocol could have been done using FTP, except for one thing: security. HTTP didn't have any, and that made it usable.
To do the same thing with FTP, the client needed to know an id and password. So before you could follow a link to a site, you'd have to first contact them and get the id and password. So a 1-second operation with HTTP would take several days with FTP.
Yes, I know about anonymous FTP. In the late 1980's, this was almost never configured by default. You had to config it yourself, and hardly anyone (even true geeks) could figure out how to do that successfully.
One of the brilliant innovations with web servers was the idea that the server would only deliver files from within its directory heirarchy, and couldn't be tricked into following ".." links. So you could tell people a simple rule: If you want a file to be public, you put it into one of the web server's directories. Anything outside those directories is invisible on the web. Simple, understandable, and fairly idiot proof. The only tricky bit was symlinks, and those are easy to find (or disable in httpd.conf).
The addition of CGI scripts added a qualification to this rule, but that only affected programmers, and they could be expected to understand the issue.
It's just one example of a more general rule that I've seen proposed: Low-level transport mechanisms (IP, highways, etc) shouldn't implement security. They should do only transport, and leave the security to the "content" level. Transport mechanisms that implement security are invariably difficult to use and are restricted to small, specialized uses. And when their security turns out to have a hole, it can't be fixed, due to the difficulty of getting at the low levels, and the near impossibility of getting all commercial systems upgraded together.
But the most elegant explanation of the web's simplicity is:
: telnet foo.bar.com 25
GET
Remember to hit the Return key twice.
(And yes, I do know about the "HTTP/X.Y" field. I even use it sometimes.
No purchase is necessary; you can read the full text online, though I will admit that even I did end up getting the hard copy eventually. The book is small, and paper still has something over HTML, even when viewed on an Apple PowerBook.
I looked at the online text with my PowerBook, too, partly because I have four browsers there. If the result indicates anything about the project, I'd say they aren't quite ready for prime time yet.
All four of them displayed the various <div> chunks so that their text overlapped, though in different ways. This was probably in part because, to fit them all on my 17" screen together, I had to make them rather narrow. But I do this routinely, because I always need several windows on the screen at once, and text that's formatted in 100-char lines isn't all that easy to read. (At least the doc doesn't force the page width with a width= attribute.;-)
Internet Explorer was the worst. This was mostly because the backgrounds were all solid, so that overlaps made the covered-up text invisible. The boxed text often had horizontal lines through the text, due to bad line breaking.
Safari was very similar to IE, but the formatting and line breaks were somewhat better. There were still headers messed up by horizontal lines.
Mozilla and Firebird were the best, and nearly identical. This was mostly because the background of everything except the upper-left doubly-boxed text were transparent, so you could at least read nearly all the text. The headers had even more horizontal lines through the text than IE or Safari.
I might test it on my linux box, which has even more browsers. Or maybe I won't bother. I am tempted to take a look with my PDA/cellphone. That's always an amusing test.
Anyway, this is what should be fairly straightforward text with a few images and hyperlinks. If it comes out on the screen so badly with these common browsers, what are the chances of XForm stuff being displayed sensibly? I can see a lot of problems getting all the common browsers to handle XForm data sensibly. Do they have a scheme for preventing the usual Microsoft variant implementation?
Such as the question whether someone having the means for their gravestone to last 300 years would have had better access to healthcare?
Indeed. It's a special case of her general observation that the surviving graveyards are not a random sample of earlier populations.
But then, there is the conventional reply to that, the old observation that until 1900 or so, residents of North America would have been (slightly) better off going to the local native medicine man than to a white doctor. It was only around then that "Western" medicine reached the point that it was significantly better than no treatment at all.
Another related suggestion is that such graveyards would typically be filled with local long-term residents, i.e., mostly property owners. Having a permanent structure to call "home" implies better protection from the elements than the average person might have had.
All of this is seriously lacking in statistically significant data. This should lead to a certain skepticism over claims that human life expectancy has really changed, for the better or for the worse.
Heh, no. Several others have mentioned this.
...
But it does remind me that I've seen some tongue-in-cheek "serious" discussions of the concept. The most fun part is defining the "standard human". A brief study shows that, among other things, the standard human would have one breast and one testicle
You might as well include a link to the T.W.I.N.K.I.E.S. project, or an "Ate My Balls" site.
Hey, you're right! I'd forgotten about those. It might be worth a visit to see if there are any good online collections on those topics.
The dhmo.org site has done a masterful job of collecting all the "information" on the DHMO story. Such things could be considered a valuable addition to our cultural memory.
Or not.
It's interesting that [the rate of cancer] started to decline in 1991. I wonder what happened then???
...", when the proper interpretation was "EDB is so dangerous that ...".
A number of things. One of the more interesting here in the US was the ban on EDB (ethylene dibromide) back in 1983. This was a bit of a political fuss at the time, with farmers and commentators using the argument that "scientists hadn't been able to measure the danger" of this compound.
This has turned into a useful textbook example of "spin". I heard an article from NPR (National Public Radio) in which they talked about being curious about the claim, so they tracked down some of the scientists who had attempted to do such measurements. It turned out that they had done the usual tests to measure the concentration that killed 50% of their test animals. They failed. At one part per trillion, the lowest level that they could reliably produce, they lost nearly 100% of the animals. Autopsies showed that the critters died of multiple cancers. They commented that EDB was possibly the most powerful carcinogen yet discovered.
This wasn't exactly new news in 1983. Information on the biological efects of EDB date back to the early 1950's. There's a report online from 1974 that was obviously a preliminary study, of only 93 rats and 94 mice, some treated for only 12 days. The death rate of around 80% in this tiny study was a red flag that triggered further studies. It took another decade before a ban went into effect.
The farmers (or at least the farm-supply companies) really wanted to continue using EDB. Their PR depended on the fact that people would hear "scientists have been unable to measure the danger level" as meaning "EDB is so safe that
Decreasing this one compound in our food supply could well explain the slight decrease in overall cancer rate in the past decade. EDB is rather persistent in the environment, and underground water in a lot of farming areas was contaminated with it. But by the 90's, the concentration was starting to drop, and it's believed to be much lower now.
This story seems to be known in medical and statistical circles. It's generally unknown to the public. I never heard any hint of this part of the story from the mass media, where the story was generally presented as "controversial". The right-wing talk-radio types really publicised this as an example of heavy-handed government over-regulation of The Market. I've wondered occasionally whether the growing rabidity of their opposition to NPR had anything to do with stories like this.
Anyway, if you want a good example of how you can phrase things so that people make exactly the wrong inference, you might remember "scientists have been unable to measure the danger level".
This might be an opportune time to mention the campaign to Do Something about the growing danger posed by dihydrogen monoxide in the environment and in our very bodies.
/. reader, you should be familiar with this story.
One of my favorite bits is the reference to "award-winning U.S. scientist Nathan Zohner" who showed that "scientist Nathan Zohner concluded that roughly 86 percent of the population supports a ban on dihydrogen monoxide." This is true.
If you're a
... is that life expectancy has increased tremendously over the past hundred years,
And, of course, this is one of the primary examples in intro statistics courses to explain why you need to know more than just such a sound-bite claim. It turns out that "life expectancy" is generally defined as the mean age at death, and almost all the change has been in eliminating causes of death before age 5. Life expectancy at ages 20 and up haven't changed all that much, despite all the medical advances. There has been a small improvement in advanced countries, mostly due to the elimination of some infectious diseases. OTOH, in some parts of the world, life expectancy past childhood has decreased in the past few decades.
My wife, whose specialy in grad school was medical economics & statistics, likes to invite people to take a stroll through graveyards around here (New England) and note the ages at death. She actually did this for a class, and found that for people who lived past 50, the mean age of death was the same 100, 200 and 300 years ago as it is today. The difference is that there are now very few child graves.
She also had a bit of fun in class by pointing out all the problems with her own "study", such as the question of what portion of the population was buried in graves that still exist. Such problems are rife in every such statistical claim.
For that matter, how does it work with my own email program?
One of the things I couldn't tell from the article was whether the hashing protocol would be published openly. Or would I have to purchase and install proprietary Microsoft software to do it (and whatever else is secretly included in the binary). Would I be sued under the DMCA if I try to reverse engeneer it?
Or maybe my machine just wouldn't be able to send email to anyone using Microsoft software? You'd think that wouldn't be a great loss, but I do have a few friends that use services like hotmail.com, and it'd be annoying to not be able to exchange email with them.
No primates are vegetarians.
Well, strictly speaking, you're right. Most primates get a small amount of their protein by eating small animals, mostly insects. But this doesn't make them predators. In general, primates get most of their calories from plants, and have few if any adaptations for predation. They're more properly classified as omnivores.
Similarly, cattle and other grazing animals inevitably eat a small quantity of insect, snails, etc that are mixed in with the herbs. But this doesn't make a cow into a predator.
In addition to humans and chimps, there are a number of other primates that actively hunt prey. Baboons come to mind. There's also the fish-eating monkey in southern Asia. All four of these species get a significant amount of protein and calories by eating small animals. But most primate species get maybe 1% of their calories by predation, so they don't really qualify as predators.
I'd guess any wolf that began to have symptoms of such a serious disease would simply starve to death in fairly short order
True. And there's lots of literature supporting the idea that predators and scavengers tend to have very good defenses against the diseases that affect their prey. Part of the defenses are powerful digestive systems that leave few cells intact and chop up most proteins and DNA into small pieces. They also have some of the best immune systems on the planet.
The explanation is fairly simple. If you're a predator or scavenger, you often eat food that was weakened or killed by disease. This puts strong selective pressure on your species in favor of defenses against those diseases.
I've read a couple of articles on the semi-exception that the top predator on the planet (Homo sap) seems to be a partial exception. This is generally explained as an artifact of our recent conversion to predation. We do have some predator adaptations, but we haven't had time to evolve them fully.
There is a bit of debate about this, though. For example, studies of wild chimp populations haved turned up data showing that they actually do get a significant part of their protein by eating small animals. So our predatory ancestry probably goes back at least 5 million years. But still, we are primates, and it wasn't all that long ago that our ancestors were vegetarians.
I think it's ironic that the two things I had to patch most often this year were OpenSSH and OpenSSL.
Well, I'd think that this is a Good Sign. The term "secure" doesn't really mean that no holes exist. That's hardly likely. What it really means is that no holes are known. Or, a hole was just discovered, and we're working furiously to fix it.
The fact that these patches came out really mean that the OpenSS[HL] crowd is 1) actively looking for problems, and 2) fixing them rapidly. In particular, they don't hide the problems behind a shield of secrecy, and they don't collect patches into sets to be released when the PR people decide it's appropriate.
If their patches taper off, it will be time to take a skeptical look, to make sure that people are still actively attacking the OpenSS* code and trying to poke holes. If this process stops, we should worry. If people are still studying and attacking the code, but failing to find holes, we'll know we're in good shape.
But we aren't quite there yet. So the patches are a Good Thing.
> We have over 1000 linux machines at my company and our biggest problem is finding the space to deploy more
;-)
Get yourself a mainframe. One cabinet, thousands of linux images.
In my country we have a saying about that. It's called "putting all your eggs in one basket."
This isn't just a joke. From the start of the "desktop computer revolution", the mainframe folks always made an efficiency argument. The purchasing of desktop machines continued. The main explanation was always "We have to get our work done. History shows that we can't rely on the mainframe and the DP department."
The mainframe supporters would invariably point to a record of 99.999% uptime. This would be countered with "Yeah, you were up all last week. But our important job kept dying for incomprehensible reasons, and your people couldn't or wouldn't fix the problems. So from our viewpoint, you were down the whole week. We spent the week moving our jobs to our new desktop machines, and we don't have to beg you for support any more. Bye, bye."
It's a winning argument in many organizations.
Actually, I forgot to include the appropriate header, so it's only one error!
...
Good point.
It reminds me of a project some years back that used a compiler that was notorious for going insane when it found the simplest typo, and getting all the error messages wrong from then on. We had an unofficial contest to see who could get the most error messages from a single-char error. I won hands down and ended the contest when I submitted a batch program with a missing comma, which ran through a whole box of paper printing the same error message out over and over and over and over and
What people really loved was the fact that none of the operations staff caught the error and killed the job before the printer ran out of paper. We kept the stack of paper around as an exhibit for several
years.
Nowadays compilers always seem to count the errors and give up when they reach some N. This takes all the fun out of it.
Yeah, and we might also add that in some circumstances, a bubble sort is a very good way to sort data. There's a lot of data around that is normally sorted into just one (usually time) order, and which is also produced in an order very close to that. For such data, "efficient" sorts are usually very inefficient, and a bubble sort can beat them easily.
Most theoretical work on sorting has assumed randomly-sorted input data. That's an important case, sure. But there are many situations where it's not a valid assumption. And a sort that's good on random data is not necessarily very good on non-random data.
...they quantified it by dividing verified defects by lines of code.
/. article, the task I was working on was adding some more tests to a test suite for a package that I'm porting to a number of different systems.)
If I write a script to go through my C and perl code, and make sure that there's a newline before and after every brace, that will approximately double the lines of code, and will thus cut my error rate in half.
This isn't a joke; I've done this on a couple of projects where they measured output by lines of code, just to illustrate the real impact of such measures.
OTOH, if I deleted the comments from my code, that would approximately double my error rate, so I guess I won't do that.
I'm also reminded of a project that I worked on a while back in which nearly every routine had some sort of error, sometimes several, and I didn't fix any of them. This would look really bad, I know. But you can probably guess what my task was. I was writing a test suite for a compiler. Most of the tests were to verify that the compiler would catch a particular kind of error. So of course my code contained that error, and the test script verified that the result was the proper error message.
This is one of the fundamental problems with nearly every definition I've ever seen of "quality code". They usually don't measure the suitability of the code for the task. If your task is to measure a system's response to failures, you code will of course intentionally produce those errors in order to determine the system's responses. So what is an error in other situations is exactly correct code. Counting errors detected without asking what the task was gives you exactly the wrong results in such a case.
I'm not sure I'd want my name associated with a project that didn't include this sort of test code in the basic distribution. If there are problems with an installation, I want to know about them before the users start using the stuff. And I want to know in a manner that will pinpoint the problems, not from the usual bug report that typically describes some symptom that is only remotely related to the actual problem. So nearly everything that I work on has a component with a high error rate, run under the control of a script that verifies the correctness of thee error messages. If the installation doesn't handle the errors correctly, the users are given output that will tell me what the problem is.
I'd only be impressed by a study that handles such a test suite correctly. One that counts such "errors" is worse than useless; it actively discourages useful test suites.
(Actually, just before reading this
Nah; it only suggests that they've saturated the market.
If they're gonna conquer Texas for its oil, they'd better do it soon. In 200 years, there ain't gonna be any left.
...
;-)
More likely that in 200 years, the Texans will be selling oil to Indians despite the fact that they don't have any to sell. Companies like Haliburton, Harken and Arbusto will still exist then
(Look 'em up.
Umm ... Note that "It's funny. Laugh." at the very start of the story.
/.
In that category, all that shit is quite on-topic. The funniest stuff should be modded up.
And it's definitely geek humor, so it's on topic in
...most user's don't actually look at the source.
Well, yes and no. For example, you might expect the typical manager or politicion to say "I'll never look at the source". But that's not what they say. When you tell them that open software is better because they can study the source, they automatically translate this to "I can hire technical people to study the source". Even a politician or PHB is smart enough to understand that you don't need everyone studying the source; you just need a few of your own people who aren't in the pay of the Other Side.
The reason people trust GNU/Linux more than Windows is because it has a record of better security than Windows.
Yes, of course, but a lot of the reason for this is the ease with which people can work on it independently, without needing permission from the owner. And the GPL encourages (;-) them to share their discoveries and bug fixes with the rest of us, while proprietary software encourages the vendor to file suit if you go public with security holes that you've discovered.
All this is basically just a corollary to the ability to examine the code, and change it if a problem is found.