Taos Operating System (1995) | Hacker News Reader

Taos Operating System (1995)

uruk.org

84 pointsxyzzy300061 comments

Open articleView on HN

The Taos Operating System (1991) - https://news.ycombinator.com/item?id=16727565 - April 2018 (9 comments)

TAOS Operating System - https://news.ycombinator.com/item?id=15527936 - Oct 2017 (21 comments)

The Taos Operating System (1991) - https://news.ycombinator.com/item?id=9806607 - June 2015 (93 comments)

ChrysaLisp - https://news.ycombinator.com/item?id=34415936 - Jan 2023 (16 comments)

ChrysaLisp - https://news.ycombinator.com/item?id=25779930 - Jan 2021 (6 comments)

ChrysaLisp - https://news.ycombinator.com/item?id=22019594 - Jan 2020 (61 comments)

ChrysaLisp - https://news.ycombinator.com/item?id=18897817 - Jan 2019 (19 comments)

ChrysaLisp – A 64-bit Lisp OS with GUI - https://news.ycombinator.com/item?id=15466124 - Oct 2017 (121 comments)

Earlier discussion, different article, same OS. Interesting top comment by one of the devs:

https://news.ycombinator.com/item?id=9806607

The newsgroup posts have an enthusiasm to them that makes them enjoyable to read in their own right, especially when they come from beleaguered communities such as the Amiga or Acorn ones.

It's a shame that the IP for this OS isn't around to play with - the retro community would no doubt have some fun with it, even if it has no value as a going concern for serious use on modern hardware.

Many moons ago, I remember reading the Byte Magazine article about TAOS and being totally enthused:

https://sites.google.com/site/dicknewsite/home/computing/byt...

Last time a TAOS discussion came up on HN, I emailed vygr (Chris Hinsley, one of the Taos founders) about the state of the Taos IP:

https://news.ycombinator.com/item?id=9811455

Sadly not good news, but I'm still hopeful whomever owns it can find it in their heart to release it to the public in some form (as Castles did with Acorn's RiscOS).

I meant to say "I asked" not "I emailed" vygr!

I write about this several times as at IT journalist the time. I remember interviewing Francis Charig a couple of times, who was - ISTR - MD of Tao Systems.

It was a tough one. The demos and the concept was absolutely beautiful and the claimed performance astonishing. It was an elegant idea. But I had no real, independently verifiable way of knowing whether it was bullshit.

I seem to recall it started off being described initially on the CIX bulletin board (think dial-up, UK version of Reddit) in conference (subreddit) of its own. Initiially it looked like philosphical ramblings until several of the conference members twiiged 'hang on - youre talking about a real OS!'. Might have been Chris Hinsley who posted the text.

A Cixen on HN. Well I never.

Yes, Taos was discussed there quite a lot.

Weirdly enough, I visited it a couple of month ago and yes - my account is still active. It was a complementary one.

Which was?

Also covered in Edge Magazine issue 9, June 1994, but I can't find a PDF of it anymore: https://www.retromags.com/magazines/uk/edge/edge-issue-9/

It can be read here: https://docs.google.com/open?id=0B3NnrPPNPKBPY09jZ2dLUHZ0Njg

Yes, that's the article I remember!

I actually own a copy of that magazine — I have the full first two years in holding cases. I feel so amazingly old.

How does this compare to Erlang? Or, to be precise, and Erlang VM running on a contemporary OS.

I always had the feeling that the Erlang VM should have been implemented on the OS level from the start, and now it turns out some company actually did it (or something very similar)...

It doesn't compare closely to anything else.

The only related tech I know of is Inferno, the OS developed later from Plan 9: binaries are platform-independent and run natively on all supported CPU architectures.

And Android, Windows Phone 7-10, IBM i, Burroughs/Unisys ClearPath MCP, UCSD Pascal, Modula-2 Lillith, Oberon, Xerox PARC...

Android is a Linux. Native binaries are definitely possible.

Windows Phone 7.x was CE, 8.x was NT. Native binaries are the default.

IBM i: the OS isn't native on the hardware, but the abstraction layer is below the OS. (Taos made it part of the file loader, roughly.)

MCP: I don't know enough to judge. I believe that they run on x86 today via a mainframe CPU emulator, though.

UCSD p-System: contained a bytecode interpreter; no native compilation possible, but of course every other version of the language did, leading to the p-System's extinction.

Modula-2, Oberon: by default, compile to native executable binaries.

A cross-platform format, SLIM, was proposed for Oberon but I am not sure it was ever implemented, let alone included as standard.

https://wiki.tcl-lang.org/page/Slim+Binaries

Or are you thinking of ORP, the Oberon-to-RISC Parser? Is that not just part of the compiler?

Xerox PARC: what did you have in mind? AFAIK, Alto, Star, Dandelion, etc. all had native binary formats -- more than one for each model, in fact, depending on the OS loaded onto it.

Here we go,

> Android is a Linux. Native binaries are definitely possible.

Android uses the Linux kernel, tranparently!

Officially only native shared libraries are allowed by non-rooted devices.

> Windows Phone 7.x was CE, 8.x was NT. Native binaries are the default.

Windows Phone 7 only allowed .NET applications for common developers, C++ applications required a special license from Microsoft.

Windows Phone 8.x used MDIL (Machine Dependent IL), with a on-device linker at installation time.

Windows Phone 10 used MSIL as main package, and Windows Store does the job of AOT compiling that MSIL with a so called cloud compiler.

> IBM i: the OS isn't native on the hardware, but the abstraction layer is below the OS. (Taos made it part of the file loader, roughly.)

Doesn't matter, unless one is using Metal C, all applications use TIMI.

> MCP: I don't know enough to judge. I believe that they run on x86 today via a mainframe CPU emulator, though.

What matters is the orignal version.

> UCSD p-System: contained a bytecode interpreter; no native compilation possible, but of course every other version of the language did, leading to the p-System's extinction.

There were commercial systems using native compilation like Corvus Systems workstations.

> Modula-2, Oberon: by default, compile to native executable binaries.

Modula-2 was designed for Lillith and M-Code originally. Lillith uses bytecode with interpreter on microcored CPUs.

A cross-platform format, SLIM, was proposed for Oberon but I am not sure it was ever implemented, let alone included as standard.

Oberon System 3, nicely documented on its manual.

> Xerox PARC: what did you have in mind? AFAIK, Alto, Star, Dandelion, etc. all had native binary formats -- more than one for each model, in fact, depending on the OS loaded onto it.

Xerox PARC systems use bytecode formats, before booting the OS, a microcoded interpreter for the respective bytecode format is loaded into the CPU.

FWIW, you are my single most respected commenter on HN, and I often find that you've commented with what I would have wanted to say myself were I only a bit quicker.

But while this is very interesting and I am learning a lot from it, I do think you're stretching a point to breaking here.

> Here we go,

:-)

> Android uses the Linux kernel, tranparently! > > Officially only native shared libraries are allowed by non-rooted devices.

OK. I didn't know that.

> Windows Phone 7 only allowed .NET applications for common developers, C++ applications required a special license from Microsoft.

Interesting.

> Windows Phone 8.x used MDIL (Machine Dependent IL), with a on-device linker at installation time.

OK. Both only ran on Arm32, though, didn't they? So, not native, true, but also not cross-platform binaries?

> Windows Phone 10 used MSIL as main package, and Windows Store does the job of AOT compiling that MSIL with a so called cloud compiler.

Again, fascinating stuff. Still Arm-only, though, right?

> Doesn't matter, unless one is using Metal C, all applications use TIMI.

I submit that it does.

I was saying that 2 OSes I knew of allow the same binaries to run on multiple different CPU architectures: Inferno and Taos/Intent/Elate. There are no native binaries and if you compile source to a binary, the result is inherently natively cross-plaform.

These examples are all fascinating but they are examples of a different phenomenon: where the OS does not allow or does not have native object code for the metal underneath, the only permitted binaries are in some abstract form or for some abstract architecture...

