I won’t pretend that I’ve read it. I’ve read critiques of it, I’ve read a book that heavily relies on it and I’ve gifted the iPad app of it twice I think. But now, according to Wolfram, it is available for free download:


You can download each chapter individually in PDF and use something like pdftk to concatenate them.

No, I will not even pretend that I will try to read this. I have other weird books in the pipeline. But still automata appeal to me, so the occasional glimpse may happen. Then again, the web version has been there for years and I’ve browsed it very few times.  Time is a resource that I cannot devote to Wolfram’s thought it seems.


Δεν είμαι φαν του Πετρίδη και του Ζουγρή. Περιστασιακά τους άκουγα και ακόμα σπανιότερα τώρα (είναι κάπου μετά το Βήμα FM, δεν ξέρω). Όμως έστω και έτσι μια κάποια ανακούφιση μου την έχουν προσφέρει (ειδικά την περίοδο της Θητείας). Το να “κεράσεις” έναν εσπρέσο τον Πετρίδη δεν είναι κάτι παράλογο, ειδικά αν σκεφτείς σε τι μπούρδες και απίθανους ανθρώπους έχεις δώσει τα λεφτά σου κατά καιρούς.

Και πόσο πιο καλά νιώθεις όταν σου στέλνει για ευχαριστώ ένα PDF με τα 200 καλύτερα rock album κατά τη γνώμη τους. Μπορεί να μην τους ξανακούσω ποτέ, αλλά πλέον μπορώ να ανανατρέχω.

Πατήστε “donate” στο site τους: http://www.apotis4stis5.com/

The Goal


Well if you’re doing DevOps (whatever that means for you) you’re supposed to have read The Phoenix Project (which I have). Inside the Phoenix there are constant references to Visible Ops and The Goal. Well, The Goal is a something of a gospel it seems so I went ahead a few months ago and read it.

It is a far better book to read than the Phoenix. Much more entertaining and insightful. I guess Goldratt is a better writer. The book does a hell of a good job to explain the basics of The Theory of Constraints which receives new attention in this age of software automation and pipelines and the perceived “clash” between DevOps, ITIL and any other related acronym. I see ToC posts pop up weekly now. The only thing that you may not like in the book is the technology from the 80s, but only if you’ve never used it.

My best part was the really nice simulation example it used to make clear a counter-intuitive result and his family crisis management. Granted, many things went the right way for the main hero, but hey, the author was trying to make a point and needed a vehicle. Fiction is not life.

I read it from the latest kindle edition. According to my Kindle I am still at 97% of the book and that is because right after the end of the book there is a paper explaining some of the concepts with real industry examples. The boredom to read this after the turmoil the hero has gone through is evident. It also explains why the author needed a novel in order to engage you in ToC.

Like a good friend said: “I really want to get in the book and help him out!”

Memory gets triggered in the most unexpected ways. I maintain a fairly large library of printed and electronic books (most of them DRMed -the light cases socially, kindle and Adobe locked the rest unfortunately) on subjects that interest me. It is fairly evident that I will not read them all, but I always have a book (and sometimes a paper) to recommend to a friend that has a problem. It seems that I am not the only one that thinks that personal libraries are supposed to be full of unread books.

Anyway, I was listening to Podcast.__init__ Episode 95 and one of the guests mentioned Parsing Techniques – A Practical Guide by Grune, I think it was when they touched Earley parsers and how most books about parsing do not really touch on how the actual parser is built. Wait a minute I’ve got that PDF! And you can go to the author’s site and download it. And you know what? There is a second edition out. For > 100 euros for a DRMed PDF I may not buy it since parsing is definitely not my thing, but somebody else out there might need the second edition. Judging from my skimming of the first edition, this is close to the encyclopaedia of parsing. I will go through some pages tonight.

Just for a refresher.

That’s the bear trap, the greatest vice. Your job. You can justify about any behavior with it. Maybe that’s why you do it, so you don’t have to deal with all those other problems.

I never expected to find the explanation of BOFHiness in The Soul of New Machine. The book lived on my wishlist for a long time and it was gifted to me, only to wait there inside the kindle for a couple more years. Tracy Kidder follows the team that built Data General’s Eagle, their first 32bit machine and a kind of Plan B for the company, since the market was being dominated by the Vaxen and they had to react. Serious computing history unfolds in front of you.

A very interesting story, and lucky Kidder got to follow a lot of the story in the making, even though this was supposed to be a secret project. While this is not a hard science book, you get to learn a lot about computer architecture, or depending your skills, computer architecture history. You get to understand the magic that happens when your keystrokes are transformed into the desired result. The moment when the software and hardware connect. I particularly enjoyed the chapters about debugging boards with an oscillator.

While I cannot claim the brilliance of Tom West, I do see elements of similar behavior and the reasons for this. I need to work on that.

Thus he supplied them one answer to the question of what happens to computer engineers who pass forty.

I reached 44 yesterday. Still not a middle manager.

I really like Bob Frankston’s essay about The Regulatorium and the Moral Imperative which links to stuff that the first pages of Technologies of Freedom (which I am currently reading) touch on. But when I read the following, I couldn’t help linking it to both the Regulatorium and Pournelle’s Law:

“In a series of valuable reports, [Ralph Nader] and his associates have confirmed dramatically what earlier studies had demonstrated less dramatically – that governmental agencies established to regulate an industry in order to protect consumers typically end up as instruments of the industry they are supposed to regulate, enabling the industry to protect monopoly positions and to exploit the consumer more effectively.”*

Or as a good friend once pointed out: It is hard for them to press hard their (most likely) future employers.

Read the rest of this entry »

We were interviewing someone for a DevOps position. They were working at a managed network / security services company and needed to change a life and career. Their work was pretty much summarized as “A client files a change request; we implement it at the network device and we’re done”.

No provisioning, no automation, no versioning of configurations was in place. The candidate was not in a position to write code also. Since they were clearly more junior than the position required, we were saddened and in a way gave them some subtle advice to improve on their skills in order to have better luck next time they knock on a door:

  • Learn to program in Python.
  • Do that because you can learn to code with paramiko and Netmiko.
  • Learn some basic git usage.
  • It does not matter that your employer does not require you to automate stuff and practice version control. You will write a program in Python that will ssh into the client’s equipment, backup the configuration in git and push the requested changes back.
  • You will have automated your work and will have more free minutes per day to read about stuff.
  • You will have more to talk about in your next interview.

When you’re not pushed by the environment, you need to begin from somewhere. Oh and understand some basic statistics, because you will need to understand what you graph. It should not only be pretty. It should be useful.