Jan Bosch is a professor in the software engineering center at Chalmers in Gothenburg. He is a dutchman who has worked all over the world. He used to run Nokia’s research labs in Finland, and then moved to Intuit in Silicon valley. Now, he is back in Scandinavia at Chalmers. What I think he tried to do was to impress the audience with the software development ethos and style of Silicon Valley. I got a feeling that he wanted to make it felt that Europe is maybe behind on modern software development.

However, I am not always sure how the experience from web companies like Google and Amazon can translate into the development of software for systems like telecoms and vehicles (which formed a large part of the audience).

The main points of the talk, and my comments:

Speed is more important than anything else. If we can get 10% efficiency improvement out of our , it should be used to cut lead times by 10%, not reduce cost and keep the same time. The earlier we get software out, the bigger our revenue. This means that you should focus engineering efforts on shortening lead times rather than reducing man hours worked- and if you get the lead times shorter, you will automatically get efficiency improvements. I must say I agree with this point.

We should turn R&D into an experimental system – quickly implement features and ideas and test them in some way. Maybe not with external customers, internal users might do just as well (that’s how Apple works, for example, by evaluating many candidate designs by prototypes that are never seen by the outside). This is a good idea, but I think it might be hard to find the resources to do this in many cases – Apple is kind of extreme in that it rides high, is immensely profitable, and release only a few products each year.

Once we have experiments, product planning should be based on data, not on opinion. Sometimes, vision is needed, but that should be turned into small experiments to validate ideas, not big long-term full-blown plans based on opinion. This sounds very nice – but getting hard data can be very hard in practice.

Initially,  I felt that this would conflict with the concept of the “BHAG” – Big Hairy Audacious Goals – from the book “Built to Last“. There, vision that transcends the current state of affairs is crucial to build products that really change the world. You cannot base that on data – if you ask people what they need, they will not reply with what they do not know. But I guess that if you have a great idea, it is a good idea to vet it with some quick experiments to ascertain that it makes sense at all, before betting the firm on it. So, I guess there is no real conflict here.

Quickly test new features with customers. He sees the world switching to a model where the producer decides when an updrade is applied to the market, not the consumers. Already in place for things like Facebook, Google, and Apple iOS devices. I wonder though if this works for professional software and systems. The customers that I know have to plan the rollout of new versions carefully in order to not disrupt projects that rely on them. When someone pays for a piece of software, they tend to want to have something to say about new features too. Consider the uproar that happens every time Facebook change their UI – if you had paid a hundred thousand dollars for the system, I think Facebook would have listened rather more to their users than they do now. As long as there is no alternative, people will grudgingly accept and learn to live with it – even though the new version might be strictly worse for them than the old version.

When users do have a choice, they often stay with older version. Just consider the vast numbers of PCs out there still running Windows XP. In some way, I feel that this freedom to choose and control your own computing environment is being threatened by this trend of the web.

If you can recruit willing beta testers in your user community, this is great. But you need quite a few customers in place to be able to have enough beta testers to have anything like a representative sample. For a consumer application with tens or hundreds of millions of users, this is not too hard. For a professional piece of software tooling with less than a hundred different customers, you tend to get three loud voices – and we are essentially back to opinion rather than data. It would have been interesting to discuss this with Jan, but I never managed to grab him during the day to discuss this. There is also the time it takes to upgrade a user and have them test a new version – even if the upgrade does not require any changes to their existing code or systems, they still might need training on the new system to fully use it.

The counter to this is obvious: if things are this complicated to use and deploy, maybe we should think about making deployment and use simpler?  And not hide behind “it is hard and we have always done things this way”. Make no mistake – I would love to be able to this, especially with things like debuggers and other daily tools of the programming trade.

Still, I do think that stability is sometimes a hard requirement. When you have a system that you want to maintain for decades, it is very sound to freeze the versions of critical tools used to develop it and stick to these, to minimize the risk of failure due to changes. If the system is certified, you basically have to. Amazon does not build flight control systems. Their system going down is certainly going to cause economic havoc, but nobody will die.

Create an after market – customers will come to expect new features over time, and might well pay for them. This “app market” idea for software features keeps coming up in current discussions on architecture and software design. My guess is that it will actually work, once professional users get influenced enough by the overall consumerization of IT to take certain patterns for granted. Selling new software for car engine control or new features into a telecom switch sounds pretty sane – and is sometimes already practiced today.