But if the OSes only ran on one arch, then the cross-platform part of the equation is missing.

> What matters is the orignal version.

Did MCP run on >1 native CPU arch?

> There were commercial systems using native compilation like Corvus Systems workstations.

Did the resultant binaries run on different platforms, though?

> Modula-2 was designed for Lillith and M-Code originally.

Originally, maybe, but that is not where it enjoyed mainstream success. I first encountered it as Topspeed Modula-2, the fastest compiler of any kind for the original IBM PC and compatibles.

> Lillith uses bytecode with interpreter on microcored CPUs.

Bitsliced, weren't they?

Anyway, I did not know that. I'd argue that in all other implementations it was just a natively-compiled language like Pascal before it.

> Oberon System 3, nicely documented on its manual.

I will read up on that. I see someone's added it to the Wikipedia page since I did quite a bit of work on that.

> Xerox PARC systems use bytecode formats, before booting the OS, a microcoded interpreter for the respective bytecode format is loaded into the CPU.

OK.

But did that bytecode run on anything else?

I was doing 3d graphics contract work for Acorn in the mid nineties, for their RiscPC. I was given an early version of Taos to try - it was so early in development as to be essentially unusable, but it definitely existed!

Steve Turnbull, then-editor of The Micro User gave it an interesting and enthusiastic write-up. Beautiful though the RISC OS Desktop was, the underlying technology didn't really hold up in the long run.

I still use my RiscPC on a weekly (and sometimes daily) basis. It would have been fun to have a Risc iX or Galileo core (or some other technology not bound to the BBC Micro way of doing things) that retained the usability and snappiness of the Desktop.

What kind of 3D work were you doing?

Edit: It was Acorn User (not The Micro User) which featured the write-up on Taos, in 1995. A link to the article can be found on the Wikipedia page for 'Virtual Processor'.

Link to the Wikipedia page for Virtual Processor here: https://en.m.wikipedia.org/wiki/Virtual_Processor

I am legitimately pleasantly surprised Taos actually existed, contrary to my earlier comment.

But can you say what 3D work you were doing with a Risc PC? I remember Top Model and so on, but not having floating point was bad enough when others had graphics accelerators.

Yeah, I wrote a set of 3D demos for Acorn, to showcase the new RiscPC at Acorn World '94. There was a landscape flyover and a virtual textured talking head. All rendering was done entirely in software of course, using integer maths. I developed a type of Bresenham's Algorithm to trace the hyperbolic curves in texture UV space that translate to scanlines, when one is doing perspective correct texture mapping.

Subsequently I wrote a sample implementation of the Xerox Rooms paradigm for Acorn. It was a 3D office environment, with clickable destinations that would "teleport you" into new spaces. I'm not sure what became of this though tbh.

Next they wanted me to write a version of SGI's GL API for RiscOS, however - for whatever reason that project never really got started, so I had to go and get a proper job! :-(

Cheers

I “founded” and ran the acorn computer user www server at this time. The remains of the site still have a Taos press release on it.

http://www.poppyfields.net/acorn/docs/acorndocs/taos2.shtml

I gave your site a mention/link on my Galileo/Turbo Nutter thread yesterday - I still visit your site occasionally, so I'd just like to thank you for all the work you did on that. It really was a very useful and pioneering resource (and remains so to this day, for people with an interest in Acorn history).

Amazing, thanks!

A GL implementation for RiscOS in 1995 (presumably as a RM?) would have been curious. My recollection of the Acorn Worlds was that a huge proportion of Acorn staff seemed more interested in running NetBSD than RiscOS itself, and I couldn't help thinking they knew something we didn't.

Yeah, the whole idea was a bit nebulous tbh. I remember the main guy I was speaking to at Acorn talking about creating an ASIC. I believe it was aimed at being some sort of early GPU. But the project never really went anywhere, anyway.

I don't know if it counts as OpenGL exactly, but Jon Kortink's Viewfinder card implemented true native hardware graphics acceleration on RISC OS.

