Slashdot Mirror

Not since the fence--which allowed the human race to change from wandering predatory animals to stable civilizations--has a tool ever had the potential to change things the way computer have.

The fence is more about "property" and marking divisions between people than it is about domesticating animals. Animal husbandry does not in and of itself require fences. The neolithic revolution owes more to cultivation of plants than it does to anything else. Horticulture precedes and feeds the growth in population that makes structures like fences feasible and worthwhile. Here is a concise chronology of a Neolithic site in Jordan.

Oh, and as for the predatory ways of our ancestors, that's pretty much debunked and debunked and just plain abandoned in favor of more scientific, less sexist views of early humans.

Stone tools, fire, language, agriculture, writing, the computer?--What about the cotton jinny? Where does the cotton jinny fit in? I'm all for having computers in schools and having kids learn to do programming, but I am also wary of hype.

> I remember almost a decade ago, there was a rash of mysterious deaths in the UK of top programmers working on top secret military projects.

To be precise, a total of 20 programers linked to Marconi Defense Systems or the Ministry of Defense died suspiciously between 1985-1987.

The first mainstream magazine to break this story was the April 30th 1987 edition of Computer News (UK), but unfortunately the article does not seem to be available online.

However, it gets a mention in the Risks Digest, as well as plenty of conspiracy sites such as this one.

Yes, crashing planes and scuds hitting army barracks are funny, but patients losing their lives is not.

Make reading the ACM's RISKS digest a part of your regular routine, and you'll hear about these kind of software-related problems and many others - usually shortly after they happen. The RISKS digest is available on Usenet as comp.risks, as a mailing list, and on the WWW at http://catless.ncl.ac.uk/Risks. A new issue is published on a semiregular basis, every one to two weeks. It's not only informative but interesting too.

--Jim

But there is plenty of prior art, and they even adminit it: the fruit fly...

And yeah, it seems pretty obvious to me too. But some people are married to the top-down, centralized approach I guess...

The naysayers may actually be right... Indeed, stability of such an adaptive system could be an issue. What happens if conditions are such that suddenly the systems decides to oscillate between two meta-stable states, dropping calls at each flip? Could mischievous network users actually deliberately cause such a situation to happen (by gathering enough friens with mobile phones, and driving around the country in certain well-crafted pattern -- remember one of the variables of the system is phones per cell)? Weren't there some problems with similarly adaptive systems in the early ninetys on landline switches in the US, where one switch after the other keeled over like dominos, all triggered by a trivial malfunction on just one switch?

Typically campus police are the worst of the police force and have authority issues.

And are there any who know anything about computers? Maybe nowadays there are. Here is a horror story about campus cops and computers from 1990. Risks of posting warnings with the wrong time or date.

Here is the short version: The real police received a bomb threat to the campus. The decision was made to clear the campus. It took hours. There was a lot of confusion, and rumours. About one hundred messages were posted to the local campus newsgroups.

After the incident someone printed them all out for the campus police. One sharp-eyed campus cop saw that one of the messages appeared to be posted prior to the call to 911, and the author of that message became their prime suspect...

See this link for the generally accepted historical view.

Does open source softawre work? Shouldn't the question be "does software really work"?

Microsoft's bugs and failure are well known here. Spend some time reading the RISKS Forum and see how low the quality of software in general is.

I work on an AIX platform. We've been going crazy the past few weeks trying to track down memory leaks in our software - turns out that there were leaks inside both AIX and DB2.

At least with open source and free software, when it breaks you get to keep the pieces and try to glue them back together. With proprietary software, trying that will probably run you afoul of somebody's imaginary^H^H^H^H^H^H^H^H^Hintellectual property rights.

I guess it's this

dylan_-

Sterno [is] warmed over a fire of newspapers preparatory to squeezing it through a sock to make a drink called "Pink Lady."

As an aside, the alcoholic 67-year old survivor of The Andromeda Strain had a penchant for strained Sterno - causing the acidosis that spared him from the (fictional) pestilence.