Get to know the customer- at Intuit, each engineer famously follows a customer for one day each year to understand their life and get empathy with their users. Knowing your customer is key, the better you know what your customer wants, the more they will take to your product. This idea is something that I have actually seen being tried in the past, with mixed results. Once again, in a business-to-business world this requires some selling to happen, and customers might be sensitive to information leakage and secrecy. However, often the value of having a product expert available to them for a few days to help them work better and run their systems more efficiently is  great idea. If your business has a consulting or services arm, this can be part of regular business – as long as you let core development engineers consult a bit and not keep them all hidden inside the company.

When it came down to practical software development practice, Jan Bosch was all about agile, automatic building, testing, and deploying, and standard modern practice. He retold the Amazon “Two Pizza Rule” – i.e., keep groups small. Keep groups self-governing, based on quantitative assessments of their output, and guide them with goals, not detailed requirements. That certainly works for a certain class of highly motivated and skilled labor that tends to concentrate in Silicon Valley – but in the real world, we also have to deal with less able developers that do need leadership to perform and do the right thing. Not everyone can be totally selective in hiring, unfortunately.

Still, a provocative talk that really did get me thinking about how we do things. Which I think was Jan’s goal to start with, so I guess that means mission accomplished. If you ever get the chance to listen to Jan, take it!

It is way too common to be so busy running around being inefficient that there is no time to think about how to become more efficient. Change also requires some discipline to actually keep pushing at habits until they change for the better.

All of this can be illustrated by tying shoes.

However, this did get me thinking some about the articulation of problems.

Reflecting over my experience from almost a decade in industry following my decade in the university, one thing that does stand out is a certain shift of focus in how I think about products and solutions. When I was an undergrad and grad student, the natural focus was on the solution. How did it work? Now, I tend to look for the problem. What can it do, why is it relevant?

To go back to the experiences that prompted this post: If someone cannot give me a good description of the problem they are trying to solve with their work, I have a hard time motivating myself to listen.

To be fair, there is usually a real and relevant problem behind most research. It is just that it might be implicit in the mind of the researcher, rather than explicit and part of the design and planning process. I sometimes find myself having to ask a series of fairly tough questions to try to pry out the problem from underneath the layers of assumptions about problem domains and what’s important.This can make people uncomfortable, but I hope that it is all for the best in the end.

Bringing out the problem into the open and making it explicit makes it much easier to discuss about it and consider the direction and potential value of research. Is the problem relevant for one or one million people? Is there some other problem that can be solved with the same methods, with a small shift in focus? Making the problem explicit can be very powerful as a methodology.

It is amazing just how much time I and my colleagues have spent over the past years trying to pin down the problems that we want to attack with the Simics product. When you have a product to sell and you depend on selling it, articulating the problem does become very important. The value of a solution to a customer comes from solving problems, nothing else.

There is one more trick to problem formulation that needs to be considered and that I think can really help anyone formulate their problem statement. When a business grows, you have to add a bigger sales force. To make new sales people productive as soon as possible, the marketing and product people have to be able to articulate just which types of accounts (companies) and which types of projects and people inside the companies to look for.  Equally (or even more) important is making it very easy to understand when to walk away from a discussion, since there is no match between the customer problems and your solution, and therefore no chance of closing a deal. Thinking about a solution or product in this light does make a difference.

The question I think any researcher should ask themselves before presenting their work is: how can I explain it in such a way that someone in the audience can explain to a third person what it is all about? Which problems are being considered – and which problems are not being considered? Can someone in the audience pick up on what I say and carry on to a third party – who might be that perfect contact I need in order to further my career as a researcher?

That is the true definition of knowing your problem, I think.

To paraphrase Bill Clinton, it’s the problem, stupid.

The Software Perspective

The modeling philosophy of tools like Simics (in which I include tools like Qemu, IBM Mambo, IBM Cecsim and innumerable efforts to simulate various old computers to run their software) takes the perspective of a software developer: as long as the software has something to run on that works, the completeness of the model when compared to a real machine is fairly uninteresting. I described it like this in my Embedded Systems Conference 2008 talk on virtual platforms:

It is a bit tongue-in-cheek but captures the essential spirit.

When the software you are interested in running runs, the work is done. Any effort spent on too much depth or breadth is wasted, as it adds no real value to the end user. Obviously, this is not a matter of black-or-white, all or nothing. The definition of “enough” is very context-dependent.

In practice, the reason that this philosophy was adopted was the customers for the simulators (virtual platforms) were concerned about software development for standard chips that they were buying from outside parties. These chips are rarely perfect fits for a particular system, but tend to contain a superset of the functionality. In this way, the same chip can be used in many different systems, providing economies of scale for all parties involved.

