[smacktoward]

In fairness, it was a different world back then. There were so few people administering computer networks that you could generally assume someone who was doing so had been thoroughly trained; and the thing about highly trained people is that they tend to view things like failsafes and safeties as pointless time-wasters.

"I know what I'm doing when I hit F7, but the damn system makes me sit there for 30 seconds before it does what I told it to do! Piece of junk."

The result was that software in that era tended to come with a lot more sharp edges. The age of the Recycle Bin that would save you from yourself didn't arrive until administering systems became something the general public was expected to do.

[tzs]

Ahhh....the days of sharp tools, no failsafes, and young programmers or admins.

I recall that time I wrote a batch manager for the VAX 11/780 at Caltech High Energy Physics. It consisted of a program to monitor the batch queue and start jobs as scheduled ("BATch MANager", or "BATMAN"), and a program for users to submit jobs ("Run Overnight Batch INput", or "ROBIN").

The configuration file for BATMAN was stored in /etc/batman.

During development, I occasionally had to "rm /etc/batman". Of course, out of habit, as soon as I typed "/etc/" my fingers would automatically type "passwd", and once I did not catch this in time. Oops. It happened to be a Sunday morning at around 7AM, and I had to call the other admin, who handled backups, to come in and restore that file. He was annoyed.

The second time I did this, he was pretty pissed.

The third time, I fortunately had been working at the terminal we had in the machine room, and managed to shut down power to the machine before the write buffers were flushed, and the file was OK after fsck. I didn't have to deal with an angry co-admininstrator that time. Just angry physicists.

The other admin (Norman Wilson, in case anyone knows him or he reads HN) then made a link named /etc/safe_from_tzs to /etc/passwd to stop my nonsense once and for all.

That worked until the first time I wanted to overwrite /etc/batman instead of rm it.

That led to a cron job that maintained a copy of /etc/passwd in a separate file, and periodically checked to see if it were missing or misformatted, and restored it if so.

[dkural]

One would think after the first two times you'd find a better way to do this, realizing your infrequent but habitual mistake. Why didn't you change any of your practices after the first two screw ups?

[thaumaturgy]

Not speaking for tzs, but back in the good ol' days, everybody was pretty busy. A lot of software got written by operators a little bit here and there in between running jobs and moving paper around the building and that sort of thing; paid programmers were frequently dealing with change requests from business departments, all of whom wanted their thing done yesterday; and depending on the size of the organization, there might be a PFY or two, but they generally weren't allowed anywhere near production hardware.

For example, one of my early jobs in IT involved running batch programs that produced reports on a mainframe designed for the punch card era. It had moved on from punch cards, but all of the batch jobs still expected them as input, so they were stored instead as "digital cards" in the job files themselves. The operator -- me -- would be responsible for bringing a job up on the terminal, changing each occurrence of some two-letter code in each card file to some other two-letter code, some date code to some other date code, and so on. Each batch job might be just one step of half a dozen or so required to produce paper printouts from the database. The terminal emulator did not have a find & replace function. Naturally, I screwed up jobs on a regular basis.

This mainframe ran mainly on COBOL74. Over the course of a lot of unpaid overtime, a few hours here and there for several weeks, I gradually wrote a variable interpolator in COBOL that could be called as the first step of a batch file and would replace all occurrences of a variable tag with an input parameter passed to the job. Instead of pulling up a job file and replacing a bunch of two-letter codes, you'd just run the job with the two-letter code as a parameter, and this program would rewrite all of the data cards in the batch file. COBOL has no string operators or a string data type, but I found a way to abuse some system calls to make it work.

So it took weeks to fix the most common operator error in that shop.

IT staff spend more time on Facebook, Reddit, HN, and online gaming now than we ever had available for fixing processes back in the day.

[tzs]

I'm not absolutely sure on the number of times. It is possible that I only rm'ed it twice, and then Norman made the link to end that. This would have been around 1981, so there has been some memory fade.

[autokad]

are you that angry co-admininstrator ? just curious

[dkural]

hahaha :) I didn't mean the comment to sound angry - nope not the co-admin. I do have a running interest in stuff like continuous improvement, organizational excellence etc. so consider this field research!

[viraptor]

