We've used them as a more reliable/resilient/replicated (with a lower operational effort) provider of HBase tables and Kafka streams, and a bit of file storage.
This is about WiFi "protected" with WPA2: basically treat it as suspiciously as you would any public WiFi.
If you choose not to use public WiFi because you can't "trust" it, then you now need to stop using your private WiFi too (until your systems get appropriate patches).
Well that's an article written by someone who's never submitted an app, that uses encryption, to the App Store.
They're big on ensuring you've applied for the correct export licence from the USA (because that's where the distribution is technically made from), even if you're based outside the USA.
(Google just make you say you have, but Apple actually want to see the approval doc)
(Cheat sheet? Cheat Novella, more like! I think it's probably past the point where it needs to be split up a bit, even if only for your own benefit.)
"How do you check disk usage. How do you trouble shoot a high disk usage issue"
which is fine, until someone's done something similar to the next bit of advice - i.e. deleted some "old", large files that were still open by the application.
Better: compare filesystem usage (with df), against disk space used (with du), to deduce that there's an open file that has been unlinked. Then use lsof (whatever Sun say about pfiles or about dtrace, lsof is an essential tool) to look for processes with open files that have large offsets.
And, when deleting large files, check whether they're open, and truncate them before deleting them if you're not sure.
(note to another poster - ain't nothing wrong with Solaris! But I'm not really sure what interviewer might ask questions about the OSI 7 layer model, these days, and I agree that there's a real odd jumble of scripting snippets in there: best advice to anyone wanting to improve that side of their systems administration skills, is to read a copy of Unix Power tools.)
It's painful to watch Unix SAs who don't understand shell scripts (which are, after all, a way of automating repetitive command-line tasks), because it is such an essential part of understanding the OS and how it works.
I think it is important to know when to use a quick shell script, and when to solve the problem with some Perl (or even some C.) Sometimes it is quicker to throw together a shell script, with a bit of sed, awk, or some simple for loops, automating the command line you just manually ran a moment ago; sometimes it's best to solve the problem by switching to some Perl.
