Unununium developers list

Konstantin Tcholokachvili | 11 Oct 2006 19:13

Re: The system design

Good evening,

>
> Well, you could probably get gcc to compile for Uuu without too much
> trouble. The reason there is no compiler in Uuu is because it wouldn't
> be useful. Without a good text editor, a linker, a debugger, a web
> browser, a multitasking environment, a full set of documentation, 361
> other things, and enough stability to avoid crashing in the middle of
> writing that critical function, a compiler in Unununium would not be
> terribly useful.
>
> The latest sources run in Linux[1][2], but since you wrote a VGA screen
> driver, and rebooted, can I infer that these are not the sources you 
> are
> using?
>
  Yes, I'm trying to improve uuu-0.1, because I'm a newbie in OS 
development, so low-level things are more interesting for me.
Writting a compiler excite me much more than  making a POSIX compatible 
system.
(I know that as you already wrote low-level code you're bored about 
that).

> Also, there is also already a VGA (and SVGA, with hardware 
> acceleration)
> driver that works in Unununium called "SNAP". There are plenty of
> unresolved issues, but it works well enough to draw shapes and text.

SNAP doesn't worked for me as for some other people. May be I will 
retry.

(Continue reading)

headers

Phil Frost | 11 Oct 2006 20:12

Re: The system design

On Wed, Oct 11, 2006 at 07:13:25PM +0200, Konstantin Tcholokachvili wrote:
> > "launching scripts" is not a concept that Unununium really has. You can
> > import the module and call functions in it, though. Most python 
> > programs
> > intended to be executed as programs have a function called main() which
> > is all that is call  when the script is executed directy.
> 
> I know about main(), but as uuu's goal is / was to be modular, I 
> thought that it would be much practical to have python scripts than all 
> in one ununuium.o.
> Do you considered to avoid the build of all the code in ununuium.o ?
> How can that be done ?

Well, when you have a single, persistent address space, "running"
programs which are in "files" is not a paradigm that follows logically.
The current way of things developed because of some historical
properties of computer software, none of which Unununium has, and many
of which modern software does not have. Lack of multitasking and virtual
memory led to the need for a user to explicitly start and end programs.
Of course with the decision to use a filesystem for persistance, it made
sense to store each program in a file.

An important aspect of Unununium's design is to not use a filesystem for
persistance. Modern computers have a large enough address space to
address all the information they need, and if that space is persistent,
then there really isn't any need for files.

Through decades of monotony, we've come to think of a computer as a
thing which "runs many programs, and oh yeah, there's an OS behind them
all." The reality is that a computer runs exactly one program,

(Continue reading)