> you could generally assume someone who was doing so had been thoroughly trained

No amount of training can prevent something like this. It's like today's browsers where the tab can be closed with ctrl+w and the whole window with ctrl+q. It doesn't matter how many times you've done it and how used are you to the position of the 'w'. One day you will close the whole window by accident.

[thefreeman]

Personally I agree. Mistakes happen, everyone has accidentally hit the wrong key at one point or another in their life. I was pretty surprised how seemingly fine he was with being fired. At the same time, I guess the net result of the mistake was big enough that it did kind of require a response, and it has been about 30 years since it happened.

[GoodIntentions]

IMHO, firing someone who owns up to a keystroke mistake like that is wrong. Good managers fix the problem, weak managers fix blame.

Root cause analysis + countermeasure might have boiled down to "operator error due to shitty interface" + "we will tape a guard over F7 key, since it will never ever get fixed in software"

[viraptor]

> the net result of the mistake was big enough that it did kind of require a response

That's a dangerous way of thinking. 9/11 was big enough that it required a response. Not sure if we'll ever reverse the airport security stupidity that was such a response.

[smsm42]

This is a result of a way of thinking called "Politician Fallacy": "We need to do something. This is something. Therefore, we need to do this". Of course, 9/11 required a response - however it didn't require just any response, it required appropriate response. TSA is not one, and it starts to be more and more clear to more and more people. OTOH, firing somebody who caused the network to go down at the critical moment may be entirely appropriate - one of your responsibilities is not to make such mistakes, you failed at it, you're fired.

[vehementi]

I never understood the rationale of "you made a mistake, so you're fired". By making a mistake, the employee has increased her value in that she will never make that mistake again. If you're going to replace the employee you have to pay to hire someone even better (to recoup costs of talent hunt, training) and someone who somehow won't make a typo. It just seems like a situation that is strictly worse than keeping the current employee.

[smsm42]

>>> By making a mistake, the employee has increased her value in that she will never make that mistake again

This is a far-reaching conclusion. That assumes that a) no mistakes can be prevented before they happen for the first time and b) every mistake can be prevented after making it. The truth of either far from obvious. Moreover, it is routine in our culture that sever mistakes are punished - e.g. if you make a mistake of driving drunk and cause harm, you'd probably be punished, not lauded as model citizen since you'd never make the mistake again.

Moreover, if no punishment follows the mistake, why the mistake would not be repeated? What would be the motivation to avoid the repetition of the mistake - do you assume the sympathy for the co-workers would be enough? It is not always a sufficient motivator.

>>> It just seems like a situation that is strictly worse than keeping the current employee.

That assumes employees are a fungible commodity, and if you pay the same money you always get the same one. This is not true - you can find employee which would be more attentive, or one with more experience.

[meepmorp]

> By making a mistake, the employee has increased her value in that she will never make that mistake again.

Personal experience tells me this is not always true.

[sliverstorm]

IMO the fact that we have multiple examples of these kinds of accident-prone key pairs does partially exonerate whoever did this particular F6/F7 bit.

[dceddia]

I can't count how many times I accidentally hit the Save Game button instead of the Load Game button in Half-Life. The keys were literally, like, right next to each other.

[jessaustin]

...the whole window with ctrl+q.

OMG I've never done that but now that I know about it I'm very afraid. If I do it tomorrow I'm blaming you.

[sushid]

Thankfully, Chrome has a built-in feature to prevent this from happening (on OSX at least). Just go to Chrome > Warn before Quitting and make sure there's a checkmark next to the option.

Now, if you accidentally press Cmd + Q, it should prompt a "Hold Cmd + Q to Quit" instead of actually quitting.

[tremendo]

Or, Settings > On Startup... "Continue where you left off". This will restore your tabs after launching Chrome.

[Houshalter]

I disabled that warning because it's annoying every time I want to close the browser, even without the dangerous keyboard shortcut. If it happens, you can go to the menu and find "recent tabs" or just ctrl+shift+t.

[sp332]

If you do this in Firefox, you can go to History -> Restore previous session. This will bring up all the tabs you had open last time it quit.

[viraptor]

This helps: https://addons.mozilla.org/en-US/firefox/addon/customizable-...

