In the picture below, we have the “Knight’s Castle” kit from 1984 (set #6073). I remember this as being a major kit at the time, one of the dream things to buy, and one of the biggest ones around. Compare it to the new Police Command Center (set #7743) from 2008. The small police station accompanying the large trailer is as high as the old castle, and the trailer as long as the castle is wide. It has about 25% more pieces that the old castle.

Also, note the old small vehicles in the front. Four Lego notches wide, unlike the six-wide police trailer. I remember the highway truck as being one of the magical models of my childhood.

To me, the most interesting aspect of comparing Lego sets is that it is a very good illustration of the economic growth that we have seen over the past 30 years. In relative terms, Lego sets have become far more affordable. Average income has certainly increased faster than the price of Lego, and my kids have quite a few more pieces to play with than I did at the same age. The nice thing with comparing Lego buying power with my childhood is that it is a product that is mostly “the same”, unlike comparisons involving electronics…

The silly thing is that I don’t have a strong recollection of it. My most vibrant memory from that tumultuous Fall is from December, as we saw tanks roll through the streets of Bucharest on TV. I saw it on the American Armed Forces Network, to be precise, a night on the base with my friends from Keflavík Naval Air Station, also known to the Icelanders as “the base”. This was during the year I lived in Iceland, and went to school on the AT Mahan High School on NAS Keflavik. Sometimes I would sleep over on the base with some friends, despite being a “neutral” (non-NATO). But I digress…

The impact of the wall coming down was felt much more clearly the next year, when me and some friends drove down to Berlin. The wall was gone, but the space it had left was still there. The trade in East Bloc memorabilia was rampant, and we had several East German military caps and some cool medals with us as we drove home. Indeed, for the next few years, East Bloc and Soviet stuff was all the rage.  I actually found the cap when we cleaned out some boxes of old memorabilia the other week, guess it was fate. Or just coincidence.

It feels strange to know that the freshmen in university this year were not even born then. They have no memory of the cold war, and newspaper articles carry sidebars about “this was the DDR”… to the youngsters of today, DDR means dual-data-rate RAM, not the Deutsche Demokratische Republik.

1989 was also the year that I got my first Macintosh. An SE, with a 8 MHz 68000 processor and 2 MB of RAM, and 20 MB of HDD. It is dizzying to compare it with the machine I have at home today, a cheap Core i7 Dell. The processor is probably around 2000 times faster (300x clock, and at least 6x more efficient per clock), the memory is 4000 times bigger, the HDD 30000 times larger. Still, it does not feel as magic as that first Macintosh did… The next year, I got myself an SE/30, with a 16 MHz 68030 and an 68882 math co-processor. Screaming machine at the time, total clunker by today’s standards.

Finally, what other big events have I seen, events that you can peg a date and a memory on? The second biggest one is the killing of Olof Palme on Feb 28, 1986. Then we have “September 11″ which was quite a shock. Chernobyl. U137. I have no personal relationship to the other two big recent disasters of Sweden, the Estonia disaster and the Thailand Tsunami, but they could have counted otherwise.

Still, the end of the cold war is a big deal, and the way in which it opened up Europe to what it is today.

I think this is an excellent way to promote the magazine, as it provides a hook that is for free for interested potential readers, and also a natural push for getting the magazine when they mention “for more details, please see the article so and so in the current issue”. At least to me, that is perfectly fine.

It also resembles the use of conference talks to promote books, where you also point to the published paper edition for more details and in-depth coverage. Unfortunately, I don’t think this is a model for the music industry as their goods lack that kind of depth…

Now, if only I had time to actually read the magazine… but I might buy some issues to read in a few years time when the kids are a bit older.

The Spitfire development starts with an excellent basic architecture for the aircraft, including the wing shape, the long nose, and the low pilot position. This offered a good basic design that lasted until the early jet era, and that was still competitive in 1945 (with lots of upgrades to engines and armament and equipment along the way).  What is truly fascinating is the detail work that went into turning that good design into a practical fighter aircraft.

Especially the performance and measured in terms of simple top speed. Here, the engineers fought a constant battle between the requirements of armament and electronics and engines and the need for as clean and streamlined an outline as possible. It was a constant attention to little details, adding things, testing the their effect, redesigning or scrapping feature. It is very similar to how we develop software today, where adding features might help some users — but often at the price of more complexity, longer critical paths, and lower absolute performance.

For example, early prototypes had a simple skid instead of a full tail wheel, as that skid was more streamlined and cheaper to build. But flying from a hard-surface airfield required a wheel, and in the end the Spitfire had to use a retractable rear wheel, which was not in the original design (RAF had decided to upgrade their airfields, and this requirement was introduced fairly late in the process). It cost some weight and complexity, but increased top speed by several miles per hour. Once again, we see the same kind of pattern in software development: you can gain performance at the cost of complexity somewhere else. Advanced optimizations tend to rely on quite complicated techniques to make the common case fast, where simpler implementations feature lower performance but shorter development time.

Simulation was also used in a very clever way. In one series of experiments, the question was asked whether simpler cheaper rivets with domed heads could be used instead of complicated flush rivets. To check this, they glued peahalves to a prototype aircraft to simulate various configurations, and in the end concluded that it was fine to have domed rivets on most of the body, but that the wings absolutely required flush rivets. Very ingenious experimentation I think. And a story that should be familiar to anyone who has done some optimization work on real-world software: some things that seem “necessary and right” actually do not have the expected benefit for the cost (flush rivets on the body), while others are crucial (flush rivets on the wings). You typically do not know until you have tried. Just guessing is usually a bad guide (I just read an article at Embedded.com about the misguided attempt to establish an “Embedded C++ subset” in the mid-1990s that is a perfect example of this).

Other examples of the battle with speed was that adding radio aerials reduced speed by a few mph, as did the addition of extra cooler air intakes for stronger engines. On the other hand, a stronger engine also increased speed, so it was a good tradeoff in the end. There was a short-lived little air intake to provide driving air flow to cockpit electronics that cost a few mph and was promptly removed. It is actually quite fascinating to see in all aircraft of this era how little bumps and protrusions can have a significant impact on speed and performance. It was a case of “death by a thousand cuts”, as each little feature by itself can seem insignificant, but the total effect is dramatic. Here we also see a modern analogy in software optimization: while undergraduate courses in software teach you to identify “the big bottleneck” and “use a better algorithm”, most real-world software has no primary bottleneck. And here, just improving little things all over the place will have a pretty major aggregate impact. The Twit Podcast #167 has a discussion on how this is the case for Windows 7, where Microsoft has made big strides in performance by a lot of small improvements.

Thus, for software, you can also get “life by a thousand cuts”, by cutting out a thousand little pieces of overhead you can make your software way more lively.

In my world of computer simulators and virtualization solutions, this is a very familiar scenario. There are sound basic architectures (and less so), and for each type of architecture, the quality of implementation can make a marked difference in performance (and stability). I recently published a white paper on some of these aspects for Simics, which I think is a good example of a Spitfire-style design with a good basic architecture and lots of detail work to really make performance shine.

The picture shown here was saved as GIF for use on the web. But scarily enough, apart from a few more GIF files, I could not open or even understand the file type of most of the files from that time, only ten years ago. Our digital archives are not very robust — more on that below.

What is kind of scary is that apart from the various GIF and TIFF renderings of the logo in various uses (for usage on the primitive web pages of 1996 mainly), I cannot retrieve the design data. It is all inside FreeHand 4 or FreeHand 5 files, for the Mac platform, using postscript fonts that only worked on MacOS 7 and 8 with Adobe Type Manager. So even if the files themselves are salvagable using contemporary software in 2007, some of the basic data they are built from is irretrievable for me. I gave away my last old Mac five years ago, and it is now dead.

A bit scary. And a good example of when simulation of a computer system could serve us well as a way to preserve the entirety of old software environment. I think this is a typical case of when you need the complete system a document was built on and not just the document itself to correctly interpret it. I guess I should make sure to “freeze” some current system environment inside a disk image at some point, to have something to go back in the future. Provided some software behaving like a 2007 PC can be created and found.

Final note: it around this time that I designed the version of the “cons box” seen as part of the logo above. This served for quite a few years as the main style of the logo of the computer science program at Uppsala University. It seems to have fallen out of use now.

This particular issue was interesting in two regards.

First, I suggested the topic.

Second, it featured what at least seemed like real paid advertising at the start. This is thanks to PodShow, the “media network” used to distribute this podcast. The deal behind PodShow is quite simple fo the podcaster: you get bandwitdh for free, in return for the possibility of there being advertising inserted into the audio.

The reasoning behind PodShow is nicely explained in a podcast from the Stanford Technology Ventures Entrepreneurial Thought Leaders series. Here, Ron Bloom and Ray Lane of PodShow describe the way PodShow got started and just what it is. Basically, they are building a new media company, to compete with radio and television. It is not just a nice place to find podcasts. Recommended listen for anyone interested in just how podcasting can be monetized. They describe how their staff constantly monitors the various shows that they carry, and find those popular and targeted enough to carry some paid advertising. Other shows carry intros and pointers to various other PodShow shows, to drive audience to more popular properties.

Thus, the conclusion must be that Matt’s Today in History has reached some threshold of audience that makes it valuable enough to carry advertising. Great job, and a sure sign of popularity of the podcast.