Unununium Operating Engine got its 0.1 official release on Sunday. This release boots with a minimal shell and… a python interpreter! You can download a floppy image or an ISO from the official website.
Unununium gets its 0.1 official release
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Hey! *It* comes whit Python!!!!! *It*s enough for me!
I’m guessing Jacques wasn’t around when we axed the Operating Engine name for Unununium Operating System.
It should be noted that damn near all of the work for this 0.1 release was done by Phil Frost, an amazing coder. Thanks Phil!
The first plataform of Python was Amoeba. Now, one of the first languages of Unununium is Python. Both are new-style architecture OSes (or a OS and a OE). Interesting…
Hey, and here I was saying you couldn’t write an OS in Python.
BTW, Its writen in assembler…
Oh, I must have misread the FAQ.
Smart guys. They took SciTech SNAP for video drivers! That means Unununium got OpenGL 3D support for most of ATI and nVidia cards.
If Project UDI(=Uniform Device Interface) matures, I think there will be no more penalties for new OSes regarding drivers.
http://www.projectudi.org/
Interesting project.
It’s good to see somebody not creating another NIX/NUX and instead trying some new ideas.
Did I interpret their intro correctly? Are they going to make it possible for one application to see the functionality of another? I hope this is done in a loose fashion. In other words it would be great if my application wants to zip a file up and only needs to ask the OS for a reference to the preferred implementor of the “Zipper” interface. This might completely sidestep Linux-brand dependency hell and solve the issue of “lack-of-reuse” in OS components that we have today. People would be able to develop software much faster and with more extensibility for future enhancements. Think Eclipse/Firefox-styled plugin-ability at the OS level.
Smart guys. They took SciTech SNAP for video drivers! That means Unununium got OpenGL 3D support for most of ATI and nVidia cards.
Umm, nope… The SciTech SNAP lacks 3D.
http://www.scitechsoft.com/pdf/White_paper_072003_r1.pdf
Read under the ‘Switching to SciTech SNAP Pros & Cons’ page.
They should split it in 2, make something like a linux VM machine that run the OS so they can test idea. then once it’s ok, the more hardware inclined coder can implement what worked well in a true stand alone OS, then feed some real benchmark to the “desing” team and so on.
that said, if the coder team find it work well like it is, don’t change it
I wonder about the legal issues, but it’s a GREAT statement about licenses:
Everybody seems to have a different opinion on how software should be made free. There exist a plethora of licenses such as the GPL or some modification of the BSD license. Unununium takes the agnostic approach. If software is free, why must it be licensed? The idea is silly. Somewhere on this page is a link to the source code, and if you find it, we promise we won’t tell.
> Umm, nope… The SciTech SNAP lacks 3D.
> http://www.scitechsoft.com/pdf/White_paper_072003_r1.pdf
> Read under the ‘Switching to SciTech SNAP Pros & Cons’ page.
Umm, no. You were correct in July 2003, but not now.
SciTech MGL
http://www.scitechsoft.com/products/dev/mgl_home.html
SciTech MGL was announced August 2003, IIRC. Doesn’t the whitepaper you referenced mention OpenGL-based approach to do 3D acceleration? It’s done.
“why must it be licensed?”
I don’t know whether this means “public domain”, which is kind of license statement; or literal lack of license, what means standard copyright law applies, which is quite restrictive (all right reserved) in many countries…
Reminds me a little of OpenDoc, which was delivered in Mac OS 8 I believe. It was a miserable failure for Apple, although I too think it’s a good thing for someone else to try and see if it can be made workable. (BTW, I think ActiveX was born of the same idea, only the ‘components’ involved were humongous: e.g., Excel spreadsheets embedded in Word documents)
It is more efficient for the system to have a component for each task, rather than monolithic applications which re-invent each others capabilities. But from a user standpoint it is more confusing to have such a blank canvas. Applications help to define a task, and provide more focus for the user. Having no apps, and just ‘functions’ and ‘containers’ is not clearly better from a UI standpoint.
Not knocking this. Just saying that in the cases so far where it’s been attempted, it hasn’t been executed well.
– It is mostly written in Python. In the past much more was written in assembly, and although it was fun and efficient, we weren’t getting much done. I’m looking forward to putting my low level x86 knowledge in to helping with a better Python implementation.
– SNAP does have 3D support, somewhat. The API is in place, and apparently SciTech has made it work with MesaGL. I have not yet played with this, nor MGL, mostly because VMware won’t run SNAP and I have only one x86 box.
– A big part of Unununium’s design is eliminating barriers, including the boxes created by applications in traditional design. All programs (excluding compatibility programs; Unununium will be able to run POSIX stuff) run in a common arena. “running a program” is simply “calling a function”. Sharing data is as simple as passing a normal reference. This doesn’t preclude task-specific applications, but instead makes it feasible to combine programs in more ways. For example, a coding IDE could use my favorite text editor, instead of having only one built in.
– You can consider the “licensing” BSD flavored. If the lack of an explicit statement is a problem for anyone, contact me and I’ll give you written permission to do whatever it is you do.
I don’t want to sound insulting or cynical but the description of the project comes across as a lot of wishful thinking. It’s great to aim high but I’m sure a huge amount of people will just think “yeah right!”. How many projects have you seen create 25 new paradigms at once ? I just think it can be balanced a bit, rather than “everyone else has got the _whole_ thing wrong”.
While what you did say makes sense, the idea behind this project wouldn’t work well if only a few of their goals were implemented. It would be quite difficult to take a Linux or other *NIX base and give it some of the functionality of UUU. Thus, the whole concept must be executed/created at one time for all functions to work. It might be possible to make something like this by breaking up a bunch of GNU, libc, and kernel calls into independent programs depicting the functions and pass everything by reference in one huge space reserved in RAM. That might achieve a workable system. But that wouldn’t be smart. And it would still be the old style of thinking, with a lot more work.
something about this project has a glow as if its heading in a very good direction that has been abandoned.
a non-crashed boot on this system should be amazingly fast and convenient. like the old ‘amiga action replay’ that could dump ram back from the drive and execute its processes, you’re looking at lets say 512MB of ram coming off a local hard drive, so maybe a 8 second boot into fully off and running..
..but beyond that, maybe you could then do multiple undo’s/redo’s at the OS level.
we’ll see how rock solid stable the guy can make a python>assembly interpreter, that will eventually have to be smooth enough to handle streaming video/audio data chunks as effortlessly as parsing text, perhaps daisy-chained along scripts of contortion.
my hunch is that some middle level will arise out of necessity between the python and the ASM, we’ll see how far they can get without resorting.
Doesn’t sound like the creators have been around along time ie since say Apple tried other stuff.
OpenDoc, Taligent, Pink etc all went nowhere, but I don’t think Apple could really make anything work with the MacOS compatibility hung around neck. Also Smalltalk and its various children.
Nice to see people truelly frustrated with what we have. It really kinda of stinks where we are today with the HW-SW that could be possible if engineers could forget about backwards compatibility.
Today PCs boot up orders magnitude slower than comps did 20yrs ago before they do anything usefull. As a HW person I see no reason why an OS couldn’t boot from cold in a sec or so (like say a TV).
But the hugeness of HDs and the bloatware that tries to hold it all together is unfathomable not to mention why OSes can’t figure why there has to be atleast 3-10 copies of the exact same dll/exe file hiding in dark corners. Every OS file should exist just once and justify its existance. I still fondly remember how small & light (and fragile) the old MacOS 1 was, been down hill since.
Kudos to anyone that can build a OS, even a play OS that works by assembling components with out falling into mega complexity trap. But I also think the cpu chip itself also needs some major rethinking too to support massive concurency with a much more associative memory management.
I like the way they think about memory too, ie its all cache at any level.
Not sure about Python, certainly C/C++ would be more obvious but would lead them right back to nix copying. Perhaps Lisp descendant would actually make more sense.
good luck anyway
JJ
For example, a coding IDE could use my favorite text editor, instead of having only one built in.
Like kdevelop?
It offers me the choice of vim, kate, and a kdesigner based text editor. Admittedly choosing vim causes it to crash, but hey.
Once again OSNews comes through!
Glad to see something new and interesting, instead of another Unix/Linux clone. Especially exciting is the opportunity for original software with unique features.
Best of luck to the Unununium team,
Bob
Why do I keep running into stuff like this?
Today there are only two popular methods of user interaction: command-line and GUI. Command-line interfaces are often favorable to the experienced user, if only because graphical interfaces are so poorly designed.
Please. Besides the fact that the second sentence is somewhere between misleading and wrong, the implication here is clear.
We don’t know how to do it. We have no idea what’s wrong. We are convinced that all current user interfaces are broken, but since we’re going into this with an open mind, we’ll be able to make a UI better than all other UI designers have been able to make
Doesn’t anyone else find this attitude highly insulting to the thousands (maybe hundreds of thousands) of experienced UI designers out there? Especially when the solution they’ve come up with is…a Python interpreter?
The same can be said for their argument against filesystems. The imaginary-but-exciting-sounding Orthogonal Persistence has existed in numerous implementations (auto-saving, for instance) over the years. And what does UuuOS 0.1 have? Why, the exact same filesystem arrangement as most every other OS.
I really don’t mean to be a jerk here, but the attitude of that entire FAQ really bugs me.
I think the only problem with their UI thread is that it never explicitly references an aim towards real usability or usability studies. That is the largest problem with user interfaces today. Most of the UI work today that has been done has been to have a consistent design towards the desktop metaphor, not real usability work. Everything from layout of buttons to the size and shape of menus and the roundness of menubars.. all of this is basically graphical design. Actually to be even more exact it’s widget design. It has almost no relation to usability.
If any of it did the desktop and windowing metaphor would have quickly been abandoned. UUU mentions wanting to do this and I believe it is correct on these grounds. Getting rid of windows means you almost also have to get rid of applications. Getting rid of applications means you have to also almost get rid of every current program oriented development model. Getting rid of the program oriented development model means you end up having to get rid of compilers that only generate programs. Of course you don’t have to really get rid of any of the above, you can always emulate it by building yet another abstraction level on top of the current ones.
If you really want to read about usability check out work done by Jef Raskin in THE (The Humane Environment). There are also a considerable number of studies done by real usability experts at various usability labs. You can easily tell the difference between a design study (desktop interest group studies ala gnome/macos) and a usability study.
The main issue with UUU is that it isn’t modular enough. They are still trying to use existing computer paradigms to accomplish a component oriented system. A better system lies in the synchronous reactive paradigm. You can read about it some at http://pages.sbcglobal.net/louis.savain/AI/Reliability.htm and Louis’s COSA work at http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
This is a fundamental issue with the development systems in use today. They suffer from being tied down to the serial computing platform von neumann designed. There has been a great deal of work accomplished in developing computer signaling systems as of recent years, so the future looks very exciting. Especially with analog/digital hybrid processors that are extremely lightweight and parallel in operation. An exciting glimpse of the future of computing.. away from current behemoth serial CPUs.
I’ve been following UUU for a few years.. back when it was called an even sillier name (of which I don’t recall off hand). It’s still around so it should possibly have some future. It may be an ok stepping stone towards developing what I describe above. I liked the Operating Engine concept better considering that the best possible future OS is one you (easily) build for yourself. I don’t believe it is worth it to develop another OS until we have the synchronous reactive programming paradigm. I’m working on developing a network built from such a paradigm.. then comes the new world/software order
btw, how do we contact Jacques Mony? I haven’t talked to him in awhile.
You make a few good points.
Yes, it is insulting to thousands of UI designers out there that we think their UIs are broken. If you ask in #uuu which UI is the least broken, you’ll most likely get a unanimous “ion” answer. If/when Uuu becomes more graphical, it’ll most probably resemble ion a lot in its user interaction.
Currently, 0.1 uses an ext2 file system with a layout that’s much like the *nixs out there. That’s mainly so that we can get data and applications in and out of the system. Eventually it’ll be replaced with well… nothing technically.
Anyone who has been following Uuu over the years knows that the people involved tend to have very idealistic views. But really, what can you expect from a 0.1 release? The goals for the releases are clearly stated on the website, and it shows that 0.1 does not have orthogonal persistence, but that’s one of the next goals.
Yeah, it seems ion is getting more and more popular. It’s a good direction to head in for current X Window systems but it still suffers from the segregated windowing/software application concept. In THE, Jef explains an interface for general computing built around a single interface mode. Modeless computing (including removing the application concept) offers many usability improvements. Offering zooming instead of switching modes keeps your locus (single focus/attention) on your content at all times instead of your window manager, menu item, which window or workspace you’re on, or other useless added kruft. You use content modifiers by using meta key combinations instead of command modes. So you’re always working only on and within your content at all times.. no interfaces ever need to get in your way.
Maybe you already looked into it, but a good way to have something efficient without losing all the good things about python is Pyrex. It’s a subset of python that compiles to C code, which C code is ready to be compiled into a python extension. Could be nice, couldn’t it?
(http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/)
They post a great quote from Hans Reiser on top of their page, and yet they use a crappy EXT2 file system as their POC. Reiser4 has tons of possibilites in a component oriented OS like this, yet they missed the boat.
What of Boost.Python, sir?
Could have a better name. The biggest flaw i see with this project is trying to build this OS on some really bad hardware(the IBM PC compatible platform). anyone still have a floppy B: drive? So i find it hard to get too excited about this. Don’t get me wrong i really respect those that want to try and change the computing world. However until someone comes up with a new hardware design coupled with a new OS(like a 0 wait state computer) then you will have my interest and possibly my support.
There’s also the Psyco JIT, btw.
But the idea behind Pyrex is more than just “python/something_else cooperation”. It allows you to write your critical sections in python-like syntax, which Boost.Python (as far as I knows) can’t do.
Boost.Python should be a very good idea in an heterogenous programming environment, with C++ and Python code needing to communicate. But for Uuu, which seems to be much more Python orientated, a pyrex-based approach seems better to me. Anyway, I have no money in Pyrex nor in Uuu
You said “For example, a coding IDE could use my favorite text editor, instead of having only one built in.”
Which made me slightly curious. How would the IDE coder implement syntax highlighting, code folding, and other goodies, if this were the case?
I’ve been having wet dreams of a system like this ever since I read THE. Some interesting things too look into:
REST (Roy Fielding) just read his disseration (chapter 5 for you lazy people). While joelonsoftware says that you should be running screaming away if someone talks about network abstraction, I really think the path forward is to abstract the computer away from the network.
GStreamer (with my limited understanding) makes me dream about opening ms-word doc files in vim withot the need for application support. Let the os assemble the needed pieces so that the requested resource can be manipulated in the representation of your choice. “Applications” shouldn’t have save/open functionallity, and they shouldnt need a single file format parser. Serve the data pre parsed to the manipulating environment.
Virtual desktops… ION… with time I form a work habit, a worspace with easy to reach tools for the tasks I doo. Why not, instead of applications, let the tools I use be “book markable”. While I work I form a UI that is tailored for the task. Task switching… keeping everything networkable, I’ll be able to load the workarea specification to any terminal I sit at.
vFolders (evolution) I just love the concept, I want them at fs level. With the workspace approach I just outlined even the data could be tied to tasks.
Just assorted thoughts… Nice to see someone acctually implementing a new world. =)
Joseph wrote:
> A better system lies in the synchronous reactive paradigm.
> You can read about it some at […] and Louis’s COSA work
The main problem with Savain’s stuff is that it isn’t based on real research. (Well, at least not afaik.) To get a deeper insight into the synchronous and reactive paradigms you should check out some research based on proper formalism and/or real(=existing) systems. I recommend to use e.g. citeseer to find papers written by N. Halbwachs, G. Berry, D. Harel, A. Benveniste, etc.
Acording to http://www.webelements.com the official name of element 111 has been changed to Roentgenium. Unununinium was only the element’s temporary name. Now what will happen to this interesting OS?
I quite like a lot of the ideas behind COSA, although without custom hardware I think the system would crawl.
Problem is though that along with the gems from Savain also comes some fairly ‘out there’ stuff to read over your coffee break.
http://users.adelphia.net/~lilavois/Seven/bible.html
***
I think that trying to attain persistence of all RAM is not going to be very efficient. Maintaining an up to date log of all RAM on disk is going to bog the whole system down in endless IO operations.
How far do you actually take such a thing? Moving a mouse means changing at least a few variables that record the current cursor position. Does that mean that every mouse movement needs to be accompanied by a log entry?
That would be impractical IMHO. Which I guess leaves the developers picking and choosing where persistence actually takes place. The ideal would be to have everything come back just as it was after a crash or shutdown. I’m just not sure that it can be done efficiently on current hardware.
moderator(s): This isn’t offtopic, it’s about related component based systems.
re: John
A zoomable interface really can use bookmarks nicely. Black & White was/is a good example of this. I get excited about really cool concepts too. Imagine replacing our reliance on proprietary 3d hardware acceleration vendors (ati & nvidia) with interactive raytracing on top of generic parallel processors as open as the x86 instruction set. Check out http://www.cs.utah.edu/vissim/projects/raytracing/
The 38mb demo is pretty cool.
re: Marcus,
I had been researching these systems for about 3 years before I found COSA awhile back. Until I found Louis’s COSA, I didn’t have a name for the ideas I was having. His site serves as a useful intro into the technology with some of the formal terminology used. Since then I’ve read a lot about it on citeseer, a great resource, as well as google. I’ve also studied analog/digital hybrid processing, general signal processing, and a few other related subjects. All of this looks like it will be the future of computing (post-x86 era). It is true that his COSA work serves as mainly a quick intro, but I also think it has potential.
In contrast with UUU and COSA, I think focusing on the operating system is a dead end (or at least chicken and egg issue). We need a better development system before we need new operating systems. There is little way any of these new operating systems will ever catch up in driver support if they do not use a better development system than ‘edit in file, test compile/interpret/run, edit in file.., etc.’ Generating a fully customized operating system for your hardware should eventually be childs play. We hopefully won’t be using these generic application developed/targeted operating systems in the future. Instead, we’ll be using something generated for us on the fly by an intelligent development system/network. Computer automation is key here.
The above will also prevent software developed from being tied into some archaic hardware platform like the x86. Even Intel can’t get people to switch from x86 no matter how much they try. Intel is a victim of its own success. No reason to develop new operating systems that will be tied into these architectures of the past. Focus instead on a development system that will let you automate the development/generation of software for any architecture. With the most performance and “correct code” production that a computer can provide.
re: err
Precisely why I linked to his older pages
He defends his right to post stuff like that and says it doesn’t demeaner his other work.. which it shouldn’t (but nevertheless does in some peoples’ views).
He did some tests on his code as part of an AI program he wrote and reported that performance was pretty good.. only the components that are used need to be active. As we get more and more parallel hardware (look at IBM’s cell architecture) the performance of such a system will become even greater than current serial architectures and software.
btw Marcus, thanks for your COSAed work and your postscript.
Joseph wrote:
> I had been researching these systems for about 3 years
> before I found COSA awhile back. Until I found Louis’s
> COSA, I didn’t have a name for the ideas I was having.
That’s about the same story as mine. When I first read about COSA it immediately struck me that it was very alike to what had been growing in my mind for some years.
> btw Marcus, thanks for your COSAed work
The version of COSAed that I have available for public download is really a piece of sh*t. I should update my webpages, if I only could find the time for it.