Lisp

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 ?

best Werner

(Werner) writes:

> 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
( 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__

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.

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 ?

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

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:


And maybe this short overview will help:


is quite ok.

ARLA as free AFS variant (distributed) looks fine.

Search for OS/MVS =>
and
This might relate somehow to LispOS, and other esoteric problems
(getting data from punch cards, sorry magnetic tapes, reasonable fast
--
Reini Urban

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 .

(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__

Pascal Bourguignon wrote:

> (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

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

Oliver Korpilla <> 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
().

--
__Pascal Bourguignon__

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.

Pascal Bourguignon <> wrote:
> Oliver Korpilla <> 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
> ().

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 assumed 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 password 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 <>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews