Slashdot Mirror

Also, I noticed the date, this was just a week or two after the boom, before the investigation could barely even start? Yeah, so they had a bunch of fail-safes on the destruct system, are you trying to imply it was caused by anything but O-rings failing in cold weather and a culture of ignoring risk?

And in case you don't understand my previous message: RISKS 1-43. Of course the true root cause was the design of the vehicle mounted on the side of the rocket, with no proper crew abort. The O-ring fault in the SRB was merely the mechanical root cause.

I'll just leave this here : Human error caused Amazon Web Services outage, Apple iCloud service issues.

First I want to express my empathy with your difficult situation.
Further beta-cell regeneration is only necessary in type 1 diabetes, which is covered in the article, although I feel also there is a suggestion that the damage to the beta-cells could be caused by the high levels of insuline that have to be produced from the time the insuline resistance kicks in in those mice.
The insulin resistance which type 2 sufferers suffer from, can be reversed by a 'not so very strict diet' for about 6 to 8 weeks only and without a very rigorous training, let alone for years.
I'd say try again, a little longer, and no guarantees promised.
(And yes, you're right, HFCS is pure shit.)

Please let them know what you think about this disorder.

http://www.ncl.ac.uk/ion/staff...

People raising issues about electronic voting go way back further than that. Here is a search on Risks List for Electronic Voting (oldest is at the top)

Bearing in mind I can remember the first removable HD http://www.staff.ncl.ac.uk/rog... which weighed about 15kg this is a vast improvement.

Seeing the pic in the TFA of the hipster guy leaning back while the car drives itself made me think that if it was me, I would not be able to relax while the car just drove. I think I'd still be continually scanning the displays and surrounding area looking out for potential trouble even though I know that I am not in control.

This make me wonder how much autonomous driving it will take before people actually feel emotionally comfortable letting the car do its thing? Or if anyone who has grown up with manual driving can ever fully trust an automated driving system? And I say this as someone who builds automated manufacturing equipment for a living and I implicitly trust those systems to do what they are designed to do (after being thoroughly tested).

(Of course the flip side is that reading Risks List gives me a dose of skepticism when it comes to other peoples systems)

Alas and dammit, that link should be http://catless.ncl.ac.uk/Risks...

Please pardon my incompetence.

As so often before, Henry Baker sums up the issue to perfection:

"Once again, in our asymmetric world, people who live in glass houses shouldn't be throwing rocks—especially at those who don't live in glass houses". http://catless.ncl.ac.uk/Risks...

It's quite certain that, of all the nations in the world, the USA has far more to lose from "cyberwar" than any other.

School, circa 1974. Sending off your sheets and hoping that the keypunch operators didn't get 0's and O's confused. O's were slashed, or perhaps it was the other way round. Getting your job back on music ruled paper the next week

University. There were teletypes that you could use to get access to the ICL mainframe, but for exams you had to use punched cards, and only got 3 goes to compile and run your program. There were always queues for the big punch machines, so if you just needed one card doing, you could use a hand punch.

There's a good page with a photo of one here: http://www.staff.ncl.ac.uk/rog...

By my first job in 1979, we had VT52's and then VT100's, as well as a LA120 for the console.

Thanks! I love "Superiority" and will check out the others.

- out with soap!

• IBM's Watson computer has parts of its memory cleared after developing an acute case of potty mouth at the RISKS Forum

It seems that Watson learned some bad words when IBM turned it on to the Urban Dictionary.

The alternative would be Watson talking about things like "The Shocker" (Google it, but not at work) - which would probably creep most of us out.

- out with soap!

• IBM's Watson computer has parts of its memory cleared after developing an acute case of potty mouth at the RISKS Forum

It seems that Watson learned some bad words when IBM turned it on to the Urban Dictionary.

There goes our only chance to find out what a "holla back girl" is.

- out with soap!

• IBM's Watson computer has parts of its memory cleared after developing an acute case of potty mouth at the RISKS Forum

It seems that Watson learned some bad words when IBM turned it on to the Urban Dictionary.

I know this because a client I once consulted for, sold 400,000 licenses for their Windows product to the Navy.

Windows isn't so bad if it's properly locked down, but it's not really possible to do that unless all of your application are Windows Logo-compliant, for example they don't store end-user documents in the Program Files folder. I expect the military has a lot of homebrew software they absolutely need to use, that prevents Program Files from being locked down.

Also everyone who actually administrates a windows box, has to actually know how to lock it down.

• USS Yorktown Dead In Water After Divide By Zero

The Navy's Smart Ship technology is being considered a success, because it has resulted in reduced manpower, workloads, maintenance and costs for sailors aboard the Aegis missile cruiser USS Yorktown. However, in September 1997, the Yorktown suffered a systems failure during maneuvers off the coast of Cape Charles, VA., apparently as a result of the failure to prevent a divide by zero in a Windows NT application. The zero seems to have been an erroneous data item that was manually entered. Atlantic Fleet officials said the ship was dead in the water for about 2 hours and 45 minutes. A previous loss of propulsion occurred on 2 May 1997, also due to software. Other system collapses are also indicated. [Source: Gregory Slabodkin, Software glitches leave Navy Smart Ship dead in the water, Government Computer News, 13 Jul 1998, PGN Stark Abstracting from http://www.gcn.com/gcn/1998/Ju... ...

``Using Windows NT, which is known to have some failure modes, on a warship is similar to hoping that luck will be in our favor,'' said Anthony DiGiorgio, a civilian engineer with the Atlantic Fleet Technical Support Center in Norfolk.

Even knowing this is happening will change how many people behave. Warnings like this are part of the problem, real security experts will be working to block the watching, not adding to the chilling effects.

I'd like to quote from Michel Foucault's essay "Panopticon" from his book _Discipline and Punish_. Here's a link to the a pdf of the text:

http://dm.ncl.ac.uk/courseblog...

But first an explanation of the term is in order. In the late 18th century Bentham designed a prison where all the cells pointed to a central guard station. Thus, inmates were always being watched. The guard house design incorporated venetian blinds and obtuse corners so that inmates would know that at any time they could be under the watchful eye of guards, but never know exactly _when_. The intent of this was to impose self-restraint upon the inmate community by fear of potential surveillance. That is, self-censorship imposed by an architectural design. Here's what wikipedia has to say on the matter:

http://en.wikipedia.org/wiki/P...

Foucault took this idea and extended it to surveillance by authorities as a kind of 'social panopticon'.

[...] The Panopticon is a machine for dissociating the see/being seen dyad: in the peripheric ring, one is totally seen, without ever seeing; in the central tower, one sees everything without ever being seen.

It is an important mechanism, for it automatizes and disindividualizes power. Power has its principle not so much in a person as in a certain concerted distribution of bodies, surfaces, lights, gazes; in an arrangement whose internal mechanisms produce the relation in which individuals are caught up. The ceremonies, the rituals, the marks by which the sovereign's surplus power was manifested are useless. There is a machinery that assures dissymmetry, disequilibrium, difference. Consequently, it does not matter who exercises power. Any individual, taken almost at random, can operate the machine: in the absence of the director, his family, his friends, his visitors, even his servants (Bentham, 45). Similarly, it does not matter what motive animates him: the curiosity of the indiscreet, the malice of a child, the thirst for knowledge of a philosopher who wishes to visit this museum of human nature, or the perversity of those who take pleasure in spying and punishing. The more numerous those anonymous and temporary observers are, the greater the risk for the inmate of being surprised and the greater his anxious awareness of being observed.

[...]

[Panopticism] is regarded as not much more than a bizarre little utopia, a perverse dream - rather as though Bentham had been the Fourier of a police society, and the Phalanstery had taken on the form of the Panopticon. And yet this represented the abstract formula of a very real technology, that of individuals. There were many reasons why it received little praise; the most obvious is that the discourses to which it gave rise rarely acquired, except in the academic classifications, the status of sciences; but the real reason is no doubt that the power that it operates and which it augments is a direct, physical power that men exercise upon one another. An inglorious culmination had an origin that could be only grudgingly acknowledged. But it would be unjust to compare the disciplinary techniques with such inventions as the steam engine or Amici's microscope. They are much less; and yet, in a way, they are much more. If a historical equivalent or at least a point of comparison had to be found for them, it would be rather in the inquisitorial' technique.

Foucault extended the idea of the social panopticon throughout all institutions of society, drawing parallels between hierarchical structures in church, state, and corporate spheres where a authority used the possibility of surveillance and the tr

"The Real Purpose of Oakland's Surveillance Center"
(original article)

Happened in San Diego too: http://catless.ncl.ac.uk/Risks/26.80.html#subj5.1

'Big Brother' eyes encourage honesty, study shows

So I didn't:

• The Sinking of the USS Gitarro

I lived on Mare Island Naval Shipyard at the height of the Vietnam War in 1968.

Well, actually I did cross the street, but just once.

Michael David Crawford, who can't be bothered to recover his password.

Ants in Weird/Odd Places:

Bugs in the computer: Sun
Microsystems, Inc. knows why Brazil is known to its native inhabitants as the kingdom of the ants.

Ants in yer... Pants? NOT!
(Toshiba notebook/laptop); Ants
Invade Apple iBook; "Yep, those are ants in that laptop".

(Tele)phones: Panasonic Cordless Phone and Ants In My Nokia Mobile Phone (A Yahoo! account is required).

Ants in Omniview switchboxes: An e-mail story of ants invading a network
switchbox.

Argentine ants invade a network hub.

Computerworld on "Ants had taken up residence in a guy's external hard drive. Seen on /.).

A photograph showing ants nesting in a guy's phone box, affecting his
digital subscriber line (DSL) connection and phone system.

A 38 seconds YouTube video showing crazy ants in a computer mouse.

One minute and 19 seconds Break video, from VideoSift: "Creepy Surprise. -- Wife asked me to try to get the printer to work, since she was having some problems with it. Imagine my surprise when I looked inside..."

Help,
A Colony Of Ants Attacked My Enterprise Rental Car And Ruined My
Vacation!

wisdom of the ancients: always mount a scratch monkey

Yea, its not like medical software errors ever killed anybody. Eh Therac-25?

Or Varian.

http://catless.ncl.ac.uk/Risks/19.60.html#subj9

"I'd worry about a Tempest virus that polled a personal computer's
CD-ROM drive to pulse the motor as a signalling method:

* Modern high-speed CD-ROM drive motors are both acoustically and
    electrically noisy, giving you two attack methods for the price of one;

* Laptop computer users without CRTs, and the PC users that can afford
    large LCD screens instead of CRTs, often have CD-ROM drives;

* Users are getting quite used to sitting patiently while their
    CD-ROM drives grind away for no visibly obvious reason (but
    that's quite enough about the widespread installs of software from
    Microsoft CD-ROMs that prompted Kuhn's investigation in the first place.)"

Actually, I think it was more like:

"return x-x";"

In S/3x0 and z/Architecture machine code; sr n , n is the conventional (and, I think, fastest) "clear register n" instruction. I.e., the subtract is there as a way of clearing the register, not as an actual semantic "subtract" operation, just as, in x86,

xorl %eax, %eax
{popl,popq} %ebp
ret

is return 0 rather than return x^x - the XOR instruction is just a quick way to clear a register in that code sequence.

And in rare cases, where "x" (actually the contents of General Register 15) had the right value in it, this would ABEND the program due to an arithmetic overflow error.

If subtracting a value from itself produces an arithmetic overflow, your hardware is broken.

Which lead to the second fix, which also had a bug...

The second fix from the RISKS Digest message was for "some-or-other problems with the linkage editor, since the END statement didn't specify the primary entry point of the routine". The third fix wasn't a bug fix, it was a change to improve core dump analysis, and the fourth fix was "something esoteric to do with save-area chaining conventions", which seems a bit odd given that the main routine is a leaf routine in IEFBR14.

IBM has a mainframe program named IEFBR14. Officially, it does absolutely nothing. It's a dummy program used for things like anchoring JCL file allocations.

There have been at least 5 releases of it, although one was an upgrade to 64-bit integers. The others all count as bugfixes. Because when it comes to computers, even doing nothing does something.

The first of them was, allegedly, the S/3x0 assembler-language and OS/360 equivalent of replacing

int
main(void)
{
}

with

int
main(void)
{
    return 0;
}

as per this RISKS Digest message (the OS/360 and C calling sequences both treat a return from the main program as an "exit", with the exit status being the numerical return value of the main program).

Actually, I think it was more like:

"return x-x";"

And in rare cases, where "x" (actually the contents of General Register 15) had the right value in it, this would ABEND the program due to an arithmetic overflow error. Which lead to the second fix, which also had a bug...

IBM has a mainframe program named IEFBR14. Officially, it does absolutely nothing. It's a dummy program used for things like anchoring JCL file allocations.

There have been at least 5 releases of it, although one was an upgrade to 64-bit integers. The others all count as bugfixes. Because when it comes to computers, even doing nothing does something.

The first of them was, allegedly, the S/3x0 assembler-language and OS/360 equivalent of replacing

int
main(void)
{
}

with

int
main(void)
{
return 0;
}

as per this RISKS Digest message (the OS/360 and C calling sequences both treat a return from the main program as an "exit", with the exit status being the numerical return value of the main program).

hmm, missing the link to the article from which I got the Brandt quote:
http://www.huffingtonpost.com/2012/09/13/stanford-organics-study-public-health_n_1880441.html

which links to the summary of Brandt's research, which says:

A meta-analysis of the published comparisons of the content of secondary metabolites and vitamins in organically and conventionally produced fruits and vegetables showed that in organic produce the content of secondary metabolites is 12% higher than in corresponding conventional samples (P

This problem is well known, so there's no excuse:-

o http://catless.ncl.ac.uk/Risks/24.82.html#subj13
o http://catless.ncl.ac.uk/Risks/24.91.html#subj12.1

This problem is well known, so there's no excuse:-

o http://catless.ncl.ac.uk/Risks/24.82.html#subj13
o http://catless.ncl.ac.uk/Risks/24.91.html#subj12.1

I'm surprised that I do not see a link to the RISKS article about how a motorist was trapped in a traffic circle for 14 hours yet.

The technology in the RISKS entry was a bit more advanced (lane occupation detection) than what seems to be described in this article.

(And if someone cannot it figure out from the date, the RISKS entry was an April fool's joke; but a lot of people took it seriously at the time.)

Fortunately that F-16 bug was caught and fixed during simulation.

Every time i see one of these amateur fly-by-wire setups, i think of the F-16 development. One of the main show stoppers in the F-16 was the fact that the software would get confused when crossing the equator. It would flip the plane upside down fast enough to kill the pilot and then happily fly upside down until it ran out of fuel. Other little things like it would allow for wheels up while sitting on the tarmac, or allowing a bomb to come off the rack while inverted. Automation in flying is hard, and quite honestly you have to be prepared to lose pilots. http://catless.ncl.ac.uk/Risks/3.44.html

A third thing you should know is that a vote will be taken in January 2012 to decouple UTC from GMT: http://catless.ncl.ac.uk/Risks/26.50.html#subj12

It just works. Always has.

I disagree that it has always worked; the PSTN is generally very reliable, I'll give you that. I will agree with your apprehension about maybe seeing it go.

When it does fail, it fails very badly, and often takes other things with it.

Personally, I often find myself longing for the higher sound quality of a fully-wired phone line versus that of a cell phone. Isn't that ironic?

The London Underground has been fully automated for years.
They sometimes even leave without their driver.

Indeed, there are a lot of different factors that you'd have to take into account. Also, as you said there are some different situations that could lead to different results. I would be hard work to try and figure it all out. Lucky for us, I found a page on the internet by people who have already worked it out, and come up with some conditions that must be fulfilled in order to see a reduction in carbon dioxide production.

http://www.ncl.ac.uk/press.office/press.release/item/working-from-home-and-online-shopping-can-increase-carbon-emissions

It would have been nice if they'd also had a link to the actual paper.
http://www.theiet.org/factfiles/transport/unintended-page.cfm

Software Engineering is an engineering discipline.

Only when it applies "technical, scientific, and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or invention."

http://en.wikipedia.org/wiki/Engineering

Most coders don't do engineering, and that's part of the problem. In most other disciplines there are also standards:

I really hate to point this out but ... there are two reasons that, in other
engineering and technological fields, we *do* manage to avoid repeating at
least the reasonably common mistakes:

1. We develop standards and practices that have the force of law.
Electrical circuitry in houses is subject to a variety of such standards.
So is plumbing. [...]

2. We require training and passing of exams *on those standards and
practices*. We enforce this requirement by requiring licenses to work in
many fields - and those licenses depend on passing the exams. [...]

We in the software industry have been leading charmed lives for many years.
We've managed to avoid liability, avoid serious training in good practices,
avoid any kind of standards - all by arguing that this would cramp our style
and keep us from continuing to innovate. Maybe that's true - but we've been
building up a massive debt side by side with all that innovation.
Eventually, that debt's going to come due. If we don't clean up our own
mess, the greater society will come along and do it for us - and the results
won't be pleasant.

And more examples of how wrong things can get can be found here: http://thedailywtf.com/

There are some good examples there, but you'll find more on comp.risks.

This reminds of a series of books Robert Glass published in the 1980s, that I read as a kid. It served as a fun way to learn a bit of computing history, and gain experiences in the reading RISKS digest (comp.risks) sense.

• The Universal Elixir and Other Computing Projects Which Failed (1977)
• Computing Catastrophes (1983)
• Computing Shakeout (1987)

They are fun, short reads, but learning from other's failures can save you time. :)

No, that's not what I meant at all.

Look at:

• The FDIV bug
• The need for ECC memory due to poor multi-layer PCB impedance control during manufacture
• The 387SX that I used to have that told me "2.0 + 3.0 = 4.0" because the motherboard had the wrong wait states hardwired
• The laptop that I had that was designed before 3 chip 1 MB SIMM's and caused improper memory refresh on them causing windows and linux to crash intermittently when using high memory

The reality is that both computers and software are ultimately designed and verified by people. People screw up. Therefore computers and software can be buggy. So you need to make sure your system can manage under these conditions.

Now is the time for people to study the comp.risks forum.

--jeffk++

You do know the story of the F16 guidance system? Allegedly, as originally designed, crossing the equator would lead to the plane doing an instant flip and carrying on upside down. http://catless.ncl.ac.uk/Risks/3.44.html

The point of all this is people can build up irrational fears of what they don't understand.

I understand computers very well, thank you. I earn my paycheck running them. It's *because* I understand computers that the idea of having one run my car's brakes makes me nervous. It's only the people who don't understand computers who believe, "The computer said it, so it must be true." Read the RISKS forum some time: http://catless.ncl.ac.uk/Risks.

On the topic of TFA, it is in the interests of local defense contractors to promote scare stories about foreign components. I am aware of some research into trojan components (such as CPUs that have a built in error that is triggered by a sequence of opcodes found in a certain encryption algorithm) but I remain unconvinced by the theories on the 2007 Syria attack.

Even more concerning, was the author's argument that the accuracy of GPS guided autopilot systems also contributed. Historically, even if two planes ended up at the same flight level, headed towards each other, the inherent sloppiness in the autopilot systems would actually increase the chance of a miss. Now, with autopilots capable of keeping planes within very close tolerances of their ideal flightpath, the same two planes accidentally occupying the same flight level may have a much higher chance of colliding.

It's not a new observation - I first saw it bandied about in the RISKS Digest back in the late 90's as GPS was just then starting to come into wide use.
 
[Side note: I've heard that William Langewiesche wants to be/is thought of as the next John McPhee. If so, he's moving away from the target - the writing in that article was really bad.]

Well, you prompted me to go back and find out where I'd seen it first. It was actually "scratch monkey", and it was from RISKS Digest, Sept. 1986.

I thought about explicitly crediting the Fark poster and thread, but this isn't a refereed publication. I don't plan on copypasta-ing my own posts from there, either, although I expect I may repeat some of the material here.

There was a UNIX networking technology some time in the past (The Newcastle Connection) which used the /../ symbols to specify a remote path host.

HP did something similar but used a /net directory instead.

It would seem simple to just discard the two dots and just have a // to specify the remote host.

If you can confirm your vote, you can prove how you voter to others. This makes room for buying and extorting votes! I can imagine some employers requiring you to prove you voted correctly to keep your job.

Or union bosses. Or the local political-organizing group slipping you some money in exchange for voting a certain way. Or even an unorganized gang of thugs trying to intimidate you (think a group of rednecks who suspect you might have voted Democratic, or a group of Berkeley hippies who suspect you might have voted for Prop 8).

But I disagree with your first sentence. It's certainly true about the scheme proposed by GP, but contrary to intuition, there are ways to confirm your vote without being able to prove how you voted to others.

Such voting systems typically use a "cut-and-choose" method in which your vote is split into two or more pieces, any one of which is useless for determining how someone voted, yet together create the full vote. The voter takes a copy of one of the pieces as a receipt and can verify that the piece was counted correctly. So if there are two pieces overall, someone trying to tamper with the votes would have a 50% chance of being caught for each vote tampered with, which quickly becomes negligible for any significant number of votes. Yet the voter can show the piece to others, and it doesn't give any information about how they voted.

Here (PDF) is one method for doing this, by David Chaum.
Here (PDF) is another (without cryptography!), by Ron Rivest.

The issues with these new systems seem to be usability, inertia, and public trust. Usability: Voting should be extremely simple for the voter. If Great-Grandma can't do it, it's not going to be our voting system.
Inertia: Current election systems seem to be "good enough" for most people; despite some agitated geeks and the occasional news story about voting machines being laughably insecure, there isn't a huge popular movement to change. (Cost of switching systems can also be included here.)
Public trust: Even if cryptographers agree that a system is secure, if the system involves a user experience any different from the familiar "check off from a list of names" protocol, they'll have to work to convince the lay public that it's ok.

The problem is that you're trying.

To extend, the problem the SSA mentions: using them as identifiers?

That's not what's causing all the trouble. You can do that all you like, and the only people you'll piss off are privacy advocates, worried about unwanted cross-correlation.

The *real* problem, as I note in a piece I wrote for RISKS DIgest last month, is people using knowledge of an SSN (or a mother's maiden name, or any other answer not *made up by the customer*) as an authenticator.

If it is discoverable, and you force a customer to use it, *you* ought to be responsible when someone does, and defrauds the customer, cause you were an accessory before, and now you're on notice; it's been posted here.

Have fun, retail authentication system designers. ;-)

It's not a nameless or faceless "terrorist" group that is costing our businesses, shutting down our infrastructure, tangling our air traffic control, our power grid, our hospitals, or stock exchanges and banks. The people promoting Windows and Microsoft technologies have real names and faces and walk among us every day. Take them out and we've won the first round. Why is the military sitting on its hands here?

First, you get a FAIL for invoking the terrorism mantra.

You get a second FAIL for blowing things out of proportion and recommending military action against everyday folks just trying to do their jobs. That's the flawed logic of a police state.

You get your third and final FAIL for singling out Microsoft/Windows in your post, when really the type of software problems that lead to infrastructure failure have more to do with competence than platform choice (read Risks Digest regularly to see what I mean). Software development enfolds numerous areas of competency: requirements gathering, architecture and design, testing strategies and techniques, configuration/build management, deployment/implementation, security [extremely tricky], usability [at the root of most failures], and interpersonal skills... to name a few. Most IT departments are unaware of these needs and have no good ways to evaluate candidates even if they were aware of them.