This is a project whose homepage has been hacked with the SourceForge backdoor by a 1337 hacker! It is extremely lucky because this message is the only change I did ;) After I found this backdoor, I, being nice, added this message to some SourceForge-hosted sites to warn them, instead of maliciously dropping their tables. Whom does this exploit affect?

No Comments

Going with MIT license

Going onward, future versions of Unununium will be distributed under the MIT license. Thank you!

No Comments

New Unununium Logo

I played around a bit with Blender trying to come up with yet another logo which would scale well and would be easy to expand upon. The previous 3 “tubes” where alright but didn’t look really good in black and white. Hopefully this one looks a bit better: New Logo

No Comments

GitHub repo

I created a new github repository for the new build of Unununium; its fairly sparse right now, although you should see the specs slowly coming to shape.

Check it out at https://github.com/ekscrypto/Unununium

No Comments

Unununium – Existence distro updated

Jmony just updated CVS with dragon (the keyboard driver) cell ported from Dimension to Existence! Thank you!

, , , ,

1 Comment

A review of original design goals

It has been quite a while without an update and I would like to apologize for that. Beside selling my house, buying a new one, coordinating two job transfers (one for myself and one for my wife) life has been a bit hectic. I must admit to have *cough* discovered */cough* Fable 2 and Oblivion..

Anyhow, re-reading my last few posts I may have misguided the direction of Unununium so in order to appease myself and ensure I broadcast the right information, here’s a summary of Unununium’s goals:

* Single Address Space
* Dynamic Relocation
* Live Upgrade (no reboot required)
* Open Design
* Approachable Internal Hacking
* Well documented and teachable

Basically, a simple system with the internals clearly visible and inspectable by the user. A system built around a fast and simple design allowing deep state inspection and debugging; providing sufficient information for the users/developpers to customize the system to their liking.

I’m still planning on using the multiple return path function calls; after all this is one good way of speeding things up a bit while better managing various output states.

The dynamic relocation and the live upgrades are without timing guarantees; in fact, the entire system should probably not be real-time based; at best soft real-time. Let’s be honest, I do not have the team nor the inclination to go through official certification and make this into a commercial endeavour.


No Comments

Synchronous Languages

Posted a quick brainstorming page about synchronous languages which may be the seed to the final design.  Would solve and put together a few concepts I have been toying with these past few years.

No Comments

Multi-core, distributed applications, asynchronous services

Wanted to share a few of my latest reads and studies.  First is the programming language “Axum” by Microsoft; a good read.  It talks about channels which are used to communicate to services using ports with the ability to define states and transitions, define protocols.  A quick google search should turn you into an “Axumite”, be careful!

Also came across Reactors, where there are no functions, channels, methods or services.  Only data, states and relations.  Services are provided by requesting a state change.  An interesting read indeed.

How will this all tie in with Unununium? no idea!  But if you put together multicore, OpenCL, CUDA, and all the multiprocessing going on nowadays, you can start formulating an idea.  Have fun!

No Comments

Security, Execution Privilege Levels, and the Past

It is surprising how sometime a simple decision can take so much thinking, how it can affect so much the overall design, and how hard it is to settle down on a final choice then say “that’s it”.

The overall role of an operating system is to provide the tools required for a software to execute, in order to simplify the life of a programmer in developping the tools and applications required to perform a specific task.  With that in mind, then comes the ability to run multiple simultaneous applications, protection and safeguards between these applications, how these applications will co-exist and have to share access to the same resources.

Looking back at the origin of Unununium, it all started back when V2_OS was identified as seriously lacking proper design and most of its developers agreed to go for a rewrite.  The only problem, these developers couldn’t agree on implementation specific ideas and the whole thing pretty much stagnated for some time.  Myself and a few folks went on to create our own “4th Axis” way of doing things.

4th Axis, as with V2_OS, was aimed to have as little barrier between the software application and the hardware, providing as little as possible abstraction so the entire system would run as fast as possible.  This contrast with common operating systems like Linux, Windows and MAC OS X where applications are severely limited in how they must access the hardware, that they will be pre-empted, they can’t access the memory of another process, etc.  Not that these things are bad, they are helping ensure stability in a world where virus writers are king of the hill.

With the introduction of Unununium, 4th Axis lost its kernel; at least in concept.  Some ideas were introduced like the ability to reload any component in the system no matter how critical it is; so that a reboot would in theory never be required and no component would have to permanently stay in memory.

So now I’m left deciding where this system is headed, whether I implement paging, multiple execution privilege levels, prevent applications from accessing other processes memory or simply allow the whole thing to simply run with as little hinderance as possible.

As there are many other choices all fighting to make the fastest and most stable secure operating system, and I’m not planning on having Unununium run on all machines on Earth and take over the world, the original ideas of V2_OS, which is the root of all this, should be maintained.

Unununium should be a set of tools and libraries to the software, not a security watchdog.  In this essence, Unununium should allow a software application to shut down task switching, or to inspect the entire system memory.  Similarly, it should also allow a software to perform I/O operations as desired.  After all, what the world need is a good “introduction” operating system which can be used to learn how computer works so that they can then step-up to more complex and security intensive systems.

Unununium should come with a set of tools to do multi-tasking, to debug a software, to trace memory accesses. It should come with libraries to access the network, setup the video card, graphic libraries, etc.  Out of all that, it should also allow an application to overtake any of these facets, to replace these components or disable them and even unload them from memory if required.  The idea, is for the operating system to be there to help and complement the software.

With this in mind, now I can concentrate on planning how this will all come together..

No Comments

Memory Management

Finally decided on how memory will be managed. In short, processes will be able to request memory pages of 4KiB to be allocated.  The memory pages, as well as the processes, are tied in to a given cpu/core so as to avoid false cache sharing between threads.  Some sub-routines will also be available to sub-allocate these memory pages into any allocation size; although the operating system will only keep track of the pages and not the sub-allocations.

The allocated memory pages can then be shared with other processes for fast and efficient data transfer; when doing so the process sharing the memory page will receive a secret code that can be used to cancel the sharing and regain full control.  When shared, memory pages are in read-only mode for all users including the original process which shared the page.

No Comments