Crighton's character explained the process of deriving potable hooch from the magenta glob, and referred to the product as 'squeeze.'

Aww!

Wrong. Poor system could pose a threat to public health. If there were an info-terror war for example. Safety and security can never be wholly divided. You want to see examples of software safety/security issues? Read through the Risks Digest. The problem is that computing security is taken TOO lightly and is too often put in the hands of those who should not be incharge of any aspect of it.

Sorry for not making a huge long rambling post, but you really should check out the Risks Digest

--xPhase

I believe that all ms document files store the actual text as printable characters. So, since strings skips everything but printable characters you can see what they wrote.

In fact you (used to|still can) see stuff they wrote they didn't intend to send you! Microsoft left a bug in word. Word used to store not only what you finally decide you want to print out, but it saved recent changes, in the document, across saves.

Word "fast save" bug

Or here is another bug.
Word transmitted hidden summaries

I believe that all ms document files store the actual text as printable characters. So, since strings skips everything but printable characters you can see what they wrote.

In fact you (used to|still can) see stuff they wrote they didn't intend to send you! Microsoft left a bug in word. Word used to store not only what you finally decide you want to print out, but it saved recent changes, in the document, across saves.

Word "fast save" bug

Or here is another bug.
Word transmitted hidden summaries

That's interesting, look further down the page, and there's Possibility of a Warhol Worm: Complete infection in 15 minutes! from August 2001.

According to RISKS Digest, someone went along to watch a friend getting laser eye surgery & noticed (a) the technician was blindly hitting RETURN to clear pesky annoying error messages, and (b) the machine was running Win95. Oh, and this machine was taking the details of the subject's eye geometry, & controlling the laser that was about to shave a thing slice off the front of the eyeball to correct some minor astigmatism (IIRC; don't have the url to hand, anyone? )

A quick Google search for "risks digest eye surgery" yields this link. Pretty frightening stuff, and it does show how well many users have become trained to treat error conditions as part of the normal behavior of computer operating systems and applications.

You're confusing preemption with mutual exclusion. Being preemptible only means you can be suspended. It does not mean the task that someone gets to break your locks.

If a low-priority task locks a resource, it can still be preempted by a high-priority task... but if the high-priority task also wants that resource, it's going to have to get in line just like everyone else. This is also what leads to the possibility of priority inversion.

Nothing changes if you substitute "kernel task" for "task" in the preceding paragraph.

--
I like canned peaches.

The problem is that even "safe" Java has had security problems. Not relating to the language itself necessarily, but relating to browser/platform implementations.

See the Risks Digest:

17.39

17.83

18.18

and there are many more listed in the archives.

So until the languge/CLR mature enough, then there will be more problems with an insecure language.

Also, note that most early Java security problems were found because sun encouraged people to find them, and then Sun would fix the problems. Microsoft doesn't want people to find and disclose bugs in it's software, so it may take longer to mature security wise.

--xPhase
P.S. pardon any spelling errors, i'm tired.

The problem is that even "safe" Java has had security problems. Not relating to the language itself necessarily, but relating to browser/platform implementations.

See the Risks Digest:

17.39

17.83

18.18

and there are many more listed in the archives.

So until the languge/CLR mature enough, then there will be more problems with an insecure language.

Also, note that most early Java security problems were found because sun encouraged people to find them, and then Sun would fix the problems. Microsoft doesn't want people to find and disclose bugs in it's software, so it may take longer to mature security wise.

--xPhase
P.S. pardon any spelling errors, i'm tired.

The problem is that even "safe" Java has had security problems. Not relating to the language itself necessarily, but relating to browser/platform implementations.

See the Risks Digest:

17.39

17.83

18.18

and there are many more listed in the archives.

So until the languge/CLR mature enough, then there will be more problems with an insecure language.

Also, note that most early Java security problems were found because sun encouraged people to find them, and then Sun would fix the problems. Microsoft doesn't want people to find and disclose bugs in it's software, so it may take longer to mature security wise.

