The book-writing process is really good fun, and gives some opportunities to dive into things that you would otherwise never get around to. The schedule can be tough at times, but taking an hour, an evening, a week, to get really into a topic and find the best way to share it with the rest of the community is a very rewarding experience.
Tonight I've spent a few hours getting into the MBR structure, and finding
od to be a more than worthy tool to tackle it. Something as low-level as the MBR is one of those things where C (or even assembler) is the obvious language to choose, but in fact the shell is more than capable of dealing with it, and od makes it totally painless. Have you ever used
od -t x1 ? You should. It's an awesome tool, and massively underused.
Read the od(1) man page
Shell Scripting Recipes is due out this August. It's got lots of recipes for useful (and a few zany) things to do in the shell, as well as a thorough tour of the features of the Bash shell (including loads of new stuff in Bash v4) and ways that the shell can interact with the Linux kernel itself.
Unlike some other Linux or Bash books it maintains a sense of context and history, because there is much more to shell programming than GNU/Linux. My free online tutorial is fervently UNIX/Bourne compatible, with a real focus on portable scripting. The book gives me the opportunity to take things further, addressing the great stuff that GNU (particularly Bash) and Linux add to the existing functionality of UNIX.
All of this
od functionality is pure UNIX though. Do you know
paste as well as
Also, if there are things that you do want the book to cover, it's not too late; get in touch via the mail me link on the left, or send email to firstname.lastname@example.org.
Does this look like a shell to you? It does to me.
The NHS NPfIT scheme is still a mess; apart from a bunch of links that I have had to update at http://steve-parker.org/articles/idcards/ due to nhs.uk documents going down, I now find http://www.nhscarerecords.nhs.uk/faqs/ which claims that:
Who can see my Summary Care Record?
Only NHS healthcare staff involved in supporting or providing your care can see your Summary Care Record. Healthcare staff who can see your Summary Care Record:
- need to be directly involved in caring for you;
- need to have an NHS Smartcard with a chip and passcode (like a bank card and PIN);
- will only see the information they need to do their job
The same document says that "If they [ healthcare staff ] cannot ask you, for example if you are unconscious, they may look at your record without asking you."
The "for example if you are unconscious" is key here. What if they can't ask you because you miss their phone call, or you don't hear them, or because they forget to ask at all?
The whole "NHS SmartCard with a Chip and PassCode" curtain disappears.
This is a clear statement that all of these bullet-points are untrue.
This document, in itself, defies its own claims. It admits that anybody with anything to do with the NHS can access your own personal details.
It also points out that if you are under 16, you can not access your own details. Everybody else can, but not you.
Richard Stallman, founder of the GNU project and the Free Software Foundation, is doing a speaking tour of the UK and Europe.
See the IET for schedule and details (this link is the London one; all the others are linked from the schedule page above).
Never send passwords by email or indeed in any electronically copyable format.
In this case, the question was, is the password still 88j4bb3rw0cky88 or is it now 88Scr3am3r88?
Stripping out the 88 at either end, the password is either jabberwocky or screamer, passed through various filters. There was no need to include the exact password. There was also no need to mention both passwords. If Greg had asked "is it scream yet"? then no password would have been exchanged, and Jussi would have been able to answer "No" whilst still giving a useful answer.
Even if Greg had asked "is it still jabber?", a lot of work would still need to be done to brute-force the password.
The 88 technique (especially if regularly changed, and better still if something random but different is put at the start and end of the password) is a reasonable way to avoid rainbow tables. Pasting both possible passwords verbatim into email drives right through what otherwise appears to be a reasonably well-planned password policy.
What is particularly frustrating, is that Greg apparently knew what the current and next password would be, but didn't simply try them both before sending them both in plaintext email. These user errors (PEBCAK) can undermine the best password protection strategies.
Debian 6.0, codenamed Squeeze, was also released this weekend: http://www.debian.org/News/2011/20110205a
Thanks for that, NextGenHacker101. I really thought that I knew how traceroute worked, but I now realise that I was wrong.