Blog Without An Important Name

Here a point is made that I find is becoming a problem (for me, anyway) in movies and books. The problem comes when the author (or scriptwriter, or whoever) tries to be realistic in a field they don’t really know. If it happens that this field is something that I know about, and the author gets it wrong, all of a sudden any suspension-of-disbelief is immediately lost.

Unsurprisingly, many movies these days include references to computers. That’s all well and good, I can put up with some liberty there. I can handle “Movie OS” scenes where the person opens a file, and a flashy 3D visualisation shows it opening on the screen. I’m desensitised to that by now. However, when they try to get a bit deeper into it, that’s when everything starts to go wrong. The prime example in my mind is the movie “Swordfish”. This has a great scene where the “hacker” has to break into a machine in 30 seconds, from the password prompt. Apparently, it has “256-bit AES encryption” or something. A valid enough statement, but has no relation to a password prompt, nor breaking into the machine from there.

I find that this extrapolates quite cleanly into things that aren’t supposed to be fiction, also. It turns out that a certain amount of suspension-of-disbelief is required to read the newspaper. Usually, if you’re just reading it without thinking, you (well, I) tend to take for granted that the things it says are correct. This house-of-cards comes falling down the moment you read an article on something that you have first-hand knowledge of…and the reporter gets fundamental things wrong. (This was brought home to me today when looking up the date that something was on. One source said it was on the 20th, another said the 19th. Fortunately I erred on the side of caution and got it right). All of a sudden, all confidence is lost in everything else said in the paper. It’s somewhat unfortunate that this state doesn’t seem to last all that long.

I think that this reminder that “things may not be exactly as they’re written” is something that needs to be reinforced. It would be nice to be able to switch it off when watching/reading something fictional that tries to be taken seriously, however.

A few years ago, I learnt LISP at university. Just for a semester, write a poetry generator, things like that. All pretty simple. I didn’t get into it much at the time, beyond what I had to, but I do remember thinking that it looked like quite a powerful and fun language.

A while ago, someone on Slashdot mentioned LISP and referred to a book that was online for learning it. So I checked it out, and it seems to be pretty good. I’m about half way through it. It has the large amount of basic instruction in the language, which is always necessary. However, after a while of that, it has a chapter on ‘Practical’ stuff, which involves implementing actual code, which is a good change, and a nice place to read chunks of code, put them into the interpreter, and play with them a bit.

Normally when reading books on programming languages, I get frustrated when they start explaining “This is a variable. You can store values in them. You can also change them. …”, as it’s a concept I’ve seen over and over, and so is quite boring. This isn’t the case here, I don’t know if it’s because LISP is different enough from the languages I usually use that it seems new, or the book just manages to avoid these kinds of problems.

If I see it lying around (or maybe even if I don’t, and I just get paid enough one day), I think I might pick up a dead tree copy.

Oh, and the book itself? Practical Common Lisp.

Going Postal by Terry Pratchett is a good layman’s introduction to network security. It only covers a few points, although they are significant ones, some of which are not often discussed:

• Social engineering
• Authentication
• Redundancy
• Robustness

The book itself teaches about these from an unusual point of view, that of looking at things from the point of view of an attacker. It is written as though it is one large anecdote that makes all these points in the course of the telling. It’s useful for those who may not understand the details of networking so deeply, as it makes heavy use of metaphor to illustrate the points.

The network described is the primary means of long-distance communication for a group of people, and the attacker uses weaknesses of it to exploit it for his own ends. As these weaknesses, which are the ones listed above, are presented, you are shown the means and method of the attacks directly through the eyes of the attacker.

It is also worth noting that the author takes an interesting moralistic approach. Where most books from the attacker’s point of view don’t put things in bad guy/good guy terms, and most books from the point of view of network security staff do, this one reverses the normal roles. In Going Postal, the attacker is seen as the ‘good guy’, and the owners of the network are the ‘bad guys’. It also contains the interesting view that the network operators specifically aren’t seen to be bad, but merely doing the best they can under bad circumstances.

The main flaw is that, while the weaknesses described are brought to the readers attention, few specific solutions are presented. This may be something of an asset for the book however, as it will certainly prevent it from becoming out of date, as many standard technical books do.

It’d recommend this book to anyone who wants to get a general feel for network security, or likes a good long-running anecdote (one might almost say ’story’).

[OK, serious bit now. I've not read much Terry Pratchett (to my own detriment), but all I have read were very fun. This book certainly doesn't go against that in any way. Go read it!]

I’ve just finished reading Big Blues: The Unmaking of IBM, by Paul Carroll. Published in 1993, it’s a bit out of date now, but it provides an interesting look into the mid-80’s to early-90’s IBM. This was a time when it went from being the largest US company, to posting a loss greater than the value of the second largest.

The points made in the book as to the cause of IBM’s troubles were made extremely clearly, and over and over. It’s hard to tell if that’s because they’re the issues that author identified and wanted to make sure the reader knew that’s what they were, or if it was that those problems were so institutional that they came up all the time. Based on the anecdotes and descriptions, I think I’m erring toward the latter.

There are a couple of major points that, according to the author, were largely the cause of the company’s downfall:

• Massive beaurocracy causing even little things to happen slowly,
• An extreme unwillingness to allow change, or even see that different markets behave in different ways

These never became such problems when the company had an 80-90% market share with it’s mainframe systems. But when cheap personal computers were being developed by much smaller, more agile companies, the competition in a new field meant that these problems became devastating, as IBM couldn’t change to make itself fit the new market, and couldn’t see that it had to. The main difference between these two types of customers is that in the mainframe market, IBM could pretty much dictate what the consumer would get. In the desktop market, costs mattered a lot more than a name brand.

There were some truely impressive examples of the beaurocracy, and the struggles to fight it. It was found that often the only times that a department did well was when it was separated from the rest of the company. Two main examples of this were the PC department (remember the terms ‘IBM XT/AT/PC’?), and the Lexington typewriters department (later Lexmark printers). However, at least in the case of the first one, once it managed to succeed, it was reabsorbed back into the fold, killing it. There were also many stories of good plans that were made to travel the length and breadth of the company, but all it took was one person feeling like it was stepping on their turf, or had the potential to cut into their product sales, and it was effectively stalled.

The company intertia is something that seems to be self evident, a large company can’t usually turn on a dime. However, if the book is remotely accurate, time and time again the culture got in the way. Things like refusing to sell computers at low prices to make it competitive, simply because it’s unthinkable that mainframe hardware profit margins can’t be made on consumer-level hardware also. Another major blind spot was that it wasn’t until many years of being pounded by competitors that the management started to realise that the IBM stamp wouldn’t be guarenteed to sell hardware to consumers the same was it would to corporate clients.

Another interesting part of the book deals with the relationship between IBM and Microsoft, particularly the mismanagement dealing with the production of OS/2.

The only problem I had with the book, or rather writing style, was that it is prone to having a new chapter restart the timeline back in the 80’s, which makes it hard to keep a mental timeline of all the events. However, I suspect that the alternative of having it go purely sequential would be even worse, as there was a lot going on all the time, and following mostly logical paths as it does is probably the best way.

It’s unfortunate that the book was written so long ago, I’d quite like to see something in similar detail about the change since then, from a hardware company into a services company that is actually starting to become significant again. There are a few points in the book where it is dealing with things that are being developed in early ‘93, and uses names that I’ve never heard of, so I expect that they’ve vanished the same way so many other IBM projects just a short time earlier did.

Recommended reading for anyone with a bit of an interest in computer industry history.