Archive for March, 2006
March 18, 2006 at 9:05 pm · tags: E
Here I am, at the end of my E-journey.
What have I learned?
The existance of great ideas. I don’t really like E’s syntax but the ideas behind and beyond this language are great. The capability security model is stupid-proof and 100% secure. It’s a pity nobody uses it. As far as I know Palladium is a capability infrastructure but I don’t like the way and the reason why it’s implemented 
The E-things I dislike are it’s javashism, the slowness of the command line intepreter, the apparent no-interest of people outside the little community and so on.
What next?
Another exotic language? Another less known or widespread language? Smalltalk? Io? Common Lisp?
March 18, 2006 at 1:05 pm · tags: E Security
Capabilities
E uses capability based security to supply both strong security and broad flexibility without incurring performance penalties. Capabilities might be thought of as the programming equivalent of physical keys
E makes use of the Principle of Least Authority (POLA) to ensure that it gives no more authority that the other part needs.
In the real physical world, if you had to depend on children to fetch CDs, you would not use an ID badge. Instead you would use keys. You would give the child a key to the front door, and a key to the CD cabinet. You would not give the child a key to the gun vault.
All current popular operating systems that have any security at all use the ID badge system of security. NT, Linux, and Unix share this fundamental security flaw. None come anywhere close to enabling POLA. The programming languages we use are just as bad or worse. Java at least has a security model, but it too is based on the ID badge system–an ID badge system so difficult to understand that in practice no one uses anything except the default settings (sandbox-default with mostly-no-authority, or executing-app with total-authority).
The “children” are the applications we run. In blissful unawareness, we give our ID badges to the programs automatically when we start them. The CD cabinet is the data a particular application should work on. The gun vault is the sensitive data to which that particular application should absolutely not have access. The children that always run to get a gun are computer viruses like the Love Bug.
In computerese, ID badge readers are called “access control lists”. Keys are called “capabilities”. The basic idea of capability security is to bring the revolutionary concept of an ordinary door key to computing.
Read the rest of this entry »
March 17, 2006 at 7:00 pm · tags: Rails Rebbin Ruby
I released a you-should-have-released-it-months-ago version
What’s new?
What’s changed?
- Requires Rails 1.0
- Atom 0.3 feed dropped
http://rebbin.berlios.de/
A live version here: http://pasteserver.net/
March 15, 2006 at 8:56 pm · tags: Misc
Just received them from Amazon.
Only listened to Kind Of Blue yet, three times. Gorgeous.
March 14, 2006 at 8:37 pm · tags: E
E programs never block. They never just sit and wait around for results.
It this just a dream ?
March 14, 2006 at 8:31 pm · tags: E
A promise is the result of an eventual send to an object:
def carVow := makeCar <- (“Mercedes”)
carVow <- moveTo(2,3)
“<-” is the eventual send operator.
Now you can start making eventual sends to the promise as if it were the object itself.
The “when-catch” clause is used to wait for the resolution of a promise:
def temperatureVow := carVow <- getEngineTemperature()
when (temperatureVow) -> done(temperature) {
println(“The temperature of the car engine is: “ + temperature)
} catch error {
println(“Could not get engine temperature, error:” + error)
}
println(“execution of the when-catch waits for resolution of the promise,”)
println(“but the program moves on immediately to these printlns”)
We can read the when-catch statement as, “when the promise for a temperature becomes done, and therefore the temperature is locally available, perform the main action block… but if something goes wrong, catch the problem in variable error and perform the problem block”. The when-catch construct waits for the temperature to resolve into an actual (integer) temperature, but only the when-catch construct waits (i.e., the when catch will execute later, out of order, when the promise resolves). The program itself does not wait: rather, it proceeds on, with methodical determination, to the next statement following the when-catch. Inside the when-catch statement, we say that the promise has been resolved. A resolved promise is either fulfilled or broken. If the promise is fulfilled, the main body of the when-catch is activated. If the promise is broken, the catch clause is activated.
References can always resolve to local object (vow references) or be unguaranteed references (receiver references) that must be treated as remote objects.
