Live data from Hacker News

Count to ten when a plane goes down

johncbeck.tumblr.com

151–160 of 284 posts

Re: Count to ten when a plane goes down

#151
post #138
post #113

How about when Russia returned the data recorders after years of refusing to South Korea - made a press spectacle of it - and then South Korea discovered the recorders were empty and missing the data tapes when the press was gone. Or the US navy crew who received medals after shooting down the Iranian airline. Once there is loss of life, it is 100% politics afterwards with little to no practicality, just look at all…

> Or the US navy crew who received medals after shooting down the Iranian airline. You make it seem like they received the medal for having shot down the plane. In reality, those who were awarded medals, were awarded Tour of Duty medals for their time spend in a combat zone. I believe the distinction is important, particularly since that class of medals are routinely awarded to individuals during their time in the mi…

If a police officer shot and killed innocent bystanders, should they get achievement awards for doing their job otherwise?

My answer would be no, you failed at your job regardless.

Same thing with military.

Re: Count to ten when a plane goes down

#152
post #2

Reset all computers in the embassy with F7? No warning prompt? Fire the idiot who wrote that function.

Some people are saying that a warning would have helped. Remember that warning functions are easy to ignore. Never use a warning when you mean undo. http://alistapart.com/article/neveruseawarning

That won't help here. You cannot "undo" a workstation reset, or any other action that results in a state propagation.

Re: Count to ten when a plane goes down

#153

The author states they felt it was appropriate when they were fired. In what world would it be appropriate to get fired for a single, simple, incredibly easy to make mistake? Doubly insane when there were exactly zero safeguards in place to prevent the mistake from being made.

According to his next post:

What I didn’t say is that it was the last day of my summer internship. The next summer they invited me back again. Everyone understood it was a mistake, but by officially firing me, someone had been punished … :)

Re: Count to ten when a plane goes down

#154
post #117
post #108

Earlier quoted context omitted.

I was leaving my old job and handing in my MacBook Pro. After getting permission from the network guys (who were going to format it anyway) I ran rm -rf / as root. It was surprisingly boring, taking a very long time to delete all my files (I should have deleted them first). Eventually it got around to deleting fonts, which caused things to render a little strange, but after 60 minutes nothing much had changed and it…

I did the same thing but had remotely SSH mounted some of our production servers. Won't make that mistake again.

I managed to run (sudo) mv /* /tmp one day.

I was trying to move everything out of a folder to tmp (mv ./* /tmp), which was fine. Then I cd to /, and, wanting to rerun the command I'd run right before the mv, pressed up twice and enter quickly...

Well, it failed once it finished moving /bin/mv to tmp. Of course cp, and a lot of other helpful commands come before mv alphabetically.

It wasn't too bad, just needed a boot from a live disc to move everything back, but I still get nervous whenever / and * are in the same command.

Re: Count to ten when a plane goes down

#155
post #139

Earlier quoted context omitted.

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.

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

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

Re: Count to ten when a plane goes down

#156
post #36

Earlier quoted context omitted.

But typing "rm -rf /" is significantly harder to do accidentally than typing F7 instead of F6.

Not really, a lot of novice unix users are of the habit of removing files with -rf switch. I cringe everytime I see it. The command "rm -rf ~/blue/" is just a single space key from being equivalent to "rm -rf /" with "rm -rf ~/blue /"

> Not really, a lot of novice unix users are of the habit of removing files with -rf switch. I cringe everytime I see it.

Every few days I remind myself of this.... then I have to delete another directory with a git repository in it, and end up add the -f in again

Re: Count to ten when a plane goes down

#157

Earlier quoted context omitted.

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…

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.

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.

Re: Count to ten when a plane goes down

#158

Earlier quoted context omitted.

It's easy to have this attitude now. But if you ask people who were in IT 30 years ago, they'll tell you that systems in those days had _many_ sharp edges. You were expected to know your way around, and the consequences of mistakes were pretty severe.

I was in IT 30 years ago, and this was never the attitude. What's different today: 1. we know a heluva lot more about human factors design 2. we have a heluva lot more excess computer power that can be devoted to human factors

I'd add: 3. many more people are using computers.

Re: Count to ten when a plane goes down

#159

Earlier quoted context omitted.

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.

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 cor…

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

Re: Count to ten when a plane goes down

#160

Earlier quoted context omitted.

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.

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 cor…

> 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.

Post reply on HN