|
|
#1 |
|
|
Idea for a File system ! Has somebody a good idea for a Lisp File system ? best Werner |
|
|
#2 |
|
|
> I try a Lisp OS to develop , and need still a good Idea for a File > system ! > Has somebody a good idea for a Lisp File system ? I'd say that it rather depends on the other features of your system. You'd not get the same kind of file system if your system is 100% capability based of if it's distributed OS, or if it's a unix system. You could also do entirely without a file system if you have persistent storage of all the OS objects like in EROS (http://www.eros-os.org): the RAM is then just considered as a big cache of the whole disks memories, and each application could define its own "file system objects". At the user interface, I'd prefer something like unix file system (with perhaps adding versions). -- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. |
|
|
#3 |
|
|
> I try a Lisp OS to develop , and need still a good Idea for a File system ! > Has somebody a good idea for a Lisp File system ? Hi! POSIX-compliant? What special forms do you think you will need beyond ANSI CL? What Lisp would you use? What processor platform? Simulated or real? Oliver Korpilla |
|
|
#4 |
|
|
Oliver Korpilla schrieb:
> Werner wrote: >> I try a Lisp OS to develop , and need still a good Idea for a File >> system ! >> Has somebody a good idea for a Lisp File system ? > POSIX-compliant? Come on, POSIX-compliancy is not lisp style. It has to be something better ![]() So either faster or more other features - quota, snapshot, large file support, ACL, versioning, journalling = undo in case of corruption, or a real undo as in the old Lisp Machine, ... - on a single machine, or take the distributed approach (AFS, Coda, ...). Christopher Browne has a nice overview of the newer ones: http://cbbrowne.com/info/fs.html And maybe this short overview will help: http://www.osdata.com/holistic/connect/filesys.htm http://www.faqs.org/docs/Linux-HOWTO...ems-HOWTO.html is quite ok. ARLA as free AFS variant (distributed) looks fine. Search for OS/MVS => http://www.osdata.com/oses/mvs.htm and http://www.mvsbook.fsnet.co.uk/chap03a.htm#Section2 This might relate somehow to LispOS, and other esoteric problems (getting data from punch cards, sorry magnetic tapes, reasonable fast ![]() -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
|
#5 |
|
|
Thank you for the hints .
A completely untrodden path to go , is not advisable . I will begin with a Unix Kernel and the File System ext2fs . |
|
|
#6 |
|
|
wernerblock@netscape.net (Werner) writes:
> Thank you for the hints . > A completely untrodden path to go , is not advisable . > I will begin with a Unix Kernel and the File System ext2fs . Trodding the unix path with lisp is like driving a F1 into a mountain track. -- __Pascal Bourguignon__ |
|
|
#7 |
|
|
Pascal Bourguignon wrote:
> wernerblock@netscape.net (Werner) writes: > >> Thank you for the hints . >> A completely untrodden path to go , is not advisable . >> I will begin with a Unix Kernel and the File System ext2fs . > > Trodding the unix path with lisp is like driving a F1 into a mountain > track. lol Especially if there's a nice highspeed-highway built around the mountain that seems unused since quite a couple of years. -ts |
|
|
#8 |
|
|
Reini Urban wrote:
>> POSIX-compliant? > > Come on, POSIX-compliancy is not lisp style. It has to be something > better ![]() > > So either faster or more other features - quota, snapshot, large file > support, ACL, versioning, journalling = undo in case of corruption, or a > real undo as in the old Lisp Machine, ... - on a single machine, > or take the distributed approach (AFS, Coda, ...). Uh, excuse me, instead of reimplementing POSIX you're arguing for reimplementing Linux? Sounds not much lisp-ier to me! Lisp-ux.With kind regards, Oliver |
|
|
#9 |
|
|
Oliver Korpilla <okorpil@fh-landshut.de> writes:
> Reini Urban wrote: > >> POSIX-compliant? > > Come on, POSIX-compliancy is not lisp style. It has to be something > > better ![]() > > So either faster or more other features - quota, snapshot, large > > file support, ACL, versioning, journalling = undo in case of > > corruption, or a real undo as in the old Lisp Machine, ... - on a > > single machine, > > or take the distributed approach (AFS, Coda, ...). > > Uh, excuse me, instead of reimplementing POSIX you're arguing for > reimplementing Linux? Sounds not much lisp-ier to me! Lisp-ux.No. It would be better to implement a capability based OS like eros (http://www.eros-os.org). -- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. |
|
|
#10 |
|
|
Pascal Bourguignon <spam@mouse-potato.com> wrote:
> Oliver Korpilla <okorpil@fh-landshut.de> writes: >> >> Uh, excuse me, instead of reimplementing POSIX you're arguing for >> reimplementing Linux? Sounds not much lisp-ier to me! Lisp-ux.> > No. It would be better to implement a capability based OS like eros > (http://www.eros-os.org). As a Linux system administrator, I greatly agree. Today's Linux (and BSD) systems do have vast security advantages over older Unix systems. Network services such as Web and FTP servers are not usually run as "root" these days. You have (if you care to use them) fine-grained restrictions on network access, user privileges, and system resources. However, all these features have basically been kludged on to a design which originally ***umed that: * Each process belongs to one user, and should be able to do anything that user can do. * Categories of privilege (groups) are declared by the root user only. Users cannot create new ones: if James wants to let Emily and Robert read a file, but not Erica, then James must petition the admin to create a group. * Users cannot express subsets of their own privilege level. I cannot, e.g., start an "sbcl" process with the proviso that it is not allowed to write to disk. * Administrative tasks frequently cannot be delegated except by handing over a setuid binary, which has the full power of root available to it. There is no way to grant users access to a program that does -only one- rootly thing (like, say, "ping"!) without trusting that program with -full- root privilege. A security bug in the ping program lets every user be root. * A handful of bits are sufficient to express file permissions. * Limitations on the use of system resources (ulimit) are strictly optional. * Even the administrator cannot control delegation of privilege by other users -- there is no mandatory access control. There is no way to prevent a user from setting his own files world readable. * Everyone's temporary files and IPC sockets should be dumped in a world-writable /tmp directory, so if anyone can guess what someone else will use for a filename there, they can do a symlink exploit. If you can guess what /tmp file a root process will create, you can trick root into wiping out the OS kernel, the system logs, or the p***word file. * Any process can talk to the network ... but in order to run a "well-known service" (port < 1024) your process must run as the superuser, with all the superuser's privilege. Running a network service -not- as root takes extra work ("dropping privilege") rather than being the default condition. A declarative, capabilities-based system would be a vast improvement over the current state of Unix/Linux security. One whose systems programming language did not invite stupidities such as buffer overflow would be even better. And -- while I'm wishing -- if it comes with a Web server and a fast relational database (not SQL, if you please!) then people might actually use it. ![]() -- Karl A. Krueger <kkrueger@example.edu> Woods Hole Oceanographic Institution Email address is spamtrapped. s/example/whoi/ "Outlook not so good." -- Magic 8-Ball Software Reviews |