[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OT: Re: [Chicken-users] rails-like framework

From: F. Wittenberger
Subject: Re: OT: Re: [Chicken-users] rails-like framework
Date: Wed, 26 Apr 2006 16:33:13 +0200

Am Dienstag, den 25.04.2006, 11:32 -0700 schrieb Shawn Rutledge:
> On 4/25/06, Jörg F. Wittenberger <address@hidden> wrote:
> > Am Montag, den 24.04.2006, 15:12 -0700 schrieb Shawn Rutledge:
> > > Well I see the idea of calling a web framework an OS is not new:
> > >
> > >
> >
> > So who was the first one? ;-)
> Oh you guys started the trend?

Dunno.  I don't care.  Once upon a time I've been thinking whether the
term applies.  Out there came the wiki entry we created (german):
Last modification: Thu Jun 21 23:57:02 2001
source forge registration 2001-10-02 10:56

> > There's quite a lot on my wish list.  But there I distinguish between
> > application level, where your Scripts and libraries reside, and kernel
> > level, which just does the message routing and state synchronization.
> In which level are the model objects then?

Application level.

> > Unfortunately the security experts insist for a reason, that you can't
> > build security into an insecure system, it has to be build in right from
> > the beginning.
> Yeah and the other risk is if you worry about too many things at once,
> the prototype never gets done.  The Xanadu project to me is both a
> great inspiration, and a great example of how not to get anything
> done.

actually I see quite some overlap, at the application level

> I
> thought the Eros project sounded very interesting, mostly because of
> the orthogonal persistence implementation.  But the focus is the
> capability security model, which is also interesting but probably
> that's the only thing that will be accomplished, the way the project
> is going now.  What do you think of that?  Seems to me it could work
> pretty well in a system like this.

It's actually pretty close.  However with I take several issues with it.
But as you said, security is of least concern to you, those are off
topic of sort.

1.:  pre-system dawn capability distribution
2.: a "swiss number" is nothing but a clear text password

Also it's hard to see, why reachability and access should be identified.
I can imagine cases, where I want to hold a reference to an project,
even though it refuses to talk to me.

Eventually: how to you prevent manufacturing of pointers, if you
transfer them over the wire?  You can with benign partner.

> > And that's more true, when the focus is legal processes.  This *must* go
> > down to the system architecture or you'll loose all your development
> > work eventually.
> Are you saying this about all possible software projects or just Askemos?

The problem is, that if there's a second person in your "reliance set",
you don't have true accountability.  There's always another one, who
could have done it (whatever you are accused to).  Facts derived such
software should never hold in the curt (except for the practical matter
that today many things are accepted, which should never have been).

To answer your question I need to distinguish between Askemos and BALL.

With Askemos I refer to the concept of a global virtual machine, which
is intrusion resistant (healing defunct part of certain percentage) and
incorruptible (no person can impersonate any other, i.e., no super user
concept, not even accidentally).  Any rule system (computer executable
or not; think of games) may qualify to be "Askemos compliant".

BALL refers to one implementation of one such system.

Now: yes, I'm saying this about all possible software projects, which
don't qualify as Askemos-compliant.  No, I'm not saying that BALL is the
only possible system.

> I don't know if a few humans can design a system so tamperproof as to
> keep out the billions of other humans trying to tamper with it.

Not a few, but they did already.  About 300 years ago.

And it's partially based on even older knowledge.  Military this time,
the problem of the byzantine generals. 

As a computer scientist it's not always you duty to invent something
new.  Often it's better to model reality as close as possible.

What I refer to is (the theory of) our legal system.  Since ethics
changed during enlightenment slightly, the legal starts out of equality
between humans.  The limited truth of legally effective facts is defined
by some kind of common understanding.  (This for instance invalidates
knowledge gained by torture before the judge.)

>   It's
> worth a try but I think security will have to keep evolving as
> different methods get cracked.

OK, but that's a political issue: how do you crack the majority vote?
There seems some kind of answer though: ask Mr. B. reach him via italian
TV.  ;-)

>   The best methods that have been
> envisioned don't even exist yet (like quantum computing).  We'll see
> if existing security architectures will adapt well to those new
> methods over time.

There's one thing we need to aknowledge: legal security and (total)
secrecy are mutual exclusive.  There needs to be a certain amount of
publication.  And all sudden: you don't need better encryption, you need
crypto protocols to reach common knowledge in presence of attack.
Agreement that is.

Not too complicated.

> > The good news is, that we have it usable.  Our pages look slightly
> > simpler that plain Spiffy or this ajax frame work posted these days.
> > Well, to me and I'm biased.  But I know about at least one person, who
> > just picked Askemos/BALL because of it's mix of XML transformation
> > features ignoring all the sec. features.
> XML transformation is yucky and inefficient IMO.  My least favorite
> language of all is XSLT.

yucky, hm, sorry, my english.

Inefficient, maybe.  What exactly is inefficient about it?

Well, since I don't know what concrete syntax is, but think only in in
core tree structures: what's the difference between xml transformation
and S-expression transformation?

As for ball: yes, there is some xslt support.  But not mandatory.  For
me it's just a handy way to store some Scheme scripts and dispatch.

> > Yes and no.   No, you don't want to trust any binary only data format.
> > Especially not, when it's a gziped memory dump.  Furthermore there are
> Wow it's even worse than I thought.

The tools ought to fit the purpose, doesn't it?  Pointer swizzling at
page fault time can be even faster than reading plain files.  It's
definately faster than parsing <insert you favorite portable format
here>.  Use it as a cache and you know what the gain is!  Don't put it
into your backup, it just doesn't belong there.

> What about hooking Scheme to a more stable, portable sort of OODB?


> What does RScheme do?

Compile to monotones C or to bytecode, both either on the fly or
offline.  So in theory, that if some more smartness where build into the
compiler, it could be possible to schedule monotones as in a real time
operating system.

> portable, yet not as verbose as XML; and the assumption would be that

As I said before: the decision to go XML is at least for germany made by
the parliament.  Who am I to go against it, just because I know this
would be technically better?

(((A man might be intelligent, mankind has yet to become so.)))


reply via email to

[Prev in Thread] Current Thread [Next in Thread]