OS News Archive

ChrysaLisp: an assembler/C-Script/Lisp 64bit OS

Assembler/C-Script/Lisp 64 bit OS. MIMD, multi CPU, multi threaded, multi core, multi user.

Runs on OSX or Linux for x64, PI64 Linux for Aarch64. Will move to bare metal eventually but it's useful for now to run hosted while experimenting. When time allows I will be doing a VM boot image for UniKernel type appliances and a WebAssembly target to play around within the browser.

Allows modelling of various network topologies with point to point links. Each CPU in the network is modelled as a separate host process, point to point links use shared memory to simulate CPU to CPU, point to point, bi directional connections. There is no global bus based networking on purpose.

The first commercial Asteroid OS smartwatch revealed

The first ever commercial Asteroid OS smartwatch, Connect Watch, was revealed today by a French company going by the same name. A Wi-Fi only model and a 3G model were unveiled with prices 99€ and 129€ respectively. Sales for these watches will commence tomorrow. Connect watch aims to provide a free watch alternative to the Android Wear and Tizen watches. The watches are capable to function on their own without the need for a smartphone and the 3G model can perform calls as well.

Asteroid OS, for those of you who don't know, is a Nemo Mobile based open source smartwatch OS and thus shares a lot of blood with Sailfish OS. Spearheaded by a talented young programmer Florent Revest, The project has matured a lot in 2 years since it inception and garnered lot of interest around the world. Jolla's Sailfish OS for smartwatch demo displayed in Slush 2016 and MWC 2017 was also based on Asteroid OS. No Asteroid OS sync application for Sailfish OS is yet to be in development.

It's 2017, and I can post a news item about an alternative operating system shipping on a smartwatch.

Today was a good day.

Genode 17.08 supports Intel Gen-8 GPUs

With version 17.08, the Genode OS project conquers the highly complex topic of hardware-accelerated graphics. In true microkernel fashion, Genode's new Intel-GPU multiplexer provides the bare minimum of functionality to enable (potentially untrusted) components to use the GPU without interfering with each other. Further highlights of the new release are the broadened support for the seL4 microkernel on ARM and 64-bit x86, the ability to boot via UEFI, and Genode's use as Xen DomU domain.

Seven years ago, the Genode developers took their first baby steps with the use of hardware-accelerated graphics. However, their original port of the Intel graphics execution manager along with Mesa/Gallium to the Genode user land never outgrew an experimental stage. One particular limitation was that the GPU could only be used by a single application exclusively. At that time, the secure sharing of GPUs among multiple - and potentially malicious - applications was an afterthought in the predominant driver architectures like Linux' DRI. A port of this driver architecture to Genode would not magically solve that.

In the meanwhile, hardware features like per-process graphics translation tables (PPGTT) and hardware contexts have proliferated and are now present in all modern Intel GPUs. What MMU-based virtual memory is to a CPU, these features are to a GPU. They in principle allow the sandboxed execution of GPU commands under the regime of a potentially very small GPU driver, analogously to how a microkernel facilitates an MMU to sandbox user-level components. However, with about 100K lines of code, Intel's official i915 driver stack as used in the Linux kernel is far from being small and simple. To put the number in perspective, modern microkernels like seL4 or NOVA consist of merely 10K lines of code. Inflating Genode's trusted computing base by on order of magnitude would be a tough decision. There had to be another way. Hence, one year ago, an experiment was started to develop a clean-slate GPU multiplexer as a Genode component. In contrast to the i915 driver stack that needs to accommodate a mind boggling number of legacy hardware that is still in broad use, Genode's custom GPU multiplexer could do a clear cut by only supporting very recent GPUs. The result is quite reassuring. At far less than 10K of code, Genode's new user-land GPU multiplexer is able to accommodate trusted and untrusted OpenGL applications side by side. The current release features the first version of this component along with several examples.

Besides the GPU topic, the new release comes with numerous other improvements. Most noteworthy is the ability to use Genode with the seL4 kernel on the ARM and 64-bit x86 architectures. The upgraded seL4 support also enables SMP on x86, priorities, and Genode's CPU-monitoring facilities. Following up on the big infrastructural changes of the previous releases, the current release comes with gradual refinements of the VFS infrastructure, the timing accuracy, and the package-management tools. The complete picture is presented in the official release documentation.