This meant that the original specification for a virtual system would include some units that would not be modeled. In other units, only certain operation modes would be modeled (it is surprising just how many different ways conceptually simple things like Ethernet controllers or serial ports can be used). The final result would be a model like this:

The A, B, etc. boxes are various subunits or operation modes of the hardware units. The system is an example, and any resemblance to any real chip, living or dead, is not intentional. We will make use of all categories in the legend later.

The key point is that some parts of the chip are left for later. The model is sufficient to run the software and solve the customer’s problem.

When a second target system comes along using the same basic chip,  it is usually necessary to fill in some of the gaps in the original model. Extensions could be caused by using a different operating system that drives the hardware units in a different way, an application that actually uses some previously unused features of the hardware, or upgrades to the software that make more aggressive use of advanced hardware operating modes.

The net result would be similar to this:

In this example, the new OS used a watchdog timer (W) that was not used by the previous OS. We are making use of more features in the Ethernet driver. The new application only uses a single CPU core to run, leaving the second core idle. After modeling the pink pieces, we are still far from a “complete” model – but we have made two customers happy and have (hopefully) hundreds of software developers hacking away delivering software.

Working in this way, a model is quickly extended to meet each successive customer’s need. There are likely parts that never get modeled as they are never needed. That might indicate that they never got used in practice – or, more likely, that there are other users of the chip that never requested a virtual platform for it. Which brings us to the second view of modeling, the hardware perspective.

The Hardware Perspective

If you are a hardware vendor, you tend to have a different view of what a virtual platform is all about. You want to equip your customers and partners with a virtual chip, and you have to assume that at least someone will be using every feature and unit of your fantastic new chip. From a hardware vendor, users expect a virtual copy of the hardware – not just a useful subset.

For the first user above, the resulting system state would be this:

We have large parts which are modeled but not used. This represents a waste from the perspective of this user. But it is a waste that does not hurt the user (we assume that unused units do not slow the simulation down).  If we look across more uses, the waste is much less. In use the second example use above, there no need for any additional modeling:

Synthesis

So far, I have presented two different perspectives. One is the one that I have been living for a long time and one its opposite. In a panel debate at a conference, it makes for an excellent topic. Both sides can claim to be right, and claim that the other side is incorrect, uninformed, dangerous, or just stupid. Great fun and a great show… but also cause for severe misunderstanding and friction between proponents for the two modeling traditions, and maybe not the best way to move forward as n industry.

There is always room for compromise and synthesis. Let’s look at a stylized illustration of the modeling effort spent over time in these two approaches:

The red blobs represent effort, and the arrows show when different users get the platform they need. The bottom case corresponds to the hardware perspective on modeling, and the top to the software perspective.

In this example, users 1 and 2 would get models faster by the step-by-step modeling preferred by the software perspective. User 3 would be the same, and user 4 shows that by having a complete model, there is no delay for additional modeling as new users sign up. What I want to show is that there is no absolute best-in-all-cases modeling strategy: it all depends on the circumstances.

The diagram is potentially a bit misleading… it is maybe not entirely reasonable to have the modeling effort for a new hardware start at the same time as use-case driven modeling. Since the hardware is new, there are probably no users for it yet. More likely, software-perspective use-case-driven modeling is applied when the hardware is already complete, sold, and designed into an OEM system. The hardware-perspective completeness-driven modeling is much more applicable in a presilicon setting, where the virtual platform is used to design-in and enable early software development.

Still, the two approaches are not completely incompatible. Even in a presilicon hardware-driven setting, it is often possible to start to deliver partial platforms early. Key customers tend to know what they need and do not need from a future hardware platform, and are often quite willing to get something started early even if not all pieces are there yet.

To port the core of an operating system, not all peripheral devices need to be in place. To create a virtual platform that can talk to a network, Ethernet is needed – but the support for Serial Rapid IO or PCIe for a rack backplane can be delivered later. In this way, an eventually complete hardware-perspective virtual platform can be delivered in increments that minimize software developer waiting.

Here is a list of some of the ideas I have seen floating around:

• They are going to put Windows 7 on ARM to defend against Linux in the sub-netbook segment. Certainly a useful move – but do you need an architecture license for that? It would not make much sense to put Windows on ARM in a way that requires you to have a Microsoft-designed processor core to run it.
• It is a case of Apple “A4″ envy – if Apple can build their own custom ARM chip for a consumer devices in the tablet space, so can Microsoft. I think this makes a lot of sense. But once again, what use is a license to design your own ARM core and ARM instructions? Apple does not seem to have created a custom processor core, instead using a standard ARM Cortex-A8 core in the A4 chip as far as I understand.
• Handheld gaming, building their own phone. It is essentially the A4 envy argument, and I cannot see how an architecture license will help.
• Deeply embedded devices. Microsoft wants to ride the ARM wave into things like power meters and other truly embedded systems. Once again, that might certainly be a good idea – but why an architecture license?
• As a defensive move in the Microsoft-Intel relationship. If Intel is toying with Linux, Microsoft can be toying with ARM. In that context, a few million dollars to acquire a license to do nothing much with it might make sense as negotiation leverage.