--xPhase
P.S. pardon any spelling errors, i'm tired.

From the article:
[the] GuideStar controls could be programmed to prevent any airplane from ever going someplace it should not ... The coordinates of restricted areas and important buildings could be entered into the new guidance system, which could thwart a pilot's

I've read about this panacea repeatedly since 9/11. The existence of an irrevocable fly-by-wire lockout mode such as this gives hijackers a new physical location (the control room) or software/protocol system to target. I believe the Risks inherent here are great.

Having trained, experienced humans local and ready to override compromised Guidestar-like devices is crucial. The 9/11 hijackers gained easy access to a plane's most valuable assets -- pilots in the cockpit -- due to a lack of Sky Marshals, security doors, and cameras. That was a tragic case of cost cutting by the airlines.

I'd hate to think that similar cost cutting measures could lead to adoption of this automatic flying device with an intention to deskill or replace pilots. The implementation of such a device requires careful human factor analysis. Perhaps a periodic, probabilistically triggered interrogation of pilot credentials (created for one-time-use during a single flight) according to flying patterns and location?

The RISKS forum already documents everyday, practical examples of technical failures and their consequences. Take a look.

While a fun idea, it's not possible. The main reason for the old technology is that only approved(by the government) systems can be used.

There is plenty of innovation going on, it just isn't talked about a large amount outside of the contractor's circles.

The primary reason for the "rigid and structured environment" is because that environment is necessary to produce quality Safety Critical and Security Critical systems.

If you look through the Risks archive you can see examples of why this is necessary.

Ever heard of the unix based scripts that brought down ESPN and USA today, just to vote for the best college mascot or band (Stanford and Michigan, respectively) with ballot stuffing goodness.

Microsoft (and friends) have taken a long time but they have basically trained the average computer user to expect and accept computer crashes - instead of going back to the store and demanding a refund for a defective product!

This can be both good and bad. Maybe less people will rely on non-fault-tolerant systems for ultra-important issues like emergency/military/banking?

Or maybe people will get desensitized to the crashing. Programmer's don't need to fully test their products anymore since people accept the crashes. People just go along thinking that it is the normal way, wreaking havoc in the world with a simple blue screen on a computer that had no business being in a critical system.

read The Risks Digest for scary stories.

--jeff

Time is an issue we rarely incorporate in our designs.

Excellent point. For exmaple, there's growing concern over data stored on "dead media"; enve stuff on readable media can be rendered useless by outdated proprietary file formats.

Some people joked about the Y10k problem a while back, but I think its quite possible that within the next century we'll be building systems with a mission lifetime of thousands of years.

Some of the details about the hijacking of HBO by breaking a communications satellite by John R. MacDougall (who had the night shift at a satellite transmission center with the required equipment) can be found at:

http://catless.ncl.ac.uk/Risks/3.24.html#subj3

This was done in 1986, and MacDougall transmitted a few messages and a test pattern over HBO interrupting normal programming. It seems likely to me he just transmitted video on HBO's frequency, so this probably wasn't a command and control hack.

--Braddock Gaskill

First, the "WiReD" article confuses worm - a program or process that propagates itself to a different computer, usually via some networking protocol, and chainmail - an email message that requires human intervention to automatically send out more email messages, usually containing the same or slightly evolved chainmail. WiReD should straighten up its vocabulary on this issue, they do no service to anyone confusing the two.

Second, the techniques used by both chainmail and worms are all used by legitimate scripts, programs and emails. How does law enforcement propose to declare one email message a crime, and another legitimate? And I don't mean "Let's ask some expert like Graham Cluely."

