On Thu, 2005-03-10 at 11:40 -0500, Jacques Mony wrote:
> Hi UUUsers,
>
> Since 0.1, Unununium got some progress. It now supports networking and
> is almost usable (I just couldn't unmount safely my partitions, so my
> work is not persistent at all).
>
> It lacks persistence and its new UI. But we have bigger problems,
> especially on the stability side. OSKit doesn't seem to be a very good
> friend. So we do investigate new avenues. Here are some:
>
> - Building uuu over a microkernel (L4 for one)
> - Building uuu over Linux kernel (not over a Linux distribution, make
> sure to understand the difference)
> - Get OSKit out of there and start from scratch with few device drivers.
Could be nice if UUU was a microkernel OS. Just a general idea..
And yes, you should start the device drivers from scratch.
>
> On the Linux front, I found LPSM (http://freshmeat.net/projects/lpsm/),
> which allows to implement memory persistence. It's old, in early alpha
> stages and abandoned as I can understand. But it could be interesting to
> test it. Maybe I'm wrong, but if we can build our core with LPSM as the
> python interpreter memory management library, we could turn it very
> quickly into a persistent memory environment. We could then take the
> development of LPSM as part of our efforts (it's LGPL anyways).
>
> Now, the UI. I must admit I haven't read _all_ posts about the UI, but
> what I tend to see is that you guys argue on whether we should go
> console based (and therefore keyboard-based) _OR_ GUI-based with
> windows, buttons, little dancing animals and crazy popups.
>
> Neither of them are good. We must think from the starting point:
> information management. A computer is nothing without information. The
> goal is to find a way to store and retrieve information... as well as
> manage/update it as conveniently as possible.
>
> Keyboard is nice for someone fast-typing. Not everybody is
> fast-typing... and it doesn't mean they shouldn't use a computer.
> Handicaped people, for example, might have trouble with typing on a
> keyboard: but they can still be very intelligent and have a lot of
> information management to do. We cannot say "keyboard is faster, we
> stick to it". Sure, I don't want to type a text with a mouse, but what
> will a computer be like in 20 years? A touch-screen wall-sized display?
> I don't know. And you guys don't, either, afaik.
>
> We must leave the door well opened for future developments. Now, the
> question to answer really is: "What is the most convenient way to
> management information?"
>
> I have no complete answer yet, but I would like to bring your attention
> to something: all well-known webbrowsers now support file://
> "protocol", which allows them to browser harddisk. My favorite
> browser, konqueror, even does auto-completion of what I am typing in the
> address bar. With short directory names, it gets faster to type the file
> name with its full path in the address bar than to go get it with mouse
> clicks. However, what annoys me, is that I need to click on that bar, or
> type "tab" a couple of times to get there.
>
> Another thing that annoys me, is window overlapping. I always lack
> space. However, I know this wouldn't be the case with very large
> displays (I used to set my video resolution to 1600x1200). I hate
> overlapping, but fixed size windows (like ION), annoys me even more... I
> have no freedom. But the solution I found is this KDE roll-over feature:
> I minimize to a bar and all I need is to place the mouse over the bar
> for the window to temporary appear.
We need something like the F9 on Mac (or is it some other F?) that gives
you a nice display of all the windows open and you can click on the one
you want. I use it sometimes when I work with Photoshop (and I hope it's
gonna run on UUU some time in the future). Quite a handy tool.
> Cut-and-paste becomes really
> efficient and I still have workspace to play with.
>
> That brings me to the "cut-and-paste" paradigm. Is that needed? We've
> been discussing icons, but what about this cut-and-paste? What, exactly,
> do we move around? Data, instances, objects? What's with file
> hierarchy? Do we really need so many levels of classification? Look at
> *nix: /bin, /sbin, /usr/bin, etc. Why not "Applications" and rights
> associated to them. (Same thing with Windows and its executables in both
> \Widnows and sub \Program Files directories). In fact, we want to
> abolish applications,
you will probably accomplish that by changing the definition of the word
application. There will still be 'executables' and 'Programs'. I think
you've got high-hopes about this one.
> so this would fix this problem. But files have a
> similar problem. People keep storing archives everywhere, files
> everywhere (think about the stupid idea of having \me\Desktop, \me,
> \me\My Documents...). Then they lost their documents because they
> forget where they are, they spend time finding them and finally... they
> lose efficiency.
This is also a memory problem. Their memory. Not just the spaghetti with
file-systems.
> With a document being able to contain content _and_ sub-documents, we
> could fix the problem. Accessing/Using these documents still to be
> defined. What's funny is that I have been thinking about that a long
> while ago (even before uuu): A document would be a framework (an empty
> window if you want), where you can place other objects (taken from an
> object library: picture, text, sound, video).
Nice idea. I like it. But wouldn't that be kind of heavy on the memory?
> You could then edit each
> of them within the document, or expand and edit their own parts. While
> this concept was really mouse-oriented, nothing stops us from using a
> command-line that would replace this "START" button. This would be
> possible to type things like "expand my little dog 2004 picture" or
> "move picture 2 left by 2 pixels".
Keep in mind that ambiguity problems might come up by using this
"syntax." Although, it will be an advantage on the future
speech-oriented operating systems. Like the computer in Star-Trek.
Although it does have a graphical interface, that is mainly used for
things such as writing down stuff and overriding the system. Wait, why
am I talking about Star Trek suddenly?...
> Obviously, internationalization is
> of big concern.
Sure is. I'm willing to work on internationalization, in fact. I can
offer you .. errm .. Hebrew.
>
> Now, what do we do for uuu? Do we keep oskit?
Throw OSkit away.
>
> ---
> Jacques Mony
> jmony@xxxxxxxxx
> ACM SIGOPS Member
>
> _______________________________________________
> Uuu-devel mailing list
> Uuu-devel@xxxxxxxxxxxxx
> http://unununium.org/cgi-bin/mailman/listinfo/uuu-devel
|