The best idea I think is the server angle. ARM is making inroads into servers where single-thread processor speed is not that important. The power consumption advantage over x86 is significant, as long as you do not need utter speed or very many cores sharing memory.

Power-efficient servers is an area where Microsoft can certainly see the potential for truly revolutionary changes in the IT field. There is no reason why x86 would be the best architecture there, and the fact that x86 is controlled by Intel and AMD makes it very hard for Microsoft to really take part in hardware-software innovation. Essentially, Intel and AMD design the processors, and the software has to adapt. This model is not optimal if you want to really see what you can do with the hardware-software boundary.

Thus, if I think Microsoft might do with the ARM license is to start tinker with the OS interface of the hardware. The beneficiary would be both Microsoft and ARM, since Microsoft innovations for ARM might well become standard in ARM land. For example, an OS might benefit tremendously from small changes in the processor in areas like:

• Memory management – a hardware scheme tailored to what Microsoft sees being done in their operating systems and their third-party server software could certainly be very beneficial to efficiency.
• Multicore and multithreading – ARM has some special support in their MPCore designs for communicating between cores in a multicore system. Such support could be extended to help the OS manage both threads and processors across multicore designs. Also, ARM might want some help from Microsoft to design a scalable OS interface that works for tens or hundreds of tightly-coupled cores (rather than the current limit of 4 in ARM Cortex-A9 MP).
• More bits – the biggest architectural problem I see with ARM in servers is that ARM is currently a 32-bit architecture. 32 bits are not enough for even medium servers today. Having Microsoft help ARM design a 64-bit version of the ARM architecture sounds far-fetched, but it is certainly something where a license to change the ARM instruction set would help.
• ARM instruction set additions to help build an emulator for x86 instructions on ARM, to allow current x86-Windows applications to run on an ARM-based device. This is an idea which has been tried in the past and which has never been very successful in the market. ARM currently has a set of instructions which help accelerate virtual machines such as .net and JVM, and I think that is as far as this idea has been proven useful.

In summary, the only reasonable use I can see that Microsoft would make of a license to build custom ARM processor cores and tweak instruction sets would be to build better servers, by improving multicore communications mechanisms, upping ARM to 64 bits, tweaking the MMU design, and possibly creating some kind of x86 emulation support.

That said, I think the most likely result is a custom ARM-based chip to power a phone or tablet or other consumer electronics device, running a Microsoft software stack (derived from Win CE/Windows Phone) on Microsoft hardware, all sold as a Microsoft product. Essentially, doing the Apple all-integrated solution.

This volcanic eruption certainly is providing a test for how the world would work if air travel became much less affordavble. I really do think it is absurd that we expect to be able to physically move anything and anyone to anywhere on globe in short time and at low cost. This party cannot go on forever, as oil starts to run out and the airline industry starts to have to pay for their carbon emissions. The energy usage needed to move people like that is just a bit too high to be sustainable, even if we make planes run on biofuels. I sometimes feel like I am living in a golden age that will soon end, and that my grandchildren will not have the same easy reach across the world. Maybe we should take the soonest chance available to go on vacation in Asia… it might not be feasible in a few decades.

Anyhow, suddenly, we are thrown into a world of no flights by a natural disaster. And sure enough, things get chaotic. In particular for those stuck far away from home with few easy ways to get back. Buses and trains become very attractive, all of a sudden. But their limitations also become clear, in that getting from southern Europe back up to Scandinavia now takes 40 hours instead of 4…

The impact on business is really interesting. The normal mode of operation of having people flying around to do sales and have important meetings is suddenly made impossible. Instead, we have to turn to the phone and videoconferencing. Incredibly good for the environment, and hopefully something of that will stick. It also shows how dependent we are on fragile supply chains, that our modern economy is often efficient at the cost of robustness.

This is a rich subject for reflection — how would you live your life if airtravel did not exist? How would business be run? One clear conclusion is that it would make sense to have lots of small offices to keep sales and support staff close to customers, and that local organizations would have to be more independent of the center as the center could not come visiting as often.

