12 ms·

The Taos Operating System (1991)

110 points by vezzy-fnord 11y ago

gandarojin 11y ago
Repost of the article that you already posted 15 hours ago: https://news.ycombinator.com/item?id=9802379 https://news.ycombinator.com/item?id=9802379
- dang 11y ago
  We sometimes invite people to repost articles that look good and didn't get much attention. 11 points is perhaps borderline for "much attention", but we thought the article deserved a discussion, so we invited vezzy-fnord to repost it. (Edit: It's astonishing that, to judge by HN Search, this operating system has never appeared on HN before, either as a story or even in a comment.) In general, a small number of reposts is ok if an article hasn't had significant attention in the last year or so [1]. Letting good stories have a few cracks at making the front page helps mitigate the randomness of what gets traction here. 1. Please see https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html.
  - benaiah 11y ago
    Off topic, but I just wanted to say how much I've appreciated the modding of late. It's been prompt, reasonable, and transparent. Thanks a lot.
  - lsllc 11y ago
    Actually, it was just mentioned two weeks ago (in reference to Apple's bitcode): https://news.ycombinator.com/item?id=9727810 https://news.ycombinator.com/item?id=9727810
    - dang 11y ago
      So it was—good catch! Looks like "taos os" was the thing to search on: https://hn.algolia.com/?query=taos%20os&sort=byDate&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=taos%20os&sort=byDate&prefix&p....
  - gandarojin 11y ago
    Ah, sorry. I did not know that reposts are explicitly allowed even in this timeframe.
    - dang 11y ago
      It'd probably be better to wait a few days, at least for non-topical stories, but our invite system isn't that sophisticated.
- protomyth 11y ago
  not the poster of this article, but when dang sends you an e-mail to repost a story, I tend to listen
rbanffy 11y ago
I've said this before, but it's worth saying it again. It's disappointing the two most popular OSs are a Unix derivative and the bastard child of VMS.
- yellowapple 11y ago
  It could be worse; it wasn't very long ago when the dominant "operating system" was DOS, for example. I personally would love to have a modern Lisp machine. Alas, having lived through the 90's, I'm glad that we at least have Unix. Perhaps someday everything will be unikernels.
  - rbanffy 11y ago
    > it wasn't very long ago when the dominant "operating system" was DOS, for example. The bastard child of CP/M...
    - nickpsecurity 11y ago
      The bastard child of TOPS-10...
- vezzy-fnord 11y ago
  The problem isn't so much Unix, but rather that we have largely failed to evolve it since the days of AT&T System III. The Bell Labs people kept working on Research Unix up to V9 with plenty of great features (like V9 IPC streams) that were never replicated anywhere else, before moving on to the ultimate culmination of these ideas in the form of Plan 9 and Inferno. Meanwhile Linux has always been a boring SysV Unix clone that only occasionally ripped some features (and in a questionable manner) like procfs, sysfs, epoll, signalfd so you don't have to do the self-pipe trick, inotify, cgroups and namespaces. Stuff that competing systems often did much better. The BSDs have been quicker to do more novel things, but by far the only two modern Unices to get the memo are DragonFly BSD and Solaris/illumos.
  - SixSigma 11y ago
glibgil 11y ago
A demo of Amiga branded Taos was released on a CD or DVD with a game magazine. I played with it. It worked.
- aardvark179 11y ago
  Quite a few companies toyed with using it as the basis for their next big thing, but it never quite happened. Pity really as a lot of good people worked at Tao.
- mrec 11y ago
  Yes, I remember it getting coverage in EDGE way back when, and thinking it looked interesting. Then again, I'm one of the few who actually bought a copy of BeOS. RIP, isComputerOn/isComputerOnFire...
dang 11y ago
There's more about this operating system, which apparently was renamed to Elate, and then Intent, at http://mobile.osnews.com/printer.php?news_id=157 http://mobile.osnews.com/printer.php?news_id=157 and http://c2.com/cgi/wiki?TaoIntentOs http://c2.com/cgi/wiki?TaoIntentOs.
- vezzy-fnord 11y ago
  And yet they've pretty much evaporated since. References to this system are very rare and it seems like only a small circle of people ever truly experienced it. No public copy from what I can see.
  - dang 11y ago
    Here's some more info: http://www.uruk.org/emu/Taos.html http://www.uruk.org/emu/Taos.html, via https://groups.google.com/forum/#!topic/comp.lang.forth/Cj_67-6g8dA https://groups.google.com/forum/#!topic/comp.lang.forth/Cj_6.... According to Wikipedia the company was sold in 2007 (https://en.wikipedia.org/wiki/Tao_Group https://en.wikipedia.org/wiki/Tao_Group). That's a pretty long run from the early 90s. I've tried emailing Chris Hinsley to see if he wants to answer questions on HN. An old email address, but maybe he'll see it at some point.
    - vezzy-fnord 11y ago
      The uruk.org opinion article was the one I encountered first, though the BYTE mag one is of higher quality. The wiki article lists quite a convoluted history, not to mention all the rebrandings. It seems like they never really focused on attracting researchers or considering any FOSS presence, which is a shame because it's now practically lost by this point. If Hinsley answers, that'd be great.
      - dang 11y ago
        I agree. Heaps of experimentation and first-class work were lost because they happened before open source became mainstream. Especially in industry, where licensing models sealed work off from community adoption.
stcredzero 11y ago
Parallels to Apple's Bitcode? Could OS X go the way of Taos VM?
- duaneb 11y ago
  LLVM bitcode is a moving target, not a firm spec.
  - stcredzero 11y ago
    That could well change.
c3d 11y ago
Oh, I'm so glad someone ressurected this old article. I kept talking about it, but docon the Internet of Taos and Elate became quite sparse. It was full of great ideas.
UhUhUhUh 11y ago
I'm wondering what stopped this development... Technical issues or financial/environmental? What strikes me is the organic-like structure and functioning of this idea. Which I believe is where things need to go to avoid boring stagnation.
sehugg 11y ago
I remember reading this and getting excited. Still today we haven't quite managed to paralellize all the things, even across cpu cores much less nodes.
haberman 11y ago
I think we've discovered over time that OS Kernels aren't the place for Grand Abstractions. Grand Abstractions are cool and powerful when you are happy to live within their universe. But they tend to be incompatible with other Grand Abstractions. That's why modern kernels tend to focus on Boring Abstractions (threads, processes, locks, memory maps, files, cgroups, etc.) Then the interesting and more opinionated stuff can happen in user-space (Docker, JIT-comiling VMs, web browsers, mobile apps, etc)
- sehugg 11y ago
  A GPU driver is a pretty grand abstraction.
  - haberman 11y ago
    How so? Yes it provides complex abstractions, but these are not inventions of the software, it is just exporting the abstractions supported by the hardware.
    - monocasa 11y ago
      And in fact the kernel space interface doesn't abstract much at all. All of this Vulkan/Metal/DX12 stuff really looks like someone decided to simply export the kernel level interface in a cleaner way.
- JoeAltmaier 11y ago
  Disagree. Those things are already GAs, just ones more familiar with programmers today. So we call them boring. Change the way you think about code, and change the world. And it starts with the application environment, often called the OS.
  - haberman 11y ago
    > Those things are already GAs, just ones more familiar with programmers today. Ask yourself this: could you efficiently implement Taos abstractions on top of POSIX? (probably yes) Could you efficiently implement POSIX abstractions on top of Taos? (probably no) That is the difference between a Grand Abstraction and a Boring Abstraction. > Change the way you think about code, and change the world. I agree that Grand Abstractions can be powerful. > And it starts with the application environment, often called the OS. Sure, just leave the GAs out of the kernel. It doesn't mean you can't have them. Just put them in user-space. Then GAs can operate in a competitive market where you use them because you want to, not because you have to.
cabirum 11y ago
Looks quite similar to Phantom OS, though it seems frozen/dead since 2012. https://en.wikipedia.org/wiki/Phantom_OS https://en.wikipedia.org/wiki/Phantom_OS http://dz.ru/en/solutions/phantom http://dz.ru/en/solutions/phantom
david-given 11y ago
Hello --- ex-Tao employee here! So Tao was my first startup. And then it was my first that-awkward-stage-when-you're-too-old-to-be-a-startup-but-still-don't-have-proper-cashflow. Then it laid off 50% of the staff, then it went bankrupt, then it came back from the dead, then it went bankrupt again. The lessons I learnt from Tao were: 1. Your company needs to be called something which people can pronounce. ('Where do you work?' 'Tao.' 'Dell?' 'Er... no.') 2. An OS which requires people to code for it in a language which only exists in-house is not going to get much external traction. 3. People don't buy advanced technology and then figure out what to do with it. They figure out what they want to do and then buy the technology. 4. When the paycheques stop showing up, leave. The technology was great. I joined just as TAOS was being migrated to intent. Both worked in the same sort of way; code was written in a custom portable assembly language, which was then translated into native machine code when it was loaded into the machine. The TAOS language was VP1, the intent one was VP2, and the first VP2 systems were hosted on TAOS, so it actually translated VP2 into VP1 and then into native. Translation was very, very fast; as both VP were pretty dense it was possible to load and translate VP faster than loading native code, on certain combinations of platforms. VP1 had 16 registers and a pretty simple instruction set. The original incarnation was a assembler macro package. VP2 was way more complicated. It had five register banks (int32, int64, pointer, float, double) of up to 65535 registers each. It was actually a pretty nice system to program in, especially when the assembler got strong typing and structured programming support... yeah, I know what you're thinking. The OS itself was way ahead of its time: it was an asymmetric multiprocessor system, where you could have any number of nodes of different CPU types hooked together via a message-passing system. Code loading was transparent, and devices and filesystems could be attached to any node on the system. It had a blisteringly fast compositing GUI, cutting edge audio synthesis, hardware accelerated OpenGL, and eventually ran on, deep breath: 386 x86 ARM MIPS PowerPC MCore ColdFire Transputer ShBoom and a V, um, V840? Or something? Our standard development procedure for new hardware was to have intent running (inside a Linux process) on a desktop PC; we'd bootstrap a development board up to the point of having serial support and the VP loader; then we'd hook them together. Suddenly, we have a two-node system. We could start a terminal on the desktop and see that node #0 was a Pentium and node #1 was, say, a ColdFire. You could then spawn a process on node #1 and it would run transparently on the dev board with full access to the desktop's filesystem and device drivers, all running, quite slowly, over the serial link. We had a TAOS-era demo box which was a 9-node system consisting of an elderly Pentium and eight transputer nodes; one of the demos was to draw a Mandelbrot, farming each scanline out to a different node. Alas, by the time the transputers had finished drawing their scanline, the Pentium had drawn the entire rest of the image... We never, ever sold the multicore system to anyone. Back in those days it was too novel for customers to know what to do with. Instead we sold it as a embedded OS, which it did really well at. We had a JVM for it, which translated Java bytecodes into VP2, which meant we got, pretty much for free, a Java JIT to native machine code which didn't require any additional porting; any system intent supported also supported Java. (See that list of architectures above? We had a Java JIT that targeted the frickin' TRANSPUTER.) For a while we were the de-facto standard Windows Mobile JVM. Even now there are still copies floating around. But you can't make money selling JVMs; the Sun licensing fees and the large team required for conformance testing soak up any margins. We were asked whether we wanted to become the standard Blu-Ray JVM. We said no --- we didn't see how we could make any money at it. In hindsight that was probably a bad idea, because if we'd said yes then maybe someone would have cared about the company surviving. C and C++ was supported, eventually; we had a gcc port which produced VP2. This was back in the gcc 2.95 days. I'm not sure you realise how horrible gcc 2.95 was, but it was very horrible. C wasn't a good match to the intent way of doing things and we didn't put as much effort into it than we should have; eventually we got traditional programming models complete with shared libraries and dlopen() but it was way too late to matter. Even right at the very end the vast bulk of the system was written in VP2 assembly. We had a fling with Amiga pretty late on, and were the technology behind Amiga Anywhere, which nobody ever cared about. (Although we did actually get a few external users. The sheer novelty of this was hard to handle.) If you actually want to get your hands on an intent development kit, there are some legal copies floating around: we bankrolled a short-lived 'magazine' (read, advertisement) called Digital Magazine, and one issue had a complete PC dev kit on the cover CD. Here's the advert, and yes, the cover picture horribly embarrassed us: http://www.amigahistory.plus.com/amiga_active/digital4press.html http://www.amigahistory.plus.com/amiga_active/digital4press.... But I don't know if there's a copy online. (If you find one, let me know!) You may find this OSNews post about it amusing; drink every time you see a commentor say 'But what is it?'. http://www.osnews.com/comments/743 http://www.osnews.com/comments/743 Eventually the company ran out of money for the last time and completely went under. I regret it deeply; the people were amazing and very, very smart, and the technology was deeply cool. Back in the 90s we worked with Motorola to produce a modern-style touchscreen smartphone; the software stack was in Java, running on an 11MHz ARM. It was fast and responsive and would run full-screen games. Did I mention it ran on an 11MHz ARM? IT RAN ON AN 11MHz ARM. But Motorola canned it shortly before launch. If they'd actually launched it, then Tao, and the entire smartphone world, would be very different. Our CEO said that his ambition was for Tao to be bigger than Acorn. Well, he got his wish when Acorn folded shortly before we did. Sigh.
carlesfe 11y ago
I think it's very relevant to mention "The Future of Programming", a recent talk roleplayed as if it were 1973, with a lot of excitement over the recent developments in computer science, and discussing how the next 40 years would be... only to realize that, 40 years later, we haven't caught up many of these innovations Watch it, it's short, funny, and food for thought: http://worrydream.com/dbx/ http://worrydream.com/dbx/
leoc 11y ago
> FILEFOLDERS > TAOS stores objects onto mass storage media like hard disks via the mailbox system, in objects called 'filefolders'. A filefolder has some similarities to a DOS or Unix directory, but rather than being a passive storage structure it is an active object (in fact a control object). The tools attached to every filefolder are responsible for storing and retrieving objects from the folder and for negotiating with the hardware device drivers that are necessary for this transfer. Because filefolders are actually instances of a broader category of TAOS object called 'filters' they may also process the data they transfer, for example compressing and expanding it transparently to the user. Emphasis added. Oh, it seems they were so close here. The biggest central problem with Unix mount, apart from synchonous/trusted I/O, is that the things that are exposed to the OS through mounting are only files, and never processes ...
- carussell 11y ago
  Sounds a bit like Hurd translators. Is that what you were getting at?
  - leoc 11y ago
    It seems closer, though I'm mainly thinking about unpublished research. ;)
- linschn 11y ago
  > The biggest central problem with Unix mount, apart from synchonous/trusted I/O, is that the things that are exposed to the OS through mounting are only files, and never processes ... With plan9port https://swtch.com/plan9port/ https://swtch.com/plan9port/ you can mount processes on any UNIX.
  - leoc 11y ago
    Sorry, I'm not as familiar with Plan 9 as I should be. I know that it has (and emphasises) user-space mount, but it is my understanding that the entities exposed to the OS through mounting are files, not processes. (Including through /proc, which exposes a directory tree of files containing data about processes, not processes themselves.)
JoachimS 11y ago
Ah Taos! One of serveral very interesting OSes from late 1980s and early 1990s. Grasshopper, Jaguar, Oberon are a few others from the same era. Its probably my age and not keeping up with the research, but it feels like there were more diversity and cool things going on in OS reserach and R&D back then. Though the development of VMs and OSes for IoT and mobile devices is probably a good counterpoint.
JoachimS 11y ago
I love the list of architectures mentioned: "Inmos T800 transputer, Motorola 680x0, PgC7600 (see article in this issue), Intel 80386/80486, Acorn ARM and Sun SPARC" Of these x86 and ARM dominates the world today.
vygr 11y ago
Useful link, several scanned articles on Taos at the bottom of the page. https://en.wikipedia.org/wiki/Virtual_Processor https://en.wikipedia.org/wiki/Virtual_Processor Chris Hinsley

110 points by vezzy-fnord 11y ago

Repost of the article that you already posted 15 hours ago: https://news.ycombinator.com/item?id=9802379 https://news.ycombinator.com/item?id=9802379

dang 11y ago
We sometimes invite people to repost articles that look good and didn't get much attention. 11 points is perhaps borderline for "much attention", but we thought the article deserved a discussion, so we invited vezzy-fnord to repost it. (Edit: It's astonishing that, to judge by HN Search, this operating system has never appeared on HN before, either as a story or even in a comment.) In general, a small number of reposts is ok if an article hasn't had significant attention in the last year or so [1]. Letting good stories have a few cracks at making the front page helps mitigate the randomness of what gets traction here. 1. Please see https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html.
- benaiah 11y ago
  Off topic, but I just wanted to say how much I've appreciated the modding of late. It's been prompt, reasonable, and transparent. Thanks a lot.
