>[!DANGER] Abandoned! Last commit in 2010. Unununium Operating Engine was a [[BSD-3]] licensed experimental operating system written in [[3. Reference/Software/Programming Languages/C|C]]. - [Website](https://web.archive.org/web/20120219035426/http://uuu.sourceforge.net/) (archived) - [Source](https://github.com/ekscrypto/Unununium) - [SourceForge](https://sourceforge.net/projects/uuu/) - [SorceForge - Berlios](https://sourceforge.net/projects/uuu.berlios/) - Archived (`Site Backups/Unununium`) > Our mission is to explore and develop new operating system concepts; to redefine the architecture while using assembly language for most of the underlying architecture. # Notability It was just a cool idea to have an operating system that basically didn't have a kernel, but instead a series of interconnected and hot-swappable cells. The early development of the OS in a lot of ways predicted how projects would be look in later years. Comparing Unununium's landing page to [[Redox OS]] for example, there are clear parallels. The developer's focus on website graphic design attracted a lot of attention for the time. They had a task tracker, project status, and even merch and donation buttons all on their website in 2005. I used their wallpaper on my computers for a long time. ![[uuulogo-inverted-1280x1024.png]] Other than being of interest to me when I was young, I like the goals of the project - as varied as they were over time - and the open discussions of ideas are always interesting. # History Named after the systematic element name for element 111, first theorized in 1979, which at the time of the project's genesis had still not been given an official name. As a placeholder, element 111 was known as `eka-gold` or "unununium". Element 111 was first synthesized in 1994 and was finally given its official name "roentgenium" in 2004. > We have been through many servers and revision control systems. Overall the project's development has been chaotic, with multiple restarts, re-envisionings, and changes to different version control systems. This is not particularly strange for a project for that era, things were changing fast, and tooling for the new millennium's requirements was poor. Given the intense revisionism and constant wiping of the website, it is difficult to piece together what it ever did and when. > As this was a research project done by a bunch of teens, most of them without formal programming background, you can imagine the code is messy, many of the modules are buggy, style differ greatly between programmers and even by the same programmers over time. ## Timeline - 1999 - Project started - 2001 - First registered on SourceForge - 2003 - Last disk image uploaded to SourceForge - 2004 - Switched from GNU Arch VCS to DARCS - 2005 - Unununium connected to an IRC server online - 2006 - Minor updates on the website > Very little code was written in 2005. 2006 so far does not look better. What code has been written isn't very useful. - 2007 - Website wiped and replaced with a static admission of inactivity and the [[#March 2007]] observations instead > Unununium development has been inactive for a long time now. It would be foolish to say development will continue since history indicates working for real money always wins over hobby projects such as this. - 2009 - Website on SourceForge was wiped again - 2011 - Created GitHub repo to house new design docs - 2011 - ekscrypto announced that future versions would be released under the [[MIT License]] instead, but no further versions were released - 2020? - ekscrypto destroyed all of the 2011 docs in GitHub, in favor of hosting a copy of the original source at the same URL, unfortunately he did not properly convert the repo, so all commit history was lost in the GitHub edition - luckily it still exists in CVS on SourceForge ## Developers - [[Dave Poirier]] (`ekscrypto`) - Original creator, owner of the repos - [[Richard Fillion]] (`raptor-32`) - Listed as co-owner of the SourceForge project, website maintainer and documentation - Phil Frost (`indigo`) - Fernando Fernandes Neto (`alphakiller`) - Niklas Klügel (`lodsb`) - [[César Yáñez Fernández]] (`Hokum`) - Michael Römer (`miro`) - IRC moderator - ?? (`doobie-do`) ## Build Process The 2005 published code is laid out strangely, with a lot of Stackless Python in the DARCS repo, but some of those directories missing from the release tarball. # Philosophy * Single Address Space * Dynamic Relocation * Live Upgrade (no reboot required) * Open Design * Approachable Internal Hacking * Well documented and teachable ## March 2007 ### Observations - Food, housing, transportation, and utilities are expensive. OS development isn't very profitable. It is, however, fun. - A new OS can not be successful without maintaining some compatibility with existing software. Reimplementing enough software to get a system worth using is too much work. History is full of interesting and innovative operating systems developed largely in academia which have grown stale because they lack utility. - A new OS can not be successful without introducing new features that provide a compelling reason to switch from existing systems. History is full of unremarkable operating systems that have grown stale because they provide little or no advantage over popular systems. - Compatibility and innovation are to a significant degree mutually exclusive. A successful system will offer enough compatibility to allow a significant amount of existing software to be ported with ease, while providing a path to incrementally migrate to something better. - Programming languages need more attention. Four gigabytes of RAM and a dual-core CPU are not very useful if a programmer can not write an efficient and useful program in a reasonable amount of time. Lower level languages like C burden the programmer too much with mundane details. Higher level interpreted languages like Python have extremely poor runtime performance. A high-level language with an intelligent, efficient runtime should burden both the computer resources and programmer less. - Closed source systems suck. ### Directions - An efficient runtime for high level languages at the core can provide programmers with a good interface to the computer, and also provide isolation between components without the overhead of context switching for system calls and between processes as usual in popular OSs today. - While the above runtime can safely execute in a single, fully privileged address space (not unlike "kernel space" in linux), isolated and restricted address spaces are still required to run most existing software without compromising isolation. This is a concession to compatibility. - Furthermore, at least C-level compatibility should be provided by implementing a POSIX-like interface, again for the sake of compatibility. Ultimately, popular software like Apache, Nethack, Vim, Bash, and such should be portable with minimal modifications. - Orthogonal persistence will be implemented in such a way that all software, including that using the legacy interfaces, will be persisted. - Initial goals should be kept to a minimum. Specifically, implementing a new GUI will wait. ## 2019 - No internal security protection - One flat memory space shared by all processes/apps/* - No "Kernel" per say, only an agglomeration of "cells" or modules together forming the basis of the system -- In our lingo we referred to this as a "VoID Kernel" since there wasn't any big or small monolithic kernel controlling everything. > Our intent back in the day was to build a system which could reload any part of itself, so if you wanted to reload a newer version of the file system drivers you could do so without rebooting. This was proven as possible but never really implemented officially in any of the modules. # Features > Most generations were able to allocate memory (in some capacity or another), read keyboard input keys, display stuff on the screen. Somewhere in there you will also find some minimal 3D library, a Ext2FS implementation, some 3Com network card driver, a SoundBlaster 16 sound card driver, a minimal shell, some games, etc. - Database file system `udbfs` - Cutom time format `Uuutime` ## UDBFS The database filesystem for Unununium. In the `toolchain` archive, there exists a `mkudbfs` program for formatting drives using this filesystem. ## UUU Time Unununium uses a new format to store time. Internally, Unix systems store time as the number of seconds since midnight Jan 1, 1970. Other systems do something similar. This will be quite a problem if in 2038 the same 32 bit signed representation is used, because there won't be enough bits to hold the time. (the problem is no less for Windows, which expires two years sooner) Thus, Unununium uses the number of microseconds since midnight, Jan 1, 2000 TAI. TAI means "Temps Atomic International", or in English, "International Atomic Time". It differs from UTC (what you would hear on the radio, for example) in that UTC introduces a notion of leap seconds to keep it less than one second in error of Earth's rotational time. At Uuu's epoch, TAI was ahead of UTC by 32 seconds. For a more thorough explanation of the issue, see the [US Navy time service](https://web.archive.org/web/20070127070108/http://tycho.usno.navy.mil/leapsec.html). The time since the epoch is stored as a signed 64 bit integer. This gives us enough time to represent just shy of 300 millennia with microsecond resloution. Because it's signed, it also extends in the past just as far. Hopefully, by the time we run out of time, we will have some new ideas on how to store it. # Platform Support - [[AMD64]] # References - 2007 [website](https://web.archive.org/web/20070219110715/http://unununium.org/introduction) archive (from before the site was wiped in March) - 2009 [website](https://web.archive.org/web/20120204122701/http://unununium.org) archive (from 2012) - 2013 Github [page](https://web.archive.org/web/20131210175317/https://github.com/ekscrypto/Unununium) archive (from before it was wiped) - Current [website](https://uuu.sourceforge.net/) live on SourceForge ## Naming - https://web.archive.org/web/20070204143546/http://www.chem.qmul.ac.uk/iupac/AtWt/element.html - https://web.archive.org/web/20061208154234/http://www.iupac.org/reports/provisional/abstract04/corish_311004.html