Am Sonntag, 6. März 2005 16:51 schrieb uuu-devel-request@xxxxxxxxxxxxx:
> Date: Sun, 6 Mar 2005 10:51:09 -0500
> From: Phil Frost <indigo@xxxxxxxxxxx>
> Subject: Re: UNUNUNNUN (Re: [Uuu-devel] Why _UNIX_?)
> To: uuu-devel@xxxxxxxxxxxxx
> Message-ID: <20050306155109.GA10721@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Mar 06, 2005 at 01:27:31PM +0100, flaig@xxxxxxxxxxxxxxx wrote:
> > UNUNUNNUN -- "Unununium's Not Unix" :-) . If there's somebody weeping in
> > the distance, it may be Richard Stallman, poor gnipper :-)) ...
> >
> > No, in dead earnest, I was also wondering a bit why the current approach
> > has such a unixish flavour, but I guess you need some kind of scaffold
> > for development. However, I would also like to learn a bit more about the
> > real intentions of the project -- what Uuu 1.0 is eventually going to be
> > like -- than available from the web pages. Where can I find more about
> > the design ideas? (I cannot promise that I'll find the time, but the
> > thing is so appealing that I could envision getting involved...)
>
> There are some other reasons:
>
> - it takes time to think of new ways to do things, and some of the
> Â things in unununium were implemented before we thought of the new way.
>
> - many old ways of doing things are already written. Especially due to
> Â the use of OSKit, getting implementations of old solutions is very
> Â cheap, but developing a new solution is expensive.
>
> - eventually Unununium will have a POSIX emulation layer, so all these
> Â things are not entirely worthless.
>
> > ...
> > scalable, and if so, how well -- after all, Uuu is designed for high-end
> > rather than low-end machines, isn't it?
>
> Unununium will be usable on typical consumer hardware. Hopefully it will
> be elegant enough that it will run on old consumer hardware, and also
> perform well enough to serve in more high-end applications. Distributed
> computing is an issue that's always in my mind. Although I want to bring
> distributed computing to the normal person, it also brings to mind huge
> clusters running on high-end hardware.
105% agreed. We already see that the pace of processor development is slowing
down by now due to physical limitations, and distributed programming will be
the only key to build more powerful machines. This is how I came to be
interested in Erlang, BTW.
> > So far, all approaches to data storage and organisation have finally
> > resorted to the age-old file model, simply because it works well, and
> > especially to the unixish "everything's a file" approach, simply because
> > it works best -- so far. Look at the Mac, they used to have this pretty
> > nifty system with two different "forks" for data and code in each file
> > and internal coding for icons and all that stuff; where is it now in
> > OS-X? Gone. Plain monolithic files, their types determined by extenders,
> > seem to do the job best. Even the internet is file-based to such an
> > extent that web browsers and file browsers are mostly identical (look at
> > Konqueror).
>
> If I were Apple, I would have done away with the resource fork model
> because it's a redundant primitive. It's nothing more than another type
> of container, but the filesystem already has containers: directories.
Hrmpf... yes, of course, but forks -- or the "chunks" implemented by some guy
in Modula-2 for the Atari ST back in 1987, with an arbitrary number of
non-sequentially arranged parts per file -- make it mandatory to use this. I
think Raoul's suggestion for storing meta-information is quite cool. This could
be used for compression, indexing, encryption etc., all on the system level.
But the way it was, it really seems to have been redundant!
> Apple probably choose to use extensions to determine filetype simply to
> conform more with the rest of the world. The previous system was nothing
> more than two 4-letter identifiers slapped on each file. Sounds like an
> extension to me, except one that is hard to edit and not used by most of
> the world.
Hard to edit, and intended to be hard to edit. Users were not expected to
meddle with it, and Apple wanted to be in full control of all program/filetype
associations. Sounds vaguely familiar, doesn't it? :-@
> I think Apple hasn't really discarded any new ideas by ditching HFS+ in
> favor of UFS (It still uses HFS+ by default, but its features are
> deprecated). Any differences were pretty minor, so it doesn't make a
> good example for doing things differently.
Sure... just another file system...
> I don't think web browsers and file browser are identical. Indeed, HTTP
> URLs have a fileish structure, but they are different in many ways:
>
> - A node need not be a file, or a directory. http://fu/ and
> Â http://fu/bar can both have content. In a traditional FS 'fu' must be
> Â a directory, and can have no content.
Maybe I have misunderstood something, but I always thought that accessing the
"content" of http://fu/ were just a conventionalized shorthand for
http://fu/index.html ? Or is "index.html" required only because servers are
based on file systems?
I believe the similarity is deeper, because both are implementations of a
zero-dimensional space -- a typical namespace, as you said a little bit below
-- with a perfectly nested structure (Raoul's links notwithstanding). Namespace
is namespace, and there is little beyond this concept, but the perfect nesting
seems to be the problem. At least for me :-) .
> - User navigation often has little to do with the file structure. How
> Â often do you look at the URL when you are browsing?
Well, I have to confess that I navigate almost exclusively by URL, but I am
probably not a typical user in this respect...
> > Do not misunderstand me: I think there *must* indeed be something better
> > than the file system approach (and the Xerox/Smalltalk GUI) from the
> > 1960s, unless we are willing to admit that four decades of research and
> > development have yielded no substantial conceptional advances. This is
> > why you have to put up with me :-) . I just think that we have to be very
> > creative here.
> >
> > What's a file system good for, anyway? Or rather say, what is required?
> >
> > (1) There has to be some type of logical structure. Data which belong
> > together are to be grouped together, others not. This structure must
> > allow data of interest to be transferred to other computers, media or
> > whatever, without interfering with other data. This structure is twofold
> > -- internally and externally.
>
> Agreed. The problem with a filesystem is that it is another namespace
> that has nothing to do with the namespace in which a programmer works
> when writing. This results in a hard barrier between the program and the
> user that programmers must go through great trouble to bridge.
I think I am beginning to see the point: Uuu will use a unified namespace for
any kind of information, with no qualitative discriminations between the
handling of the objects contained within this namespace.
Funny enough, a few of my friends and myself have designed (mostly for the fun
of it) a functional programming language named EQUUS (the name being an acronym
for "EQUivalence of all Useful Stuff"), which is partly based on comparable
ideas. If you are interested, you will find our web pages at
http://www.incitatus.net .
> > (2) There must be privacy. Data will have to be stamped in such a way
> > that the rights of authors, authorized readers and the riffraff can be
> > distinguished clearly. In face of the contemporary situation, this may be
> > the most important point of all.
>
> ACL style permissions are not something that will happen in Unununium.
> Instead, privacy and security will be based on the assumption that if a
> program has something, it can use it. For this to be effective, there
> must not be a global shared namespace (like a filesystem). Instead,
> functions (there are only functions in Unununium; a traditional program
> is a function bound to the filesystem namespace) are given references to
> the things they need directly through parameters.
>
> To illustrate, I might play a song in linux by running
> "mpg123 music/grassgreen.mp3". I'm telling mpg123 where to find the
> thing I want to play by giving it a reference to a string. It then uses
> this string as a key to a global namespace (the filesytem), but it could
> actually use any string at all. If mpg123 were running as root this
> could be very dangerous.
Yes indeed, that's why I'm asking.
> In contrast, in Unununium I would do something more like
> "mpg123(grassgreen)". The expression "grassgreen" is not a reference to
> a string, but a reference to the thing which I want to play. There is no
> global namespace, so the mpg123 function can't access anything but
> "grassgreen".
Yeah, that's the way EQUUS does it (using Erlang/Lisp-style "atoms" as
references), though fettered to the Unix file system...
If I may quote from my own web page:
# As said before, EQUUS programs consist of functions only. The starting point
# of a program is a function whose name is identical to the program's file
# name.
#
# [ophis@naglfar]$ cat hello.q
# function hello.q[ A B C D ] -> [ A B C D ]
#
# [ophis@naglfar]$ equus hello.q Nice to see you!
# Program result = [ (A=)[Nice] (B=)[to] (C=)[see] (D=)[you!]].
(http://www.incitatus.net/tutorial.html#argumentpassing)
Of course, when reducing a program design to a single complex function, you
cannot avoid side effects. So if I want to write a letter, I call my text
processing function (which is, I remember, called whenever any piece of
software desires formatted input), and this function will create an object
which survives after the function has terminated, i.e. the program ended. (It
cannot be returned to the user as it could be returned to a calling function,
of course.)
Then I find out that I need another copy of the letter and invoke the text
processing function again, passing the reference to the former letter as an
argument. So far so good. But now Mr. Bad Guy places a trojan on my wonderful
machine which I am dumb enough to execute, with the result that my letter is
mailed out to everyone whom it does not concern. Or overwritten with
four-letter words or whatever -- using side effects too.
Could you please enlighten me about how persistence and security can be
reconciled on the "if a program has something, it can use it" basis?
> > (3) Persistence is among the goals of Uuu anyway, but backups must not be
> > forgotten. Is anyone in possession of information about the relation of
> > "fast-changing" versus "slow-changing" data? I mean to say that I have
> > some 30 GB of stuff on my hard disk, but of these 25 GB change rarely if
> > ever, leaving me with some 5 GB to be backed up monthly to DVD -- and of
> > these, less than 15 MB are worked on so heavily that I am doing daily
> > backups, using a good old 3.5" floppy disk! So basically this is an
> > extension of (1).
>
> Making backups with the model of persistence I plan to implement is an
> interesting problem.
>
> One way to do it is to make backups of the logs. This is efficient
> because it saves only state that has changed. The disadvantage is that
> it is atomic; one must make a backup of the state of the entire machine.
> It's also not portable because there is no common way to serialize an
> object between architectures.
Serialization might be standardized (using XML or whatever you like), and there
is no need for us to be compatible with extraterrestrian architectures, in
spite of Emmerich's "Independence Day" :-) . So I do not think that's a real
problem. And generally this sounds like a really smart idea, both on the "PC"
and on the server level.
> Another way is to stream the logs over a network to another machine with
> compatible hardware. This isn't as useful for personal backup, but it
> would be a killer feature for servers. Using this method one could have
> a hot spare for every machine ready to go in the case that a production
> server dies from hardware failure or power loss. Usually this takes a
> ton of work for each application, but this would be a general solution
> that would work for any application, even those running in POSIX
> emulation.
AND you could use this for keeping track of versions too, couldn't you?
> Unununium will soon remove the barrier between hard disk and ram from
> applications. Eventually, I'd like to remove the barrier between the
> local machine and remote machines as well. This will require some
> portable representation of objects. When this is implemented, the same
> serialization could be used to make portable backups of individual
> objects.
Well, in nature there *are* syncytia -- associations or clusters of cells
without separating membranes, often of enormous size, with many thousands of
nuclei cooperating --, but in general common multicellularity prevails. As a
life scientist, I am a bit prejudiced by that. As one of my bioinformatics
students once realized, growing very pale: "The power to do everything implies
the power to get everything wrong..."
(see above)
> > (4) Efficiency of storage and retrieval: Now this is where the
> > traditional approach has become a real problem -- M$ keep on talking
> > about their new "search-centric" Longhorn but so far it's just
> > vapourware, and the unices are pretty poor in this respect too, whether
> > you use Apple's Sherlock or the traditional shell tools. I remember that
> > once upon a time when I was young the WordPerfect package had a neat
> > fulltext indexing system, but it was restricted to WordPerfect documents
> > on the local hard disk.
>
> from the application's view, writing a search engine should be simply
> creating a mapping object and populating it with whatever keys it
> desires. However, the problem is serializing these structures to disk in
> a cache-friendly way. While mirroring the byte structure of ram on disk
> works well for small objects, for a very large mapping this could have
> terrible cache locality.
E.g. a database comprising the annotated human genome (size is "beyond DVD")...
That's the class where things become interesting. But if this really works,
this might be one of the knockout arguments in favour of Uuu. I am under the
impression that conventional file systems do not really excel in terms of
scalability, even less so when there's networking involved.
> I'd need to experiment more before finding an exact solution to this
> problem. However, it is definate that the way an application manipulates
> a small mapping or a big one will be the same. This is the "orthogonal"
> in "orthogonal persistence".
Equivalence of all... ;-)
> > Okay, I trust you all know that, but I wanted to make sure we are talking
> > about the same things. So how is Uuu going to meet these needs?
> >
> > The design of Star Trek computers is from a time when computing was an
> > arcane science and people knew virtually nothing about the underlying
> > technology and its restrictions. So Roddenberry and friends were free to
> > invent an ideal system. What does it look like? "Computer, all relevant
> > information about the current state of the Acerebros civilisation" -- and
> > the computer returns you a structured report distilled from all the
> > available data. Well, we have some two hundred years more to achieve such
> > perfection, but we should give it a try...
> >
> > How?
>
> Read Your Mind(tm) technology, of course!
Uagh... I thought M$ had filed a patent on that too, to be used in their new
VisualPukeBox(TM). ;-P
- Rüdiger Marcus
--
Diese E-Mail wurde mit http://www.mail-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender dieser E-Mail hatte die IP: 129.206.124.135
|