Also, I made a mistake, it doesn't close the window. It closes all windows at once. Be afraid!

[pooper]

ctrl + q very appropriately quits the application. If this came as a ticket to me, I'd close it as working as expected.

[djur]

Traditionally applications have asked the user if they're sure they want to quit. That's a no-no these days, but it's still a reasonable choice in situations where the cost of quitting might be high (there's unsaved content, or the app takes a long time to start, or it's impossible to persist the current state of the application).

For some time, the Chrome team refused to implement a 'Sure you want to quit?' popup due to a general anti-popups consensus. They also refused to implement a checkbox to enable that behavior due to a general anti-configuration consensus. They've since relented on the latter.

[pooper]

Mozilla Firefox used to have a setting under options/preferences to disable loading images and loading javascript. People complained and said this should be removed as not enough people use it and that people who use it can create/use an add-on to do the same.

It is not easy to find a right balance between providing adequate functionality while avoiding information overload. The web is still evolving. We are learning and we will do better (overall) as time goes by. :)

[SilasX]

... and then you'd spin it off as a feature (or design review) request for better handling of accidental quit actions, right?

[pooper]

I like this idea. I will try to remember this because it is the perfect answer in situations like these...

[nitrogen]

Ctrl-Q typically preserves the session though, so all non-ajax sites will come back as they are, including partially filled forms.

[Sami_Lehtinen]

Yeah, if you don't care about privacy and save such data to disk as active session, active browser tabs, history, cookies, etc. Those should be RAM only for privacy reasons and never stored to any medium which can store those for extended periods.

[LukeShu]

I've done it enough times that I was finally motivated to figure out to set browser.showQuitWarning=true in about:config.

[oakwhiz]

The other reason I enable browser.showQuitWarning in Firefox is because you can Save and Quit instead of just quitting.

[steven2012]

No, this isn't true at all.

The power switch on the IBM PCs were way at the back so that people couldn't unintentionally reset the computer. The same thinking went into Ctrl-Alt-Del, which was a combination that people wouldn't accidentally hit.

So having a system where F7 would reboot the entire system was pretty dumb, even in the early 80s.

[RachelF]

Probably not. The power switch was at the back because that was were the power supply was.

IBM didn't put much thought into safety. You could blow up the early IBM's if you turned on the monitor (screen) before the CPU box.

[gry]

I can't find information why the design(s) were as they were. The design of Ctrl-Alt-Del was intentionally unintentional.

Gates noted Ctrl-Alt-Del should have been one button, not three [1]. David Bradley, the inventor of the trifecta, did make it deliberately difficult to reboot, however, it was also originally an Easter Egg which made it to production [2].

[1] http://www.theverge.com/2013/9/26/4772680/bill-gates-admits-... [2] https://en.wikipedia.org/wiki/Control-Alt-Delete#History

[MBCook]

Ctrl-Alt-Del was an excellent choice for it's intended purpose. It can be easily typed at they keyboard (no need to fiddle with the back of the computer) but it's very unlikely to be something you hit accidentally.

I'm not sure a single key would have been a good idea. "The reboot key" just sounds like a mistake waiting to happen. I've seen enough stories on the 'net of laptops with power buttons in terrible places on the keyboard to get a glimpse.

The mistake was using it for the Windows NT screen lock/unlock. Changing the "reboot your computer" sequence into the "start using my computer" sequence is a rather non-sensicle (ignoring implementation) choice.

[taejo]

> "The reboot key" just sounds like a mistake waiting to happen.

It already did happen: I've used keyboards with shutdown and reboot keys, and yes, it's a terrible idea.

My alma mater used to run programming competitions in a lab where the workstations had the reset button exactly at knee height. This wasn't a problem normally, when you're sitting under the desk next to the computer; but when you have three or four people gathered around the screen, kicking the reset button was a definite possibility. Eventually taping the cover of a calculator over this button became part of our regular routine.

[deckiedan]

I actually really like the added knowledge that my login screen and password input box is a system one...

[flomo]

Meanwhile, the Apple II+ had the reset button right above the return key.

[lavamantis]

I was about to argue, then I realized my first computer was the Apple IIe. Reset button offset a bit to the right. http://images.cdn.fotopedia.com/flickr-144862832-hd.jpg