If you combine this experience with the past Winter’s train chaos, you cannot but reach the conclusion that the way to plan your life is to keep it physically very local. If you can get everywhere you need to in everyday life on foot, you have a very robust personal solution. Obviously, in a modern economy, you are still dependent on goods deliveries to work over long distances — but those are less timing sensitive  than getting to and from work and pick-up at daycare (the main concern for modern parents).

Guess this years vacation will be planned based on trains and cars, not on flying

Basically, the article describes the changes in mindset that a development team goes through as they progress from research to enthusiastic early adopters to normal users. The large population of normal users want useful results, not necessarily a deep understanding for how a tool works. In my experience, this leads to “ah, why didn’t we see that” moments as big (and in hindsight, obvious) flaws in the product and its user interface are revealed.

It also leads to “aich, why do we have users” moments when users want something that just is not feasible, sensible, or even sane. There is a nice quote from the article that really made me laugh:

Users really want the same result from run to run. Even if they changed their code base. Even if they upgraded the tool. Their model of error messages? Compiler warnings. Classic determinism states: the same input + same function = same result. What users want: different input (modified code base) + different function (tool version) = same result. As a result, we find upgrades to be a constant headache. Analysis changes can easily cause the set of defects found to shift…

There are so many similar requests made by users of technically advanced tools… and finding ways to get around them is part of the real fun of technical marketing. Reconciling impossible requirements with the technically feasible in some way that meets customer expectations is a very nice challenge to go through.

In this case, the fundamental issue is that the Coverity tool is an approximation, not an exact tool. Small fluctuations in input or the tool itself can change the set of issues flagged in a body of code. If a tool tried to be exact, its runtime complexity would explode. Even going some distance in that direction like the Polyspace Verifier (now part of the Mathworks) drastically increases the runtime. For more on static analysis in practice, I recommend a MSc Thesis from Linköping.

The article is a good read for anyone interested in either static checking as a technology, or in how to commercialize good research.

The main theme of the interview is the need to shift business thinking from small details to entire systems. From operations research where you spend lots of time understanding some process or department in great detail, to a system-level thinking where you focus on what an entire enterprise is doing.

For me, this struck a chord in my system-level heart… in my world of computer systems and virtual platforms, system-level is what it is so hard to get engineers to. Far too much time is spent (in my opinion) understanding, modeling, and tweaking subsystems. Far too little effort is spent on understanding the whole, how things fit together in practice, taking software, hardware, and software system evolution over time into account. The analogy is not perfect, but there are more things that are alike than are not.

The most interesting analysis that Russell Ackoff fires off from his perspective is that of comparing companies and architecture. An architect knows the whole of a building, but does not entirely go into details on just how it is to be built. He/she trusts the carpenters, bricklayers, and other workers to know how best to solve their local problems. Basically, applying hierarchical abstraction to the task of constructing an actual building.

This got me thinking some of why this is the case. I think it could be because building things (castles, cathedrals, houses, walls, pyramids, canals, …) must have been among the most complex tasks undertaken for a very long time in human history. Thanks to this long history, we have perfected the abstraction and division of labor in construction. Buildings are built in a certain way, by a certain set of crafts, since that method has been proven to work well for a very long time. So just like in the case of the design patterns craze in the late 1990′s, architecture might have something to teach us about how to build hardware/software systems too.

Note that for some reason, I cannot find a link to the podcast on the BBC homepage. But if you subscribe in iTunes or similar, I think you will find it. Something is not as user-friendly as it could be.

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.

Finding information on this card was very hard, and here is the best that I could find:

With front and back LEDs and a removable system configuration card, the Sun Fire V120 server maximizes system availability by allowing system administrators to concentrate on scheduled service through easy installation and management. The removable system configuration card allows you to store a system’s host ID, MAC address, and NVRAM settings to another server while you perform routine maintenance. As a result, system downtime is minimized.

Why I find this interesting is that it is also a nod to commercial software companies relying on hostids for licensing. In this way, you can maintain the same hostid even when a server has issues, and without compromising the integrity of licensing. Sun’s hostids are unusually safe and reliable, unlike the common x86 anchors like Ethernet MAC addresses (which are easy to change) and disk IDs (which are not available on Linux typically).

Making the ID physical in this way is usually the best way to handle identity in general. A GSM/UMTS SIM card is another example of a physically represented identity, which is way preferable to virtual identies that are just software. Much easier to handle, and safer for all involved.

From the comments on that blog and discussions with iPhone users that I know, it seems that MMS is a feature that is not receiving the love it should from mobile phone users.