Sure an IIS worm like Code Red usually uses some initial exploit, like overflowing a buffer in an IIS module or service or plug-in or whatever the MSFT lingo is, but Nimda used a variety of techniques built in to IIS, "shares" and Outlook. The variety of Outlook worms (Anna Kournikova, Nude Housewife, etc etc) and even the CHRISTMA EXE chainmail of 1987 used entirely legitimate techniques built in to Outlook and other email viewers. The 1988 Internet Worm used both legitimate techniques (BSD "r" commands that didn't require a password) and exploits like "fingerd" buffer overflows. How do we define the crime - "I didn't authorize this use of Outlook" really doesn't amount to a way to decide whether or not a particular program committed a crime. Similary, worms like x.c get telnet servers to crash in particular ways when they spread. Gee whiz, a network server process crashes! That's news, for sure. I guess that hasn't happened to me since yesterday. How do we make one instance of a crashed program a crime, and another instance into a bug report?

Yeah, the sendmail worm didn't even require user intervention.

The sendmail worm wasn't an e-mail virus. It used an exploit in the sendmail daemon as did it use an exploit in the finger daemon. rsh/rexec daemon, and performed password hacking. Whether someone read their e-mail was irrelevant to the worms spread. It was only until Mircosoft came along that we were introduced to auto-executing e-mail payloads that went off when someone read their e-mail.

What are you talking about? These look black-and-white to me!!!

What are you talking about? These look black-and-white to me!!!

What are you talking about? These look black-and-white to me!!!

Interesting. I'm still in favor of redundancy, though, at least in the data center. Sure, two power supplies means twice as many power supply failures, and twice as much power supply maintenance, but a single power supply failure doesn't result in a "catastrophic" system outage. And unless you're twice as unlucky[1], the chances of two power supplies failing at once are less than the chances of one power supply failing at once.

As long as either of the two engines can keep the craft airborne (e.g., the Fairchild A-10 [nandotimes.com]), I'd imagine the same "n points of failure" principle would apply to skycars as well.

Consider two aircraft. One has two engines, and either engine is capable of sustaining flight independently. The other has three engines, and requires two to stay airborne. The odds of two engines failing simultaneously on the three engine aircraft are much higher than the odds of both engines on the twin-engine aircraft failing. (See RISKS 8.16) The odds of an engine failing on a single-engine aircraft are even lower, but if it happens, the aircraft is making an unscheduled landing.

With eight engines, and a minimum of four (one in each of four nacelles) needed to keep a SkyCar airborne, and having so many means that the odds of one failing is increased greatly. I doubt the FAA is going to knowingly let anybody fly one of these things around with an engine or two non-functional.

Having eight engines also increases the cost and complexity of maintenance, which increases one of the biggest risk factors for catastrophic failure: improper maintenance. If one engine fails due to poor maintenance, the odds of the other engines failing due to the same are increased. Joe "how do you change the oil?" Blow isn't likely to take maintenance seriously, and I doubt that any amount of redundancy is going to keep him safely in the air.

(Of course, the probability of Skycars actually falling out of the sky depends greatly on the probability of Moeller actually getting them airworthy enough to fly long enough to experience a failure.)

Many color photocopiers implement copy protection (seriously!). They will detect that you're trying to copy money, and screw up the colors so it looks fake (unless you resize it). Try it sometime. I'm not sure if color printers have the same "feature".

"Microsoft apologizes for *offensive* thesaurus errors"

Microsoft Mexico has an on-line Spanish-language thesaurus that has caused
quite a stir. For example, the word "Indian" was equated with "man-eater"
and "savage"; "Western" with "Aryan", "white", and "civilized"; "lesbian"
with "pervert" and "depraved person". Microsoft Mexico has apologized, and
is rushing in a language expert from their software development center in
Ireland. [Source: *The Boston Globe*, 6 July 1996, p.58.]

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. Response

A few notes:
"Non-local telephone service was cut off for customers in an approximately 500 square mile area"

The phone company employees tried to call the fire department, but of course the telephone lines did not work.

Depends. I think for a doorframe that deletes floppy disks you should get a superconducting inductor to keep the cost down.
And it would be dangrous with anyting magnetic in your body or around, see e.g. this item of the Risks Digest for what can happen.

So, then Microsoft will just need to rename itself in "Port Authority", and happily ignore these (software) building codes