headers
Florian Büther | 9 Nov 2006 08:39
Favicon
Gravatar

Design proposal, Uuu-backend the functional way

Hello everybody,

its me again (o:

I'd like to present a little proposal on how i would like to design the
backend-system for some functional Uuu.

As a connection to everything that should be build on top i would like
to have a interpreter-command-line, just as like it is now present at
Uuu-0.1, except for it beeing a sml-command line.

For support of different parts of the machine, like a interface to the
graphics (for whatever kind of gui would be presented), for sound in-
and output and all the other stuff, i would like to introduce different
functions, that supply the programmer with an abstract view of the
respective part of the machine.
Statefulness may present a problem here, although i guess that this can
be solved via mutable storage (which is like variables in conventional
imperative programming), so if you change the mutable storage of the
display, some pixels change in color.

As for the the orthogonal persistence, i thought of placing the
hard-drive in the state of the ram; making every variable a kind of
"file". So, to access data, you just use the variables that are
available in your scope. This allows for creating every type of
storagable stuff, as you can emulate even the well known directories,
files and alike via datatypes. So on this level we are able to store
information (and by storing the current point of evaluation we also
support persistence between reboots) without enforcing some kind of
format for our data. Just put it in the datatypes you like.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Frost | 8 Nov 2006 16:53

Re: Moving Away From WIMP Interfaces One Step at a Time

On Fri, Nov 03, 2006 at 12:00:49PM -0800, cold wolf wrote:
> We caught a lot of flak about international keyboards that had different
> layouts, so a lot of people couldn't use Archy effectively. This is one of
> the reasons why I'm going to support customization, even though most of my
> colleagues disagree. Good thing it's open source. (i've started learning
> Python, but it'll be a while before I can contribute anything useful.
> Still...)
>
> The command problem is surprisingly less of one than I thought. But again,
> context detection is the savior here. There's only one "copy" command for
> text/pictures/[any other object], one "upper case" command, one "spellcheck"
> command and so on. And if you do have to type more than 3 characters (it's
> really not that bad as I've discovered in my years of using Archy) there is
> a function that detects how often you use a command with a similar name. So
> if you use "copy out" more than "copy", Archy will know and adjust
> autocomplete so that "copy out" will be the first one to be suggested,
> therefore eliminating any extra time wasted specifying the command. There
> are ways to alter the command names so that you still remember what they are
> while retaining their meaning (and to rename one you simply leap to the
> command center and change it right then and there and the effect will be
> immediate).
> 
> It helps immensely to have autocomplete immediately appear. You are always
> looking where you are typing (even if this is not true, the command
> quasimode is noticeable enough that you don't have to look directly at it),
> so you know immediately which command you are about to run. If any conflict
> arises, you will see it and adjust accordingly. Plus, as I mentioned, that
> other command won't show up if you've already trained the autocomplete.
> 
> I don't recall anything about programming commands like that, but it's an
(Continue reading)

Permalink | Reply | 7 comments |
headers
Florian Büther | 4 Nov 2006 10:56
Favicon
Gravatar

Re: Filesystem layout

Marius Amado-Alves wrote:
> Now you are on the right path, challenging the old ways. But it seems
> the problem with these discussions is always the same: you say "file"
> like it was a given, perfectly defined, concept. Do you mean a Unix
> file? In that case, the Unix system is appropiate IMO, no need for a
> new OS. Do you mean something else? In that case you have to define
> it. It may be similar to a Unix file, but it must be defined. For
> example, can it be a soft link? Is it a sequence of bytes? Bits?
> 64-bit strings? Does it have a name? Date of creation? Modification?
> Last access? Etc.
> 
> Personally I tend to think that the basic unit of data should be the
> bitstring, unamed; and more complex items untyped, directed, subgraphs
> thereof; and yet more complex items typed graphs. (Untyped, typed
> graph mean the *edges* are untyped, typed.)
> 

Probably you can build the basic concepts for the frontend of Uuu on top
of the low-level-design; As i propagated, i would like to use some
functional language. These typically use some basic datatypes like
Integers, Strings, and allow for easy implementation of structures like
lists, trees, graphs and alike. Maybe you could build something out of this?

bueda
Permalink | Reply | 0 comments |
headers
cold wolf | 4 Nov 2006 00:22
Picon

Re: Filesystem layout

Right, I basically have no idea how to talk about an os without a filesystem. When I say file, I'm talking about objects, but I haven't a clue how the details work. I was kinda hoping I could learn more about orthogonal persistence by lurking. So I'm going to hold my tongue until I know more.
Cheers,
-Corey

On 11/3/06, Marius Amado-Alves <maa <at> liacc.up.pt> wrote:
Now you are on the right path, challenging the old ways. But it seems
the problem with these discussions is always the same: you say "file"
like it was a given, perfectly defined, concept. Do you mean a Unix
file? In that case, the Unix system is appropiate IMO, no need for a
new OS. Do you mean something else? In that case you have to define
it. It may be similar to a Unix file, but it must be defined. For
example, can it be a soft link? Is it a sequence of bytes? Bits?
64-bit strings? Does it have a name? Date of creation? Modification?
Last access? Etc.

Personally I tend to think that the basic unit of data should be the
bitstring, unamed; and more complex items untyped, directed, subgraphs
thereof; and yet more complex items typed graphs. (Untyped, typed
graph mean the *edges* are untyped, typed.)

_______________________________________________
Uuu-devel mailing list
Uuu-devel <at> unununium.org
http://unununium.org/cgi-bin/mailman/listinfo/uuu-devel
Permalink | Reply | 0 comments |
headers
Omar Campos | 3 Nov 2006 14:04
Picon
Favicon

My take on UUU

Hello everyone,

  First I want to say that this my first time posting on this list, even though I have been on it for nearly three
years.  I just want to share my opinion about UUU with the rest.

  I was quite excited when I first found out about UUU.  The concept of Orthogonal Persistence and a system made
entirely in Python, it was fascinating.  Here's a things I want to share my opinion about, things I've seen
mentioned here at least once in my time on this list:

1. Orthogonal Persistence: it is indeed a truly revolutionary concept, if it can actually be implemented. 
Now, I am not an expert in OS programming, but having the OS always retain the memory state would require
constant writing to disk (if that's where the memory state will be saved to), which could slow things down
or damage the hard drive in case of an unexpected shutdown.  OK, then we write the memory state only when a new
program is opened or closed.  But, is this any different from the "Save session" option already provided by
OS's, including X/KDE for Linux.  I haven't used Gnome much, but I am certain that it has a similar option.  My
point is, it wouldn't be "real" persistence.  Not much different from the Hibernate option in Windows.  But
then again, I am not an expert on this topic.

2. Programs as Python functions:  it was said once that all programs on UUU will run as Python functions.  I
don't know if this plan has changed or not, but I think this was a bad idea then and is a bad idea now.  Looking at
a far future (a very far future, it seems), when UUU is ready for production use, everyone will be forced to
write their UUU programs using an interpreted language, meaning that most, if not all, programs will need
to be open source.  While it is good for the free world, it pretty much eliminates the chance of creating
commercial, propietary software.  Also, there is the issue of compatibility.  Switching to a new OS, most
people look to have the same functionality of their previous OS.  Will Firefox run on UUU, or will it need to
be rewritten as a Python function?  Will OpenOffice.org run on it?  Or will I need a Python version of OO?  Who
will want to rewrite all this software?  Who will bother?  This is, of course, assuming that UUU is a serious
project, that actually intends to bring the OS to the masses, to rival the likes of Linux and Windows.  But
perhaps, I am not understanding the goals of this project correctly.

3. The breaking of the "desktop metaphor": Once it was discussed that UUU would not use the traditional
"icons" and "desktop" used in practically all other OSes. So what will be used?  Hopefully it will not be a
command line interface.  That would be a step backward.  The idea of an OS is to make communication between
user and computer simpler.  And CLIs have been basically abandoned because it is not as easy for the less
computer literate to understand.  So it would have to be a graphical interface.  But my mind is really unable
to grasp anything different than icons to represent programs, or programs running on windows on my
screen.  What will UUU use if not windows and icons?  And will this theoretical, revolutionary interface
concept be compatible with all existing types of software, like browsers and word processors?  Will my
OpenOffice now run on some kind of 3D sphere rather than a window?  Please excuse me if I sound sarcastic.

  Now, I haven't been really following this project for over a year so I don't know if any of this has changed. 
But I had hope that this project would move forward, and it hasn't.  I even thought of contributing once, but
it seems this community has no time to train "beginners".  They only accept "experts".  I was told once that
if I wanted to contribute, I would have to download the source, interpret it myself, and make something,
some new feature, by myself.  I think maybe this attitude has kept some people away from this project.  But
then again, I haven't contributed on open source projects before, and perhaps all projects look for
people they don't have to train.  But it seems to me that most people contribute in open source to learn
something new, if only to have something nice to put on their resumé.  Most "experts" probably have steady
jobs and have no real need to contribute with open source projects, unless they are really passionate,
which I doubt.

  Finally I want to apologize in advance to the people on this list who will probably feel offended by this
message.  I want you all to excuse my sometimes sarcastic tone.  I do not mean to "flame" anyone as they say. 
But it's been nearly a year since there has been any progress on this project.  I realize how difficult it is,
in this time and age, to dedicate time to projects like this one.  While planning an OS is very important,
perhaps some progress would be nice.  I just wanted the community to know how I feel.  Still, this project is
not mine and, other than this message, I have never contributed anything to it.  This message is my good bye,
as I intend to unsubscribe from this list soon.

Thanks for listening to the ramblings of a frustrated programmer,

Omar
Permalink | Reply | 1 comment |
headers
narke | 3 Nov 2006 13:10
Picon
Favicon

Primary language for Uuu (self-corrected)


I make CORRECTIONS:

There's something which can interest some of you,
a research project called Isaac/Lisaac,( http://isaacos.loria.fr/ ).
Shortly, as I understood while browsing the site few minutes, the purpose seems
to be to implement a safe/fast/object-oriented language and and an operating
system (NO-KERNEL IF I REMEMBER), AS C WAS CREATED TO CREAT UNIX IN THE PAST.
The project seems to be pretty documented, and having implemented Lisaac, but I
don't read any of related docs since I don't liked the syntax.

Konstantin Tcholokachvili

>Hello,

>There's something which can interest some of you,
>a research project called Isaac/Lisaac,( http://isaacos.loria.fr/ ).
>Shortly, as I understood while browsing the site few minutes, the purpose seems
>to be to implement a safe/fast/object-oriented language and and an operating
>system, like C/Unix.
>The project seems to be pretty documented, and having implemented Lisaac, but I
>don't read any of related docs since I don't liked the syntax.
Permalink | Reply | 3 comments |
headers
Daniel Andersson | 2 Nov 2006 12:29

Moving Away From WIMP Interfaces One Step at a Time

some might/will find it interesting:

http://www.osnews.com/story.php?news_id=16372

/ d
Permalink | Reply | 5 comments |
headers
Florian Büther | 2 Nov 2006 09:00
Favicon
Gravatar

Compability to other OSs

Fernando Fernandes Neto wrote:
> Well, as far as I know, we never said or wrote about Windows or POSIX 
> compliance in the website.
> Unununium is about to research new Operating System Technologies and 
> Techniques in order to bring a new dynamism in the operating system. So the 
> main question is: Why having POSIX compliance ? Linux and lots of other 
> operating systems already do that. Why having Windows API Compliance ? 
> Windows it self and ReactOS, (and wine under linux) already do the job too.
> We should focus on something new, that does not follow these established 
> directions, otherwise, our research does not make sense. It would be yet 
> another operating system project.
> 
> Some days ago, I was talking to Phil and Rick about a "unununium's rebirth", 
> by trying to bring some more modularity to the Python modules coded in 
> C/Assembly, by implementing an elf-linker in the interpreter layer and with 
> that, be able to load new Operating System Components. Well, the main 
> problem is how to trust this code. I'm still thinking on a way to track and 
> be able to keep a track to avoid a system crash caused by these modules. 
> Anyway, if somebody has any suggestion on how could we keep a track of these 
> untrusted extensions in order to avoid crashes in the system, send your 
> suggestion. Take in mind that components are loaded and linked against 
> interpreter at run-time. So at least, if there's a way of tracking these 
> external loaded code, it would be nice, because we could be able to extend 
> some critical parts in faster pieces of code.
> 
> My nickname is alphakiller and idle sometimes on #uuu at irc.oftc.net.
> 
> Hope any suggestion.

Hello once more,

second topic: Interoperability with other OSs/Applications.

I am quite unshure about what your post said. At first, you explain, why
you dont want any POSIX/Win compliance; this is alright, i feel the same
way about this. You may enable the sharing of data with these systems
(after all, Uuu might need network capabilities some day) or allow for
reading and saving data from and to external devices; but i dont think
that we need to allow for using tools from these other OSs.

So why do you suggest implementing an elf-linker? well, you can take
advantage of the huge linux-community, but, after all, this is the
direct opposite of your first paragraph. Just as Phil pointed out, this
is about developing new ideas and probably even implementing them. Not
reusing existing stuff.
If you have to reuse stuff thats already out there, my best guess would
be taking the source from the components you would like to use and
migrate them to Uuu. And giving credit to the people :)

So far,
bueda
Permalink | Reply | 0 comments |
headers
Florian Büther | 2 Nov 2006 08:16
Favicon
Gravatar

Primary language for Uuu

Hello everyone,

third topic: Language.

As nobody really took care of my proposal for a different language for
Uuu, i will put it here in a seperate thread.

As already pointed out, i would like to have a different language than
Python as main language for Uuu; Mainly speaking of Haskell or SML.

Reasons include:
- These are both functional languages. Not only do these have a radical
different approach to programming (as it is the basic principle for
Uuu), but i feel, they are more easy to learn and use.
- As functional languages allow for a way higher abstraction from the
computing machine, it is easier to implement some higher level functions
in a language like this.
- As they are quite abstract, they allow for easy porting to different
architectures (if we will ever make it that far :))
- As they are quite abstract, these languages allow for easy
implementation of parallelism; and i am not talking about big
mainframes, but just about the 8-core machines of next year. I am not
aware of the fact, that windows or linux offer parallelism for their
programms for free; lets be the first!

I would be happy for replies and discussion, but at least notify me if
you agree or not.
This is indeed one of my most important points, as i am for a running
prototype like Uuu-0.1, which boots into a full
sml/haskell-command-interpreter like smlnj or Glasgow.

Thanks for your patience,
bueda
Permalink | Reply | 4 comments |
headers
Fernando Fernandes Neto | 1 Nov 2006 01:06
Picon
Favicon

Re: Basic design concepts

This is an irc transcription of some ideas that I had and explicited
on #uuu at irc.oftc.net.
This is far from complete yet, but I think it would be nice. Here we
go: (I'm alphakiller, anyway ;) )

<alphakiller> I was thinking about a stack structure to keep a track
of untrusted C/Asm code that the linker I proposed loads/links
agains the interpreter
<alphakiller> so all untrusted C code that is called, you know Who
is calling
<alphakiller> and Where we are
<alphakiller> so I think, this is the basical information to avoid a
deadlock or a system crash
<alphakiller> when a untrusted C/Asm module is loaded, it must
register and inform which resources it uses ...
<alphakiller> maybe we could implement a "protect" API
<alphakiller> so every malloc
<alphakiller> free
<alphakiller> is tracked
<alphakiller> (used by untrusted code)
<alphakiller> so a smart comparison between, for example, if a
buffer overflow occurs, and to know who caused it, you just search
within a list in this protect API
<alphakiller> I think it covers a good part at least of the problems
of loading untrusted code
<alphakiller> so you import code by a method
<alphakiller> like: extension.load("/load/hello.o")
<alphakiller> a = "Hello World!\n"
<alphakiller> extesion.call("print_msg", a)
<alphakiller> when you do this ^^ all subsequents callings from here
are going to be tracked by our "Protect API", in order to be able to
verify what could cause a system crash.
<alphakiller> but this is just information about what could cause.
Since the system is persistent, in the context restore, you can
simply avoid loading this component and whatever depends on it
<alphakiller> to keep a track of such dependencies, we can do a
stack based registering
<alphakiller> so if one component crash, all other that relies on
it, we unload
<alphakiller> like if you remove a book from a stack, the others on
top of it falls, and only the ones that are in the stack's bottom
are left in the same place
<alphakiller> so we should think on an optional way of restoring the
context where the user has options to avoid such modules loading.
<alphakiller> My best wish is to be able to load critical code that
can enhance the system performance
<alphakiller> or an application performance
<alphakiller> I do not intend, on any way, replacing python as the
main language, because that would break up the philosophy of
developing the system in a safe language, and all other stuff
related to our programming language philosophy
<alphakiller> anyway, this is not a complete idea
<alphakiller> I'm waiting for critics or suyggestions
<alphakiller> *suggestions
<alphakiller> The elf-linker is pretty ready, and can be used to be
the next uuu startup system, since it really needs a way of
exporting the core components, like the linked libc, and interpreter
functions to be able for the newer loaded components
<alphakiller> so it's just a matter of linking UUU as a Relocatable
ELF
<alphakiller> That's it :)

>>From: "Fernando Fernandes Neto" <alphakiller_ <at> msn.com>
>>To: uuu-devel <at> unununium.org
>>Subject: Re: [Uuu-devel] Basic design concepts
>>Date: Tue, 31 Oct 2006 21:30:52 -0200
>>
>>Well, as far as I know, we never said or wrote about Windows or POSIX
>>compliance in the website.
>>Unununium is about to research new Operating System Technologies and
>>Techniques in order to bring a new dynamism in the operating system. So 
>>the
>>main question is: Why having POSIX compliance ? Linux and lots of other
>>operating systems already do that. Why having Windows API Compliance ?
>>Windows it self and ReactOS, (and wine under linux) already do the job 
>>too.
>>We should focus on something new, that does not follow these established
>>directions, otherwise, our research does not make sense. It would be yet
>>another operating system project.
>>
>>Some days ago, I was talking to Phil and Rick about a "unununium's 
>>rebirth",
>>by trying to bring some more modularity to the Python modules coded in
>>C/Assembly, by implementing an elf-linker in the interpreter layer and 
>>with
>>that, be able to load new Operating System Components. Well, the main
>>problem is how to trust this code. I'm still thinking on a way to track 
>>and
>>be able to keep a track to avoid a system crash caused by these modules.
>>Anyway, if somebody has any suggestion on how could we keep a track of 
>>these
>>untrusted extensions in order to avoid crashes in the system, send your
>>suggestion. Take in mind that components are loaded and linked against
>>interpreter at run-time. So at least, if there's a way of tracking these
>>external loaded code, it would be nice, because we could be able to extend
>>some critical parts in faster pieces of code.
>>
>>My nickname is alphakiller and idle sometimes on #uuu at irc.oftc.net.
>>
>>Hope any suggestion.
>
>_________________________________________________________________
>Inscreva-se no novo Windows Live Mail beta e seja um dos primeiros a testar 
>as novidades-grátis. Saiba mais: 
>http://www.ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d
>

_________________________________________________________________
Inscreva-se no novo Windows Live Mail beta e seja um dos primeiros a testar 
as novidades-grátis. Saiba mais: 
http://www.ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d
Permalink | Reply | 0 comments |
headers
Florian Büther | 31 Oct 2006 19:50
Favicon
Gravatar

Basic design concepts

Hello everyone,

as there seems to be not that much going on about Unununium (as this
mailing list is not used big time), i thought that this might be the
fitting place for some concepts that have been going around in my head
recently.

First of all, I apologize if this is the wrong place to turn to; but as
my ideas are at least somewhat related to Uuu, i guessed this might be a
nice place.

As there is not that much of concept really written down, i thought that
i might start by writing just that; this would help me understanding
what is really going on behind everything and also clarifing my ideas.
Also this might (as i hope) get the people that are still listening to
be working on the same thing, probably :)

Okai, recently i found some post of this list [1] (via wikipedia,
interestingly ;)), which argued about changing the basic language for
Uuu. As i elaborated about Haskell the last Term and now working with
some parallel functional language at my job, i thought about using a
functional language for Uuu. The 3 most famous languages being LISP, SML
and Haskell, i would like to suggest the later two:

- SML for beeing somewhat wide-spread and well-known. Moreover one
should be able to equip Uuu with a decent virtual machine for SML, as
there is one there already.

- Haskell; as Haskell is the most functional language, if you want to
put it that way.

Why functional? On one hand, my prof is saying, that functional
languages will be used more in the future ;) On the other hand, because
functional languages allow for quite some optimisations wrt. parallelism
without changing the language. Also it would be fitting the concept of
orthogonal persistence or even "file-free storage", as they by
themselves do not speak for or against these things.

So much for that idea,
starting from the other side; i recently have been trying to think of
alternatives to the well-established concepts in computer usage; what
could be a replacement for a file/directory-based
information-storage-system, and, how would you design interaction with
other systems? Say, viewing a webpage, which refers to different
pictures, links and the site by itself all beeing seperate files?

Secondly, what could be an alternative to the known gui-systems like
windows or kde/gnome?
The input devices cant be changed (as i prefer using Uuu on regular
computers, spreading its popularity probably), so how make use of them?
Could the mouse be used for something different than a "mouse-pointer"?
Laking any alternatives, the idea of mouse-guestures came to my mind; i
dont know of any os currently featuring mouse-guestures at basic
os-level, only for special applications. Good idea? Bad idea?

So long and thanks for all the fish,
bueda

[1] http://unununium.org/pipermail/uuu-devel/2006-April/000982.html
Permalink | Reply | 11 comments |

Gmane