https://www.zeridajh.org/hardware/viewfinder/index.html

Sounds somewhat similar to Java combined with an MQ engine, if you turned it into an OS (like the jnode guys did) and made it load code in response to receiving messages on a queue. Not surprising that they ended up doing JVMs as it seems spiritually very similar.

So many of these ideas have become implemented, in a hodge-podge of disparate mechanisms.

Does anyone know how much of TAO really existed and if it can be accessed today?

It became “Intent” https://en.m.wikipedia.org/wiki/Tao_Group

There was a reasonable amount of noise about this in the Acorn and Amiga universes of the mid 90s but I have never encountered it actually running despite my later being involved in things like interactive tv and mobile games in the appropriate era.

Honestly this is one where I suspect the core OS was vapourware while the company really only made media player libraries.

Edit: according to quite a lot of other comments it did exist. It sounds like I professionally arrived just as it definitively bit the dust.

It never arrived anywhere from the Acorn and Amiga POV (my take on that internally was "we shouldn't be wasting our time with these Amiga chancers", not that my opinion mattered), but it absolutely shipped. The main driver of sales I think was being a JIT Java engine for whatever the mobile-phone-Java-flavour of the time was (in that setup the RTOS underpinnings were all still there, but it ran "hosted" rather than bare-metal, with 'device drivers' that talked to the host OS). We also ended up as the RTOS in a JVC video camera. And of course it being a startup there was a bunch of "have a go at getting into some market/some contract, but it doesn't work out" work as well (I think I did a port to a PS4 devkit at some point, and I still have the Dreamcast devkit that somebody else did a port to, for instance).

Interesting.

Also just checking, but do you mean PS3 devkit?

At this late date most of the details have fallen out of my memory, but checking PS3 and PS4 release dates, yes, it must have been PS3. I remember now that it was the PPC one, which also indicates the PS3. IIRC we had to change our codegen to avoid the "sets flags" versions of instructions because on that CPU they were all microcoded and took an immediate 20 cycle penalty or something...

This is the devkit for the follow up to Taos

"Intent ADK 1.1.1 with some Amiga Anywhere stuff bundled and with Amiga branding."

Not sure if it'll run on 64bit windows.

https://archive.org/details/AmigaPartyPack https://archive.org/details/taos_intent_collection

There's a copy held by the Centre for Computing History, at least according to this record: https://www.computinghistory.org.uk/det/20622/Taos-Operating...

I looked through the IA but it was all locked behind accounts and contacting their sales team.

Presumably one of the many reasons that Tao didn't catch on (although it was a common practise back in the dark ages...)

That's more I think that the business model was B2B and fairly high-touch-per-customer -- "are you a mobile phone handset manufacturer who wants to ship a MIDP Java engine for it? come talk to us about porting our stuff to whatever custom RTOS you're running on it". It was never intended to be direct to consumers or to run on hardware that an end-user would have the ability to install new code to. The Windows and Linux ports were there as the development environment/tools.

I think the main reason it didn't work out was that there was a brief window of opportunity where mobile was a thing but where there was a massively divergent variety of custom platforms and OSes, and so "we can port this to anything and it will then be a common platform for running games/MIDP applications/etc" was a potentially sellable product. But then Android and iOS came along and the whole mobile space coalesced into "there are only two platforms, plus web apps are feasible for a lot of cases, and it's pretty much all Arm", and the need for a middleware layer that abstracted away CPU and OS differences basically evaporated.

It nearly became the next AmigaOS:

https://web.archive.org/web/20170108073531/http://www.amigah...

I'm still not clear, so please correct me if I'm wrong.

I thought that it wasn't really going to be the new OS, it was just taking the Tao elate and putting Amiga branding on it - ie. it couldn't run any existing Amiga software. It existed, you could buy games to run on it but it wasn't anything to do with the existing Amiga OS. There was supposed to (eventually) be some way to run Amiga software emulated or something.

AmigaDE was the 'full developer' thing that you used to develop tao/intent apps. And AmigaEverywhere was the sort of portable runtime.

