• "The more you react, the less you understand."
  
• "'Loss of situation awareness' is the difference between what you now know, and what other people knew back then."

Vulture Culture fucked around with this message at 07:30 on May 22, 2015

• How did the world look to them at the time?
  
• How did the situation unfold around them; what cues did they get when?
  
• What goals were they likely pursuing at the time (not knowing the outcome you now know about)?

• "The mystery for understanding human error is not why people could have been so unmotivated or unwise not to pick up the things that you can decide were critical in hindsight., The mystery--and your job-- is to find out what was important to them, and why."

Roargasm fucked around with this message at 18:46 on May 23, 2015

• "What (you think) should've happened cannot explain people's behavior"
  
• "Counterfactuals are not opportunities missed by the people you are investigating. Counterfactuals are products of your hindsight."

Vulture Culture fucked around with this message at 05:48 on May 25, 2015

Gucci Loafers fucked around with this message at 05:39 on May 25, 2015

Docjowles fucked around with this message at 06:04 on May 25, 2015

• Chapter 1, USB installing: You don't need to use liveusb creator. You can (and should) just just dd it to a flash drive, especially since this works somewhat better with EFI (which has a different part of a joliet image)
  
• Chapter 2, ,Accessing from Another Linux System: universally recommending "ssh -X" instead of "ssh -Y" can cause problems with some applications, notably remoting into a system and trying vncviewer with a password -- the prompt will always fail. If you expect a password dialog to pop up, use -Y not -X. Also, xauth is required to be on the host, but no other parts of X.
  
• Chapter 3, File System Tree: it's misleading to say that "/boot may be expanded as part of the preparation to update the kernel". /boot is almost always at the beginning of the disk with no room to expand, and kernel %pre/%post scripts aren't trying to expand it. Far later down the line, preupgrade may require a larger filesystem than 500MB to do major (7->8, say) RHEL upgrades but this isn't a kernel upgrade. The installer will complain if you try to size it less than 500mb, probably, but nothing automatically expands it.
  
• Chapter 3, Filesystems (opt-ish): it's also misleading to say that "/opt holds additional software installed on the system" or that "/var/opt storages log/status/etc". This is regurgitating the FHS, but the vast majority of vendors dump their poo poo in /opt (all of it) and dump their logs in /var/log. In a perfect world, I guess this /var/opt stuff would happen, but not in reality. Also, "additional software installed on the system" means "that tarball for Oracle or Tivoli or whatever", not "stuff you install from yum or optional RHEL components (except Ceph, which I think is still in opt)"
  
• Chapter 3, "more and less": always use less. more is a nightmare, especially with huge logs that can trigger the OOM killer

• "You have to assume that people did not come to work to do a bad job (otherwise, don't turn to human factors as a field of explanation).
  
• "Bad language ... implicitly puts up a standard of what is 'good' practice and then judges the observed performance deficient by that standard."

• Starting off, "$ as the sign for regular users and # as the sign for the root user" is actually a prompt variable called \$. This is potentially confusing when dealing with the variable interpolation he uses for PS1 later. $ and # are not at all fixed, and setting PS1 without \$ means this won't be present
  
• I find the entire "this introduces the concept of subshells" bit on the first page misleading, because it doesn't actually introduce the concept of subshells at all. A subshell happens when another instance of the shell is invoked inside yours. You could do it by directly calling "bash", but the most common case is running a script which starts with #!/bin/bash
  
• The bits of "export PS1" look like magic, and are double confusing with the \$ variable above. So let's be clear. $LOGNAME will never change. It's evaluated once and only once, when PS1 is set. Because "\$PWD" is escaped, it's evaluated every time the prompt is redrawn. Change this to "$PWD" to watch it never change. Surround it with single quotes instead of double quotes, and that '\$' is suddenly interpreted as the prompt special character '\$' above, and it'll become '$PWD" if you're not root and "#PWD' if you are. This substitution section should be after his bit on escapes and quoting later. Come back and play with it after you read that, because this "export PS1..." bit is a good example of how learn escaping.
  
• 2> /dev/null works because bash opens file descriptors 1 and 2 for stdout and stderr by default. You can override this if you want, or open new descriptors. I'm only commenting to make this seem less magic. 2 is not magic for "STDERR".
  
• Regular expressions -- just to clarify, bash itself does not recognize regular expressions (for Linux people, I'm ignoring =~ in scripts here). It's grep and sed and other utilities which do, but "grep ^root /etc/passwd" doesn't match ^ as a function of bash. That's grep doing it. I'm clarifying so you don't try to use this with ls or other utilities. You can however....
  
• Metacharacters (and globbing) -- He says "we covered ^ and $ earlier". Which we did. But didn't. They're very different things, and they do different things (^ is used inside brackets to invert a match, $ will go do variable interpolation). Please read this and this. Really.
  
• "Listing processes by User and Group ownership": if it's not obvious (and he doesn't explain), a question mark under the "TTY" column in "ps" means it's not attached to a tty (which your shell is, and other login prompts are -- physical logons are tty, ssh is pty, in general).
  
• "Zombie" -- "it's retained until the parent process permits it to die". Well, no. It hangs around until the parent reads the exit code, then it gets "reaped" by init (the process gets terminated). The parent "permits it to die" by reading the exit code. It's just hanging around as a zombie to say "hey, I exited with 255" or whatever. "echo $?" to view the exit code from your last command. Success is 0. Not success is not. "ls abcdefg" will be 2, for example.
  
