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.
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. 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, 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.
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). 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". Obviously, internationalization is
of big concern.
Now, what do we do for uuu? Do we keep oskit?
---
Jacques Mony
jmony@xxxxxxxxx
ACM SIGOPS Member
|
