No, the US isn't problem free, and the Iraq was the stupidest theater of war on record.
Are you sure of that? There's a lot of competition for that title, y'know. Most of the wars in the last couple of decades are serious contenders.
There's yet another one ramping up in the area between Russia and the Black Sea, similar to the American Civil War, but even stupider. In the case of Iraq, Saddam was a seriously evil bastard, with lots of blood on his hands, though of course that didn't come close to justifying what the US did to the Iraqi population (and what Iraqi factions did to each other), so it's pretty far up there on the stupid-meter. But do a bit of reading about the recent history in, say, Rwanda or Kosovo or Cambodia, if you want to see some really over-the-top stupid slaughter of civilian populations for no discernible reason other than the insightful word "theater".
You can also (re-)read Jonathan Swift's tale of Gulliver's Travels, especially the section about the war between the Big-Endians and the Little-Endians, for a good explanation of how such wars get started.
Of course not; that's why they give bribes (uh, I mean campaign contributions) to Congressional candidates (or to their "unaffiliated" support groups) to get the laws passed.
... my professor's computer is not managed by the university, nor is mine. Our data would be OK.
I hope you verified this before posting.;-)
Since a reformat and reinstall was done, the permissions involved were presumably handled at a lower level (BIOS?) than the installed OS. So it could easily have hit any Intel-based machines accessible via the network. Such low-level operations are rarely done by software that understands subtleties like ownership and organizational structures.
It might be interesting to know whether non-Windows and/or non-centrally-managed machines were affected by this event. So far, comments on the topic sound like guesses or conjectures or assumptions based on reasonability; i.e., i
nteresting, but probably not reliable information.
I've often said that you don't fix a software bug until you've fixed the process that allowed the bug to be created. The above quote is of a similar sentiment.
Sounds great! Now just show me a program (more complex than "Hello World") with no bugs.
Of course, it has been occasionally pointed out that the canonical "Hello World" program (from the "C Bible") actually has a bug. Granted, it's not one that you're ever likely to observe in the wild, and good luck writing malware to exploit it. But most programmers, even expert C programmers, can't spot it despite being trivially obvious when pointed out. This is actually a fairly nice example of how difficult it can be to write bug-free software, and I'd wonder if it was done intentionally in that book "with malice aforethought".;-)
ALL CAPS has been optional since 1990, at least. Fortran has had modularisation, structured code since 1990, Classes and object-orientated since 2003. Please update your prejudices.
Reminds me of a quip I heard back in the early 1980s: We don't know what language the scientific community will be using 40 years from now, but we know it'll be called "Fortran".
We might also note that the most common implementations of Fortran are now part of a package that also contains C and several other languages. They all effectively have the same capabilities, because if something isn't "doable" in one language, you can just call a subroutine in a language that makes it easy. The first-level parsers translate into a common internal language, and the modules past that level don't care what the surface syntax was.
I've seen a number of "Fortran" programs that were 90% coded in other languages. But the top-level entry-point routine was in Fortran, so the "program" was in Fortran. I once spoofed this on a project by writing an app "in C", meaning that the entry point was a C main(ac,av) routine, but everything else was in other languages. I actually used all the languages that we had "installed" in the compiler package, including Fortran. This got me tongue-in-cheek accusations of being a major geek show-off.
Dijkstra was right about BASIC, but a lot of us managed to recover.
Yeah, and I ran across part of the explanation in an earlier form that's really similar: In high school, I took several years of German and French. The teachers all commented that most of the students wrote and (occasionally;-) spoke those languages with English word order, and were obviously doing word-at-a-time translation; I was one of the few who quickly adopted non-English phrasing from these languages and sounded more like a native speaker.
It's similarly with software. You can often identify the first programming language of the author of a piece of code, because the code is obviously structured like a "native" Fortran or Basic or whatever program, while using the surface syntax of the project's actual language. But some of us look for interesting new conceptual tools in a new programming language, and concentrate on learning to use them effectively.
Dijkstra's comments were fairly accurate for the large majority who never really learn more than one "native" language, and treat all others as a translation task. Such people will rarely learn any conceptual tools that didn't exist in their first language, and are crippled just as he claimed. A minority of us look for the interesting new things in a new language, and his comments don't much apply to us. And I there's good evidence that Dijkstra was one of us.
OTOH, I've often wished I could use the tools from Lisp or Prolog or Snobol or APL or... in the languages that are in common use now. It's idiotic that we still have to write loops to add two arrays; all languages should implement parallel array operations by now. Similarly, imagine the things you could do in C++ or Java if you could simply resolve an expression. And we had much better parsing tools than Regular Expressions 3 decades ago. (And Cobol even had the "CORResponding" adverb.;-)
But those things didn't exist in Fortran or Basic or Pascal or C, so they'd be inaccessible to most people who had one of those as their first language.
Wow. You do know that terminals and PCs where common in 1983. Great way to make work....
Yeah, outside of government and corporate environments they were becoming common. I think the main point of this story is that in those environments, access to computers was still done via paper, with the DP department's priesthood the only only ones allowed to actually touch the computing equipment.
In 1982, I had some interesting experiences as a computer "consultant" to a big American company that I won't name (because they considered themselves among the highest of high-tech at the time). Their computer was the usual big IBM machine, and the DP people could do a lot of work from terminals. The rest of the company did everything by sending printed pages to DP, where the "keypunch operators" typed the data in (via their terminals, but they still called it keypunching) and fed to batch runs. They were slowly introducing terminals to the rest of the company, because some people had caught onto what was becoming possible. The terminals let a select few access the computer directly, and read the results of their batch runs on their screens. I was part of a small team of programmers brought in to write code that expanded this capability.
One of the things I did that amazed them was to provide a few programs that actually displayed the data from the computer's databases, so they could for the first time actually read the data that the "keypunch operators" had entered, and see the typos that plagued their operations. But what really amazed them was when I showed them how they could edit the data on their screen, hit the Enter key, and the computer's data was modified. This was much faster than printing out reports, marking them up, and sending them back to the keypunch operators. We had to make the method of doing this unobvious, though, because the DP department would have gone insane at the idea of this end-run around their data-entry process. Users were still sending in the original data to the keypunchers, though, until I finally showed them how they could "edit" a non-existent record using the same tool.
A part of this that was more interesting was that when our team wrote new reports for them, we included an extra output file: We looked for redundancies in their data, and wrote code that crossed-check it, with comments on inconsistent data going to the "Dubious Data Report" output. When we showed this to the users, they were at first horrified that it was possible. Then they slowly realized what could be done with our "data display" tools that could also edit the data. They started asking for the runs with the main reports suppressed, and just the dubious-data info printed, which they took to their terminals. When the data was clean, they finally ran the jobs to get the main reports printed.
Some time after I left the project, I was told by one of the guys who stayed longer that eventually the DP people had discovered what we'd given to their users, and they were outraged. But it was too late; their users had learned some of the marvels that their computer was capable of without the intervention of the DP priesthood.
Funny thing was that we'd worked primarily with top management, who were overjoyed with the orders-of-magnitude improvement in their DP operations that we'd achieved. They were actually quite aware of the difficulty of introducing such new technology into their own "high-tech" company. That's why they hired outsiders to do the job that their own DP department wasn't capable of understanding.
From the viewpoint of the general public, we can simplify it to "Programmers are brain damaged." This conclusion is often especially obvious to management, who find programmers both incomprehensible and arrogant. After all, would a truly sane person clearly tell their bosses that something can't be done the way the bosses said it is to be done? But programmers do this all the time, so they must be mentally deranged.
Someone could easily do all their criminal business on a smart phone.
It's far more significant to point out that more and more regular people are doing a lot of their "business" via their smart phone (or tablet or laptop). Banks are seriously pushing electronic payment of bills, for instance. Have you ever paid a bill online? Or have you checked a credit card's balance via your portable gadget? If so, your gadget contains your account login info. That's part of what the police want. With that info, they can impersonate you to your bank or other businesses, drain your account, run up charges on your cards, etc. They can destroy you financially before you can get to another phone and contact your bank and credit-card companies.
This is a much bigger problem to all of us than it is to "criminals". Real-life criminals probably have some idea of the risks, and take steps to limit the damage that the police (or other bureaucratic types) can do to you once they have your electronic gadget. But honest citizens are generally ignorant of this, and fall for the "I don't have anything to hide" lie. We need to explain to them that they do have something to hide: Their financial ID information, which is more and more being stored in everyone's "smart phone".
I have a felling that the cops will win the warrantless search argument
Quite likely. And we might point out that this means they'll have instant warrantless access to all your account information, including your bank accounts, so they'll be easily able to impersonate you and drain your bank accounts.
Let's see a show of hands: How many people here access their bank accounts from their "phones" or other personal computers? Do you pay bills online? Do you check your credit cards' info online? If so, a "warrantless search will give all that access to everyone in the police department.
We should be publicizing this more. It's not just a question of finding "criminals"; it's a question of instant access to all your banking and other financial info to every employee of your friendly local police force.
... No matter what you say, the dog will think you're just about the best thing around and might you please consider rubbing my tummy? Be aware though, this is less effective with human females. Tummy-rubs inexplicably do little to assist the resulting situation.
I've found that back rubs work a lot better with human females. Dunno why, though. Maybe some biologists can explain it.
(Funny thing is that we have had a number of small parrots - cockatiels, conures, etc. - as pets, and the females have all liked back rubs, but the males generally don't. I wonder how widepread this pattern might be in other vertebrate species.;-)
How unlikely is it really, on a cosmic scale, to have a large Luna-like moon and Earth-like axial tilt?
Well, if you start with a list of the list of large (say, over 1000-km diameter) planets and their moons in our solar system, you'd expect such things to be fairly common. All the planets larger than ours have such big, round moons, and little Pluto has one with a 1200-km diameter. Uranus has an extreme axial tilt; all the rest are within 30 degrees of perpendicular to the system's plane. (Venus is a bit odd, though, since it rotates so slowly that it's usually listed as "retrograde", with the south pole pointing nearly north;-).
Of course, all this is effectively a "sample of one" star's planets and moons, so we really do need more data before we start jumping to conclusions.
Astronomers have suggested that, were it not for our moon, we'd have an atmosphere thicker than Venus's. But this really just means that most Earth-like planets will turn out to be somewhat smaller than Earth. They'd also have to be bigger than Mars to keep their atmosphere, so the differences shouldn't turn out to be all that great.
If all you need to be rich is a college degree, then hot damn I'm already rich!
Heh. My first reaction was "If you have to work at all, you're not rich."
The "rich" they're talking about are what most of us call upper-middle class.
I've read several explanations of why most of the US's truly rich pay no income tax. The reason can be summarized by merely observing that little or none of the money they have or receive legally qualifies as "income".
To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild.
One problem with this is that there's already a documented history of companies rejecting bug reports and not paying the bounty, and then some time later include a fix for it in their periodic updates. It's basically the same process that causes a company's "app store" to reject a submitted tool to do a particular job, and then a few months later releasing their own app that does the same thing.
I know a good number of people who've been bitten by the latter, from both MS and Apple. In the case of a bug, it's a lot harder to document that this has happened, but various software guys I know express a strong suspicion that it has been done to them.
It's widely believed that corporations don't have ethics at all, only costs and income, which would easily explain this sort of fraudulent "offers" of rewards with no intent to pay. We've heard here often from lots of people who think that this is right and proper, and that corporations should only be motivated by the bottom line.
When combined with the growing penchant for treating someone who reports a security bug as a criminal "security hacker" and prosecuting people who report bugs in software products, this should reasonably make a sensible developer reluctant to take rewards programs seriously. Given an offer which could get you thanks and some money, or could land you in jail for your efforts, and no way to know beforehand which the company will do, why would you even consider letting them know your name?
(Actually, my name has appeared in numerous companies' lists of honored contributors thanks to my bug reports and patches. But I haven't sent in security-related bug reports to many companies, only to the ones I have reasons to believe I can trust.)
A second and more important fact is that the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code.
"âoeWe developed a product called Safeguard, which automatically tests things like encryption and authentication,â Chartier said. âoeWe started testing the product on our own infrastructure, which uses Open SSL. And thatâ(TM)s how we found the bug.â"
So you're say that when I, as a (professional;-) programmer, create a chunk of code that tests for something, you don't think I should get any credit for what it discovers, because it's the code that discovered it, not me. This pretty much shoots down the value of nearly everything I do, because like most programmers, I spend most of my time writing and running my test suites; the actual product itself usually takes only a small percent of my work time.
Maybe I'm overly arrogant, but I disagree with this. I think that whatever a chunk of code does, the credit (or blame;-) should go to the programmer, not the code or the cpu.
By similar reasoning, we might argue that the "many eyes" never actually discover any bugs at all, because the real work is done by the brain behind the eyes, not the eyes themselves. And with computer bugs, the human brain almost never figures out the bugs; it merely writes code that does appropriate testing, providing the brain with information that it could never have figured out by itself.
This is sorta the inverse of the old saw that guns don't kill people; it's saying that the human that pulled the trigger should get no blame for a killing, because it was the bullet (or maybe the trigger mechanism) that actually did the job.
No, just no. No one with any sort of a clue ever argued these issues cannot happen with Free Software.
No, they haven't made that claim in so many words. But they've sure as hell implied it for years now. That's the whole line of thought that Raymond's statement (quoted in TFS) is based on.
Huh? The quote is "given enough eyeballs, all bugs are shallow." That's a clear admission that open software, like all other software, contains bugs; that's why you want the many eyeballs. Any claim otherwise is a symptom of not understanding plain English. Eric's whole point was that the bugs in open software will be found and fixed faster than the bugs in other software, due to the population of interested people who will study it, looking for the bugs. Nothing in that quote implies (to anyone with reasonable understanding of English and basic logic) that open software doesn't have bugs. I expect Eric would just chuckle at the very idea of software without bugs.
(Actually, someone near him should ask him. Tell us whether he chuckles, or snickers, or just gets a sad look on his face. Or maybe he'll say "Well, there is a conjecture that bug-free software exists, but in has never been observed in the field by reliable observers.";-)
A much more useful conclusion from this story (if you're serious about computer security) is that this bug has been found and fixed in OpenSSL, but with its proprietary competitors, we have no way of knowing what horrible exploits they may be hiding. And you'd be a dummy to think they don't have exploits; every chunk of security-related software has exploits. The meaningful question is whether they can be found and fixed by the people using the software. If not, you'd be a fool to use that software.
Because OpenSSL is such a common tool and is arguably vital to the function of the Internet as we know it, this sort of a bug really is one of those "worst case scenarios"
True, but the main lesson to learn from it can be summarized by the old cliche saying "Don't put all your eggs in one basket". The warning about a "monoculture" also applies here. If one specific piece of software is universally used, even a minor bug in it can be a widespread disaster. If people had any sense, the very fact that something is so popular and widespread would be a strong argument for duplicating its functionality with independently-developed code.
Of course, in reality we humans tend to act like herds of sheep ("sheeple", to coin a term;-), and we tend to think that if everyone is buying X, then X must be a good thing to buy. With software, this is a major failure of logic that should stand out in the current story. If everyone is using X, then all it takes is one exploit to take down everyone's favorite toys.
But history teaches us that, no matter how many times we warn people about a single basket, people in general don't learn.
(Actually, I've long thought that this was a major explanation of why computer geeks tend to have such a wide variety of systems, with different release levels from their neighbors and friends. They're usually not much impressed by popularity. But the geeks are a tiny minority of humanity.)
So far, your post is the only one I've found here that even attempts to talk about the article's actual topic.;-)
The rest of it seems to be various theological and/or political and/or sociological arguments that have nothing whatsoever to do with the Internet's effects on society. I was sorta hoping to find such a discussion, but I guess this crowd isn't up to it these days.
I'd just add that religion has always required "belief", i.e., accepting a particular package of ideas without requiring any evidence, and continuing in a religion requires carefully ignoring any evidence that contradicts it. This hasn't changed with the Internet. It "merely" supplies a lot more evidence (and a lot more disinformation) than any previous communication mechanism we've had. But you can ignore its information exactly like you ignore information from any other source. It's not really all that difficult.
Well, I didn't mention the propaganda on/. because it didn't occur to me that anyone would think it special. The astroturfers and other propagandists have been here since before I had an account, and a lot of their work is so blatant that it's hard to miss. So it's not that the propaganda here didn't occur to me; it's more like I thought it such a cheap shot that I'd be criticized (and possibly downloaded) for wasting reader time by mentioning something so obvious.
Not that there's anything about this that's special to/. either. A growing and well-known problem on sites to attempt to collect ratings of various sorts from users is that companies pay their people to spend time watching such sites and flooding the rating system with bogus positive ratings and reviews. Companies routinely set up hundreds or thousands of accounts for this purpose.
This goes back to the early days of online forums. An especially clumsy one showed up back in the 1980s, when a lot of BBs, newsgroups, etc. found that any occurrence of the string "Armenia" in any message would trigger the automated submission of thousands of bot-generated messages from Turkish extremists, filling up disk systems and making the site useless until they were purged.
The propagandists have gotten a bit more subtle since then, but they've always been with us./. has had them since the early days of 5- and 6-digit id numbers.
And "blase" (only one 's', and the 'e' really should have an acute accent, but/. garbles it;-) isn't really the right word. It's more like we need to acknowledge that propaganda is and will remain "part of the landscape". Rather than get all excited about it, we should be quietly working to limit the junk, and try to find ways to get the real info more visible. Exposing propaganda is most useful if it's done in a matter-of-fact manner, rather than as a shouting match.
So instead of using a meaningless phrase like "critical thinking", why don't you say what you mean? What specific skills should the schools be teaching?
Yeah, that was pretty much my reaction, too.
A more to-the-point approach might be: Any school class described as "science" should include teaching scientific methodology, in a way that's understandable by the students at that grade level. This should include opportunities to apply the methods in situations that the students can understand.
One long-standing problem with the way that most school textbooks do this is by teaching only "the experimental method" as the way that science works. This has been widely criticized by presenting an obvious counter-example: Astronomers have never used experimental methods, but astronomy is generally considered one of the hardest of the "hard sciences" (in both senses of the term "hard';-). This is often used as a primary example explaining why you must teach scientific methods (plural). It's a big, complex subject, and different methods are used in different scientific fields. We can do lab experiments with bacteria or fungi; we can't (yet) with planets or stars.
But the phrase "critical thinking" isn't much used by scientists. Rather, you should try to teach the scientific meanings of terms like "conjecture", "hypothesis", and "theory", which in scientific jargon aren't polysyllabic synonyms for "guess". Figuring out how to produce understanding of such terms would go a long way toward fixing the problems with the way schools teach science these days. It'd also confound the religious folks who dismiss evolution as "just a theory".
Yup. An even better example is the widespread use of fermentation processes, often several of them in the same society. It was generally explained by what are now semi-mystical terms, such as a "living essence" in the fermentation cultures. But, since a culture could be easily divided into many small pieces, which would then take over a new container of the food material, it was obvious to many that the active thingies were simply too small for the human eye to discern.
There were lots of examples of natural processes like this, caused by what we now call micro-organisms, and while some people did consider it ineffable magic, there have always been some that guessed right about the tiny agents at work.
The idea that there could be things that our eye can't quite make out isn't exactly radical. Just watching a small critter fly away shows that, as they slowly become smaller, they eventually disappear. Nobody with any sanity would think they're gone; the explanation is that our eyes just aren't good enough to see them. An obvious guess is that there are such things even smaller, that we can't even see close up.
Slashdot Mirror
No, the US isn't problem free, and the Iraq was the stupidest theater of war on record.
Are you sure of that? There's a lot of competition for that title, y'know. Most of the wars in the last couple of decades are serious contenders.
There's yet another one ramping up in the area between Russia and the Black Sea, similar to the American Civil War, but even stupider. In the case of Iraq, Saddam was a seriously evil bastard, with lots of blood on his hands, though of course that didn't come close to justifying what the US did to the Iraqi population (and what Iraqi factions did to each other), so it's pretty far up there on the stupid-meter. But do a bit of reading about the recent history in, say, Rwanda or Kosovo or Cambodia, if you want to see some really over-the-top stupid slaughter of civilian populations for no discernible reason other than the insightful word "theater".
You can also (re-)read Jonathan Swift's tale of Gulliver's Travels, especially the section about the war between the Big-Endians and the Little-Endians, for a good explanation of how such wars get started.
Congress makes laws. Corporations do not.
Of course not; that's why they give bribes (uh, I mean campaign contributions) to Congressional candidates (or to their "unaffiliated" support groups) to get the laws passed.
By reading this post, you agree to refrain from downmodding this message or any other message that I may post here in the future.
(Lessee ... where's the font-size control here ...)
... my professor's computer is not managed by the university, nor is mine. Our data would be OK.
I hope you verified this before posting. ;-)
Since a reformat and reinstall was done, the permissions involved were presumably handled at a lower level (BIOS?) than the installed OS. So it could easily have hit any Intel-based machines accessible via the network. Such low-level operations are rarely done by software that understands subtleties like ownership and organizational structures.
It might be interesting to know whether non-Windows and/or non-centrally-managed machines were affected by this event. So far, comments on the topic sound like guesses or conjectures or assumptions based on reasonability; i.e., i nteresting, but probably not reliable information.
I've often said that you don't fix a software bug until you've fixed the process that allowed the bug to be created. The above quote is of a similar sentiment. Sounds great! Now just show me a program (more complex than "Hello World") with no bugs.
Of course, it has been occasionally pointed out that the canonical "Hello World" program (from the "C Bible") actually has a bug. Granted, it's not one that you're ever likely to observe in the wild, and good luck writing malware to exploit it. But most programmers, even expert C programmers, can't spot it despite being trivially obvious when pointed out. This is actually a fairly nice example of how difficult it can be to write bug-free software, and I'd wonder if it was done intentionally in that book "with malice aforethought". ;-)
What about for those students who won't read?
There's another good old quip to the effect that people who don't read have no advantage over people who can't read.
But studies have been finding this for the past two decades.
I once heard it summarized as: The classroom lecture approach is the best method yet discovered for teaching people who can't read.
ALL CAPS has been optional since 1990, at least. Fortran has had modularisation, structured code since 1990, Classes and object-orientated since 2003. Please update your prejudices.
Reminds me of a quip I heard back in the early 1980s: We don't know what language the scientific community will be using 40 years from now, but we know it'll be called "Fortran".
We might also note that the most common implementations of Fortran are now part of a package that also contains C and several other languages. They all effectively have the same capabilities, because if something isn't "doable" in one language, you can just call a subroutine in a language that makes it easy. The first-level parsers translate into a common internal language, and the modules past that level don't care what the surface syntax was.
I've seen a number of "Fortran" programs that were 90% coded in other languages. But the top-level entry-point routine was in Fortran, so the "program" was in Fortran. I once spoofed this on a project by writing an app "in C", meaning that the entry point was a C main(ac,av) routine, but everything else was in other languages. I actually used all the languages that we had "installed" in the compiler package, including Fortran. This got me tongue-in-cheek accusations of being a major geek show-off.
It's an interesting conundrum. We can at least try to pass laws to prevent our governments from spying us, ...
While you're at it, you should also pass a law saying that government agencies must obey the laws of your country.
Good luck with that.
Dijkstra was right about BASIC, but a lot of us managed to recover.
Yeah, and I ran across part of the explanation in an earlier form that's really similar: In high school, I took several years of German and French. The teachers all commented that most of the students wrote and (occasionally;-) spoke those languages with English word order, and were obviously doing word-at-a-time translation; I was one of the few who quickly adopted non-English phrasing from these languages and sounded more like a native speaker.
It's similarly with software. You can often identify the first programming language of the author of a piece of code, because the code is obviously structured like a "native" Fortran or Basic or whatever program, while using the surface syntax of the project's actual language. But some of us look for interesting new conceptual tools in a new programming language, and concentrate on learning to use them effectively.
Dijkstra's comments were fairly accurate for the large majority who never really learn more than one "native" language, and treat all others as a translation task. Such people will rarely learn any conceptual tools that didn't exist in their first language, and are crippled just as he claimed. A minority of us look for the interesting new things in a new language, and his comments don't much apply to us. And I there's good evidence that Dijkstra was one of us.
OTOH, I've often wished I could use the tools from Lisp or Prolog or Snobol or APL or ... in the languages that are in common use now. It's idiotic that we still have to write loops to add two arrays; all languages should implement parallel array operations by now. Similarly, imagine the things you could do in C++ or Java if you could simply resolve an expression. And we had much better parsing tools than Regular Expressions 3 decades ago. (And Cobol even had the "CORResponding" adverb. ;-)
But those things didn't exist in Fortran or Basic or Pascal or C, so they'd be inaccessible to most people who had one of those as their first language.
Wow. You do know that terminals and PCs where common in 1983. Great way to make work. ...
Yeah, outside of government and corporate environments they were becoming common. I think the main point of this story is that in those environments, access to computers was still done via paper, with the DP department's priesthood the only only ones allowed to actually touch the computing equipment.
In 1982, I had some interesting experiences as a computer "consultant" to a big American company that I won't name (because they considered themselves among the highest of high-tech at the time). Their computer was the usual big IBM machine, and the DP people could do a lot of work from terminals. The rest of the company did everything by sending printed pages to DP, where the "keypunch operators" typed the data in (via their terminals, but they still called it keypunching) and fed to batch runs. They were slowly introducing terminals to the rest of the company, because some people had caught onto what was becoming possible. The terminals let a select few access the computer directly, and read the results of their batch runs on their screens. I was part of a small team of programmers brought in to write code that expanded this capability.
One of the things I did that amazed them was to provide a few programs that actually displayed the data from the computer's databases, so they could for the first time actually read the data that the "keypunch operators" had entered, and see the typos that plagued their operations. But what really amazed them was when I showed them how they could edit the data on their screen, hit the Enter key, and the computer's data was modified. This was much faster than printing out reports, marking them up, and sending them back to the keypunch operators. We had to make the method of doing this unobvious, though, because the DP department would have gone insane at the idea of this end-run around their data-entry process. Users were still sending in the original data to the keypunchers, though, until I finally showed them how they could "edit" a non-existent record using the same tool.
A part of this that was more interesting was that when our team wrote new reports for them, we included an extra output file: We looked for redundancies in their data, and wrote code that crossed-check it, with comments on inconsistent data going to the "Dubious Data Report" output. When we showed this to the users, they were at first horrified that it was possible. Then they slowly realized what could be done with our "data display" tools that could also edit the data. They started asking for the runs with the main reports suppressed, and just the dubious-data info printed, which they took to their terminals. When the data was clean, they finally ran the jobs to get the main reports printed.
Some time after I left the project, I was told by one of the guys who stayed longer that eventually the DP people had discovered what we'd given to their users, and they were outraged. But it was too late; their users had learned some of the marvels that their computer was capable of without the intervention of the DP priesthood.
Funny thing was that we'd worked primarily with top management, who were overjoyed with the orders-of-magnitude improvement in their DP operations that we'd achieved. They were actually quite aware of the difficulty of introducing such new technology into their own "high-tech" company. That's why they hired outsiders to do the job that their own DP department wasn't capable of understanding.
... C programmers are brain damaged too.
From the viewpoint of the general public, we can simplify it to "Programmers are brain damaged." This conclusion is often especially obvious to management, who find programmers both incomprehensible and arrogant. After all, would a truly sane person clearly tell their bosses that something can't be done the way the bosses said it is to be done? But programmers do this all the time, so they must be mentally deranged.
Someone could easily do all their criminal business on a smart phone.
It's far more significant to point out that more and more regular people are doing a lot of their "business" via their smart phone (or tablet or laptop). Banks are seriously pushing electronic payment of bills, for instance. Have you ever paid a bill online? Or have you checked a credit card's balance via your portable gadget? If so, your gadget contains your account login info. That's part of what the police want. With that info, they can impersonate you to your bank or other businesses, drain your account, run up charges on your cards, etc. They can destroy you financially before you can get to another phone and contact your bank and credit-card companies.
This is a much bigger problem to all of us than it is to "criminals". Real-life criminals probably have some idea of the risks, and take steps to limit the damage that the police (or other bureaucratic types) can do to you once they have your electronic gadget. But honest citizens are generally ignorant of this, and fall for the "I don't have anything to hide" lie. We need to explain to them that they do have something to hide: Their financial ID information, which is more and more being stored in everyone's "smart phone".
I have a felling that the cops will win the warrantless search argument
Quite likely. And we might point out that this means they'll have instant warrantless access to all your account information, including your bank accounts, so they'll be easily able to impersonate you and drain your bank accounts.
Let's see a show of hands: How many people here access their bank accounts from their "phones" or other personal computers? Do you pay bills online? Do you check your credit cards' info online? If so, a "warrantless search will give all that access to everyone in the police department.
We should be publicizing this more. It's not just a question of finding "criminals"; it's a question of instant access to all your banking and other financial info to every employee of your friendly local police force.
... No matter what you say, the dog will think you're just about the best thing around and might you please consider rubbing my tummy? Be aware though, this is less effective with human females. Tummy-rubs inexplicably do little to assist the resulting situation.
I've found that back rubs work a lot better with human females. Dunno why, though. Maybe some biologists can explain it.
(Funny thing is that we have had a number of small parrots - cockatiels, conures, etc. - as pets, and the females have all liked back rubs, but the males generally don't. I wonder how widepread this pattern might be in other vertebrate species. ;-)
How unlikely is it really, on a cosmic scale, to have a large Luna-like moon and Earth-like axial tilt?
Well, if you start with a list of the list of large (say, over 1000-km diameter) planets and their moons in our solar system, you'd expect such things to be fairly common. All the planets larger than ours have such big, round moons, and little Pluto has one with a 1200-km diameter. Uranus has an extreme axial tilt; all the rest are within 30 degrees of perpendicular to the system's plane. (Venus is a bit odd, though, since it rotates so slowly that it's usually listed as "retrograde", with the south pole pointing nearly north ;-).
Of course, all this is effectively a "sample of one" star's planets and moons, so we really do need more data before we start jumping to conclusions.
Astronomers have suggested that, were it not for our moon, we'd have an atmosphere thicker than Venus's. But this really just means that most Earth-like planets will turn out to be somewhat smaller than Earth. They'd also have to be bigger than Mars to keep their atmosphere, so the differences shouldn't turn out to be all that great.
If all you need to be rich is a college degree, then hot damn I'm already rich!
Heh. My first reaction was "If you have to work at all, you're not rich."
The "rich" they're talking about are what most of us call upper-middle class.
I've read several explanations of why most of the US's truly rich pay no income tax. The reason can be summarized by merely observing that little or none of the money they have or receive legally qualifies as "income".
To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild.
One problem with this is that there's already a documented history of companies rejecting bug reports and not paying the bounty, and then some time later include a fix for it in their periodic updates. It's basically the same process that causes a company's "app store" to reject a submitted tool to do a particular job, and then a few months later releasing their own app that does the same thing.
I know a good number of people who've been bitten by the latter, from both MS and Apple. In the case of a bug, it's a lot harder to document that this has happened, but various software guys I know express a strong suspicion that it has been done to them.
It's widely believed that corporations don't have ethics at all, only costs and income, which would easily explain this sort of fraudulent "offers" of rewards with no intent to pay. We've heard here often from lots of people who think that this is right and proper, and that corporations should only be motivated by the bottom line.
When combined with the growing penchant for treating someone who reports a security bug as a criminal "security hacker" and prosecuting people who report bugs in software products, this should reasonably make a sensible developer reluctant to take rewards programs seriously. Given an offer which could get you thanks and some money, or could land you in jail for your efforts, and no way to know beforehand which the company will do, why would you even consider letting them know your name?
(Actually, my name has appeared in numerous companies' lists of honored contributors thanks to my bug reports and patches. But I haven't sent in security-related bug reports to many companies, only to the ones I have reasons to believe I can trust.)
A second and more important fact is that the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code. "âoeWe developed a product called Safeguard, which automatically tests things like encryption and authentication,â Chartier said. âoeWe started testing the product on our own infrastructure, which uses Open SSL. And thatâ(TM)s how we found the bug.â"
So you're say that when I, as a (professional ;-) programmer, create a chunk of code that tests for something, you don't think I should get any credit for what it discovers, because it's the code that discovered it, not me. This pretty much shoots down the value of nearly everything I do, because like most programmers, I spend most of my time writing and running my test suites; the actual product itself usually takes only a small percent of my work time.
Maybe I'm overly arrogant, but I disagree with this. I think that whatever a chunk of code does, the credit (or blame ;-) should go to the programmer, not the code or the cpu.
By similar reasoning, we might argue that the "many eyes" never actually discover any bugs at all, because the real work is done by the brain behind the eyes, not the eyes themselves. And with computer bugs, the human brain almost never figures out the bugs; it merely writes code that does appropriate testing, providing the brain with information that it could never have figured out by itself.
This is sorta the inverse of the old saw that guns don't kill people; it's saying that the human that pulled the trigger should get no blame for a killing, because it was the bullet (or maybe the trigger mechanism) that actually did the job.
No, just no. No one with any sort of a clue ever argued these issues cannot happen with Free Software.
No, they haven't made that claim in so many words. But they've sure as hell implied it for years now. That's the whole line of thought that Raymond's statement (quoted in TFS) is based on.
Huh? The quote is "given enough eyeballs, all bugs are shallow." That's a clear admission that open software, like all other software, contains bugs; that's why you want the many eyeballs. Any claim otherwise is a symptom of not understanding plain English. Eric's whole point was that the bugs in open software will be found and fixed faster than the bugs in other software, due to the population of interested people who will study it, looking for the bugs. Nothing in that quote implies (to anyone with reasonable understanding of English and basic logic) that open software doesn't have bugs. I expect Eric would just chuckle at the very idea of software without bugs.
(Actually, someone near him should ask him. Tell us whether he chuckles, or snickers, or just gets a sad look on his face. Or maybe he'll say "Well, there is a conjecture that bug-free software exists, but in has never been observed in the field by reliable observers." ;-)
A much more useful conclusion from this story (if you're serious about computer security) is that this bug has been found and fixed in OpenSSL, but with its proprietary competitors, we have no way of knowing what horrible exploits they may be hiding. And you'd be a dummy to think they don't have exploits; every chunk of security-related software has exploits. The meaningful question is whether they can be found and fixed by the people using the software. If not, you'd be a fool to use that software.
Because OpenSSL is such a common tool and is arguably vital to the function of the Internet as we know it, this sort of a bug really is one of those "worst case scenarios"
True, but the main lesson to learn from it can be summarized by the old cliche saying "Don't put all your eggs in one basket". The warning about a "monoculture" also applies here. If one specific piece of software is universally used, even a minor bug in it can be a widespread disaster. If people had any sense, the very fact that something is so popular and widespread would be a strong argument for duplicating its functionality with independently-developed code.
Of course, in reality we humans tend to act like herds of sheep ("sheeple", to coin a term ;-), and we tend to think that if everyone is buying X, then X must be a good thing to buy. With software, this is a major failure of logic that should stand out in the current story. If everyone is using X, then all it takes is one exploit to take down everyone's favorite toys.
But history teaches us that, no matter how many times we warn people about a single basket, people in general don't learn.
(Actually, I've long thought that this was a major explanation of why computer geeks tend to have such a wide variety of systems, with different release levels from their neighbors and friends. They're usually not much impressed by popularity. But the geeks are a tiny minority of humanity.)
The internet isn't "taking away" anything. ...
So far, your post is the only one I've found here that even attempts to talk about the article's actual topic. ;-)
The rest of it seems to be various theological and/or political and/or sociological arguments that have nothing whatsoever to do with the Internet's effects on society. I was sorta hoping to find such a discussion, but I guess this crowd isn't up to it these days.
I'd just add that religion has always required "belief", i.e., accepting a particular package of ideas without requiring any evidence, and continuing in a religion requires carefully ignoring any evidence that contradicts it. This hasn't changed with the Internet. It "merely" supplies a lot more evidence (and a lot more disinformation) than any previous communication mechanism we've had. But you can ignore its information exactly like you ignore information from any other source. It's not really all that difficult.
Well, I didn't mention the propaganda on /. because it didn't occur to me that anyone would think it special. The astroturfers and other propagandists have been here since before I had an account, and a lot of their work is so blatant that it's hard to miss. So it's not that the propaganda here didn't occur to me; it's more like I thought it such a cheap shot that I'd be criticized (and possibly downloaded) for wasting reader time by mentioning something so obvious.
Not that there's anything about this that's special to /. either. A growing and well-known problem on sites to attempt to collect ratings of various sorts from users is that companies pay their people to spend time watching such sites and flooding the rating system with bogus positive ratings and reviews. Companies routinely set up hundreds or thousands of accounts for this purpose.
This goes back to the early days of online forums. An especially clumsy one showed up back in the 1980s, when a lot of BBs, newsgroups, etc. found that any occurrence of the string "Armenia" in any message would trigger the automated submission of thousands of bot-generated messages from Turkish extremists, filling up disk systems and making the site useless until they were purged.
The propagandists have gotten a bit more subtle since then, but they've always been with us. /. has had them since the early days of 5- and 6-digit id numbers.
And "blase" (only one 's', and the 'e' really should have an acute accent, but /. garbles it ;-) isn't really the right word. It's more like we need to acknowledge that propaganda is and will remain "part of the landscape". Rather than get all excited about it, we should be quietly working to limit the junk, and try to find ways to get the real info more visible. Exposing propaganda is most useful if it's done in a matter-of-fact manner, rather than as a shouting match.
So instead of using a meaningless phrase like "critical thinking", why don't you say what you mean? What specific skills should the schools be teaching?
Yeah, that was pretty much my reaction, too.
A more to-the-point approach might be: Any school class described as "science" should include teaching scientific methodology, in a way that's understandable by the students at that grade level. This should include opportunities to apply the methods in situations that the students can understand.
One long-standing problem with the way that most school textbooks do this is by teaching only "the experimental method" as the way that science works. This has been widely criticized by presenting an obvious counter-example: Astronomers have never used experimental methods, but astronomy is generally considered one of the hardest of the "hard sciences" (in both senses of the term "hard' ;-). This is often used as a primary example explaining why you must teach scientific methods (plural). It's a big, complex subject, and different methods are used in different scientific fields. We can do lab experiments with bacteria or fungi; we can't (yet) with planets or stars.
But the phrase "critical thinking" isn't much used by scientists. Rather, you should try to teach the scientific meanings of terms like "conjecture", "hypothesis", and "theory", which in scientific jargon aren't polysyllabic synonyms for "guess". Figuring out how to produce understanding of such terms would go a long way toward fixing the problems with the way schools teach science these days. It'd also confound the religious folks who dismiss evolution as "just a theory".
Yup. An even better example is the widespread use of fermentation processes, often several of them in the same society. It was generally explained by what are now semi-mystical terms, such as a "living essence" in the fermentation cultures. But, since a culture could be easily divided into many small pieces, which would then take over a new container of the food material, it was obvious to many that the active thingies were simply too small for the human eye to discern.
There were lots of examples of natural processes like this, caused by what we now call micro-organisms, and while some people did consider it ineffable magic, there have always been some that guessed right about the tiny agents at work.
The idea that there could be things that our eye can't quite make out isn't exactly radical. Just watching a small critter fly away shows that, as they slowly become smaller, they eventually disappear. Nobody with any sanity would think they're gone; the explanation is that our eyes just aren't good enough to see them. An obvious guess is that there are such things even smaller, that we can't even see close up.