Ask permission for reproduction.

July 26th 2004, around 2am :)

Getting ready for a multi-os era
Guess which machine and OS I'm writing this text on? Windows, perhaps (which one? :) Or Linux, MorphOS, or.. what if it does not matter. There used to be a time when OSes did matter. Or, perhaps, an OS did. Windows ruled the world and the ones going other roads (very few) were constantly in bumps because they were not using the "de facto" OS that everyone else was.. I believe this started around late 80's (Win3.x) and ended around... right now. It was the growth of Internet and raised importance of OS-independent formats (s.a. PDF, XML, ..) that pushed this trend forward. It no longer was an absolute necessity to own a Windows computer. It was essential to be able to browse the web and read the email, even to open some Office documents, perhaps, but this no longer required one to run a Windows system. Also other trends were in play, notably the security holes (everyone knew it was a Swiss cheese - who's surprised??) that started to alarm even the corporate IT and other managers. Sticking to one horse, and one horse only, was a risk. So what's the future? Java. Dotnet. Flash. Python. What do they have in common? They all run on multiple platforms and mostly without major (or any) rewrites of the application code. Even JavaScript could be in here.. So OSes -for applications- become an underlying mechanism that doesn't really matter. As long as the app runs, who cares what OS it runs on. This has already happened for applications s.a. Opera, OpenOffice (partly) and so on. People should value the apps, and app designers should design the apps, not port them to yet-another operating system. I'm not saying this could happen. I'm saying (depending on your context) it has happened, is happening or will be happening. Even by the time you run Longhorn (whatever the eventual product name will be?) running it will not matter. That OS will just be one horse in a race of many, and things will be back to normal again. The implications? The change will probably flourish a group of 'small' or 'independent' OS releases. Such as SkyOS, MorphOS, Syllable and whatever. Due to many apps being Open source, it is now possible for such offerings to gain wider application support from "day 1" than ever before. Due to a converging tool chain (most of them will be using gcc) the price of porting will be almost none. Projects such as Gentoo are already fuzzifying the borders of traditional OS boxification. For them, it simply does not matter any more. Last fortress Some applications areas s.a. Industrial control will be slower to adopt the changed state-of-affairs. Why? Because for them, not only the software but also the controlled (and purchased) add-on devices count. They won't change the OS if it doesn't support the devices they already have. While a practical PC lifespan is probably as short as 3-4 years, for measurement devices it could easily be double that. And, these people are cautious in any bigger moves they'd make. So they (you?) don't want to be a first implementor, but neither the last one (that also costs!). There needs to be a guided path from the one-OS-only state to the OS-does-not-matter (at least, not so much) state. Who's providing this? Business potentials The traditional OS vendors hardly want to push for OS-independence. For them, it's better to tie their users (and especially developers!) to their system, which will further their sales. This will be a losing battle. The other way would be to compete on the open, making everything (migrating in and out) easy and supporting multi-os development in the first place. Probably the small OS vendors (s.a. MorphOS) will have such an approach, because it's in their own interests, too (until they become the big guys, that is :) The reason Sun is currently in such a yes-no-maybe situation regarding Java licensing issues is probably very much because of this. On the one hand, they have the OS-vendor's hat (SunOS - remember such? :) on the other they're sliding more and more to the same B-level group as MorphOS & others, making multi-os development the only scenario in which people would be targetting their platform. What they decide - if anything - remains to be seen. Dotnet. Mono. Could be a winner but basically, it's just the logical continuation of C++ and Java merged into one. Not a bad thing, but - to be successful - it cannot be used for tying people back to the MS environment. I don't think developers will eat that, the rules of the game have changed. Flash. Good, but then you're tying into Macromedia as an 'OS'. I used to work a lot with Toolbook, their former competitor (at the time when Internet was new and it wasn't sure who'd eventually win). The Toolbook runtime had one memory management bug (only one, that's not bad! :) that turned up in my customers' computers, sometimes (luckily, quite rare). To them, it seemed like an application failure. To me, it was a Toolbook bug. Something I just couldn't bypass (as I did some others). This wasn't fatal that time but I sure wouldn't trust a company on similar grounds again. So Macromedia's doomed, unless they'll open their runtime sources. Which, if they ever do it will be too late - just as it's becoming almost too late for Java. Sorry about that! What's left? Python (and Ruby, Lua, whatever open source scripting language you prefer). I prefer Lua, but that's me. :) This could really lead the way, in the long term. Bindings already exist for libraries s.a. GTK+ and others, making Python development less and less OS specific. Then again, I wouldn't know since I've written zero lines of it. Lua is my horse in this race, but they all are sort-of related. What should you do? Who am I to tell? Be prepared for the change, even embrace it. If you're a developer, don't be frightened of multi-os projects. They used to be N times the nuisance (perhaps, to a suitable power?) but the emerging technologies will really lift you from targetting this-and-this-os in C or C++ to targetting Python, Java, C# or Lua instead. Pick the language, not the OS. The OSes will be supported by the language. - Asko Kauppi
ps. The right answer to chapter 1 was "iMac 700 MHz and OS X 10.3.4". And, that it did
not matter. :)