Amibian is what you need to transform your ODROID into an Amiga. It is a very lightweight SD card image that fits on SD cards from the size of 2GB and up. It is made to give you the best Amiga experience you can get without having an actual Amiga. Amibian allows you to remember, relive, and rediscover the joy of Amiga easily with cheap hardware and minimum effort.
Early this month I announced that the official hardware will be based around Hardkernel’s ODROID-XU4 line of SBC’s (single board computers) which deliver good performance, exceptional stability, and low power consumption at a reasonable price. I also availed that the first Amibian.js setup would consist of five ODROID-XU4 boards working together in a cluster, meaning that work is divided among these five boards for high efficiency and that they share resources.
Amibian.js is gaining momentum as more and more developers, embedded systems architects, gamers, and retro computer enthusiasts discover the project. I have to admit I’m pretty stoked about what we are building here myself!
The second trap you can fall into is to exaggerate what a new technology can do, and attach abilities and expectations to a product that simply cannot be delivered. It is very important to me that people don’t fall into either trap, and that everyone is informed about what Amibian.js actually is and can deliver, as well as what it won’t deliver. Rome was not built in a day, and it’s wise to study all the factors before passing judgement.
I have been truly fortunate that people support the project financially via Patreon, and as such I feel it’s my duty to document and explain as much as possible. I am a programmer and I often forget that not everyone understands what I’m talking about. We are all human and make mistakes. Hopefully this article will paint a clearer picture of Amibian.js and what we are building here. The project is divided into two phases: first, to finish Amibian.js itself; and second, to write a Visual Studio clone that runs purely in the browser.
What the heck is Amibian.js?
Amibian.js is a group of services and libraries that combined creates a portable operating system that renders to HTML5. A system that was written using readily available web technology, and designed to deliver advanced desktop functionality to web applications.
The services that make up Amibian.js were designed to piggyback on a thin Linux crust, where Linux deals with the hardware, drivers, and the nitty-gritty we take for granted. There is no point in trying to write a better kernel in 2018, because you are never going to catch up with Linus Torvalds. It’s much more interesting to push modern web technology to the absolute limits, and build a system that is truly portable and distributed.
What does Amibian.js consist of?
Amibian.js consists of many parts, but we can divide it into two categories:
- A HTML5 desktop client
- A system server and various child processes
These two categories have the exact same relationship as the X desktop and the Linux kernel. The client connects to the server, invokes procedures to do some work, and then visually represent the response This is identical to how the X desktop calls functions in the kernel or one of the Linux libraries. The difference between the traditional, machine code based OS and our web variation, is that our version doesn’t have to care about the hardware. We can also assign many different roles to Amibian.js. More about that later.
The Amibian.js server is not a single program. The back-end for Amibian.js consists of several service applications (daemons on Linux) that each deliver specific features. The combined functionality of these services make up “the Amibian kernel” in our analogy with Linux. You can think of these services as library files in a traditional system, and programs that are written for Amibian.js can call on these to a wide range of tasks. It can be as simple as reading a file, or as complex as registering a new user or requesting admin rights.
The greatest strength of Amibian.js is that it’s designed to run clustered, using as many CPU cores as possible. It’s also designed to scale, meaning that it will replicate itself and divide the work between different instances. This is where things get interesting, because an Amibian.js cluster doesn’t need the latest and coolest hardware to deliver good performance. You can build a cluster of old PCs in your office, or a handful of embedded boards. An ODROID-XU4, Raspberry Pi or a Tinker Board are brilliant candidates.
Why not just stick with Linux?
That is a fair question, and this is where the roles I mentioned above comes in. As a software developer, many of my customers work with embedded devices and kiosk systems. You have companies that produce routers and set-top boxes, NAS boxes of various complexity, ticket systems for trains and busses; and all of them end up having to solve the same needs.
What each of these manufacturers have in common is the need for a web desktop system that can be adapted for a specific program. Any idiot can write a web application, but when you need safe access to the filesystem, unified API’s that can delegate signals to Amazon, Azure, or your company server, things suddenly get more complicated. Even when you have all of that, you still need a rock solid application model suitable for distributed computing. You might have 1 ticket booth, or 10,000 nationwide. There are no systems available that are designed to deal with web technology on that scale. Yet.
Let’s look at a couple of real-life scenarios that I have encountered. I’m confident you will recognize a common need. Here are some roles that Amibian.js can assume to help deliver a solution rapidly. It also gives you some ideas of the economic possibilities.
- When you want to change some settings on your router, login to your router. It contains a small apache server (or something similar) and you do all your maintenance via that web interface. The web interface is typically skin-deep, annoying to work with, and a pain for developers to update since it’s connected to a native apache module which is 100% dependent on the firmware. Each vendor ends up reinventing the wheel over and over again.
- When you visit a large museum notice the displays. A museum needs to display multimedia, preferably on touch capable devices, throughout different exhibits. The cost of having a developer create native applications that display the media, play the movies, and give visual feedback is astronomical. This is why most museums adopt web technology to handle media presentation and interaction, once again reinventing the wheel with varying degree of success.
- Hotels have more or less the exact same need but on a smaller scale, especially larger hotels where the lobby has information booths, and each room displays a web interface via the TV.
- Shopping malls face the same challenge, and depending on the size they can need anything from a single to a hundred nodes.
Amibian.js provides a rich foundation of more than 4000 classes that developers can use to write large, complex, and media-rich applications (see Smart Mobile Studio below). Just like Linux and Windows provide a wealth of libraries and features for native application development, Amibian.js aims to provide the same for cloud and embedded systems.
As the name implies, Amibian.js has roots in the past with the machine that defined multimedia, the Commodore Amiga. The relation is more than just visual: Amibian.js uses the same system architecture because we believe it’s one of the best systems ever designed.
First of all, I’m not selling anything. It’s not like this project is something that is going to make me a ton of cash. I ask for support during the development period because I want to allocate proper time for it, but when done Amibian.js will be free for everyone (LGPL). And I’m also writing it because it’s something that I need that I haven’t seen anywhere else. I think you have to write software for yourself, otherwise the quality won’t be there.
Prior to starting the Amibian.js project, I spent roughly 9 years creating Smart Mobile Studio. Smart is not a solo project–many individuals have been involved. The product provides a compiler, IDE (editor and tools), and a vast run-time library of pre-made classes (roughly 4000 ready to use classes, or building-blocks).
But how would I use Amibian.js?
Amibian.js can be setup and used in four different ways:
- As a true desktop, booting straight into Amibian.js in full-screen
- As a cloud service, accessed through any modern browser
- As a NAS or Kiosk front-end
- As a local system on your existing OS. A batch script will fire it up and you can access it on https://127.0.0.1:8090 using your browser.
So the short answer is yes, you install it. But it’s the same as installing Chrome OS. It’s not like an application you just install on your Linux, Windows, or OSX box. The whole point of Amibian.js is to have a platform independent, chipset agnostic system. Something that doesn’t care if you are using ARM, x86, PPC or Mips as your CPU of preference. Developers will no doubt install it on their existing machines. Amibian.js is non-intrusive and does not affect or touch files outside its own ecosystem. However, the average non-programmer will most likely setup a dedicated machine (or several) or just deploy it on their home NAS.
The first way of enjoying Amibian.js is to install it on a PC or ARM device. A disk image will be provided for supporters so they can get up and running ASAP. This disk image will be based on a thin Linux setup, just enough to get all the drivers going (but no X desktop). It will start all the node.js services and finally enter a full-screen web display (based on Chromium Embedded) that renders the desktop. This is the method most users will prefer to work with Amibian.js.
The second way is to use it as a cloud service. You install Amibian.js like mentioned above, but you do so on Amazon or Azure. That way you can login to your desktop using nothing but a web browser. This is a very cost-effective way of enjoying Amibian.js since renting a virtual instance is affordable and storage is abundant.
The third option is for developers. Amibian.js is a desktop system, which means it’s designed to host more elaborate applications. Where you would normally just embed an external website into an IFrame, but Amibian.js is not that primitive. Hosting external applications requires you to write a security manifest file, but more importantly: the application must interface with the desktop through the window’s message-port. This is a special object that is sent to the application as a hand-shake, and the only way for the application to access things like the file-system and server-side functionality, is via this message-port.
Calling “kernel” level functions from a hosted application is done purely via the message-port mentioned above. The actual message data is JSON and must conform to the Ragnarok client protocol specification. This is not as difficult as it might sound, but Amibian.js takes security very seriously so applications trying to cause damage will be promptly shut down.
You mention hosted applications, do you mean websites?
Both yes and no: Amibian.js supports 3 types of applications:
- Ordinary HTML5/JS based applications, or “websites” as many would call them. But like I talked about above they have to establish a dialog with the desktop before they can do anything useful.
- Hybrid applications where half is installed as a node.js service, and the other half is served as a normal HTML5 app. This is the coolest program model, and developers essentially write both a server and a client and then deploy it as a single package.
- LDEF compiled bytecode applications, a 68k inspired assembly language that is JIT compiled by the browser (commonly called “asm.js”) and runs extremely fast. The LDEF virtual machine is a sub-project in Amibian.js
The latter option, bytecodes, is a bit like Java. A part of the Amibian.js project is a compiler and runtime system called LDEF.
The first part of the Amibian.js project is to establish the desktop and back-end services. The second part of the project is to create the world’s first cloud based development platform. A full Visual Studio clone if you like, that allows anyone to write cloud, mobile, and native applications directly via the browser.
Several languages are supported by LDEF, and you can write programs in Object Pascal, Basic and C. The Basic dialect is especially fun to work with, since it’s a re-implementation of BlitzBasic, with a lot of added extras. Amiga developers will no doubt remember BlitzBasic as it was used to create some great games back in the 80s and 90s. It’s well suited for games and multimedia programming and above all–very easy to learn.
More advanced developers can enjoy Object Pascal (read: Delphi) or a subset of C/C++. Please note: This IDE is designed for large-scale applications, not simple snippets. The ultimate goal of Amibian.js is to move the entire development cycle to the cloud and away from the desktop. With Amibian.js you can write a cool “app” in BlitzBasic, run it right in the browser, or compile it server-side and deploy it to your Android Phone as a real, natively compiled application. Any notion of a “mock desktop for HTML” should be firmly put to the side. I am not playing around with this product and the stakes are very real.
But why don’t you just use ChromeOS?
There are many reasons, but the most important one is chipset independence. Chrome OS is a native system, meaning that it’s core services are written in C/C++ and compiled to machine code. The fundamental principle of Amibian.js is to be 100% platform agnostic, and “no native code allowed.” This is why the entire back-end and service layer is targeting node.js. This ensures the same behavior regardless of processor or host system (Linux being the default host).
Node.js has the benefit of being 100% platform independent. You will find node.js for ARM, x86, Mips, and PPC. This means you can take advantage of whatever hardware is available. You can even recycle older computers that have lost mainstream support, and use them to run Amibian.js.
A second reason is this: Chrome OS might be free, but it’s only as open as Google wants it to be. Chrome OS is not just something you pick up and start altering. It’s dependence on native programming languages, compiler toolchains, and a huge set of libraries makes it extremely niche. It also shields you utterly from the interesting parts, namely the back-end services. It’s quite frankly boring and too boxed in for any practical use–except for Google and its technology partners, that is.
I wanted a system that I could move around, that could run in the cloud on cheap SBC’s. A system that could scale from handling 10 users to 1000 users–a system that supports clustering and can be installed on multiple machines in a swarm.
What is this Amiga stuff, isn’t that an ancient machine?
In computing terms yes, but so is Unix. Old doesn’t automatically mean bad, it actually means that it has adapted and survived challenges beyond its initial design. While most of us remember the Amiga for its games, I remember it mainly for its elegant and powerful operating system. A system so flexible that it’s still in use around the world–33 years after the machine hit the market. That is quite an achievement.
Amibian.js, as the name implies, borrows architectural elements en masse from Amiga OS. Quite simply because the way Amiga OS is organized and the way you approach computing on the Amiga is brilliant. Amiga OS is much more intuitive and easier to understand than Linux and Windows. It’s a system that you could learn how to use fully with just a couple of days exploring and no manuals.
But the similarities are not just visual or architectural. Remember I wrote that hosted applications can access and use the Amibian.js services? These services implement as much of the original ROM Kernel functions as possible. Naturally I can’t port all of it, because it’s not really relevant for Amibian.js. Things like device-drivers serve little purpose for Amibian.js, because Amibian.js talks to node.js, and node talks to the actual system, which in turn handles hardware devices. But the way you would create windows, visual controls, bind events and create a modern, event-driven application has been preserved to the best of my ability.
How does this thing boot?
If you have set up a dedicated machine with Amibian.js then the boot sequence is the same as Linux, except that the node.js services are executed as background processes (daemons or services as they are called), the core server is initialized, and then a full-screen HTML5 view is set up that shows the desktop.
But that is just for starting the system. Your personal boot sequence which deals with your account, your preferences and adaptations–that boots when you login to the system.
When you login to your Amibian.js account, no matter if it’s just locally on a single PC, a distributed cluster, or via the browser into your cloud account, several things happen:
- The client (web-page if you like) connects to the server using WebSocket.
- Login is validated by the server.
- The client starts loading preferences files via the mapped filesystem, and then applies these to the desktop.
- A startup sequence script file is loaded from your account, and then executed. The shell-script runtime engine is built into the client, as is REXX execution.
- The startup-script will set up configurations, create symbolic links (assigns), mount external devices (Dropbox, Google drive, FTP locations and so on).
- When finished the programs in the ~/WbStartup folder are started. These can be both visual and non-visual.
As you can see, Amibian.js is not a mockup or “fake” desktop. It implements all the advanced features you expect from a “real” desktop. The filesystem mapping is especially advanced, where file data is loaded via special drivers; drivers that act as a bridge between a storage service (a hard disk, a network share, a FTP host, Dropbox, or whatever) and the desktop. Developers can add as many of these drivers as they want. If they have their own homebrew storage system on their existing servers, they can implement a driver for it. This ensures that Amibian.js can access any storage device, as long as the driver conforms to the driver standard.
In short, you can create, delete, move, and copy files between these devices just like you do on Windows, OSX, or the Linux desktop. And hosted applications that run inside their own window can likewise request access to these drivers and work with the filesystem (and much more!).
Can Amibian.js really run actual programs?
But the really interesting part is probably QEmu. This allows you to run x86 instances directly in the browser too. You can boot up in Windows 7 or Ubuntu inside an Amibian.js window if you like. Perhaps not practical at this point, but it shows some of the potential of the system.
I have been experimenting with a distributed emulation system, where the emulation is executed server-side, and only the graphics and sound is streamed back to the Amibian.js client in real-time. This has been possible for years via Apache Guacamole, but doing it in raw JS is more fitting with our philosophy: no native code!
I heard something about clustering?
Remember I wrote about the services that Amibian.js has? Those that act almost like libraries on a physical computer? Well, these services don’t have to be on the same machine—you can place them on separate machines and thus its able to work faster.
A cluster is typically several computers connected together, with the sole purpose of having more CPU cores to divide the work on. The cool thing about Amibian.js is that it doesn’t care about the underlying CPU. As long as node.js is available it will happily run whatever service you like with the same behavior and result.
The official Amibian.js cluster consists of five ODROID-XU4/S SBC (single board computers). Four of these are so-called “headless” computers, meaning that they don’t have a HDMI port and they are designed to be logged into and software setup via SSH or similar tools. The last machine is a ODROID-XU4 with a HDMI out port, which serves as “the master”.
The architecture is quite simple: We allocate one whole SBC for a single service, and allow the service to copy itself to use all the CPU cores available—each SBC has eight CPU cores. With this architecture, the machine that deals with the desktop clients doesn’t have to do all the grunt work. It will accept tasks from the user and hosted applications, and then delegate the tasks between the four other machines.
Please note that the number of SBC’s is not fixed. Depending on your use, you might not need more than a single SBC in your home setup, or perhaps two. I have started with five because I want each part of the architecture to have as much CPU power as possible. So the first “official” Amibian.js setup is a 40 core monster shipping at around $250.
But as I mentioned, you don’t have to buy this to use Amibian.js. You can install it on a single spare X86 PC you have, or daisy chain a couple of older PC’s on a switch for the same result.
The headless SBC’s in the initial design all have a GPU (graphical processing unit) as well as audio capabilities. What they lack is GPIO pins and 3 additional USB ports. So each of the nodes on our cluster can handle graphics at blistering speed—but that is ultimately not their task. They serve more as compute modules that will be given tasks to finish quickly, while the main machine deals with users, sessions, traffic and security.
The 40-core cluster I use has more computing power than Northern Europe had in the early 80s. That’s something to think about. And the pricetag is under $300! I don’t know about you, but I always wanted a proper mainframe, a distributed computing platform that you can login to, and that can perform large tasks while I do something else. This is as close as I can get on a limited budget, yet I find the limitations thrilling and fun!
Part of the reason I have opted for a clustered design has to do with future development. While UAE.js is brilliant to emulate an Amiga directly in the browser, a more interesting design is to decouple the emulation from the output. In other words, run the emulation at full speed server-side, and just stream the display and sounds back to the Amibian.js display. This would ensure that emulation of any platform runs as fast as possible, makes use of multi-processing (read: multi threading), and fully utilizes the network bandwidth within the design (the cluster runs on its own switch, separate from the outside world-wide-web).
I am also very interested in distributed computing, where we split up a program and run each part on different cores. This is a topic I want to investigate further when Amibian.js is completed. It would no doubt require a re-design of the LDEF bytecode system, but this something to research later.
Will Amibian.js replace my Windows box?
That depends completely on what you use Windows for. The goal is to create a self-sustaining system. For retro computing, emulation, and writing cool applications Amibian.js will be awesome. But Rome was not built in a day, so it’s wise to be patient and approach Amibian.js like you would Chrome OS. Some tasks are better suited for native systems like Linux, but more and more tasks will run just fine on a cloud desktop like Amibian.js.
Until the IDE and compilers are in place after phase two, the system will be more like an embedded OS. But when the LDEF compiler and IDE is in place, then people will start using it en masse and produce applications for it. It’s always a bit of work to reach that point and create critical mass.
My personal need has to do with development. Some of the languages I use installs gigabytes onto my PC and you need a full laptop to access them. I love Amibian.js because I will be able to work anywhere in the world, as long as a browser and normal internet line is available. In my case, I can install a native compiler on one of the nodes in the cluster, and have LDEF emit compatible code. Voila, you can build app-store ready applications from within a browser environment.
I also love that I can set up a dedicated platform that runs legacy applications and games, and that I can write new applications and services using modern, off-the-shelf languages. Should a node in the cluster break down, I can just copy the whole system over to a new, affordable SBC and keep going. No super expensive hardware to order, no absurd hosting fees, and finally a system that we all can shape and use in a plethora of systems. From a full-fledged desktop to a super advanced NAS or router that uses Amibian.js to give its customers a fantastic experience.
And yes, I get to re-create the wonderful reality of Amiga OS without the absurd egoism that dominates the Amiga owners to this day. I don’t even know where to begin with the present license holders–and I am so sick of the drama that rolling my own seemed the only reasonable path forward.
I hope this helps clear up any misconceptions about Amibian.js, and that you find this as interesting as I do. As more and more services are pushed cloud-side, the more relevant Amibian.js will become. It is perfect as a foundation for large-scale applications, embedded systems, and indeed, as a solo platform running on embedded devices. I can’t wait to finish the services and cluster this sucker on the ODROID rack!
If you find this project interesting, head over to my Patreon website at http://www.patreon.com/quartexNow and get involved! I could really use your support, even if it’s just a $5 “high five”. For comments, questions, and suggestions, please visit the original article at https://jonlennartaasenden.wordpress.com/2018/12/05/amibian-js-under-the-hood/.