[flomo]

And on the IIe or later you had to press Ctrl+Open Apple+Reset. (Similar to the IBM PC.) On the earlier models, if you mistyped, BEEP, the system rebooted.

[CoolGuySteve]

Another alternative is confirmation fatigue.

As in: I hit F6, "Do you want to reboot this?" dialog pops, I hit 'Y', "Do you really really want to reboot this?", I hit 'Y' again.

Instead of actually reading what it says, you just instead press F6-Y-Y in quick succession.

Modern interfaces sometimes make you type some kind of string to confirm, but most either use a password (like sudo) or some hardcoded string that everyone eventually memorizes.

But even today, Windows 7 only makes you click that one button in UAC, and most people probably do it without even thinking about it.

[djur]

Whenever I implement a bulk delete feature I tell the user how many records they're about to delete and ask them to type it back in.

If it's possible they're trying to delete data from the wrong place (say, an administrative account that manages many customers) another safeguard is to have them select the name of the context (customer name, etc.) out of a list of four or five nonsense alternatives.

The user experience tends to involve a lot of double takes and rereading, which is precisely what I want.

[alxndr]

In another comment, derefr points out that GitHub similarly makes you type the name of the repo when you delete it.

[btilly]

I have idly considered addressing that problem when it really matters by asking multiple random questions whose answers need to be some combination of "Y" and "N" to proceed. With the result that you simply cannot engage in muscle memory.

Anyone using the app would hate me.

[derefr]

When you delete a github repo, you have to retype the fully-qualified name of the repo you want to delete. I think that's exactly the right level of annoyance: it makes sure that if you're mistaken about where you are, you realize it, and that if you're making a typo, you'll have to make it the same way twice.

[jjoonathan]

Not as much as we hate the person who made the decision to prevent phones/computers from turning on immediately when the battery is empty, even if they're plugged in :P

If I ever meet that person IRL... I might even go so far as to make a tasteless joke about committing physical violence in retaliation for the hassle they've caused me.

[gridspy]

There are good reasons for this

- When the battery has just started charging, the voltage will not be high enough for the phone to actually work, because the draw from the battery exceeds the plug pack input

- Sometimes when transmitting, the phone uses more power for a fraction of a second than the power pack can deliver. This surge of energy could come from the battery, but the battery is empty so it won't work correctly

- Having some amount of battery means the phone can soft-off correctly when the plug is removed suddenly. The alternative is an un-expected hard off which is usually bad. The user might experience data loss.

There are a bunch of grey areas around low voltage, such as flash writes failing marginally or radio not working correctly or partial saves. Much easier for the engineers and perhaps more reliable for the users to make them wait just a little.

[mkesper]

Sounds logical, but then why on earth do many phones turn the screen on right after plugging in?

[jjoonathan]

> There are good reasons for this

They all seem pretty bad to me.

> When the battery has just started charging, the voltage will not be high enough for the phone to actually work, because the draw from the battery exceeds the plug pack input

What type of battery has an innate "draw"? They need a certain voltage and have a certain internal resistance, but it's easy to efficiently increase the effective internal resistance by boosting voltage with switched capacitor circuits (or whatever). If there's a "smart battery manager" you can bet the hardware to do this is already there.

"Draw" would be an excuse if you were hooking things up manually to a car battery. It's not an excuse in the highly integrated environment of a cellphone where corrective circuitry is dirt cheap (and free relative to what's already probably there).

> Sometimes when transmitting, the phone uses more power for a fraction of a second than the power pack can deliver.

That's what capacitors are for. They're almost certainly more efficient, too. Efficiency slumps away from the optimal I,V much faster for batteries than for capacitors.

> Having some amount of battery means the phone can soft-off correctly when the plug is removed suddenly. The alternative is an un-expected hard off which is usually bad. The user might experience data loss.

I'm pretty sure this is the actual reason why it's done. It's an awful reason.

First of all, you claim that "an un-expected hard off is usually bad". WTF? Does your ext4 linux partition usually die when you hard-off it? I've probably hard-offed ext4+linux 1000 times, never had any problems. I would go to great pains to avoid hard-offing a production server but you must acknowledge that in the age of solid journaled filesystems, hard-offs almost never lead to actual bad consequences, especially for light usage patterns. I'm sure it's worse on some hardware configurations but I've never met a system where it got all the way to "usually bad" territory.

