uuu-devel Mailing List for Unununium

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

For everyone interested, the Unununium website has been updated at  
http://unununium.org/

Enjoy

Dave Poirier
dav...@ie...

is it me or this list hasn't been used for a long time?

Jacques Mony
jm...@jm...

>From: Dave Poirier <in...@us...>
>To: uuu...@li...
>Subject: [Uuu-devel] asm, hardware drivers and why a towel is the most 
>important item a hitchhiker can have
>Date: 05 Aug 2003 13:51:44 -0500
>
>Personally I don't think I want to even get close a "desktop" operating
>system.  There are 3 main reasons for that:
>
>1.) the variety of hardware
>2.) the diversity in software expected by the users
>3.) has to be user friendly and provide support for joe-nobody
>
>That said, that leaves us with a few crowds:
>
>A.) "desktop for hacker" - which is mostly what Linux and BSD are (or
>was at some point)
>B.) "cheap embedded" - wrist watches, etc. Think Palm OS
>C.) "life critical embedded" - car computers, life support, etc. ex: QNX
>D.) "research os" - Tacos, Plan9, Sombrero, Xok, etc..
>
>I don't think we are in gear for approaching anything life critical, so
>we might as well remove (C).  Research OS sometime get to some level of
>functionality, they are rarely adopted, a bunch of papers are written
>(mostly to pass get your doctorate/* at univ) and few ppl ever hear of
>them.  Cheap embedded is and will always be a market, but like some ppl
>said already, x86 isn't in there (or barely). The desktop for hackers is
>pretty much already fulfilled, unless we plan to fight the likes of
>AtheOS.
>
>There are two things that we see as problematic and for which we already
>started moving (or running in circle):
>
>a.) being tied to x86 isn't good in the long run
>b.) asm is cool but prone to errors and too hard for a lot of ppl
>
>I'm open to other languages, but I won't go with C for various reasons,
>and the most important of them to me is the lack of proper pointer and
>array handling (lack of boundary checks). Both C and C++ aren't
>introducing any new idea that really helps the programmer.
>
>Languages that I liked until now are Ada95, Python and the obvious
>Assembly.  Languages like Crush seems to offer a few interesting (good?)
>concepts, even though the language looks a bit like a cludge in the docs
>at this point.
>
>One might also want to know what is really our goal, our target
>platform(s) and our audience before we go and even select a language.
>
>Personally I think asm can be used for any task, but then I'm probably
>biased ;)
>
>---
>
>If you plan to write drivers, at least try to develop some that are not
>already supported. We already have (old) drivers for 3C90xB,
>SoundBlaster, PS2/Serial Mouse, IDE, Floppy and a few other things.
>
>One area that doobie-do started working already but for which some work
>is still required is Scitech SNAP drivers.  This is the shortest way to
>support a few graphic cards, we need ppl that know how to write the
>driver interface.
>
>---
>
>A towel, it says, is about the most massively useful thing an
>interstellar hitchhiker can have. Partly it has great practical value.
>You can wrap it around you for warmth as you bound across the cold moons
>of Jaglan Beta; you can lie on it on the brilliant marble-sanded beaches
>of Santraginus V, inhaling the heady sea vapors; you can sleep under it
>beneath the stars which shine so redly on the desert world of Kakrafoon;
>use it to sail a miniraft down the slow heavy River Moth; wet it for use
>in hand-to-hand combat, wrap it round your head to ward off noxious
>fumes or avoid the gaze of the Ravenous Bugblatter Beast of Traal (a
>mind-bogglingly stupid animal, it assumes that if you cant see it, it
>cant see you  daft as a brush, but very very ravenous); you can wave
>your towel in emergencies as a distress signal, and of course dry
>yourself off with it if it still seems to be clean enough.
>
>More importantly, a towel has immense psychological value. For some
>reason, if a strag (strag: nonhitchhiker) discovers that a hitchhiker
>has his towel with him, he will automatically assume that he is also in
>possession of a toothbrush, washcloth, soap, tin of biscuits, flask,
>compass, map, ball of string, gnat spray, wet-weather gear, space suit
>etc., etc. Furthermore, the strag will then happily lend the hitchhiker
>any of these or a dozen other items that the hitchhiker might
>accidentally have lost.
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Uuu-devel mailing list
>Uuu...@li...
>https://lists.sourceforge.net/lists/listinfo/uuu-devel

On Fri, Feb 06, 2004 at 07:35:46AM -0800, an...@sc... wrote:
>  Do I have your
> > permission to place the attached PDF on our (and > possibly others)
> > web site for promotional purposes? > > > Andrew
> > 
> > 
> > Yes, of course, I would appreciate if you could let us know of a date
> > so maybe we could try to coordinate a release/demo for the same day
> > also.
> 
> Thanks! As for a promotion date lets shoot for Tuesday of next week 
> (2/10)  - If that work for your schedule... Would also be helpful to 
> get a bit of information on your specific target market...
> 
> 
> Andrew
> ---
> Andrew Bloo
> Director of Sales & Marketing
> SciTech Software, Inc.
> Phone: (530) 894 8400
> Mobile: (530) 520 2061
> http://www.scitechsoft.com

We are aiming mostly at embedded devices, network switches and other
similar applications.  Basically anything that requires non-interactive
upgrades, high availability and high performances.  We hope to also
eventually tap into wider markets such as display booths, picture
frames, digital clocks and such devices.

  Dave Poirier
  Unununium Project Leader
  http://unununium.org/
  +1.204.997.6253

Hi guys,

eks yesterday almost fully integrated the SNAP libraries into
existence. There are a couple of pieces still missing. Since
there's nobody in the channel to talk to right now, I'm listing
what needs to be done before I sleep:

- Some uuu timing functions need to be created for the SNAP
*CpuSpeed procedures to work correctly. uuu_getticks() won't
cut it alone.
- My local version of uuu/ has issues with calls to uuu_malloc,
uuu_exit and uuu_getcwd. eks mentioned that this was fixed in his
own version, so I'll leave those and pretend they're fixed.
- All the missing PM_ procedures need to be coded! Either that, or
we take out the agplib.o module for now to at least see this SNAP
library integrate with no agp support.

The version of libpm.a that I've committed includes the udivdi3.oS
module from libgcc.a, which gets rid of those annoying build errors
complaining about __udivdi3. It won't affect the current diskimage
build because SNAP support has not yet been linked in on CVS.

If anybody wants the unbuildable/unstable uuu-branch, please ask eks
or myself.

--
doobie-do

Nice work Dave !

I've added this document link to google index, so that it should be accessible via "The 
VOiD architecture white paper" search query.

I've set up a wiki page on berlios so that every developper would be able to enter 
more and more information on cells, etc, etc...
	http://openfacts.berlios.de/index-en.phtml?title=Unununium

I still don't know how to add a document to UUU sourceforge page (can I ?)

Also, where is the VOiD initializer in the CVS (what file, as I don't seek too much in 
the sources) ?
How this initializer know about the cells that need to be installed ? (So I could add a 
cell to the list of cell to install)

Still need a TODO list (with drivers, functions, etc, etc...)

Okay, that's enough for this mail
Sincerly, 
Cyril Russo

Nice work Dave !

I've added this document link to google index, so that it should be accessible via "The 
VOiD architecture white paper" search query.

I've set up a wiki page on berlios so that every developper would be able to enter 
more and more information on cells, etc, etc...
	http://openfacts.berlios.de/index-en.phtml?title=Unununium

I still don't know how to add a document to UUU sourceforge page (can I ?)

Also, where is the VOiD initializer in the CVS (what file, as I don't seek too much in 
the sources) ?
How this initializer know about the cells that need to be installed ? (So I could add a 
cell to the list of cell to install)

Still need a TODO list (with drivers, functions, etc, etc...)

Okay, that's enough for this mail
Sincerly, 
Cyril Russo

For those of you desiring to read a bit more about VOiD, you can find
our original documentation here:

  http://sourceforge.net/docman/display_doc.php?docid=1810&group_id=14652

Let us know if you have any question.

-eks

On Tue, Dec 09, 2003 at 08:52:44PM +0000, mount me wrote:
> i have not tasted it. I hear it for the first time.
> Could anyone tell me, how it would it be.
> Could it replace the DOS in a handheld ?
> The kind of file format used by this OS ?
> Is it easy to use ? How about developing and porting
> a dos based exe file into this OS after porting 
> into my target board ? Does it support linux 
> filesystem or has FAT support ? Is it stable ? share 
> ur xperiences !!
> 
> karthik bala guru
> sdc...@ya...

The UUU/Frustration system has ext2 support and could be ported to any
IA32 386+ system rather easily.

While the system was stable for most "desktop" use, I would not qualify
it as stable for any commercial release.  If you do want the system for
this use, let me know and I will see what I can do for you, it should be
possible to make it fit for that purpose with a minimum of work.

-eks

i have not tasted it. I hear it for the first time.
Could anyone tell me, how it would it be.
Could it replace the DOS in a handheld ?
The kind of file format used by this OS ?
Is it easy to use ? How about developing and porting
a dos based exe file into this OS after porting 
into my target board ? Does it support linux 
filesystem or has FAT support ? Is it stable ? share 
ur xperiences !!

karthik bala guru
sdc...@ya...

________________________________________________________________________
Yahoo! India Mobile: Download the latest polyphonic ringtones.
Go to http://in.mobile.yahoo.com

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  CellList.html
     Date:  9 Dec 2003, 17:45
     Size:  67089 bytes.
     Type:  Unknown

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  Cell Diagram.png
     Date:  5 Dec 2003, 19:14
     Size:  77468 bytes.
     Type:  Unknown

Hei Cyril,

Just to put in my 5 cents, please go on developers.berlios.de, make =
yourself
an account there ;). And make also an account on uuu.berlios.de/forum. =
When
you've done that, we'll give you the permission to add documentation in =
the
appropriate section.

Thanks for your engagement

Lukas Demetz
Cislesstr. 51
39047 St. Christina
Cell: 339 8732678
www.lukepower.com

PS: I'm a bit tired, yesterday I saw "Finding Nemo" at 0h00 ;P

-----Urspr=FCngliche Nachricht-----
Von: uuu...@li...
[mailto:uuu...@li...] Im Auftrag von
cyr...@fr...
Gesendet: Donnerstag, 4. Dezember 2003 18:13
An: uuu...@li...
Betreff: [Uuu-devel] I would do the doc, if some can help me

Hi,=20

Once again, I am new to UUU. But I want to enter this project correctly.
What do I find here ? A lot of knowledge, technical abilities, etc... =
but no
good=20
presentation. Once again, even with the best technical experience if =
there
is no way=20
for understanding the whole thing, this project will stop badly.

So, as I want to help, but can't find an easy way to understand the =
whole
project, I will=20
first write a documentation with diagrams (because with them, it is =
always
easyier to=20
understand).

Diagrams will be in SVG (so you will be able to read it, even with a web
browser=20
plugin) and edit it in SodiPodi under any platform that runs GTK.
(Linux or Windows)

The Documentation itself will be in HTML (because I know about it) only,
without any=20
included stylesheet so that you will be able to adapt it to your needs.

I will require some time of current developpers if they could explain to =
me
what is :

  1) Link between the cells (and hardware)
  2) Kernel relation with hardware
  3) Desired tree in DevFS
  4) Functions in kernel (and links with the cells)
  5) Memory partitionning (so that I could draw a memory map)
	=3D> need to take into account the future, with a "possible" protected
paging=20
system on a SAS, to prevent "untested" software from crashing the whole
system for=20
example
  6) A TODO list, with a developper coordinator.

I will also need a place on SF server to put my stuff in.

I hope this will be a good thing to do.
Good luck
Cyril Russo

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Uuu-devel mailing list
Uuu...@li...
https://lists.sourceforge.net/lists/listinfo/uuu-devel

Hi, 

Once again, I am new to UUU. But I want to enter this project correctly.
What do I find here ? A lot of knowledge, technical abilities, etc... but no good 
presentation. Once again, even with the best technical experience if there is no way 
for understanding the whole thing, this project will stop badly.

So, as I want to help, but can't find an easy way to understand the whole project, I will 
first write a documentation with diagrams (because with them, it is always easyier to 
understand).

Diagrams will be in SVG (so you will be able to read it, even with a web browser 
plugin) and edit it in SodiPodi under any platform that runs GTK.
(Linux or Windows)

The Documentation itself will be in HTML (because I know about it) only, without any 
included stylesheet so that you will be able to adapt it to your needs.

I will require some time of current developpers if they could explain to me what is :

  1) Link between the cells (and hardware)
  2) Kernel relation with hardware
  3) Desired tree in DevFS
  4) Functions in kernel (and links with the cells)
  5) Memory partitionning (so that I could draw a memory map)
	=> need to take into account the future, with a "possible" protected paging 
system on a SAS, to prevent "untested" software from crashing the whole system for 
example
  6) A TODO list, with a developper coordinator.

I will also need a place on SF server to put my stuff in.

I hope this will be a good thing to do.
Good luck
Cyril Russo

Here's a message from Cyril Russo about a replacement to SNAP that would
be GPL.  Note that I haven't yet checked on it, so you will have to do
your own evaluation for now.  I'll check it later tonight (if I happen
to have time)

-eks

----- Forwarded message from sta...@la... -----

From: sta...@la...
To: in...@us...
Subject: A GPL replacement for SNAP drivers, that also allow 3D Hard Accel
X-Spam-Score: 0.3 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	Report problems to https://sf.net/tracker/?func=add&group_id=1&atid=200001
	0.3 NO_REAL_NAME           From: does not include a real name

Concerning an "after" SNAP development, see the
KGI project (common 3D hardware accelerated video card drivers)

It included support for ATI and Matrox card and maybe S3 card. 
Need NVidia card however. 

It is under GPL and MIT license

Its front end in 2D is GGI, which is also under GPL license.

Kernel stuff 
http://www.kgi-project.org/

User space stuff
http://www.ggi-project.org/

I know that it doesn't seem to match what you were targetting, but might worth a 
quicktour, as this allow in the same time, hardware accelerated in 3D and 2D, and, 
moreover, is under GPL (while SciTech SNAP drivers are not, even for end-users. 
Check on SciTech site, this is what I've read yesterday. So SciTech can decide to 
stop developping, or worse stop distributing their drivers, and then all UUU will stop 
because of its "future" dependencies to SNAP). 
That is why a closed source driver system is bad.

Sorry to feel afraid about SNAP, it works, okay, but I still remember a lot of projects 
based on non-free source code, and stopped because of their intrinsic dependencies 
to the commercial stuff.

There is so much reading for a day now...
Cyril Russo

----- End forwarded message -----

Hi, 

 I'm new here, some of you already know me, as Cyril Russo. 
I have created a "spam ready" email, so if you want to email me directly, please use 
stage.nexvision at laposte.net (or cyril DOT russo AT free DOT fr)

As I have already said, I will post some code for specialized memory function for any 
kind of processor. In order to do so I've read all the Intel programmer code, AMD K6, 
K6-2, Athlon, P3 developper guide.  I have implemented the basic MemCpy, MemSet 
function for each processor. Here they are in the attached file. I really don't know 
where to put them in the UUU source tree. 

I also have the CPU detection routine, but Richard seems to have already done it.

So, my code has been tested in a project I've finished, and it works and detects the 
kind of CPU (386, 486, Pentium, K6 etc...)

I hope someone will tell me how to deal with the source tree.
Thank to all
Good luck
Cyril Russo

PS : Even if the file is .c it is a assembler file (with C function naming).

On Tue, Dec 02, 2003 at 12:17:29PM +0100, cyr...@fr... wrote:
> On 1 Dec 2003 at 16:55, in...@us... wrote:
> 
> > > Another question about ASM stuff. I've read about the simple hello 
> > > world program. You get a pointer on a function to call stdout, okay, but 
> > > what happened if I try to write on this address ? How do you succeed 
> > > in a correct memory proctection scheme ?
> > 
> > Memory protection is implemented by the compiler/language, not by the
> > system.  This avoid costly system checks on trusted applications,
> > allowing hand-optimised applications to take full advantage of SAS with
> > a minimum of overhead, while offering even better protection than
> > standard systems for untrusted applications.
> > 
> > See the BRiX operating system and the Crush language implementation for
> > more detail on language/compiler implemented security.
> 
> Waouuh. That is a big step to ... a bad point of view. I have read some doc about 
> protected mode, and, okay, you have to set up a lot of "stuff", to cluster memory, etc 
> (in fact this is done mainly just after the start of the system). However, once this is set 
> up (correctly I mean), no "expensive" tests are done. Any bad access (that would be 
> avoided with a good langage but mainly with good programmers), would simply 
> trigger an exception. Moreover, not doing this leads to no virtual memory support 
> (that could be useful in the only case of huge application). I still can't believe this kind 
> of system could be efficient, not in terms of speed (I trust you, it is clear that a direct 
> near call will perfom better than any int 0x80), but in terms of "Third party Software". I 
> mean, if your system works perfecly with all the software you made, I can screw it up 
> with just a "mov SOMEADDRESSIDONTOWN, SOMETHING". I think it's bad. 
> 
> Another point, how do you deal with "low address space", I mean, there is some 
> addresses in linear space that are reserved (for hardware purpose I mean) such as 
> the first 1MB for DMA support, some MB for Graphic card with overlay, etc ?
> 
> On the UUU website, you explain how to write an application, while this method is 
> unsafe, it must be protected in a way. 
> 
> I have an idea to do so, why don't you protect the near call table from writing. So that 
> nobody will be able to modify the kernel entries (in a first approach). However, this 
> implies setting up memory area so go back to step 1... Grrr. I can't figure it out.
> 
> Where could I find a kind of UUU kernel and memory architecture document so that I 
> would be able to make a diagram of it, and send it back to you?
> 
> Thank you for your time, again.
> Sincerly
> Cyril Russo

Your concerns are valid about the protection mechanisms, but here a few
things where the conventional systems fail short on:

- variable access boundary checking
- variable value limits
- memory corruption within an application, whether data or code
- memory protection from other kernel elements/drivers

Also, most of the system will not be developed in assembly, but in a
bytecode.  This bytecode is compiled into machine code at
runtime/install time and therefore it would be impossible for you to do
"mov SOMEADDRESSINDOWNTOWN, SOMETHING", you would rather be doing "SET
SOMEVARIABLEDOWNTOWN to SOMETHING".

While you explain properly the protected mode setup on the x86, it is
also important to understand its shortcomings (as detailed above) and
develop better ways to handle them cleanly.

If you look at Linux and other kernel developments, you will find that
most of them track down memory corruption using lengthy techniques,
often taking many hours if not weeks to find a single memory corruption.
Using a language like ours, memory corruption would be impossible to
write.

You might also be interested in looking up the Ada programming language,
which offers self built-in boundary and value limits check.

Another reason not to go with a protected memory scheme is the very high
cost of switching between the various protection levels; which are the
very reason why we can use a direct near call instead of a int 0x80.  If
you call a kernel service that requires ring 0 access, the current ring
3 software has to somehow gain privileges or carry its request thru.
This can be done in three ways:

- Interrupt
- System call to some code that will execute the switch
- Send a message to a system task

Now, all that said, it is possible to setup protected mode but
execute/run all software in ring 0, thus avoiding the need to switch
between protection level, enable paging (one of your arguments) and
still proceed with our optimisations.  Furthermore, this can be done
transparently by the system and could be implemented as configurable
option.

- eks

On Fri, 2003-11-28 at 07:15, cyr...@fr... wrote:

--snip--

> I've also been to SciTech SNAP website, but then I haven't found=20
> any "free" driver to use, they were only in a "real unlimited trial, only=
=20
> limited by license". If UUU is GPL how can you use SNAP drivers=20
> internally (which is not GPL)? The SNAP SDK is GPLed but not the=20
> drivers, am I right ?=20
> It seems that SciTech is also having a hardware OpenGL port. It=20
> might be interesting to test it. (I would try to test them soon)

--snip--

I'm sorry if there was any confusion,but Uuu is not under the GPL, it is
BSD licensed.  There's no licensing problem with SNAP, or atleast that I
know of.

Richard Fillion
ri...@rh...

On Mon, Dec 01, 2003 at 12:48:19PM +0100, cyr...@fr... wrote:
> Hi,
> 
>   In the paper I've sent you, Ion is basically the idea nb 2 (more 
> extended of course). I've tried it, it is great as long as there is not so 
> many windows (because then it's difficult to remember that your 6th 
> xterm is on the right, 3rd row, etc...)
> 
> It is okay however, because everything is beneath your eyes.
> 
> But, and this is, I think, the real drawback, Ion is not user friendly, the 
> menu is not clear, no icons to explains (images are not "langage 
> dependent", etc...).
> 
> I agree that SNAP couldn't release the source code for their drivers, 
> but if they don't release the binaries for free, how would you implement 
> them in UUU ? 
> I mean, I am not ready to pay for a graphic driver just to try UUU (as a 
> basic user would), so will you have to have a kind of agreement with 
> Scitech or what happened after the trial period ? 

Scitech have binary drivers freely available for home users.
Enterprises have a 30day trial (unless I'm mistaken).  So if you are
just a home user you should be able to try out Uuu without buying
anything.

> What is exactly UDBFS (stand for Unununium Data Base File System 
> or not) ?

UDBFS does stand for Unununium Data Base File System.  It is exactly
what you'd expect, an advanced merge of the two concepts, allowing
queries, relational data, etc.

> Another question about ASM stuff. I've read about the simple hello 
> world program. You get a pointer on a function to call stdout, okay, but 
> what happened if I try to write on this address ? How do you succeed 
> in a correct memory proctection scheme ?

Memory protection is implemented by the compiler/language, not by the
system.  This avoid costly system checks on trusted applications,
allowing hand-optimised applications to take full advantage of SAS with
a minimum of overhead, while offering even better protection than
standard systems for untrusted applications.

See the BRiX operating system and the Crush language implementation for
more detail on language/compiler implemented security.

> Is it quicklier to call a function than trigerring an interrupt ?

Yes, by a wide margin.  It takes an average 800 cycles to execute an
interrupt while taking only 10 cycles to execute a direct near call.
The interrupt system was partly (even completely) replaced in some
systems for what they now call a "Fastcall" system; which is a kindof
in-between interrupts and what we are doing.

The only fastest way than a direct near call is to inline the functions
directly in the code so as to avoid any call at all, but that would make
the system a bit big ;)

> Okay, that is all for this email, if you need some programming in any 
> domain, please ask.
> Cyril Russo 

You'd be welcome :)

-eks

Hello again Cyril,

I just finished reading your paper about GUI design, seems like the
ideas are mostly still geared toward a "desktop" interface with some
menu system.  While this system has been in use for quite many years, I
tend to disagree with its overall utility by power users.

In my view, as far as the GUI goes, a power user should be able to
perform the following actions with a minimum of effort:

- start an application with a defined location/size on screen
- quickly re-arrange windows to maximize the amount of visible information
- easily and quickly switch between multiple applications

A standard windowing system is bothersome to use for a power reasons for
exactly those reasons.  Using individually resizeable windows, if a user
has multiple applications sharing a screen, one has to resize each of
those applications individually if he desires to change the visual
ratio.

Changing between >4 applications can become cumbersome and long, see
even confusing or requiring the user to use a pointing device.  By
defining a clear screen separation, it becomes possible to define
standard ways of navigating thru the windows (up, down, left, right,
etc) as well as resizing multiple windows at a time.

The idea of a desktop is, in my opinion, conceptually bad.  Access to
the desktop information is only available when the user has:

a) no application open
b) applications that do not cover the entire screen
c) or requring the additional step of selecting the desktop by mimizing
all applications.

To get back to your last email, you are right about Scitech SNAP.  The
SDK is GPLed but for various reasons, the drivers aren't.  Most graphic
card manufacturer requires signing NDA before accessing the
specifications of a card, it is therefore unauthorized to release any
source code to the public.  In this regard, Scitech SNAP is as good as
it will get (unless those companies change their policy).

If you haven't tried Ion yet, you should.  Ion is like a fully useable
and keyboard/mouse driven interface, much more so than PicoGUI.  Mind
you the themeability of PicoGUI is pretty impressive compared to the
lame Ion themes.

The database file system is planned to eventually be implemented on top
of ReiserFS, but right now we are working with UDBFS, since we believe
we can achieve a (slightly less efficient but) working system in a
shorter time.

-eks

On Fri, Nov 28, 2003 at 02:15:39PM +0100, cyr...@fr... wrote:
Content-Description: Mail message body
> Hi,
> 
>   First of all, thank you for your answer. You did answer, it's really 
> important for me.
> Here is the document I've been talking about. It comes from my 
> personal researches, and shouldn't be diffused, as I've never asked 
> people from my bibliography if I could use what they've said or done.
> 
> You can send it to any member of the UUU projects (I've registered 
> on Wednesday)
> 
> I really encourage you to test "Spaces" software from "Spatial 
> Research" (see the bibliography), as it is really an evolution in terms 
> of desktop spaces. However, this software is not easy to use due to 
> mouse movement very unnatural.
> 
> I've been to the PicoGUI website, downloaded their soft, and compile 
> it on a linux and Windows machine. It works very well, and it is very 
> interesting. I think it could be a starting point to port it to UUU.
> 
> I've also been to SciTech SNAP website, but then I haven't found 
> any "free" driver to use, they were only in a "real unlimited trial, only 
> limited by license". If UUU is GPL how can you use SNAP drivers 
> internally (which is not GPL)? The SNAP SDK is GPLed but not the 
> drivers, am I right ? 
> It seems that SciTech is also having a hardware OpenGL port. It 
> might be interesting to test it. (I would try to test them soon)
> 
> Finally, what I like the most in your project is the DataBase file 
> system, because all "modern" OS doesn't have any. I still didn't read 
> the specification for this FS, but I'm sure you made it correctly.
> 
> I hope we might find a common point for developping, as UUU might 
> become a very interesting system. 
> 
> 
> Yours Sincerly,
> Cyril Russo
> PS: I've done some platform dependent code for MemCopying / 
> MemSetting / MemComparing. I have a specific code for Pentium 
> processor, Pentium2 Pentium3 and Pentium4, K6-2, Athlon, using 
> their specific intructions (MMX, 3DNow, SSE, SSE2, etc...). With that 
> I achieved memory copy at rate upto 450 Mo / s on my Althon 1Ghz. 
> If you are interested in it, I would share it with the community.

Hi all,

Unununium.org is now registered and parked.

--
doobie-do

Hello,

thank you for your interest in Uuu and your obvious dedication to the
project follow-up.  We are pretty close from a GUI release, we are
hoping to mock something quick (not a complete interface but at least
gfx) for early january.  It's a tight pull but we are going to try
anyway.

As for the GUI itself, don't worry, we are far from going toward a
Windows lookalike.  If you ever tried PicoGUI or Ion, that's more like
what we have in mind.  Myself and a few other Uuu developers have been
using Ion for some time and found it to be much friendlier and faster in
many daily tasks.  While PicoGUI has similar concepts, the usage of it
was entirely driven by mouse/pointer and was rather cumbersome.

For hardware acceleration, we are going with the Scitech SNAP interface.
We have been in close contact with Scitech for a few months now and we
are also hoping to coordinate the development of SNAP network and sound
drivers.

Remember that one of the key point of Uuu is that its entirely
reloadable, so driver plugin is kindof a given.  Even the realtime
scheduler and memory manager are hot swappable.

-eks

On Wed, Nov 26, 2003 at 02:37:36PM +0100, cyr...@fr... wrote:
> Hi, 
> 
>   I've read about UUU a lot, and I'm really waiting for a first GUI release.
> How far are you from a GUI release?
> Are you implementing a kind of dynamic load of drivers?
> If yes, are some accelerated graphics drivers available ?
> 
> I know that I'm nothing in this world, but since you are very close to have a useable GUI, 
> I think you are going to make decision about how will the GUI looks like, how it reacts, etc...
> 
> This is the point I might be interrested in.
> 
> I think you don't have so many time, but please, don't repeat the same error as your predecessors, and don't try to make an x-nth windows clone.
> Think different.
> 
> So if you can, go to the SkyOS GUI contest, and via the forum, read the candidates' remarks.
> I've made a kind of sum up of what should be a good user 
> experience (distinct 15 points) in order to both suit the Fittz's law, and feel a good 
> reactness of the OS. If you are interested in this summary, I could send it to you.
> 
> I've read about the new Sun system OS, with a 3D desktop. I think it's a pretty good 
> idea (in fact I've tested it, and it's really useful (try "Spaces" from Spatial Research), 
> when it's simple (not like 3DNA which is really slow and not user friendly).
> 
> The decisive point is how UUU could be different from any other OS ?
> 
> I'm ready to share my time with you (in order to help you (if you need it)) in developping UUU.
> I could implement a kind of 3D desktop with something very interesting, as I've already done it numerous time for my work.
> I've some experience in hardware programming as I am porting a linux version to run on an ARM9/10 processor.
> I've also some experience in MPEG4 player/compressor because of my job (I'm MPEG4 CE in my company)
> So if you are interested, please contact me at cyr...@fr... or reply this mail. 
> 
> Thanks by advance. (I'm french, so sorry for my bad english)
> 
> PS: Below is a summary of all OS I have contacted for my idea, I would try first to work with any of them directly if possible, or in parallel if not.
> I'm looking for a base OS (free if possible) for a totally new user experience, and I've 
> conluded that :
>     - BeOS reactness is the best ever (even if strong calculus are slower)
>     - Linux is done made for a 3D desktop (in fact it's not made for GUI)
>     - MenuetOS will not reached a usuable point as the developper don't want to 
> include hardware specific code (but reactness is good too)
>     - Syllable is interesting, I'm contacting them
>     - UUU (unununium) might be a good choice too, as they are starting from scrash
>     - OpenBEOS will not be released soon, unfortunately...
>     - SkyOS is reaching a decisive point, but it's not really free (as long as I would be 
> able to change the way the desktop act, it's okay)
>     - Windows however, modify the desktop is always a "hack" and it's not really 
> reactive due to its size I think and it's hundred ms before any window opens...
> 
> Sorry for this long email, I hope you will be able to answer me.
> Sincerly,
> Cyril Russo
> 

hello,

maybe some of you wondered what happened to the network stack being in development for uuu:
after some research, i started writing a paper about how a possible netstack especially geared towards a SAS
os could look like. the concept was pretty straightforward, it offered several enhancements over
the original bsd implementation. However, i started to talk about it with doobie-do who did some research on his own, too.
he finally told me that my design was more or less (well at least practically) similar to the STREAM network implementation
by Dennis Ritchie. on the one hand this was good news, because it proved that my concept works, on the other hand it was bad
news because i wasted a month for the concept. therefore i stopped working on the paper, which you can get at 
http://www.lodsb.org/index.php?DocName=documents&Path=1 .
in the end i came up with another more sophisticated concept that is basically an enhancment over the old one.
however, it remains unproven that this is a practical implemention of a network stack, therfore i already started working on it.
the code is written in C, and furthermore, it currently runs on linux to allow for benchmarking when the core of the stack is done.
the benchmarks will finally decide whether the stack will be ported over to uuu.
doobie-do is helping me atm, he helped me in various aspects for the paper, too.

sincerely,
nik

I'm bouncing this over to the uuu-devel mailing list, I hope you don't
mind.

Thanks for showing interest in Uuu, what's strange is that this is the
2nd email in 24 hours that I've received directly about special
interests in it.  A good strange, I assure you. eheh

How far is Uuu from a GUI release... Good question.  Our goal with
Uuu/Existence is to have it be pure graphical, and so far we've been
following that idea, even with the bootloader, it boots up in a
graphical mode (anything VGA) and gives a damn sexy boot console. =20

As for a real GUI though.. we're working on the video driver aspect of
it currently, and we're getting nearer and nearer, we only have 1 more
major thing to do (DLL linker) before they should work.  Once that's
done, then we can worry about the GUI.  Once our SNAP loader is
complete, we will have access to accelerated (2D) drivers for over 100
cards.

We have some ideas already on how we want the GUI to function.  Dave and
I (and probably others too) want it to be entirely controlable by the
keyboard.  For an example of this, you can look at the ion window
manager for X11.  A few hotkeys such as alt+tab just isn't enough.  You
need to be able to know that a certain combination of keys _will_ bring
up the application you want it to bring up, all the time.  However this
doesn't mean we're abandoning the mouse, you can still use the mouse in
ion, it just means that if you don't want to use the mouse, you don't
have to.

Unfortunately, if you're goal is to make a kickass desktop out of an
operating system, I'd think that you're looking at the wrong place at
the moment.  You'll be stuck waiting atleast another 6 months before we
get much of anything graphical up besides our bootloader.  Our
priorities are not with the desktop, they are with the inner workings of
the system.  But.. if you're looking to lend a  hand, we're always
looking for more coders, and you may be able to get us to the point you
want faster. =20

As for how Uuu could be different than other OSes.  Well that has never
really been a question for us.  The fact that it's written entirely in
hand coded assembly is a start, then there's the fact that it is a real
time OS which also sets it apart.  Having it's main filesystem being a
database will also work in our favor, and then we'll have the best video
support of any hobby OS once we have SNAP stuff going.  Oh yeah, and the
lack of kernel too, can't forget that.  We don't have problems standing
out :)

There were a few nice images for the SkyOS competition, unfortunately..
they were images, created by people who probably had very little idea
how GUIs work.  They were mostly made to look pretty, not be ultra
usable.  90% of the ones I saw were some amalgamation of Windows,
MacOS(X), and BeOS. =20

I hope this answered your questions, if not, don't hesitate to give
another shout.

Richard Fillion
ri...@rh...

On Wed, 2003-11-26 at 07:38, cyr...@fr... wrote:
> Hi,=20
>=20
>   I've read about UUU a lot, and I'm really waiting for a first GUI relea=
se.
> How far are you from a GUI release?
> Are you implementing a kind of dynamic load of drivers?
> If yes, are some accelerated graphics drivers available ?
>=20
> I know that I'm nothing in this world, but since you are very close to ha=
ve a useable GUI,=20
> I think you are going to make decision about how will the GUI looks like,=
 how it reacts, etc...
>=20
> This is the point I might be interrested in.
>=20
> I think you don't have so many time, but please, don't repeat the same er=
ror as your predecessors, and don't try to make an x-nth windows clone.
> Think different.
>=20
> So if you can, go to the SkyOS GUI contest, and via the forum, read the c=
andidates' remarks.
> I've made a kind of sum up of what should be a good user=20
> experience (distinct 15 points) in order to both suit the Fittz's law, an=
d feel a good=20
> reactness of the OS. If you are interested in this summary, I could send =
it to you.
>=20
> I've read about the new Sun system OS, with a 3D desktop. I think it's a =
pretty good=20
> idea (in fact I've tested it, and it's really useful (try "Spaces" from S=
patial Research),=20
> when it's simple (not like 3DNA which is really slow and not user friendl=
y).
>=20
> The decisive point is how UUU could be different from any other OS ?
>=20
> I'm ready to share my time with you (in order to help you (if you need it=
)) in developping UUU.
> I could implement a kind of 3D desktop with something very interesting, a=
s I've already done it numerous time for my work.
> I've some experience in hardware programming as I am porting a linux vers=
ion to run on an ARM9/10 processor.
> I've also some experience in MPEG4 player/compressor because of my job (I=
'm MPEG4 CE in my company)
> So if you are interested, please contact me at cyr...@fr... or rep=
ly this mail.=20
>=20
> Thanks by advance. (I'm french, so sorry for my bad english)
>=20
> PS: Below is a summary of all OS I have contacted for my idea, I would tr=
y first to work with any of them directly if possible, or in parallel if no=
t.
> I'm looking for a base OS (free if possible) for a totally new user exper=
ience, and I've=20
> conluded that :
>     - BeOS reactness is the best ever (even if strong calculus are slower=
)
>     - Linux is done made for a 3D desktop (in fact it's not made for GUI)
>     - MenuetOS will not reached a usuable point as the developper don't w=
ant to=20
> include hardware specific code (but reactness is good too)
>     - Syllable is interesting, I'm contacting them
>     - UUU (unununium) might be a good choice too, as they are starting fr=
om scrash
>     - OpenBEOS will not be released soon, unfortunately...
>     - SkyOS is reaching a decisive point, but it's not really free (as lo=
ng as I would be=20
> able to change the way the desktop act, it's okay)
>     - Windows however, modify the desktop is always a "hack" and it's not=
 really=20
> reactive due to its size I think and it's hundred ms before any window op=
ens...
>=20
> Sorry for this long email, I hope you will be able to answer me.
> Sincerly,
> Cyril Russo
>=20

Hey folks,

today I got the actual test-image from indigo (the one mentioned in =
#uuu's
topic) and gave it a try on my old 486 and - Tada! -  it works!!

Great job Phil! :)

Lukas Demetz
Cislesstr. 51
39047 St. Christina
Cell: 339 8732678
www.lukepower.com
=A0

WARNING: current CVS unstable until boot record update

A slight superblock format modification was required; mkudbfs and
udbfslib have been updated.

The CVS system will be non-bootable until the boot record is updated
(expected to be completed tonight).

-eks

2001	Jan	Feb	Mar (89)	Apr (156)	May (92)	Jun (84)	Jul (107)	Aug (83)	Sep (138)	Oct (263)	Nov (187)	Dec (115)
2002	Jan (332)	Feb (74)	Mar (22)	Apr (17)	May	Jun (21)	Jul (1)	Aug (34)	Sep	Oct (12)	Nov (10)	Dec (24)
2003	Jan (15)	Feb (23)	Mar (7)	Apr (5)	May (42)	Jun (2)	Jul	Aug (33)	Sep (59)	Oct (17)	Nov (6)	Dec (14)
2004	Jan (1)	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2005	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2009	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec

uuu-devel Mailing List for Unununium

uuu-devel — Developper's mailing list