The lack of multilingual affordances in modern software

Before I link you to the story this item is actually about, I want to tell you about one of my biggest frustrations with computer hardware and software. It's something that I have to work around every single day, and its consequences bother me almost every few minutes.

Hardware and software have no idea how to handle people who lead multilingual lives.

Like hundreds of millions of people, I speak and understand several languages, but on top of that, I use two languages every single day: Dutch and English. I switch between these two all the time, often even multiple times a minute when juggling multiple friends, clients, work-related material, entertainment, and so on. I might be writing an e-mail to a client in English, work on a translation in Dutch, WhatsApp with a friend in English, and write a Facebook post in Dutch - switching between all of these.

Software has no idea what to do with this. The most operating systems like Windows and OS X can do is offer a small icon somewhere tucked away to manually switch input languages, which is incredibly cumbersome and just wholly impractical to perform every time you have to switch languages. It gets even worse on mobile operating systems, which are heavy on the autocorrect (I cannot type on a touchscreen), so if my input method is still set to English while I'm typing something in Dutch, it gets autocorrected into meaningless garbage (it's only recently that both Android and iOS at least offer some form of true multilingual input).

It's even worse when it comes to these voice assistants the entire technology industry is trying to ram down our throats, like Google Assistant or Apple's Siri. Do you know what you need to do to switch voice assistant input language on an Apple Watch or Android Wear device? Are you ready for it?

You need to perform a full wipe and set up the device as new.

Since my use of Dutch and English is split about 50/50 - or maybe 60/40 - the end result is that for about 50% of the time, I cannot use any of these devices to reply to an e-mail or write a text message. While Android Wear 2.0 has a keyboard and handwriting recognition, I have no idea how to change the input language for those input methods. Even if I could by tapping around - the point of these things is that you can use them without having to look away from whatever you're doing (e.g. cycling).

And just in case you think this kind of multilingual use is rare or an edge case: just in the United States alone, dozens of millions of people speak both Spanish and English every single day. This is not an edge case. This is not a peculiarity. This is daily reality for possibly hundreds of millions of people all over the world.

There's countless other daily irritations that arise from this inability of software to deal with multilingual use (Win32 vs. Metro vs. Chrome vs. Office vs. etc., which all have their own input language switching mechanisms I manually have to keep track of), but the point I want to make is the following.

Because software has no idea how to deal with multilingual use, I know for a fact that very few of the engineers working on Windows or Office or iOS or WatchOS or Android or whatever lead multilingual lives, because any person who uses multiple languages every single day would be able to spot these problems within 15 minutes of use. If the manager responsible for WatchOS led a multilingual life, or had a bunch of people on his team that led multilingual lives, WatchOS would've never been released without the ability to easily switch Siri input language.

Despite what some low-level Googler claims in his rambling manifesto of idiocy, diversity matters. Or, as ex-Googler Yonatan Zunger puts it way more eloquently:

Engineering is not the art of building devices; it's the art of fixing problems. Devices are a means, not an end. Fixing problems means first of all understanding them - and since the whole purpose of the things we do is to fix problems in the outside world, problems involving people, that means that understanding people, and the ways in which they will interact with your system, is fundamental to every step of building a system.

If, at this point in time, you still don't understand the importance of diversity when developing products, you are beyond help, and have no place on any product development team.

How old are operating systems?

Today, it hit me that iOS is already ten years old. I consider iOS a relatively new and fresh operating system, but can we really say that at ten years old? In order to figure that out, I quickly threw together a little graph to visualise the age of both current and deprecated operating systems to get a better look at the age of operating systems.

It counts operating system age in terms of years from initial public release (excluding beta or preview releases) to the last release (in case of deprecated operating systems) or until today (in case of operating systems still in active development). I've included mainly popular, successful, consumer-oriented operating systems, leaving out more server or embedded oriented operating systems (such as UNIX and QNX), which tend to have vastly different needs and development cycles.

As far as the nomenclature goes, Windows 9x includes everything from Windows 1.0 to Windows ME, and Mac OS covers System 1 through Mac OS 9.2.2. Windows CE is currently called Windows Embedded Compact, but its line also includes Windows Phone 7, Windows Mobile, and Windows PocketPC.