"Amiga DE is an updated version of Tao Group's Elate operating system. As part of the agreement, Tao Group provided the embedded OS, while Amiga Inc. develop the 'Usability Layer', drivers, and codecs required for a consumer market. "[0]

[0] http://www.bambi-amiga.co.uk/amigahistory/amigade.html

Disclaimer: while I was an admirer of Taos' tech from when it was new, I very rarely actually touched it myself. I played with a demo RiscPC at a show in Wembley, and that's about it.

My understanding (much of it from prior HN threads -- go back and read all the earlier discussions; someone posted links, and it's totally worth it!)

* Taos 1.x was a very basic, almost skeletal. This ran natively on some Acorn ARM kit, and via a DOS loader on x86-32, and some other CPUs.

* Taos 2.x was a much more complete OS and was renamed. Confusingly, to 2 different names; and more confusingly, with embedded formatting. >_<

Int_e_nt was on, El_a_te was the other, I think. Life is too short.

Elate was the bare-metal version. Intent ran under other OSes, but not as a guest or VM, because x86 couldn't do that yet.

(As I wrote:

https://www.theregister.com/Print/2011/07/11/a_brief_history... )

My understanding is that Amiga wanted both, and would run one on bare metal on its own kit, but that the other, runtime version would be made available for other platforms. So, Amiga games authors could write once and run anywhere.

Amiga's own version would have an Amiga-like desktop UI which Amiga Inc. would write.

The runtime wouldn't have a UI, and would just launch apps.

It was, in its way, a good plan, and they should have pressed ahead with it.

I think QNX stole the thunder, and that never went anywhere.

Result: well, AmigaOS 4.x is slowly limping along, and there's MorphOS, which was promising, but both are tied to elderly PowerPC kit.

And there's AROS which seems to be faltering.

I've never used it either, I remember it back from Gateway 2000 days, and an article on OSnews. I have read those HN articles, interesting stuff.

More pieces of the puzzle - intent vs. elate.

If you've got time, here is a LONG tale (with links to sources) about the Amiga Gatgeway/ Hyperion saga legal saga..

https://sites.google.com/site/amigadocuments/home

I never had an Amiga growing up, but AmigaForever & Amikit work well as emulators.

I wish Amiga (also RiscOS), made a sort of Carbon API but for Amiga OS. Cleaned up to work with the new kernel, memory protection for Amiga/ pre-emptive multitasking for RiscOS, source code code be ported relatively easily.

Then the problem would be the "alternate OS problem", how to get money by writing apps for a new api, with a small user base? ( cough BeOS).

ps. You're comments are always quite interesting and informative.

> a sort of Carbon API but for Amiga OS.

That's a great idea! I reckon you should write up that idea as a blog post and see if you can get the community to offer some proposals, and maybe get some AROS, MorphOS and Hyperion (AOS 4) folks to chip in.

> ps. You're comments are always quite interesting and informative.

Thank you very much! That's really good to hear. :-)

Unfortunately, I don't have code, cash or technical knowledge. Also, the Amiga was cool, but like say an SGI workstation (or any Unix workstation really), or an AS/400 or Tandem Nonstop (my personal nerd favs) I don't know what I'd actually do except run some demos. So my blog post would go something like (this is supposed to be deadpan truth, not caustic sarcasm) :

Hi, I've never owned an Amiga, or used one on a daily basis, but I play around with Amikit on my pi400 sometimes because it's interesting to me. Also, I played on my neighbour's Amiga around the time that Hot Shots came out. It had text-to-speech and a flight simulator (Falcon?) but we couldn't figure out how to take off.

I think it would be cool to have a sort of Carbon API for Amiga cleaned up and modernized, so apps could be ported to a new kernel relatively easily.

Sadly, I have zero money to donate to this cause. As well, I don't have the technical knowledge to document an API, and/or note its shortcomings and/or write a new one.

So, lazy-webs lets do this!

ps. I did write a mini-game called "Time Waster 2000" in Visual Basic 3 sometime during the 90s if that helps.

:-)

I'd do it anyway. Stick it in some of the subreddits about Amiga stuff, see if you can get the idea some discussion.

Seems very much ahead of its time (and ours as well).

I’d love to see a demo of it running, in particular the network transparency part.

Here you go...

https://archive.org/details/taos_intent_collection

Also looks like since I last checked, some disks of v1 of the OS has been rediscovered.

https://stardot.org.uk/forums/viewtopic.php?t=19943

Amoeba OS, Plan9 and Inferno OS explored the same stuff.

Only very very loosely, so on balance, I would have to say "no".

The point of Taos was not network transparency, or clusters, or any of that.

The USP of Taos was platform-neutral binaries, translated on the fly to native format as they were loaded from disk. Full native performance on every platform from a single binary file, with the loader/translator embedded into the OS itself.

[Aside: It ended up very small compared to native OSes so it could be used as a runtime as well. It was so efficient that it could convert Java bytecode to its own format and convert that to native code and still outperform the JVM... for a while. ]

Something akin to Java, but the JVM is an addon that you install on a different OS, and there's no "native" OS*. Apps aren't native and don't look or feel like native.

Plan 9 has nothing like this; Plan 9 is UNIX 2.0 with networking and GUI right there in the kernel. Binaries are written in C and compiled to the native CPU; no portability.

Amoeba OS I've never seen but I think it was much the same.

Inferno is Plan 9 2.0, which is to say, it is UNIX 3.0. C is banished, native binaries are banished. A runtime VM, Dis, is embedded in the kernel. Binaries are written in Limbo and compiled to Dis. The same binary runs everywhere, like Taos, but it's not translated as such: there is a bytecode interpreter at a low level.

[Aside #2: It ended up very small compared to native OSes so it could be used as a runtime as well. It was so efficient that it was competitive with the JVM, and so was offered as a rival, but still with its own format that could outperform the JVM... for a while. ]

[Aside #3:

Note the very similar asides 1 & 2. That's deliberate. Both fell into the same trap. Both failed and I think this was a contributing factor. ]

[Aside #4: Java fell into the same trap and failed to compete with Javascript embedded right into the HTML renderer itself. ]

-----

* Yes I know about SavaJE etc. Not directly relevant, and all flopped.

Thanks for the details. It's interesting to know the differences between them. Yes, it looks like Inferno is the closes thing to Taos. My point was that there was a lot of interesting research operating systems that explored ideas in that direction (heterogeneity, distribution, networking, etc). But Taos seems super interesting. In what language is it written?

I do not know for sure, but my impression is that v1 was mostly hand-coded assembler for the low-level stuff, while v2 replaced quite a lot of that with C.

True, but treating a network as a single computer is not something we can easily do even now. You can't easily run Firefox, Slack, LibreOffice, and Thunderbird on a desktop cluster (Think a couple NUC boards tied together) without lots of installation and configuration (and network trickery to fool X clients).

Having said that, this seems like a natural evolutionary path for the Boxes OS.

Read this as "tacos," came expecting some pointlessly quirky OS filled with taco references (perhaps arguments are "fillings", passed to objects called "shells"), am now very disappointed

There is at least an OS like environment called Nachos (Not Another Completely Heuristic Operating System) used many moons ago in the University OS class.

https://en.wikipedia.org/wiki/Not_Another_Completely_Heurist...

https://homes.cs.washington.edu/~tom/nachos/

(Not sure what the possible relation to Taos would be, to make this OT. ;-)

Tacos are an embarrassingly parallel problem after all. It makes sense TacOS would naturally be a thing. It might even need to be hard real time because hangry customers can get a little cagey.

Fedora had a "Beefy Miracle" way back in the day...

Thanks for that; this was a bit before my time. Here’s the link, if anyone wants to be entertained: https://opensource.com/life/12/5/whats-beefy-miracle-anyway-...

Is there any video or screenshot?

https://arstechnica.com/gadgets/2018/03/a-history-of-the-ami...

Reply on news.ycombinator.com