• Process states: this is also another bad generalization. Most daemons implement a signal handler that tells it to re-load its configuration on SIGHUP. But if you write a program (or a bash script, or whatever), you can write your own signal handler which ignores SIGINT. And SIGHUP, SIGUSR, and all the rest won't do anything unless you specifically handle them. You cannot handle SIGKILL or SIGSTOP without doing it in the kernel, but any application may do whatever it wants (or nothing) on many of these signals.

• Packages are certified? I don't even know what that's supposed to mean. Hardware is certified. Vendors certify their applications to run on RHEL. Our packages aren't really "certified" in any real way. Signing is part of the release process, and that's our "certification" that it's good enough
  
• RHSM and SAM: why bother even talking about these? I work for Red Hat and I've never had to look at SAM, and he goes into a very confusing paragraph then says he's not gonna talk about it. The RHSM part could have been useful if he added screenshots.
  
• Querying packages: possibly the most important part got missed, which is that all of these can be combined. If you read the manpage for rpm, you'll see a whole list of stuff you can do when it's in "query" mode. You can combine them in almost any combination. You can do "rpm -qpl /path/to/somepackage" to list what files are in an RPM you haven't installed. I'd also say that "--filesbypkg" is somewhat nicer than "-ql"
  
• "rpm -U" makes a backup of files with ".rpmsave". yum does better by saving the files it would replace as ".rpmnew" You should use "yum localinstall" instead of "rpm -U" most of the time.
  
• The output on the top of page 145 is hilariously wrong. He says he's gonna install ypbind, actually tries to install system-config-keyboard, and the output says it updates zsh. Editor!
  
• Along with yum history, rpm keeps a history. "rpm -q --last somepackage" shows you the last time it was updated or installed.
  
• gnome-packagekit is going away and isn't even part of a base Fedora workstation install anymore. Learn yum. Love yum. Almost all of it will transfer to dnf later.
  
• Chapter summary: did I miss something in this chapter? Why is it asking about rhn_register and rhnsd? It didn't talk about those at all, and you should be using subscription-manager instead of rhn_register. Missed questions from a RHEL6 book?
  
• Also, yum does have a limit to the number of commands it can install. It's academic for yum, but there is a definite limit to MAX_ARG_PAGES that the shell is limited to. Every so often you'll see a shell expansion (like "rm *") spit out "argument list too long" (since * actually evaluates to "the name of every file" when it passes in -- try "echo *"). Good luck typing that many packages in, though.

• Looking for sources of failure far away from people at the sharp end is counterintuitive. And it can be difficult. If you find that sources of failure lie really at the blunt end, this may call into question beliefs about the safety of the entire system. It challenges previous views. Perhaps things are not as well-organized or well-designed as people had hoped. Perhaps this could have happened any time. Or worse, perhaps it could happen again."
  
• "People and organizations often want the surprise in the failure to go away, and with it the challenge to their views and beliefs. The easiest way to do this is to see the failure as something local, as something that is merely the problem of a few individuals who behaved in uncharacteristic, erratic or unrepresentative (indeed, locally 'surprising') ways."
  
• "Faced with a bad, surprising event, we change the event or the players in it, rather than our beliefs about the system that made the event possible. Instead of modifying our views in the light of the event, we re-shape, re-tell and re-inscribe the event until it fits the traditional and non-threatening view of the system. As far as organizational learning is concerned, the mishap might as well not have happened."
  

Vulture Culture fucked around with this message at 07:25 on Jun 4, 2015

• "The occasional human contribution to failure occurs because complex systems need an overwhelming human contribution for their safety. Human error is the inevitable by-product of the pursuit of success in an imperfect, unstable, resource-constrained world."
  
• "The reconstruction of mindset begins not with the mind. It begins with the circumstances in which the mind found itself."

• "Cause is not something you find. Cause is something you construct."
  
• "This is how practitioners create safety: they invest in their understanding of how systems can break down, and then device strategies that help forestall failure."
  
• "What you call 'root cause' is simply the place where you stop looking any further."
  
• "Some investigators get so frustrated with the need to present a 'probable cause' that they simply pick the last technical event that, if removed, could have prevented the mishap from occurring.

Vulture Culture fucked around with this message at 08:24 on Jun 4, 2015

• "The problem with the linear thinking behind sequence-of-events models is that it is easily outrun by the real complexity of real systems."
  
• "...Looking for causes in a sequence of events is a bit like a drunk outside in the night, looking for his housekeys. He looks for the keys not where he lost them, but in the light of the streetlamp. That is, after all, where the light is better."
  
• "The challenge is to explain why people gradually come to see deviant behavior or system performance as normal or acceptable, not judge it deviant from the outside and hindsight."
  
• "Systemic models see accidents as a by-product of the normal functioning of the system, not the result of something breaking down or failing inside of that system."

1. Have participants tell the story from their point of view, but do not provide them with any outside information which might lead their memory and impact the way they recall the situation
   
2. Tell the story back to them to ensure you understood it the same way the participant understood it
   
3. With participants, identify what you and they consider to be critical moments in the story
   
4. Rebuild the situation to them, and attempt to fill the gaps, possibly by showing replays or data that does not fit their description of events