If someone does not know it, MMS is basically richer short messages between mobile phones, where you can add pictures, sounds, and animations to the basic text of SMS. When MMS arrived I felt it to be a “why?” feature, but today, I really appreciate it.

Lots of iPhone users, and Apple as a company, seem to consider MMS a poor man’s email. “If you want to send a picture, use email and then you can pick it up on any client etc. etc.” is a common sentiment. However, this is not a correct understanding of what MMS is for. It is a different modality than email, it is a fast immediate messaging service whose purpose is to show a picture on another phone for immediate appreciation. Not a mechanism to send well-taken digital photos for long-term storage at the recipient. Email does not achieve the same universal delivery into the pocket of the recipient that MMS affords.

For me, MMS is all about short immediate picture communication. Like SMS, but with pictures. Me and my family use it to send short “postcards” to each other, and when you have children and grand parents, it is really ideal. On vacation, all people bring their mobiles, but most people (outside the core tech crowd) do not check email that regularly. MMS is really “instant delight” in this manner.

Also, the simplicity of MMS compared to email makes the interface much simpler to implement. Take a picture, add a caption, and send to a mobile phone number. Email is always more complicated and slower.

MMS also roams better when travelling internationally: an MMS typically carries a decent cost per message, where email would entail data roaming charges that tend to be horrific, still today. Looking for Wifi is often not an option when you are in smaller towns, out in the mountains, in France (it is still hard to find useable public Wifi connections there for some reason), and similar places.

What is also interesting is the effort of the mobile phone network to really deliver MMS messages to everyone, even those without or with limited MMS-capable phones (older models). For example, my wife’s dead basic Nokia lacks a camera and refuses to accept particularly large MMS messages. What happens then? First, the phone tells her in an MMS that “you have a new MMS message, but this phone cannot display it”. Then she gets an SMS saying “to read your MMS, go to this website and enter this code”. Pretty good as a workaround for a lacking phone capability (and likely what an iPhone user would see as well). But as long as pictures are phone-sized, it works well to send her a greeting over the phone in this way.

She wondered why the network was so nice to her, and I think the explanation is pure money: the more people can receive MMS, the more people will send them… and sending MMS is a good source of income to the networks. So having a fairly easy-to-use workaround makes eminent sense.

So, I really like MMS and I find it and SMS  to be one kind of communucation, more immediate and direct, while email is asynchronous with typically quite long delivery times. MMS and SMS together fill a useful niche, quite different from email and phone conversations in my arsenal of messaging solutions.

It is mostly in Swedish, though, but they have some English-language information at http://www.crimemedicine.com/lib/html/english.html.

I think this is pretty important stuff, way too many people are buying counterfeit and illegal and usually dangerous medical stuff over the Internet. That is not how you deal with your health: if you have a problem, go to a doctor or at least a physical pharmacy and talk to someone with proper credentials. Never ever self-medicate with stuff you find of the net. Or even sometimes buy in physical pharmacy in less well-policied countries. Real medications can be expensive — but most of the time, you are getting what you pay for. As always.

It just struck me the other day that the idea prevalent in chip design that you want to explore the design space of a certain with great detail and precision might be the wrong way to go about things. It is in some sense similar to the ideas of planned economies: you decide a priori what is important, and try to optimize the design to do just that. If you are right, it is brilliant. If you are wrong, it can be very wrong. That is scary to say the least. It seems to assume that you have a pretty good idea of what you need to achieve, and that this is not likely to change for the lifetime of a design.

In product design in general, this tends to be a brittle strategy. In many areas today, especially in consumer-oriented markets, the approach that appears the most successful is to throw things in there and see what works. It appears to be more successful as a strategy to launch ten different mobile phones that might well overlap in target markets and feature sets, and then let the market figure out what was the good and what was bad. In foods, instead of having a single flavor of a product, you launch a bunch and then discontinue the ones that did not sell too well. For example, some of my favorite cookies did this a couple of years ago, branching out from plain nougat to mint and banana and orange and toffee… the banana is apparently dead now, judging from the Ballerina homepage.

Anyway, I can see the reason why chip design is not done this way: the cost of each try is forbiddingly high… but maybe if we could find a way to make it cheaper to just try things? Could we then move back to a more relaxed creative environment where being wrong ain’t so bad as long as something else worked out?

We are doing that on a grand scale, really, in the way that different chip startups pop up with a truly new idea, and the market tells us what works and what does not. The kinds of architectures being explored that way are usually much more radical than what a traditional chip design house will come up with in a “architecture exploration” phase. The cost of failure for a chip startup is certainly non-neglible, but I hope something will happen to help bring the cost under control so we can continue to explore the truly new architectures by the mechanisms of the free market…

