In the late eighties we were at war. My friends and I fought at the frontline in the battle between Commodore Amiga and Atari ST users. Our childhoods were tinted by anti-Atari demos that were released on our supreme Amigas. Every opportunity to ridicule Atari ST was gratefully taken and we did not refrain from excessive violence: a sharp tongue in our scrolltexts flanked by mocking cartoons. It was a religious crusade. Our devine goal was to force our arch enemies on the knees and get them to ditch their foul Atari STs and pacify them with proper Amigas.

Atari Computers by Bjørn Lynne, 1990

The Amiga and Atari ST were released around the same time in 1985. Commodore and Atari were fishing in the same pool of home computer users, along Apple with their Apple Macintosh and they became very succesful in sales. The two 16/32-bit computers each had characteristics that made them unique: the Atari had a built-in MIDI interface and a high resolution monochrome screen that had it adopted quickly in music and DTP studios. Amiga featured superb multitasking and a set of revolutionary custom chips that would allow for high quality audio and video playback that had it penetrate video and broadcasting companies in no time. Both were groundbreaking gaming machines too. My personal opinion on these computers was — and still is — highly biased but bear with me.

During the war I remember visiting a classmate that — as I found out way too late — owned an Atari ST. (Woe had he mentioned that sooner!) After the initial shock of being trapped on hostile terrain, quickly looking for exits, we beheld our views and had lots of laughs over the anti-demos — he showed me some Atari-forged ones of the anti-Amiga type — and we discussed our mutual love: 68000 assembly language. I learned about the 68000’s TRAP instruction — rarely if not at all used on Amiga — and I teached him the joy of having those custom chips, which the Atari ST lacks. Remarkably, we both happened to use HiSoft DevPac, an assembler that was available on both platforms. It goes without saying that the Amiga version of DevPac was slightly better, although my new ST-friend did not agree.

Obviously this was no reason for a truce, at all. My Amiga consortium agreed that I had succesfully infiltrated behind enemy lines and the war continued — bloodier than ever. Afterwards I met my ST-friend frequently and we greeted eachother in demos, making sure to mention the ‘lameness’ of the other computer every time. The Amiga versus Atari ST wars were a playful thing; like Cowboys and Indians for generation X computer nerds.


You can be lured into thinking that this was just us, back then, being childish. There are, however, enduring religious wars fought by ‘professionals’ of which the EMACS vs Vim, Microsoft vs Apple, and iPhone vs Android bloodshed is arguably the most notorious. You can enter a suitable IRC channel, forum, or FaceBook page and find yourself ablaze in flames for getting too enthusiastic about a certain system or technology. Religious wars have something in common: they cannot be won.

Our war was quite different: we did not take ourselves too serious, and we were genuinely interested in eachother, including our ‘enemies’. Our war was childsplay, not childish.

Share and enjoy

“I hideously stole 68000 routines from an Atari ST user!”

My Atari ST-friend and I shared code. As the Atari ST used an MS-DOS compatible disk format that the Amiga could easily read we were able to exchange data. However, I noticed that my friend’s source code files had extra bytes of crud attached: extra carriage returns (CR). Instead of a single linefeed (LF) there was a CR+LF combination after every single line. I found this strange and clumsy and thus perfectly fitting an inferior Atari ST. In those years it was considered normal to just code another conversion utility each and every time to kick files into shape: read the file, walk the data, ditch the extraneous byte, write the file. We wrote numerous converters for CP/M, Commodore 64, MS-DOS, AmigaOS, Akai samplers, Apple System 7, and — of course — never for Atari ST. When I threw back source code to my ST-friend he would just have to add CRs to a very long string of ASCII.

Incompatible filesystems had been the hill — a wall even — between computer systems for a long time. Transporting files from one computer to another was potential hell. However, nearing the end of the nineties, networking progressed, standards developed and nowadays we can effortlessly lift files off any filesystem and open them using any OS in any program. Well, at least theoretically. That is a good advancement: I am already looking forward to read my data many years from now without the need to recreate some obsolete system. That’s why I started using open file formats, plain text even, where I can. By the same token, I fancy my backups decrypted, and within physical reach. That way (I bear the illusion that) I will forever own my precious data. (Until we are EMP bombed, that is.)

The new hill

Thirty years ago it was a privilige to even be near a computer. Nowadays it is not that rare to find a multitude of computer systems in the average Western world household. Different machines of various brands, running distinct operating systems. Usually they’re all connected. We use Windows, OS X, Linux or BSD flavours. We operate desktop computers, tablets, phones and we need to keep adjusting to different user experiences all the time. The initial disconcerting change of scroll-wheel direction in Mac OS X Lion a few years ago is an example that blatently showed that we need to adapt repeatedly. In my opinion, that’s walking uphill.

From a functional perspective operating systems are very much alike: ultimately they allow us to juggle files. We just want to read and change our files without too much hassle. The environment in which that is done is part of the user experience. Maybe, just maybe, it would be nice if we could stick to a common user experience or UX, independent of processor, system manufacturer, device type, et cetera.

Apple, for instance, addresses that in part by unifying their ‘portable’ iOS experience with their ‘desktop’ OS X experience. Over the years they have spent a considerable amount of effort merging the two and they’re not quite done yet. Microsoft, in turn, is heading towards a unified version of both their desktop and mobile Windows operating systems also.


In a perfect world, if all we really do is read, change, and write files, there should be no need to be exposed to all these different operating systems. Instead, one common OS could adapt to whatever device it’s currently on and give access to your data, wherever that data may reside.

Last February I was contacted by Hogne Titlestad who shared a lovely idea. His company is building a platform agnostic operating system that resembles what I described above. It’s even better than that actually: the Friend Unifying Platform or FriendUP, as Hogne calls it, abstracts all underlying systems and networks as disks, files and directories. Hardware becomes a mere resource: the computer on your desk, some nifty device on the network, some service online. All these resources become part of the filesystem, of the ‘computer’ FriendUP runs on, as you wish. In other words: the OS runs on available resources. Resources form the computer.

I like teaching. When I teach classes I nor my students want to ‘walk uphill’ because of smoking computer hardware, malfunctioning OSs, let alone incompatible filesystems. Not ever. I’ll be happy to support any platform clients or students feel comfortable with but the system itself should never be dominant. A computer is just, well… a computer, there to serve people.

FriendUP would allow me and students to really concentrate on matters without caring about OS X, Windows, or Unices and to easily share documents, applications, memory, services, devices, and processing power across the platform. Moreover, FriendUP would support an ad hoc approach: bring your own system — any system — and join in smoothly.

Imagine an open source operating system that runs everywhere: it kind of ‘hovers’ above all your computers and devices.

I find this quite an interesting concept, not in the least because FriendUP is definitely inspired by an OS I care about: AmigaOS. By design it just oozes all the good stuff like assigns and inter-application communication. Remember exec.library or ARexx? SmallTalk-like messaging, if you like.

Thirty years ago FriendUP would have enabled me and my ‘enemy’ ST-friend to  work together — building joint anti-demos (while secretly installing bootblock viruses) — as if we were on the same platform, comparable UX, but each on our own beloved computer systems. With one obvious difference, my Friend Unifying Platform would have access to slightly better resources: an Amiga! Of course, I would let my ST-friend use my custom chips through FriendUP once in a while.

No, I would not. Who am I kidding.