[unios] runtime example I

[Anders Petersson]

Pieter Dumon wrote:
>I was rather surprised when I read the "run time example #1". Some comments.

I'll address Pieter's comments before giving my own.

>The example is actually rather an exaple of an OS that is not generic,
>and not transparant. 
>
>The article was pretty amusing, up to the point when Bob discovers the
>Fat32(1) partition. This is just an example of how whe shouldn't do
>this. The file system (or whatever storage system UniOS uses) should
>be completely transparent. The user mustn't be confronted with cryptic
>names like Fat32(1) and more important, it doesn't mather,certainly to
>a home user, what file system resides on the disk, which disk it is or
>whatever. This does not mean he can't ask the system what type of file
>system it uses on a certain partition, but the system mustn't confront
>the user with it automatically.

I agree. Disks are mounted, but the user will most probably want that
invisible.

If there is such a structure as an array (which would be quite useful, so
probably there will be), arrays would be "real" - the items are really
enumerated but otherwise unnamed elements under the array object itself.
So, there would be in this case one object "HDD", containing the actual
devices ("HDD (1)", etc). Arrays should not be done by simply appending an
index to the name. This is for the sake of consistency. With everything
looking the same way (and that's a manageable way too), everything can be
acted on in the same way.
But the user don't want to see it this way anyway, partitions are mounted
somewhere else.

>If you make UniOS really transparent, the second example in the
>document is also not very 'clean': the user shouldn't be confronted
>with the fact that the image is BMP or TIFF or whatever, but if the
>user would like, to he/she _can_ get the information, convert image
>formats to each other etc...

That's right, the example is gravely misleading. Neither converting or
format restrictions should be used. This is where OO comes in play. Our
friend Bob would be presented with a dialog box showing all available
objects with an appropriate 'image interface'. He could choose any object
aspiring to be an image. Or maybe even an animation.
The image interface would in some way be a subset of the animation
interface. How? There's several possible ways... one is to register a
system-wide translation filter, knowing how to represent an image as an
animation. Requests for an animation interface would yield the image
interface with the translation filter in front of it. No, this isn't
completely satisfactory, but it's a beginning.

>The shutdown thing is, on the other hand, a good example: 
>an OS called UniOS Home PC needs to be able to be shut down easily
>by a normal user. Let's not forget this is not the fact for lots of
>computers. The computer on which I'm sitting right now typing this is
>our local Linux web/proxy/mail server. You cannot let such a system be
>shut down by a normal user. Only a privileged (on Unix 'root') user
>must be able to do that. But, indeed, for home users, shutting down
>their computer must be possible whithout trouble.

You can't keep the user from pushing the power button or simply pulling the
plug, of course... but software shutdown should be completely protectable.
That shouldn't be a problem to achieve.

OK, my own comments will be a little jumpy here. I'll use ">>" for text
cited from the doc.

Wouldn't it be feasible to choose type of system at installation -
selections like 'home single-user', 'home multi-user', 'workstation',
'server', etc?
In addition you could choose system layout; win9x look (fool-proof),
advanced (advanced options enabled), wizard (complete control), and so on...

> When the system completes loading, the system informs him that UniOS only 
> installed enough to start the system, and that it must not determine what 
                                                         ^^^ ehrm
> hardware he has, and install drivers for this.

"UniOS System" - I'd prefer "Local system", since that more correctly says
what it is. Or "Local root" or something (the link would lead to the root
of the current user, I guess). That could be different for different
distributions, however.

Instead of the 'System Desktop' item, have something like 'User interface
configuration' or 'Windowing subsystem'.
Maybe the 'Configure system' item should be abandoned altogether and have
its items moved to 'Application', or 'Running subsystems'.
But then again, he wanted a win9x UI, so why not.

The main reason you should switch to UniOS would *not* be its respond time
- I don't think there's much room for improvements relative existing
systems - especially not when regarding UniOS will make use of slightly
more costly ways, traded for flexibility and consistence.

>> NOTE 2: You may be asking yourself where the object orientedness of the OS
>> comes into play.  It is throughout the system, but it's mostly behind the 
>> scenes. For examples there is no desktop wallpaper. The background is
actually 
>> an application that always resides at Z(0) on the desktop. This is the
same 
>> for the virtual "Start" bar, another object bound to Z(1).  However these 
>> elements are seamlessly integrated into the system design.

1) I can't agree that the OO aspects are hidden. They should truly affect
the way you work - to the better.
2) Explain what you mean by 'Z(0)' and 'Z(1)'. Whatever it is, I don't like
the idea with things hardwired to specific locations. What if you want
several UI's?
3) I'm unsure if seamless integration into the system design is a good
thing. The system design should rather be independent of anything like
this, but have the ability to adopt new 'subsystems' at will. Seamlessly.

>> "despite the strange ways the mouse and keyboard works" - UniGUI would be 
>> totally configurable, like X. 

Enlighten me on this, is X really _totally_ configurable?

>> " system prompts him with a box saying that the application was removed 
>> entirely" - This is another example of the object paradigm. All
applications 
>> are stored as a tree structure, with their Icon (in GUI mode) as the top
of 
>> the tree. Once the Icon is deleted, so goes the program.

I'd say that applications are contained in packages of common format. The
top object (the container) would support an 'application' interface,
exporting things as icon, ways to launch the application and so on. If you
delete such a package - well, then you really delete the application,
period. You don't act on the icon, you act on the package itself.
Note: The term "package" is a loan from Alan Grimes, but I consider the
usage as my own.

binEng

PS.
I think the new way XOOM advertises on pages is very bad. If UniOS grows
more serious, it's my opinion we should get our own domain and server.
How's the site mirrors doing, BTW?