And by the way, I like the traditional Nougat the best, even if Mint Chocolate can be pretty OK too.

Another sign that it is getting colder is the reaction of consumer electronics.

The plastic in the cords for my earpieces for my iPod gets noticeably stiffer when temperatures drop down towards zero, and the touch wheel tends to work worse in colder conditions. Not to mention trying to operate a touch wheel when wearing gloves. Most times, it just does not work at all.

It really makes one wonder how designers test these things, and whether they really think about common types of weather across the globe. I can see a problem with designing things in a climate like Northern California, where it never particularly overly hot or in any sense cold. The designers just do not naturally experience having to work equipment in minus twenty degrees and snow fall…I think that could lead to some different choices in materials and designs, seriously.

Case in point: last time I was on a skiing holiday, we had pretty nice warm temperatures between minus ten and minus five degrees. The iPod headphone cords were sufficiently rigid at that temperature that you could hear them rustle against themselves and my clothes. Seriously, minus ten is not a particularly severe temperature. I have some friends who design forestry equipment that works in Siberia. Minus forty in the morning. Or try living in nothern Finland or Norway — civilized areas, but you can expect many days of minus twenty (which is a temperature where you can easily be outside given sufficiently good clothing).

I managed to kill the battery of my mobile phone last winter as well, as it did not particularly take well to walking in minus ten-like temperatures while on the phone. Fortunately, the battery could be changed to a new one, which is pretty necessary when using portable electronics in cold weather. I guess severe heat can be just as bad for electronics, it is just rarer for me personally.

Obviously, most keyboards on phones are too cramped to be worked with heavy gloves.

Maybe the consumer electronics industry should think a bit like the automotive people who have to make sure things work between minus 30 and plus 80 (or something similar to that).

I guess this goes into a rant category, as electronics will keep being designed for benign environment and “normal” temperatures. Bad luck for us living in colder climates… or maybe a niche to be exploited. People still look for the classic Ericsson R310s: one of the most rugged phones ever made…

One could think of a similarly toughened music player. And accessories made to work well in severly cold weather for use on skiing trips, Arctic research expeditions, and by Siberian loggers. Huge market here, somewhere, right?

Living in a decently old city does provoke a certain interest in history and how to access the past. Note that Uppsala, like everything in Sweden, is fairly recent on the grand scale of things. We have a cathedral from the 1200s, and some older churches going back to the 1000s, but before that there is not much to boast about. It is not like Rome or Egypt or China with thousands of years of civilization and with impressive buildings that still stand. But I digress…

The real problem with archives and digital technology is that it is really hard to preserve a large portion of the intellectual data that we produce today. When I was an archivist at Smålands Nation here at the university in the 1990s, it was real fun to browse through the old papers we had in the archive (only stuff from the past century, all the really old and valuable stuff was in professional hands at the national archives). Reading a menu from a party held in 1945, or the time plan for a large formal celebration in the 1950s, or a guest list from such an event was actually quite intruiging. You could see how tastes and traditions change, even as students all believe they are maintaining ages-old traditions faithfully… Browsing the member list in old handwritten ledgers was also great fun.

In another fifty year’s time, what will we have left from today’s activities? The party plans are now all just printouts from a throwaway word document, the member list a database on a PC, and unless you make a conscious effort, memories and printed papers will quickly fade (you do need to use the appropriate laser toner on low-acid archive-quality paper if you want the things to last even a decade, let alone a hundred years) and the students fifty years from now will have no idea on we ran our parties, who were in the nation, and other such facts of daily life. “Print it out” is easy to say but hard to do. Much of today’s digital data does not really print out in a useful way. A wiki, for example, can be printed as a snapshot. But the links and the edit history is gone.

But imagine if we could retain these digital documents accessible, in their living digital form. Having a proper database available for use and query is so much more interesting and powerful than a stack of papers. Being able to look at the audit history of a wiki, or the commit history of a program’s source code would offer a much deeper insight into the people and processes that produced the end results compared to just looking at a static snapshot.

What does it take to do that? A huge and known problem in digital archiving is the physical media access. All great archival institutions in the world have scores of different tape readers, disk readers, some new, some antique, and try to use these to pry the bits of equally antiquated storage media. This is bad, just like we have problems looking at old movies as the reams of film are literally falling apart. Clay tablets start to look positively sophisticated and a smart choice compared to our very brittle technologies.

