First computer – Tesla PMD 85-1

Once in a while people ask me what was the first computer I could get my hands on.  Mistakenly, I’ve often answered that it was Commodore 64.  But today I did some digging and realized that it wasn’t true.  I did use Commodore 64 too, but that was mostly for playing games – my uncle was a head of a nearby Fire Station and he had one of these in the office, but that wasn’t the first computer I used, and it wasn’t the one I learned to program on.  That honor goes to Tesla PMD 85-1.  Here is a picture to give you an idea (thanks to root.cz):

pmd85

We had a computer lab in school, with 11 of these things.  10 were used by the students and 1 was for the master station for the teacher.  Some of the highlights that I still remember: black and green monitor, cassette tape drive for loading and saving programs (sorry, no hard drives or floppies, or network really, except for printing on a slow and very load dot-matrix printer), a very uncomfortable yet colorful  keyboard.  The keyboard is worth a separate mention.  As seen above, it had blue, red, and grey keys.  It didn’t have an Enter or Escape keys.  But it had two EOL (end of line) keys right next to each other – I don’t remember why though.  And STOP and RST (reset) buttons.  And it was almost QWERTY.  Here is a close-up image from Wikipedia:

PMD_85-1

For some reason, I remember the keyboard slightly different.  Those blue K-keys were to the left of the main area, organized into two vertical columns.  But I was unable to find an image of such model, so it must be my memory failing.

When I was back in 5th grade (that must have been … hmm … somewhere around the year 1990), a new Informatics (that’s how Computer Science was called back then) teacher at school opened up an after hours Computer Club, which allowed all students, and not just the high graders access to the machines.  I don’t remember the name of the guy, or how I got involved with it, but I do remember that I got hooked on it pretty much immediately.

A few times a week, we’d stay for an hour or two after classes and learn Basic programming language.  He’d explain to us some basic concepts such loops, conditions, and variables, and then would let us work on our code.  For the rest of the days, I remember, I was walking around with the paper notepad, in which I’d write source code by hand, debug it, test it, and improve it, so that I could spend less time doing so in the lab.  Machine time was limited (an hour or two per session, with some of it taken for loading the program from tape, typing in changes, and saving back to tape), so you’d optimize for using it to actually run the program, verify the result, and, maybe, try one or two more ideas.

If I remember correctly, I worked on these machines for two or three years.  Then, my other uncle, who was the first real IT guy I knew, got me an IBM XT machine.  It wasn’t an original IBM, but a mix of Soviet countries manufacturers.  But that was great!  That was the closest thing to the modern PC – CGA graphics with 4 colors, 640 KB of RAM, 10 MB hard disk, and a floppy drive!  I thought nothing better was possible until I saw a VGA monitor with 16 colors.  I think then I realized that I’ll never catch up to the technology developing so fast.

And one last bit of memory.  Even though I wrote quite a bit of Basic code while learning English in a specialized school, it wasn’t until I came to Cyprus and started learning Pascal programming language in Intercollege, that I realized that all those words I’m typing into the computer to make it do things are ACTUAL ENGLISH WORDS!  Now that was both embarrassing and empowering at the same time…

Oh, good old days.

P.S.: Yes, I’ve played on Atari too at my friends’, but I never owned one of those.

10 Years of Git: An Interview with Git Creator Linus Torvalds

AtlassianGit10year

Linux.com reminds us that git is celebrating its 10th birthday this year.  An interview with git creator Linus Torvalds sheds some light on to how and why it happened, and how long it took.

You can actually see how it all took shape in the git source code repository, except for the very first day or so. It took about a day to get to be “self-hosting” so that I could start committing things into git using git itself, so the first day or so is hidden, but everything else is there. The work was clearly mostly during the day, but there’s a few midnight entries and a couple of 2 a.m. ones. The most interesting part is how quickly it took shape ; the very first commit in the git tree is not a lot of code, but it already did the basics – enough to commit itself. The trick wasn’t really so much the coding but coming up with how it organizes the data.

So I’d like to stress that while it really came together in just about ten days or so (at which point I did my first *kernel* commit using git), it wasn’t like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right.

Very impressive!

And, of course: HAPPY BIRTHDAY GIT!  The world is a much better place with you.

The Secrets of the FBI by Ronald Kessler

secrets_of_the_fbi

The Secrets of the FBI” is the second audio book by Ronald Kessler that I’ve listened to.  I enjoyed it much more than “In the President’s Secret Service“.  This one covers the history of the FBI in much more detail, and provides both insider’s perspective and a bird’s eye view of how the FBI was created, evolved and got the where it is now.

One thing that I found very interesting was how much an impact each of the directors had on the development of the FBI, and how different these were.   Also, descriptions of technology evolution in the FBI were particularly interesting to me.  The state of the computeres by the 9/11 was especially depressing.  I nearly couldn’t believe what I was hearing…

Overall, I’d recommend this book to anyone interested in law enforcement history, government projects, and special tactical units.

What is the shortest and most effective code ever written?

Quora runs the question, that by now has plenty of awesome answers.  But this one is my favorite so far:

The ‘true’ program in Unix from the 1970s was an empty file. The shell interpreted that as a shell script which ran and resulted in no error status, so the result was zero. Zero is the shell exit code value that represents ‘success’ or ‘true’ within if and while clauses.

So, no program can be shorter than that. And it was entirely effective at meeting its specification.

False was much longer, being

exit 1

Once lawers got in, both programs were sullied with plenty of copyrights. BSD also eventually established a format for identifying shell scripts explicitly, and those codes got added to the file too. Eventually, ‘true’ stretched to hundreds of bytes of copyrights on top of the shell script format intro code. Now, annoyingly, Linux and Mac OS have made it a compiled binary program. In Ubuntu, it is a 22K binary with an 18K code size. Ugh.

At least writing a correct C program for true can be very short. It is one of the few C programs that should require no #include files, and can be simply:

int main(void){return 0;}

Of course make sure to add lots of copyright notices.