Red indicates the operating system is no longer being developed, whereas green means it's still under active development. The only question mark in this regard is Windows CE; its latest release is Embedded Compact 2013 in 2013, and while I think it's still in development, I'm not entirely sure.

This graph isn't a scientifically accurate, well-researched, quotable piece of information - it takes many shortcuts and brushes several questions aside for brevity's sake. For instance, looking at the last official release doesn't always make sense, such as with Windows Service Packs or Mac OS X point releases, and I haven't even been entirely consistent with these anyway.

On top of that, the graph doesn't take months or weeks into account, and just counts everything in terms of years. Linux shouldn't technically be included at all (since it's just a kernel), and you can conceivably argue that, for instance, Mac OS X is older than its initial release in the form of 10.0 since it's so heavily based on NEXTSTEP. Amiga OS is also a bit of a stretch, since its development pace is slow and has even died down completely on several occasions. You could maybe possibly argue that BeOS is still in active development in the form of Haiku, but I consider Haiku a reimplementation, and not a continuation.

In any event, I originally wasn't planning on doing anything with this, but I figured I might as well publish it here since it's an interesting overview.

The Multics CPU simulator

The Multics CPU simulator created by Harry Reed and Charles Anthony is available for public download. A complete QuickStart installation package is available that provides software, compilers, system source, install scripts, and several initial projects (SysDaemon, SysAdmin, Daemon, etc.) and users.

This is Multics, the complete multi-user operating system, running on a simulated Honeywell DPS8M processor. The simulator is available for Mac OS X, Linux, or Windows, both 32bit and 64bit versions, and also supports the Raspberry Pi.

Atari ST multitasking OS Geneva/NeoDesk to be open sourced

Back before MiNT became officially supported by Atari Corp, there were a few attempts at adding multitasking on the Atari ST. One of them was Geneva, a multitasking environment that was very light on resources and worked on a standard ST. NeoDesk is a desktop replacement that works well with Geneva.

Quite a long time ago there were some questions posed to the writer of these great software packages, Dan Wilga, in an attempt to see if the source could be opened. After a successful petition caught the attention of Wilga, he explained he still had his Atari TT030 sitting around, with the source code for a version that was never released.

Sadly, one of the hard drives with some of the required code to build everything was damaged, and it was too expensive to have the drive fixed. Thanks to a member of the Atari community, the drive has been fixed, and this should mean we're going to see open source releases of Geneva and NeoDesk soon. New builds are being tested, and they will be released soon - followed by the source code.

This is amazing news, and a fantastic example of software conservation. Thanks to OSNews reader Leech for pointing this story out and writing the first two paragraphs of this story so I had an idea of what was going on!

Sandboxing in Fuchsia

On Fuchsia, a newly created process has nothing. A newly created process cannot access any kernel objects, cannot allocate memory, and cannot even execute code. Of course, such a process isn't very useful, which is why we typically create processes with some initial resources and capabilities.

Most commonly, a process starts executing some code with an initial stack, some command line arguments, environment variables, a set of initial handles. One of the most important initial handles is the PA_VMAR_ROOT, which the process can use to map additional memory into its address space.

Not the most detailed description just yet, but Fuchsia seems to be getting fleshed out more and more.

Genode 17.05 introduces package management

With the new version 17.05, the Genode project moves forward to the goal of becoming more attractive and approachable to a wider audience. On the one hand, the release promises to be a sustainable basis for longer-term projects. With a modern tool chain based on GCC 6.3, Qt 5.8, VirtualBox 5.2.11, and the framework's finished API modernization, the foreseeable future will be free of disruptions for users. On the other hand, Genode introduced a new approach and tooling for package management to relieve users from low-level technicalities.

Modern operating systems are unthinkable without a package-management solution for installing and updating software. Until now, however, Genode's work flows were primarily geared towards appliance-like systems that come in the shape of system images. Even though the Genode developers managed to build a day-to-day usable OS (called "Turmvilla") for their own use on that basis, there is a natural limit of how scalable such systems can be. Even for the developers, installing and updating such a system is a burden. Instead up building and installing a new system image on each update, users universally expect to install software from ready-to-use packages, and to update and configure the system in parts instead of a whole.

The discussion of suitable package-management approaches for Genode reaches several years back. The first step in this direction were custom tools for managing and integrating 3rd-party source code with the framework. But there was no notion of pre-built and easy-to-install packages, nor even a tangible idea of what a package in the context of Genode should represent. During a long period of experimentation, the developers encountered and fell in love with the Nix package manager. This encounter was followed by porting work, mind-bending architectural discussions, and a series of prototype scenarios. However, while those prototypes were technically sophisticated and interesting playgrounds, they were also complicated. A real-world solution remained cloudy.

At one time, it became clear that the universal notions of "software packages" and the role of a package manager made things more complicated than they should be. After all, Nix is designed for Unix-like systems with its existing ecosystem of libraries, build tools, conventions, and methodologies. In contrast, Genode opens up unique opportunities for simplification thanks to its breath of scope that covers the entire software stack including the build system, tool chain, the ABI and API design, the inter-component protocols, the dynamic linker, the system configuration, and the execution runtime. By taking a step back and soul-searching for the actual problem to solve, a strikingly simple new approach emerged. It is undeniably inspired by the virtues of Nix. But it leverages Genode in ways that wouldn't be possible with a ported version of Nix. For example, it facilitates Genode's notion of library ABIs to largely decouple libraries from applications and thereby completely eliminates transitive build-time dependencies. Or as another example, by introducing sensible categories of packaged content, the need for a package description language disappeared.

Genode's release 17.05 contains the new packaging tools. Even though they are still labeled as experimental, the release comes with several examples of modest system scenarios based on them. Other prominent news are a feature-complete version of VirtualBox 5 for the NOVA microkernel, the update of Qt to version 5.8, added support for the Nim programming language, a new tool chain based on GCC 6.3 including Ada support, new tools for monitoring network traffic and CPU load, greatly enhanced flexibility of the init component, and a brand new timeout API. All these topics are covered in detail by the release documentation.

PC DOS 1.0, but not quite

Astute readers will notice that that's exactly the same message as PC DOS 1.0 (August 1981) shows, but this COMMAND.COM did not prompt for the date. That's because this disk is not from August but rather early June 1981 - newest file is timestamped June 6, 1981 - which may make it the oldest known surviving piece of software written for the IBM PC (not counting the IBM PC ROMs which are dated April 1981). It’s certainly the oldest known surviving PC operating system.

I'm starting to sound like a broken record on this topic, but it can't be said often enough: the preservation of software - whether important world-changing or not - is crucial if we want to document the history of where software came from, and where it's going to.

Samsung’s Tizen is a cracker’s dream

But the operating system is riddled with serious security vulnerabilities that make it easy for a hacker to take control of Tizen-powered devices, according to Israeli researcher Amihai Neiderman.

"It may be the worst code I've ever seen," he told Motherboard in advance of a talk about his research that he is scheduled to deliver at Kaspersky Lab's Security Analyst Summit on the island of St. Maarten on Monday. "Everything you can do wrong there, they do it. You can see that nobody with any understanding of security looked at this code or wrote it. It's like taking an undergraduate and letting him program your software."

Raise your hand if you're surprised.

Installing SymbOS on an emulated MSX2+

No fancy introduction or longwinded story about childhood memories, just a quick and relatively easy how-to regarding installing and running SymbOS on an emulated MSX2+. Since it's quite likely you're not aware of what SymbOS and the MSX are, I'll give you a short description of both.

First, the MSX is a standardised home computing platform conceived by Microsoft Japan in the early 80s. It was quite succesful in Japan, and saw decent success in (weirdly) The Netherlands and Spain, but saw little to no adoption in the United States. I didn't have an MSX myself growing up, but a friend of mine had one, and I remember playing games on it with him when I was round 7-8 years old.

SymbOS is - other than a marvellous showcase of programming expertise - a microkernel operating system with preemptive multitasking with a mouse-driven, windows-based graphical user interface. It's available for a number of Z80-based machines of the 80s - the MSX2, MSX2+, MSX TurboR, the complete Amstrad CPC 464/664/6128 range (old and new generation), and all Amstrad PCW models of the 8xxx, 9xxx, and 10 series.

Installing SymbOS on an emulated MSX2+ is actually quite easy.