- lsllc 11y ago
  Actually, it was just mentioned two weeks ago (in reference to Apple's bitcode): https://news.ycombinator.com/item?id=9727810 https://news.ycombinator.com/item?id=9727810
  - dang 11y ago
    So it was—good catch! Looks like "taos os" was the thing to search on: https://hn.algolia.com/?query=taos%20os&sort=byDate&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=taos%20os&sort=byDate&prefix&p....
- gandarojin 11y ago
  Ah, sorry. I did not know that reposts are explicitly allowed even in this timeframe.
  - dang 11y ago
    It'd probably be better to wait a few days, at least for non-topical stories, but our invite system isn't that sophisticated.
protomyth 11y ago
not the poster of this article, but when dang sends you an e-mail to repost a story, I tend to listen

rbanffy 11y ago

I've said this before, but it's worth saying it again. It's disappointing the two most popular OSs are a Unix derivative and the bastard child of VMS.

yellowapple 11y ago
It could be worse; it wasn't very long ago when the dominant "operating system" was DOS, for example. I personally would love to have a modern Lisp machine. Alas, having lived through the 90's, I'm glad that we at least have Unix. Perhaps someday everything will be unikernels.
- rbanffy 11y ago
  > it wasn't very long ago when the dominant "operating system" was DOS, for example. The bastard child of CP/M...
  - nickpsecurity 11y ago
    The bastard child of TOPS-10...
vezzy-fnord 11y ago
The problem isn't so much Unix, but rather that we have largely failed to evolve it since the days of AT&T System III. The Bell Labs people kept working on Research Unix up to V9 with plenty of great features (like V9 IPC streams) that were never replicated anywhere else, before moving on to the ultimate culmination of these ideas in the form of Plan 9 and Inferno. Meanwhile Linux has always been a boring SysV Unix clone that only occasionally ripped some features (and in a questionable manner) like procfs, sysfs, epoll, signalfd so you don't have to do the self-pipe trick, inotify, cgroups and namespaces. Stuff that competing systems often did much better. The BSDs have been quicker to do more novel things, but by far the only two modern Unices to get the memo are DragonFly BSD and Solaris/illumos.
- SixSigma 11y ago

glibgil 11y ago

A demo of Amiga branded Taos was released on a CD or DVD with a game magazine. I played with it. It worked.

aardvark179 11y ago
Quite a few companies toyed with using it as the basis for their next big thing, but it never quite happened. Pity really as a lot of good people worked at Tao.
mrec 11y ago
Yes, I remember it getting coverage in EDGE way back when, and thinking it looked interesting. Then again, I'm one of the few who actually bought a copy of BeOS. RIP, isComputerOn/isComputerOnFire...

dang 11y ago

There's more about this operating system, which apparently was renamed to Elate, and then Intent, at http://mobile.osnews.com/printer.php?news_id=157 http://mobile.osnews.com/printer.php?news_id=157 and http://c2.com/cgi/wiki?TaoIntentOs http://c2.com/cgi/wiki?TaoIntentOs.

vezzy-fnord 11y ago
And yet they've pretty much evaporated since. References to this system are very rare and it seems like only a small circle of people ever truly experienced it. No public copy from what I can see.
- dang 11y ago
  Here's some more info: http://www.uruk.org/emu/Taos.html http://www.uruk.org/emu/Taos.html, via https://groups.google.com/forum/#!topic/comp.lang.forth/Cj_67-6g8dA https://groups.google.com/forum/#!topic/comp.lang.forth/Cj_6.... According to Wikipedia the company was sold in 2007 (https://en.wikipedia.org/wiki/Tao_Group https://en.wikipedia.org/wiki/Tao_Group). That's a pretty long run from the early 90s. I've tried emailing Chris Hinsley to see if he wants to answer questions on HN. An old email address, but maybe he'll see it at some point.
  - vezzy-fnord 11y ago
    The uruk.org opinion article was the one I encountered first, though the BYTE mag one is of higher quality. The wiki article lists quite a convoluted history, not to mention all the rebrandings. It seems like they never really focused on attracting researchers or considering any FOSS presence, which is a shame because it's now practically lost by this point. If Hinsley answers, that'd be great.
    - dang 11y ago
      I agree. Heaps of experimentation and first-class work were lost because they happened before open source became mainstream. Especially in industry, where licensing models sealed work off from community adoption.

stcredzero 11y ago

Parallels to Apple's Bitcode? Could OS X go the way of Taos VM?

duaneb 11y ago
LLVM bitcode is a moving target, not a firm spec.
- stcredzero 11y ago
  That could well change.

c3d 11y ago

Oh, I'm so glad someone ressurected this old article. I kept talking about it, but docon the Internet of Taos and Elate became quite sparse. It was full of great ideas.

UhUhUhUh 11y ago

I'm wondering what stopped this development... Technical issues or financial/environmental? What strikes me is the organic-like structure and functioning of this idea. Which I believe is where things need to go to avoid boring stagnation.

sehugg 11y ago

I remember reading this and getting excited. Still today we haven't quite managed to paralellize all the things, even across cpu cores much less nodes.

haberman 11y ago

I think we've discovered over time that OS Kernels aren't the place for Grand Abstractions. Grand Abstractions are cool and powerful when you are happy to live within their universe. But they tend to be incompatible with other Grand Abstractions. That's why modern kernels tend to focus on Boring Abstractions (threads, processes, locks, memory maps, files, cgroups, etc.) Then the interesting and more opinionated stuff can happen in user-space (Docker, JIT-comiling VMs, web browsers, mobile apps, etc)

sehugg 11y ago
A GPU driver is a pretty grand abstraction.
- haberman 11y ago
  How so? Yes it provides complex abstractions, but these are not inventions of the software, it is just exporting the abstractions supported by the hardware.
  - monocasa 11y ago
    And in fact the kernel space interface doesn't abstract much at all. All of this Vulkan/Metal/DX12 stuff really looks like someone decided to simply export the kernel level interface in a cleaner way.
JoeAltmaier 11y ago
Disagree. Those things are already GAs, just ones more familiar with programmers today. So we call them boring. Change the way you think about code, and change the world. And it starts with the application environment, often called the OS.
- haberman 11y ago
  > Those things are already GAs, just ones more familiar with programmers today. Ask yourself this: could you efficiently implement Taos abstractions on top of POSIX? (probably yes) Could you efficiently implement POSIX abstractions on top of Taos? (probably no) That is the difference between a Grand Abstraction and a Boring Abstraction. > Change the way you think about code, and change the world. I agree that Grand Abstractions can be powerful. > And it starts with the application environment, often called the OS. Sure, just leave the GAs out of the kernel. It doesn't mean you can't have them. Just put them in user-space. Then GAs can operate in a competitive market where you use them because you want to, not because you have to.

cabirum 11y ago

Looks quite similar to Phantom OS, though it seems frozen/dead since 2012. https://en.wikipedia.org/wiki/Phantom_OS https://en.wikipedia.org/wiki/Phantom_OS http://dz.ru/en/solutions/phantom http://dz.ru/en/solutions/phantom

david-given 11y ago

Hello --- ex-Tao employee here! So Tao was my first startup. And then it was my first that-awkward-stage-when-you're-too-old-to-be-a-startup-but-still-don't-have-proper-cashflow. Then it laid off 50% of the staff, then it went bankrupt, then it came back from the dead, then it went bankrupt again. The lessons I learnt from Tao were: 1. Your company needs to be called something which people can pronounce. ('Where do you work?' 'Tao.' 'Dell?' 'Er... no.') 2. An OS which requires people to code for it in a language which only exists in-house is not going to get much external traction. 3. People don't buy advanced technology and then figure out what to do with it. They figure out what they want to do and then buy the technology. 4. When the paycheques stop showing up, leave. The technology was great. I joined just as TAOS was being migrated to intent. Both worked in the same sort of way; code was written in a custom portable assembly language, which was then translated into native machine code when it was loaded into the machine. The TAOS language was VP1, the intent one was VP2, and the first VP2 systems were hosted on TAOS, so it actually translated VP2 into VP1 and then into native. Translation was very, very fast; as both VP were pretty dense it was possible to load and translate VP faster than loading native code, on certain combinations of platforms. VP1 had 16 registers and a pretty simple instruction set. The original incarnation was a assembler macro package. VP2 was way more complicated. It had five register banks (int32, int64, pointer, float, double) of up to 65535 registers each. It was actually a pretty nice system to program in, especially when the assembler got strong typing and structured programming support... yeah, I know what you're thinking. The OS itself was way ahead of its time: it was an asymmetric multiprocessor system, where you could have any number of nodes of different CPU types hooked together via a message-passing system. Code loading was transparent, and devices and filesystems could be attached to any node on the system. It had a blisteringly fast compositing GUI, cutting edge audio synthesis, hardware accelerated OpenGL, and eventually ran on, deep breath: 386 x86 ARM MIPS PowerPC MCore ColdFire Transputer ShBoom and a V, um, V840? Or something? Our standard development procedure for new hardware was to have intent running (inside a Linux process) on a desktop PC; we'd bootstrap a development board up to the point of having serial support and the VP loader; then we'd hook them together. Suddenly, we have a two-node system. We could start a terminal on the desktop and see that node #0 was a Pentium and node #1 was, say, a ColdFire. You could then spawn a process on node #1 and it would run transparently on the dev board with full access to the desktop's filesystem and device drivers, all running, quite slowly, over the serial link. We had a TAOS-era demo box which was a 9-node system consisting of an elderly Pentium and eight transputer nodes; one of the demos was to draw a Mandelbrot, farming each scanline out to a different node. Alas, by the time the transputers had finished drawing their scanline, the Pentium had drawn the entire rest of the image... We never, ever sold the multicore system to anyone. Back in those days it was too novel for customers to know what to do with. Instead we sold it as a embedded OS, which it did really well at. We had a JVM for it, which translated Java bytecodes into VP2, which meant we got, pretty much for free, a Java JIT to native machine code which didn't require any additional porting; any system intent supported also supported Java. (See that list of architectures above? We had a Java JIT that targeted the frickin' TRANSPUTER.) For a while we were the de-facto standard Windows Mobile JVM. Even now there are still copies floating around. But you can't make money selling JVMs; the Sun licensing fees and the large team required for conformance testing soak up any margins. We were asked whether we wanted to become the standard Blu-Ray JVM. We said no --- we didn't see how we could make any money at it. In hindsight that was probably a bad idea, because if we'd said yes then maybe someone would have cared about the company surviving. C and C++ was supported, eventually; we had a gcc port which produced VP2. This was back in the gcc 2.95 days. I'm not sure you realise how horrible gcc 2.95 was, but it was very horrible. C wasn't a good match to the intent way of doing things and we didn't put as much effort into it than we should have; eventually we got traditional programming models complete with shared libraries and dlopen() but it was way too late to matter. Even right at the very end the vast bulk of the system was written in VP2 assembly. We had a fling with Amiga pretty late on, and were the technology behind Amiga Anywhere, which nobody ever cared about. (Although we did actually get a few external users. The sheer novelty of this was hard to handle.) If you actually want to get your hands on an intent development kit, there are some legal copies floating around: we bankrolled a short-lived 'magazine' (read, advertisement) called Digital Magazine, and one issue had a complete PC dev kit on the cover CD. Here's the advert, and yes, the cover picture horribly embarrassed us: http://www.amigahistory.plus.com/amiga_active/digital4press.html http://www.amigahistory.plus.com/amiga_active/digital4press.... But I don't know if there's a copy online. (If you find one, let me know!) You may find this OSNews post about it amusing; drink every time you see a commentor say 'But what is it?'. http://www.osnews.com/comments/743 http://www.osnews.com/comments/743 Eventually the company ran out of money for the last time and completely went under. I regret it deeply; the people were amazing and very, very smart, and the technology was deeply cool. Back in the 90s we worked with Motorola to produce a modern-style touchscreen smartphone; the software stack was in Java, running on an 11MHz ARM. It was fast and responsive and would run full-screen games. Did I mention it ran on an 11MHz ARM? IT RAN ON AN 11MHz ARM. But Motorola canned it shortly before launch. If they'd actually launched it, then Tao, and the entire smartphone world, would be very different. Our CEO said that his ambition was for Tao to be bigger than Acorn. Well, he got his wish when Acorn folded shortly before we did. Sigh.

carlesfe 11y ago

I think it's very relevant to mention "The Future of Programming", a recent talk roleplayed as if it were 1973, with a lot of excitement over the recent developments in computer science, and discussing how the next 40 years would be... only to realize that, 40 years later, we haven't caught up many of these innovations Watch it, it's short, funny, and food for thought: http://worrydream.com/dbx/ http://worrydream.com/dbx/

leoc 11y ago

> FILEFOLDERS > TAOS stores objects onto mass storage media like hard disks via the mailbox system, in objects called 'filefolders'. A filefolder has some similarities to a DOS or Unix directory, but rather than being a passive storage structure it is an active object (in fact a control object). The tools attached to every filefolder are responsible for storing and retrieving objects from the folder and for negotiating with the hardware device drivers that are necessary for this transfer. Because filefolders are actually instances of a broader category of TAOS object called 'filters' they may also process the data they transfer, for example compressing and expanding it transparently to the user. Emphasis added. Oh, it seems they were so close here. The biggest central problem with Unix mount, apart from synchonous/trusted I/O, is that the things that are exposed to the OS through mounting are only files, and never processes ...

carussell 11y ago
Sounds a bit like Hurd translators. Is that what you were getting at?
- leoc 11y ago
  It seems closer, though I'm mainly thinking about unpublished research. ;)
linschn 11y ago
> The biggest central problem with Unix mount, apart from synchonous/trusted I/O, is that the things that are exposed to the OS through mounting are only files, and never processes ... With plan9port https://swtch.com/plan9port/ https://swtch.com/plan9port/ you can mount processes on any UNIX.
- leoc 11y ago
  Sorry, I'm not as familiar with Plan 9 as I should be. I know that it has (and emphasises) user-space mount, but it is my understanding that the entities exposed to the OS through mounting are files, not processes. (Including through /proc, which exposes a directory tree of files containing data about processes, not processes themselves.)

JoachimS 11y ago

Ah Taos! One of serveral very interesting OSes from late 1980s and early 1990s. Grasshopper, Jaguar, Oberon are a few others from the same era. Its probably my age and not keeping up with the research, but it feels like there were more diversity and cool things going on in OS reserach and R&D back then. Though the development of VMs and OSes for IoT and mobile devices is probably a good counterpoint.

JoachimS 11y ago

I love the list of architectures mentioned: "Inmos T800 transputer, Motorola 680x0, PgC7600 (see article in this issue), Intel 80386/80486, Acorn ARM and Sun SPARC" Of these x86 and ARM dominates the world today.

vygr 11y ago

Useful link, several scanned articles on Taos at the bottom of the page. https://en.wikipedia.org/wiki/Virtual_Processor https://en.wikipedia.org/wiki/Virtual_Processor Chris Hinsley