Count to ten when a plane goes down • Hacker News Board

Re: Count to ten when a plane goes down

#161

Post by Sami_Lehtinen » Tue, Jul 22, 2014, 6:28 AM UTC

nitrogen wrote: post #122

viraptor wrote: post #86

Earlier quoted context omitted.

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!

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

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.

Re: Count to ten when a plane goes down

#162

Post by mreiland » Tue, Jul 22, 2014, 6:40 AM UTC

marbletiles wrote: post #18

mikegreco wrote: post #4

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.

The world where you know you that a) you have an incredibly powerful key with no safeguards at your fingertips and b) you might be in a breaking news situation and nonetheless you go for the key right next to the dangerous one carelessly enough that you miss? Think about it: Unix is equally as "insane". If you're the guy on the console who meant to clean out some crap dir and accidentally typoed "rm -rf /" and then c…

rm -rf / is not quite the same as the f7 key restarting all machines sitting right next to the f6 key to restart a single machine.

you cannot fat finger rm -rf /

Re: Count to ten when a plane goes down

#163

Post by ProAm » Tue, Jul 22, 2014, 6:43 AM UTC

mikegreco wrote: post #4

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.

attention to detail is a more valuable skill than people realize

Re: Count to ten when a plane goes down

#164

Post by ern » Tue, Jul 22, 2014, 6:49 AM UTC

smacktoward wrote: post #37

feld wrote: post #2

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

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

Re: Count to ten when a plane goes down

#165

Post by mandalar12 » Tue, Jul 22, 2014, 6:49 AM UTC

graylights wrote: post #46

baddox wrote: 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 /"

What would be the "good" alternative ? I often tries "rmdir" or "rm -r" if the directory is not empty and very often there are some "protected files" so I add -f. Thus it happens that I directly lauch "rm -rf".

Re: Count to ten when a plane goes down

#166

Post by claudius » Tue, Jul 22, 2014, 6:51 AM UTC

mreiland wrote: post #162

marbletiles wrote: post #18

Earlier quoted context omitted.

The world where you know you that a) you have an incredibly powerful key with no safeguards at your fingertips and b) you might be in a breaking news situation and nonetheless you go for the key right next to the dangerous one carelessly enough that you miss? Think about it: Unix is equally as "insane". If you're the guy on the console who meant to clean out some crap dir and accidentally typoed "rm -rf /" and then c…

rm -rf / is not quite the same as the f7 key restarting all machines sitting right next to the f6 key to restart a single machine. you cannot fat finger rm -rf /

  # rm -rf /tmp/bla

  # rm -rf / tmp/bla

Re: Count to ten when a plane goes down

#167

Post by smsm42 » Tue, Jul 22, 2014, 7:11 AM UTC

vehementi wrote: post #120

smsm42 wrote: post #91

Earlier quoted context omitted.

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…

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

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

Re: Count to ten when a plane goes down

#168

Post by astrodust » Tue, Jul 22, 2014, 7:20 AM UTC

mreiland wrote: post #162

marbletiles wrote: post #18

Earlier quoted context omitted.

The world where you know you that a) you have an incredibly powerful key with no safeguards at your fingertips and b) you might be in a breaking news situation and nonetheless you go for the key right next to the dangerous one carelessly enough that you miss? Think about it: Unix is equally as "insane". If you're the guy on the console who meant to clean out some crap dir and accidentally typoed "rm -rf /" and then c…

rm -rf / is not quite the same as the f7 key restarting all machines sitting right next to the f6 key to restart a single machine. you cannot fat finger rm -rf /

You can fat-finger enter before you're done typing.

Re: Count to ten when a plane goes down

#169

Post by thaumaturgy » Tue, Jul 22, 2014, 7:37 AM UTC

dkural wrote: post #116

tzs wrote: post #101

Earlier quoted context omitted.

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 /et…

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?

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.

Re: Count to ten when a plane goes down

#170

Post by wildpeaks » Tue, Jul 22, 2014, 7:54 AM UTC

jpatokal wrote: post #15

endtime wrote: post #5

Earlier quoted context omitted.

> In what world Japan, I guess? I've never been there but the story was consistent with my impression of their work culture.

This was the American Embassy, which follows American work culture. Also, in Japanese companies, it's basically impossible to fire people. They can, however, be assigned to a desk in a windowless room and be given nothing to do for several years, until they take the hint and "voluntarily" quit.

The Japanese way is good in the sense that, as long as you have Internet, you could make your startup without worrying about putting a roof over your head or finding an office space to work from, and you get a still-full salary to bootstrap it without having to put the time.

You even get access to a pool of other soon-to-available engineers to work with if you're stuck with other poor sods in the room.

Definitely another scenario than the being suddendly kicked out of the door by security right before the week-end with a box of your belongings and, if you're lucky, a tiny check to not starve until next week.