Second, once we have the bits, what can we do with them? Now we have to tackle the file formats, and having pried them open, to find the fonts and character sets which are suitable for displaying them. Rendering a MacWrite document from 1985 on a modern machine will likely not quite give the same wonderful black-and-white 72-dpi view that you got back then… Or figuring out that for a while, we used 7-bit ASCII to write Swedish texts by replacing [, ], |, {, }, \ with å, ä, ö, Å, Ä, Ö (not in exactly that order — but I used to be fluent in reading and writing that!). Even worse, decoding a database file or purely binary CAD/CAM file is going to require some serious reverse engineering of the old programs that created them… unless you could run these same old programs in some way.

At least to me, an “obvious” solution is to use virtual platform technology to make keep the old software stacks running. Some archivists are apparently working on OS emulation of various kinds to keep the old software running, but I do think that it is much simpler and more general to just simulate the entire machine hardware. This will result in the smallest risk of error, and the greatest fidelity to the original software as oddities such as word lengths and character sets can be faithfully reproduced. Simply because the SW-HW interface in a machine is the best document and narrowest interface in the entire machine. Old tapes and disks should be turned into files stored on the mass storage of current machines, and these files can then be migrated to new machines as they come online. As long as you maintain the copies of the materials by reproducing them on new hard drives, they will not rot.

It will also have the property that the entire look and feel of the old systems remains accessible. Which is a blessing in that it maintains our digital heritage and lets computer historians also go back and see how old software looked and worked. It is also considered a curse by practising archivists who do not particularly like the idea of learning how to operate strange old operating systems with arcane command lines. I think this is not necessarily a big problem. Just like people today study and learn ancient languages to learn more about ancient cultures as embodied in their written records, I can see historians of the future learning to use old operating systems and programming languages to study the ancient culture of our time as embodied in our computerized records.

Creating these kinds of virtual platforms is quite different from the dominant virtual platform thinking in the commercial market place today which is focused on modeling new and future hardwares. Rather, we need to study an existing artefact and make a very good model of it. It is a different type of task, requiring slightly different types of tools.

Of particular importance is that the simulation platform totally insulates simulation models from the underlying machine. You need to be able to port the simulation to new operating systems, machines, and architectures without changing a line in the source code of the models. This means making sure to locate all host dependencies inside the simulation framework, and making sure that models are completely portable regardless of word lengths, endianness, and other aspects. You want to be able to take a model that you run today on an x86-64 on Linux and run it on some future 128-bit middle-endian platform with a completely different type of operating system. Basically, the simulation platform has to be a complete virtual machine in its own right. Probably, over time, we are going to add more layers of virtual platforms to get around really major shifts in computer system architecture. There is nothing saying that you can only virtualize once, already the IBM S/370 showed that you could virtualize recursively and to an arbitrary depth.

I do think that some tools that we have today are perfectly useful for this kind of undertaking.

The business aspects are going to be interesting, though. We would like to use the technologies already available in the sophisticated commercial virtual platform tools, that’s kind of given. But the archival market place is not the most lucractive… and that they would like to have very good insurance that the tools remain available. Including source-code escrow that would make the requirements of 25-years military projects look positively light.

Developing a completely new totally open-source solution sounds like a nice idea in theory, but is probably a bit too much work. It also takes no advantage of all the commercial technology available today. Maybe as the virtual platform market matures, the industry can come up with some way to provide this technology for the greater benefit of society. Basically, doing a bit of social work where we really have the tools to help.

I have no good solutions to that to offer right now.

But imagine how cool it would be to, in fifty years from now, gather the old team from Virtutech around some kind of display device and watch an ancient Simics 4.0 run on top of a virtual quadcore x86 with Linux 2.6… all running on top of Simics 29.0 (estimating one major version every two years) on some future I-have-no-idea-what-it-will-be hardware and software system. That really is something that would be cool to see happen.

The only caveat is that the train time are not particularly well synchronized with the park hours: taking the 08.19 train from Uppsala puts you outside the gates of a closed park at 09.22. It opens at 10.00. So bring some picnic coffee for the wait (but it was a sunny and nice day, so no need to complain about that pause). The next train is at 10.19, which gets you there a rather late 11.22. That is something they should consider for next year’s iteration of this offer. Getting home, the 17.40 train is perfect. And so does everyone else think, so it was pretty completely full from Furuvik until Tierp, after which it started to clear up as passengers got off at the stations going south.

Updated: Here is the video inline, let’s see if this works.

If you happen to be at the FTF in Orlando, do come by and look at the demos!

I have been involved in this work for the past year, and it is wonderful to finally see it coming out and be able to talk about it.