On the other hand, having a power manager lock me out of my phone for 15 minutes after I determine I need to use it has led to loss of data. Significant loss of data. And worse. Pictures that were never taken, phone calls that were delayed at significant inconvenience, the inability to look up contacts for others... these are real world negative consequences that are 1000x more important than a .1% chance of filesystem corruption times, say, a 20% chance of actual power failure. It seems hopelessly myopic to suggest that the cost/benefit trivially favors the prevention of uncommon filesystem errors over addressing the immediate and possibly time-sensitive needs of the user.

I think that whichever organizations choose to implement the lockout feature are doing a massive disservice to their customers, foisting significant hassle upon them in order to save a few pennies/customer of repair costs, if that. Your arguments haven't convinced me otherwise.

[rickmode]

I believe UAC works well even when a human always hits OK. The point is to make sure a human is there and trying to do something and not some malicious code.

[austinz]

This is very true, which begs the question - why was a 23-year-old summer intern placed in charge of the embassy computer system, or even given access to its central console? He may have have self-taught facility with computers, but I find it hard to believe he'd have much experience at that age with the sort of large, mission-critical institutional computer system described in the article.

I wonder if he had a supervisor sysadmin that he was working under, but given how he described his boss, that seems unlikely as well.

[analog31]

You might be surprised. What I observed during that time was that a lot of, if not most, senior people were clueless about what computers were actually doing. The potential "reach" of that intern might just not have occurred to people.

And we still have national security / diplomacy disasters resulting from relatively low level people having access to vital computer systems beyond anybody's imagination.

[gambler]

You're invoking an annoying and ridiculously overused false dichotomy that is as false today as it was 30 years ago. An interface that has fail-safes does not have to be annoying and clunky. In fact, interfaces that are annoying and clunky are a great contributor to human mistakes, because they require a lot of rote action, which encourages people not to pay attention and work on auto pilot.

If something has changed over these years, it's the overall understanding of design principles and their popularization. (Thanks, Don Norman and other people in the field!)

Training has nothing to do with it. Even if you can train a person to work with a badly designed system without making mistakes (often), designing the system well in the first place is almost always significantly easier and cheaper.

For example, accidental key presses can be easily prevented by requiring the user to type a command of reasonable length. Typing "reboot-all-workstations" is not that difficult, but it would definitely prevent the incident described in the article.

[SolarNet]

I think he was pointing out why it was built that way, not why it was that way. Today we know it is a false dichotomy, he was pointing out, back then, the world thought it wasn't.

[nightpool]

You know, I think that was the point of the comment. I might just be reading it wrong, but it seemed to me that he was decrying such interfaces, using obviously hyperbolic language like "pointless time-wasters" (in the context of something other people believed) and "the damn system makes me sit there for 30 seconds". It sounded to me like he was even slightly making fun of that worldview.

[smacktoward]

You are correct, making fun of it was my intention. I suppose next time I will have to hang a "WARNING: SARCASM" sign on my comment, to make sure everybody gets it :-D

[zaidf]

You're not taking into account the fact than what is considered bad and clunky interface today may have been the best in class 30 years ago.

[efnx]

Even allowing for the era, providing the opportunity for a possibly disastrous effect to take place due to someone dropping the keyboard or knocking it with their elbow is inexcusable. Accidents happen - they should be minimized and steps should be taken towards quick recovery but they should be expected.

[ern]

It wasn't until Windows 95 (or was it 3.1?) that usability and standardization were taken very seriously in the PC world. I recall vaguely using an 80's-era DOS-based word processor at my father's office, and pressing "F1" for help, and wiping out my work.

[Gravityloss]

If you visit countryside museums with old agricultural or workshop equipment, you can verify they are basically all maiming devices. Things used even in the 1950s. In one machine you push a piece of wood downwards and there's a blade that hacks slices off the bottom. Real tough men pushed right till the end so there was no waste. They often had some missing fingertips. Some really small changes made those accidents avoidable, like using some other pieces to hold the worked piece.