From peter.minten at wanadoo.nl Sat May 1 08:56:48 2004 From: peter.minten at wanadoo.nl (Peter Minten) Date: Sat, 01 May 2004 10:56:48 +0200 Subject: [movitz-devel] Object sharing between processes Message-ID: <40936650.2050708@wanadoo.nl> Hi people, I was wondering about how Lisp objects can be safely shared in a hypothetical Movitz LispOS[1]. The problem is the following shell script: (bar (foo)) Say foo and bar are both programs, not functions. Foo gives something as output which becomes bar's input. Now I see two problems with a each-process-an-address-space system: * When foo is done it's address-space gets released, killing the output objects. * Even foo's address-space is still available bar can't get to the output objects of foo because they aren't in it's address space. In a single address-space system this problem would of course not occur, because when foo ends the objects it has created are still referenced and thus don't get GC'ed, and bar can always access the objects if it has a reference. So far it seems that a single address-space solution is best. But security springs to mind as a major problem. In principle this can be solved by making sure that no process can address an object using low level tricks, so that the only way to reference objects is by holding a reference. I see however a problem: heavy linking objects. If an object contains many many references and it get's passed to another process then it would allow a great deal of access to the objects of the source process. I don't know how likely this situation is, but it could cause major security leaks. Greetings, Peter Footnotes: [1] Which should really get a name so that we don't constantly have to say 'hypothetical LispOS'. What about MILOS (Movitz Illuminating Lisp OS) or ALOS (All-Lisp OS)? From jdz at dir.lv Sat May 1 20:56:36 2004 From: jdz at dir.lv (Janis Dzerins) Date: Sat, 01 May 2004 23:56:36 +0300 Subject: [movitz-devel] Object sharing between processes In-Reply-To: <40936650.2050708@wanadoo.nl> References: <40936650.2050708@wanadoo.nl> Message-ID: <40940F04.7020708@dir.lv> Peter Minten wrote: > > I was wondering about how Lisp objects can be safely shared in a > hypothetical Movitz LispOS[1]. The problem is the following shell > script: > > (bar (foo)) > > Say foo and bar are both programs, not functions. Foo gives something > as output which becomes bar's input. Now I see two problems with a > each-process-an-address-space system: I don't quite understand what you mean by "are both programs, not functions"! What is a program in LispOS? And "shell scripts"!? I think other questions may get answered or disappear when we deal with this one... -- Janis Dzerins Common Lisp -- you get more than what you see. From peter.minten at wanadoo.nl Sun May 2 07:46:59 2004 From: peter.minten at wanadoo.nl (Peter Minten) Date: Sun, 02 May 2004 09:46:59 +0200 Subject: [movitz-devel] Object sharing between processes In-Reply-To: <40940F04.7020708@dir.lv> References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> Message-ID: <4094A773.5070400@wanadoo.nl> Janis Dzerins wrote: > Peter Minten wrote: > > > > I was wondering about how Lisp objects can be safely shared in a > > hypothetical Movitz LispOS[1]. The problem is the following shell > > script: > > > > (bar (foo)) > > > > Say foo and bar are both programs, not functions. Foo gives something > > as output which becomes bar's input. Now I see two problems with a > > each-process-an-address-space system: > > I don't quite understand what you mean by "are both programs, not > functions"! What is a program in LispOS? And "shell scripts"!? I think > other questions may get answered or disappear when we deal with this > one... Hmm, good point. I think one can define a program as a function that runs in another process. On the other hand one could also think of stored functions running in the current process instead of separate programs. I think shell scripting in MILOS (to give the thing a name for now) consists mainly of loading stored functions (in fast-load files) into the current process and using them, but sometimes you'll want to run a function in a different thread. Traditionally this is solved by heavyweight threads (processes) and lightweight threads (threads), but given enough flexibility in the threading system of Movitz I can imagine the difference fading. If the treading system is able to create threads that have only limited access to the global and special state of their creators, it's possible to pretty securely use stored functions without having to fear the mess up the spawning program. This would effectively mean you'd get processes, but more powerful since they can share some global state with their parent thread. On a related note I think that shell scripting in MILOS will not be different from writing a program. For example this is how a simple script could look like: (uselib "text") ;if not loaded load and use (format t "~&Word count of file /data/foo = ~A.~%" (wc $/data/foo)) (write *standard-output* ($/bin/ls $/data)) Here you can see two ways of using stored functions. In the wc form the function comes from the text lib which is explicitely loaded at the start of the script. In the ls form the ls function is stored on disk, but since it's used in a function context it's automatically loaded and used. The wc form is more efficient if used often (loaded once, instead of ls which can be loaded every time it's used), but the ls form allows better quick-and-dirty scripting. The $... is a reader macro that expands into (file ...) to make it easy to work with files in a script. Greetings, Peter From peter.minten at wanadoo.nl Sun May 2 11:53:01 2004 From: peter.minten at wanadoo.nl (Peter Minten) Date: Sun, 02 May 2004 13:53:01 +0200 Subject: [movitz-devel] On filesystems Message-ID: <4094E11D.5090203@wanadoo.nl> Hi people, I did some thinking about the best way to use filesystems in a hypothetical LispOS (I'll call it MILOS for now). It seems to me that the old fashioned one-root virtual fs model is still the most practical, despite the kludges it causes, because people are used to it and it's a relatively easy to use model. There is room for improvement however. First of all we should stop thinking about the virtual fs as the ultimate representation of the filesystem for all purposes. While it may be good for many purposes, some things require a different _view_. Such a view could be provided by an application, or by some system thingy. Here's an example of views. Say each user has a directory web in his/her homedir. These directories need to be mapped under the wwwroot of the webserver. This can be done in two ways: symlinking and instructing the webserver to create virtual directories. In the latter case the webserver creates a view by mapping wwwroot directories onto virtual fs directories. It should be clear that the latter is a better solution than the former. But now the admin wants to create a wwwroot with subdirs 'students', 'teachers' and 'managers'. This requires filtering on groups which the webserver can't. To solve the problem the admin creates a view by writing some simple code, loads it and sets the wwwroot of the webserver to the root of that view. A little syntactic intermezzo. A normal pathname is written as $/foo/bar (/foo/bar in unix terms). A pathname in a view is written as $[viewname]/foo/bar. Views are nice, but there is more. In the virtual fs that I envision all files are objects, at the very least subclasses of stream. The class of a file is virtually unrestricted, as long as it's a subclass of stream and file and/or directory. Operations on file in the virtual fs are implemented as generic functions. Thus it's easy to set up translators like in the HURD. Files also have associated plists or hashtables (the actual implemention doesn't matter) which can be used to store properties. So one can store whether a file is configuration, who created it, when it was last backuped, etc. The getters and setters of properties are also generic functions so that one can set the configuration attribute and at the same time add it to the configuration view. Finally the virtual fs will allow custom options for the actual filesystem. Take for example a CVS FS in which the movitz code is stored. Now say I want to look at an older version of my code. What I would type is something like: '(view $/cvs/movitz/losp/tmp/harddisk.lisp[rev=1.1])'. The [rev=1.1] is a parameter that's passed to the CVS fs. Parameters can also be used with views (first the view checks if they mean something, then the actual fs) to get something like a versioned package system. Say you want to load the 1.1 version of movitz: '(load $[pkg]/movitz[version=1.1]/load.lisp)'. Ok, that's all for now. Greetings, Peter From peter.minten at wanadoo.nl Sun May 2 12:11:50 2004 From: peter.minten at wanadoo.nl (Peter Minten) Date: Sun, 02 May 2004 14:11:50 +0200 Subject: HD driver working (was: Re: [movitz-devel] Re: Possible macroexpansion bug) In-Reply-To: <2hoepdi5i1.fsf@vserver.cs.uit.no> References: <408E97A1.9070101@wanadoo.nl> <2hoepdi5i1.fsf@vserver.cs.uit.no> Message-ID: <4094E586.8050403@wanadoo.nl> Frode Vatvedt Fjeld wrote: > However, I'd suggest using an approach like the one I've adopted in > x86-pc/dp8390.lisp for such register accessors. However, this needs > some fixing because it assumes 8-bit registers exclusively right > now. I'll look into it shortly. Well, the simple macro solution works best for me and it's IMHO easier to understand so I'll stick to it for now. Anyway the reason I write this mail is to announce the first working version of the hd driver (at 'http://www.il.fontys.nl/~silvernerd/harddisk.lisp'). Currently read-sectors and write-sectors are implemented. I've used the following code in los0.lisp for testing: (defun hdc-reset-test () (muerte.x86-pc.harddisk:hdc-reset 0)) (defun read-test (&optional (s 1)) (muerte.x86-pc.harddisk:hdc-reset 0) (muerte.x86-pc.harddisk:hd-read-sectors 0 s 1)) (defun read-multi-test (&optional (s 1)) (muerte.x86-pc.harddisk:hdc-reset 0) (muerte.x86-pc.harddisk:hd-read-sectors 0 s 2)) (defun write-test (&optional (s 1)) (muerte.x86-pc.harddisk:hdc-reset 0) (let ((data (make-array 512 :initial-element #xAB))) (dotimes (x 256) (setf (aref data (* x 2)) #xCD)) (muerte.x86-pc.harddisk:hd-write-sectors 0 s data))) (defun write-multi-test (&optional (s 1)) (muerte.x86-pc.harddisk:hdc-reset 0) (let ((data (make-array 1024 :initial-element #xAB))) (dotimes (x 512) (setf (aref data (* x 2)) #xCD)) (muerte.x86-pc.harddisk:hd-write-sectors 0 s data))) Note that hdc-reset has to be invoked at least once (at boot) and takes a harddisk controller number. The numbering scheme for harddisks is simple: 0 primary master 1 primary slave 2 secondary master 3 secondary slave ... The harddisk controller number is: 0 primary controller 1 secondary controller ... aka (mod hd-number 2). Hd-read-sectors takes three arguments: hd-number, first sector location in LBA format and number of sectors to be read. It returns a vector with size (* 512 number-of-sectors) and elements of (unsigned-byte 8). Hd-write-sectors take three arguments: hd-number, first sector location in LBA format and the data (a vector with size (* 512 number-of-sectors)). It returns nothing. Note that for now only disks 0 and 1 work, though adding more disks is just a matter of adding a few make-instances to *hd-controllers*. Greetings, Peter From jdz at dir.lv Wed May 5 14:31:18 2004 From: jdz at dir.lv (Janis Dzerins) Date: Wed, 05 May 2004 17:31:18 +0300 Subject: [movitz-devel] Object sharing between processes In-Reply-To: <4094A773.5070400@wanadoo.nl> References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> <4094A773.5070400@wanadoo.nl> Message-ID: <4098FAB6.7080007@dir.lv> Peter Minten wrote: > Janis Dzerins wrote: > >> Peter Minten wrote: >> > >> > I was wondering about how Lisp objects can be safely shared in a >> > hypothetical Movitz LispOS[1]. The problem is the following shell >> > script: >> > >> > (bar (foo)) >> > >> > Say foo and bar are both programs, not functions. Foo gives >> > something as output which becomes bar's input. Now I see two >> > problems with a each-process-an-address-space system: >> >> I don't quite understand what you mean by "are both programs, not >> functions"! What is a program in LispOS? And "shell scripts"!? I >> think other questions may get answered or disappear when we deal with >> this one... > > > Hmm, good point. I think one can define a program as a function that > runs in another process. How does that make a function a program? What you want (I guess) is to bring a lot of concepts of conceptual OSes to Movitz (LispOS). What "we" are after, on the other hand, is the *Lisp* OS. We don't want programs each having different understanging of what arguments are and how they are specified -- we have functions with their calling mechanism. We want "Lisp down to the metal", with all the benefits it brings us. I suggest reading some materials on existing Lisp OSes (use google, or this link for a start: ). An aside: most things you want to discuss here are not Movitz related -- Movitz is meant as a substrate for the things you discuss. But since there's no list for Muerte and Movitz is in its very early days, we can discuss our dreams here. The "we" I refer to above is the group of people I associate myself with who appreciate Lisp and the benefits it brings as an OS implementation language, and things we now can see in some particular museums (like this one: ). > On the other hand one could also think of stored functions running in > the current process instead of separate programs. I also suggest you use existing terminology where possible. I have no idea what a "stored function" is and I'm quite sure we don't need that term at all. > I think shell scripting in MILOS (to give the thing a name for now) > consists mainly of loading stored functions (in fast-load files) into > the current process and using them, but sometimes you'll want to run a > function in a different thread. Traditionally this is solved by > heavyweight threads (processes) and lightweight threads (threads), but > given enough flexibility in the threading system of Movitz I can > imagine the difference fading. Exactly. We are talking LispOS here: ;; function invocation (some-function foo bar) ;; function invocation in another process (process-run-function "Foo process" #'some-function foo bar) The shell is your REPL. There's no such thing as "shell programming" (or, it is your plain old ordinary programming in the REPL). > If the treading system is able to create threads that have only > limited access to the global and special state of their creators, it's > possible to pretty securely use stored functions without having to > fear the mess up the spawning program. There's no point in fearing your own programs, is it? Processes (let's call them processes, as that's how they are called in current Lisp OSes) can access *anything* only through the means provided: arguments passed to the process's function, globals (special) variables, and maybe some other means and/or low-level implementation things. > This would effectively mean you'd get processes, but more powerful > since they can share some global state with their parent thread. How is what you have described more powerful than processes in current Lisp implementations? I may be missing something, but overall I have a sense that you don't quite know what you are talking about... > On a related note I think that shell scripting in MILOS will not be > different from writing a program. For example this is how a simple > script could look like: > > (uselib "text") ;if not loaded load and use > (format t "~&Word count of file /data/foo = ~A.~%" (wc $/data/foo)) > (write *standard-output* ($/bin/ls $/data)) How about: (require 'text-utils) (format t "...whatever: ~A..." (wc #p"/data/foo")) (do-whatever (ls #"/data")) ? > Here you can see two ways of using stored functions. In the wc form > the function comes from the text lib which is explicitely loaded at > the start of the script. In the ls form the ls function is stored on > disk, but since it's used in a function context it's automatically > loaded and used. The wc form is more efficient if used often (loaded > once, instead of ls which can be loaded every time it's used), but the > ls form allows better quick-and-dirty scripting. The $... is a reader > macro that expands into (file ...) to make it easy to work with files > in a script. Leave "scrpiting" (i.e., whatever that is) to script-kiddies. Programmers do programming. Actually, I don't quite want to discuss your just-invented reader macros and functions because it looks like you want to invent too many wheels at once. I don't want to discourage you from doing anything, or discussing your ideas. It's just that I'll be very hesitant to participate in them if it goes on like this. -- Janis Dzerins Common Lisp -- you get more than what you see. From mikel at evins.net Wed May 5 14:59:39 2004 From: mikel at evins.net (mikel evins) Date: Wed, 5 May 2004 07:59:39 -0700 Subject: [movitz-devel] Object sharing between processes In-Reply-To: <4098FAB6.7080007@dir.lv> References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> <4094A773.5070400@wanadoo.nl> <4098FAB6.7080007@dir.lv> Message-ID: On May 5, 2004, at 7:31 AM, Janis Dzerins wrote: [snip] > What you want (I guess) is to bring a lot of concepts of conceptual > OSes > to Movitz (LispOS). What "we" are after, on the other hand, is the > *Lisp* OS. We don't want programs each having different understanging > of what arguments are and how they are specified -- we have functions > with their calling mechanism. We want "Lisp down to the metal", with > all the benefits it brings us. I suggest reading some materials on > existing Lisp OSes (use google, or this link for a start: http://www.its.caltech.edu/~weel/lispm.shtml >). Note, though, that there are some handy features of non-LISP operating systems that we would probably like to have (certainly, that I would like to have). One of them that I would certainly like to have is some sort of support for security; Symbolics and other LispM systems were quite insecure, by design. Anyone could frob anything in any process anywhere at any time, which was certainly very handy when developing software, but it's not so great when you want to have a system that lives on the net or otherwise shares resources with users and processes that may not necessarily be trustworthy. From james at unlambda.com Thu May 6 04:33:55 2004 From: james at unlambda.com (James A. Crippen) Date: Thu, 06 May 2004 04:33:55 -0000 Subject: [movitz-devel] Object sharing between processes In-Reply-To: References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> <4094A773.5070400@wanadoo.nl> <4098FAB6.7080007@dir.lv> Message-ID: mikel evins writes: > Note, though, that there are some handy features of non-LISP operating > systems that we would probably like to have (certainly, that I would > like to have). Definitely. There's been a lot of innovation in the past fifteen years. Things like 3D support, user interfaces, filesystems, networking, and the like. All should be designed from a modern perspective, not just as a slavish recreation of the old LispM designs. > One of them that I would certainly like to have is some sort of > support for security; Symbolics and other LispM systems were quite > insecure, by design. Anyone could frob anything in any process > anywhere at any time, which was certainly very handy when developing > software, but it's not so great when you want to have a system that > lives on the net or otherwise shares resources with users and > processes that may not necessarily be trustworthy. Hear hear! It should be possible, of course, for random processes to poke at each other, but only if the user really wants it to be this way. Normally they shouldn't be able to. Interprocess communication in Unix and similar systems is awful. It's awful because the processes have no 'insecure' way of poking at each other without the crock that is shared memory, or the ugliness of pipes, et sim. If processes are allowed to poke at each other without restriction, or at least easily through well defined interfaces, then the person doing IPC gets a big win. However, it's still necessary nowadays for processes to be somewhat protected from each other. Thus I envision some sort of ACL like thing that could be part of a plist in each stack group and accessible globally. A lot of attention needs to be paid to how threading systems are implemented in existing Lisps. Also some good examination needs to be written on multiprocessing on Lispms so that people who don't happen to own one can learn how it works. 'james -- James A. Crippen Lambda Unlimited 61.2204N, 149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From mikel at evins.net Thu May 6 05:33:22 2004 From: mikel at evins.net (mikel evins) Date: Wed, 5 May 2004 22:33:22 -0700 Subject: [movitz-devel] Object sharing between processes In-Reply-To: References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> <4094A773.5070400@wanadoo.nl> <4098FAB6.7080007@dir.lv> Message-ID: On May 5, 2004, at 9:33 PM, James A. Crippen wrote: > mikel evins writes: > >> Note, though, that there are some handy features of non-LISP operating >> systems that we would probably like to have (certainly, that I would >> like to have). > > Definitely. There's been a lot of innovation in the past fifteen > years. Things like 3D support, user interfaces, filesystems, > networking, and the like. All should be designed from a modern > perspective, not just as a slavish recreation of the old LispM > designs. I posted a couple of messages along these lines a little while back. If you look at Plan 9 you can see a particularly elegant realization of the Unixy way of thinking about systems. What I want to think about is: what is the equivalent lispy way of thinking about systems? Plan 9's great organizing principles are files and a uniform hierarchical namespace. What are the corresponding leveling abstractions of a Lisp OS? Closures? Trees? Streams? What? > >> One of them that I would certainly like to have is some sort of >> support for security; Symbolics and other LispM systems were quite >> insecure, by design. Anyone could frob anything in any process >> anywhere at any time, which was certainly very handy when developing >> software, but it's not so great when you want to have a system that >> lives on the net or otherwise shares resources with users and >> processes that may not necessarily be trustworthy. > > Hear hear! It should be possible, of course, for random processes to > poke at each other, but only if the user really wants it to be this > way. Normally they shouldn't be able to. > > Interprocess communication in Unix and similar systems is awful. It's > awful because the processes have no 'insecure' way of poking at each > other without the crock that is shared memory, or the ugliness of > pipes, et sim. If processes are allowed to poke at each other without > restriction, or at least easily through well defined interfaces, then > the person doing IPC gets a big win. However, it's still necessary > nowadays for processes to be somewhat protected from each other. Thus > I envision some sort of ACL like thing that could be part of a plist > in each stack group and accessible globally. > > A lot of attention needs to be paid to how threading systems are > implemented in existing Lisps. Also some good examination needs to be > written on multiprocessing on Lispms so that people who don't happen > to own one can learn how it works. > It's instructive to read about the Eros implementations of persistence and capabilities. There are actually some kind of tricky aspects to getting ACLs to work right, and those guys have spent several years on it now. --me From jdz at dir.lv Thu May 6 14:24:07 2004 From: jdz at dir.lv (Janis Dzerins) Date: Thu, 06 May 2004 17:24:07 +0300 Subject: [movitz-devel] Object sharing between processes In-Reply-To: References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> <4094A773.5070400@wanadoo.nl> <4098FAB6.7080007@dir.lv> Message-ID: <409A4A87.3040106@dir.lv> mikel evins wrote: > > On May 5, 2004, at 7:31 AM, Janis Dzerins wrote: > > [snip] > >> What you want (I guess) is to bring a lot of concepts of conceptual OSes ^^^^^^^^^^ I meant "conventional" here. >> to Movitz (LispOS). What "we" are after, on the other hand, is the >> *Lisp* OS. We don't want programs each having different understanging >> of what arguments are and how they are specified -- we have functions >> with their calling mechanism. We want "Lisp down to the metal", with >> all the benefits it brings us. I suggest reading some materials on >> existing Lisp OSes (use google, or this link for a start: > http://www.its.caltech.edu/~weel/lispm.shtml >). > > > Note, though, that there are some handy features of non-LISP operating > systems that we would probably like to have (certainly, that I would > like to have). I'm all *for* it, too. That's what the Movitz is for, after all -- to experiment with those features in order to make a "better OS". And that means we should try to do better than the OSes we have now. In other words -- we get a lispy substrate (Movitz) and then build our dream OS on that. I'm quite strongly against "yet another OS", which it would become if we'd focus our work on reimplementing stuff from other OSes (like the stuff Peter mentioned in his other mail about web-servers and wwwroots and what not -- in lispy OS the concepts are different so there's no need to even talk about such things). In yet another words, if we want to make something better, we *must* talk in kinda meta level, not in terms of current OSes and their concepts. I think lispniks are quite used to discussions in meta-level :) I hope I'm making my point a bit clearer now. But I may still lack the communication skill to get it over to the other side. -- Janis Dzerins Common Lisp -- you get more than what you see. From james at unlambda.com Fri May 7 10:28:41 2004 From: james at unlambda.com (James A. Crippen) Date: Fri, 07 May 2004 10:28:41 -0000 Subject: [movitz-devel] Self-hosting Message-ID: What needs to be in place for Movitz to become self-hosting? By this I mean that it could compile itself and create a bootable image (or something similar). What is missing in the compiler such that it can't compile itself yet? 'james -- James A. Crippen Lambda Unlimited 61.2204N, 149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From ffjeld at common-lisp.net Fri May 7 12:07:16 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Fri, 07 May 2004 14:07:16 +0200 Subject: [movitz-devel] Re: Self-hosting References: Message-ID: <2had0k30gb.fsf@vserver.cs.uit.no> james at unlambda.com (James A. Crippen) writes: > What is missing in the compiler such that it can't compile itself > yet? More than anyhting I think what's missing is simply the infrastructure such as access to files etc. Also, there are probably quite a few places in the current compiler that assumes some sort of cross-compiling setup, and that one wants to change somewhat for a self-hosting system. I think there are two strategies for getting the compiler going: 1. To "import" parts of the compiler piece-by-piece, taking the pieces that are needed, and re-writing some other pieces. The first piece would be the (or an) assembler. 2. To "port" the whole thing as a unit. I think option 1 is the better choice. -- Frode Vatvedt Fjeld From peter.minten at wanadoo.nl Tue May 11 14:57:47 2004 From: peter.minten at wanadoo.nl (Peter Minten) Date: Tue, 11 May 2004 16:57:47 +0200 Subject: [movitz-devel] Object sharing between processes In-Reply-To: <409A4A87.3040106@dir.lv> References: <40936650.2050708@wanadoo.nl> <40940F04.7020708@dir.lv> <4094A773.5070400@wanadoo.nl> <4098FAB6.7080007@dir.lv> <409A4A87.3040106@dir.lv> Message-ID: <40A0E9EB.4090509@wanadoo.nl> Janis Dzerins wrote: > In yet another words, if we want to make something better, we *must* > talk in kinda meta level, not in terms of current OSes and their > concepts. I think lispniks are quite used to discussions in meta-level :) If I understand you correctly you mean that we first have to develop an abstract vision of the system before diving into the details. In that respect it might be best to make lists of what the system should and what it shouldn't do. I'll start with a couple of my points: * The system should treat the user with respect, as an intelligent, thinking, being capable of making decisions. This means not treating the user like a baby (if you design for dumb users, you end up with dumb users). * The system should assist the user at the users request by providing good and concise help. * The system should not be interruptive whenever it can be avoided. The elegance of the CLI is that you don't have to worry about the focus moving to another window which causes your ENTER to have a different meaning, it should be possible to have this advantage in a graphical environment too, something along the lines of taskbar buttons changing color to signal that user interaction is required. * The system should isolate the user from the details of the implementation of resources (see below for what I mean with resources), unless the user specifically requests detailed information and has the right to access this. * The system should, to the highest reasonable extent, be secured against virusses and crackers. * The system should be admin-friendly, meaning that it should be easily managable, and should be open for changes if the admin desires it. * The system should be hacker-friendly, it should provide good hacking tools and the internal API should be well documented. Resources are a vague idea of how to replace files. A resource is something like an object that you can use for input and output of data of some kind and that can have properties. The idea is that you could simply create a resource, set some properties and _let the system figure out where it goes_. For example a configuration resource could be created by making a new resource with it's configuration property set to t and it's persistent property set to t. Greetings, Peter PS: To whom it concerns: 'http://www.il.fontys.nl/~silvernerd/harddisk.lisp' updated, fixed a few bugs in addressing and added 48 bits addressing.