70's futuristic technology

Programming focused drivel

Wednesday, May 23, 2007

Installed mcclim-0.9.4 for openmcl. Used the asdf method. Had to launch X11 and run emacs and openmcl from an xterm. Then I

(require :clx)
(require :mcclim)

and the demo's finally ran. Woo hoo. I am a bit concerned that I won't be able to make mcclim work on Windows XP, but I have no installed on Mac OS X and Ubuntu fiesty, so I will go ahead and learn how to do graphics with CLIM.

Labels:

Wednesday, May 09, 2007

Here are my notes from A New Way to look at Networking
by Van Jacobson.

Packet switching
old new
focus on paths ====> focus only on endpoints
conversations ====> packets
Transitivity makes routing emerge

they encapsulated the data and made a standard addressing structure to
glue together networks

TCP/IP too successful???
Connected - binary either your in our your out
Connecting requires - globally unique address that is stable minutes to
hours
Connection is heavyweight
point to point ( conversation ) is supported, but TCP/IP hates broadcast

Problem space for TCP/IP
Connecting users who have access to one machine
circuit and packet switched networks focus on getting two machines to
talk

New Problem Space
One user has tons of machines
A machine wants to read a named chunk of data ( web page, email, etc )
This is dissemination not conversation

Dissemination
Data is important, not the channel
Data must be secured, not the channel
Dissemination must be efficient, which it isn't with communication
Currently users have to do the plumbing to make dissemination
Protocol and medium agnostic - IP, zeroconf, multicast, pigeons)
Anything with the data can respond
Data is signed and optionally secured so receiver can verify integrity

Example
REQ http://nytimes.com/today

RESP http://nytimes.com/today
http://nytimes.com/20060830/index.html
<namemac>
<datamac>
<html>
...
</html>

Design philosophy
Data has a name, not a location
Integrity and trust are derived from data, not the channel
Anything that moves in time or space is a pipe

Communication
User communicates intent, so network can optimize
Request / response model gives user fine grained control over incoming
traffic QoS
Network is content focused, not conversation focused, so popular content
won't generate congestion
No distinction between bits on disc, on wire, or in memory
Nodes are nameless - wireless & sensor nets can use simple local
protocols like - flooding, proximity, diffusion, etc
Opportunistic transport - planes, trains, automobiles, as well as mobile
phones on people

Security
Trust and data integrity are baked in - solves Phishing, Pharming, and
Spam
Trust is associated with data not SSL channels
Security of country improves, can't disrupt carrier pigeon

Already solved
PGP
Repositories - "instant PKI", "UT Austin Snakebite"
Data location - URL, search, epidemics, directed diffusion, filtered
'small world'

Names and Naming
Augment names with time/version - cacheable, stable
Integrity preserving data segmentation - keep responses idempotent and
small
Nicknames and intentional names - "all the open doors in building A"

Hard Stuff
Incentive structure ( flow & congestion control, sharing &
redistribution incentives ) - leechers
Miscreant & freeloader detection - anonymity
Redistirbution - content routing, storage replacement strategies,
liability issues
Corrupted, invalid, or expired content - hints up the line

Conclusion
Telephones - plumbing at wire level - phone number is a routing program
IP - plumbing at the data level - URL is a endpoint from another
endpoint
Dissemination Based Arch - push data plumbing down - Decentralized named
content

Ad-hoc dissemination overlays - Akami CDN, BitTorrent, Sonos mesh, Apple
Rendezvous

Labels:

Friday, May 04, 2007

I am looking for a GUI technology for the Knitting simulation software I have been working on. Currently the GUI is written in Java, but I don't want to deploy such an unwieldy beast. I was thinking of writing the finished version in JavaScript with the canvas tag, or perhaps Flash.


The backend is Common Lisp + Sqlite exposed through HTTP.

Those Bruce Eckles ads allover the net have been giving me heart-burn. Aftering reading about all of the open source efforts at Adobe, I thought, what the heck, give Apollo a shot.

After reading their marketing material, which make many of the promises that Java originally ( and still does ) make, I found this:

Does Apollo support Linux

Apollo 1.0 will not be available on Linux. We plan to release Linux support shortly after the 1.0. release.
While we had originally planned to support Linux in the 1.0 timeframe, we have had to wait on the core Flash Player's support for Linux to be finalized.

Macromedia and Adobe have never supported open, cross platform development. It sounds like they will have as much trouble getting it right as Sun has.

The Squeak browser plugin is a real honest to God cross platform plugin. Why? Because the don't hand write the virtual machine for each platform, they use a code generator to generate it so that it is bit for bit compatible across platforms. Browser penetration of this plugin is probably smaller than than G W B's Iraq approval ratings, but it is an example of how to do cross platform runtimes.

Another attractive option is to build the ReST backend, build one superb frontend, say in Cocoa for Mac OS X, and then hope that others copy your frontend into Win32 and GTK, etc.

All technologies are flawed, but I am really disapointed that Adobe/Macromedia is continuing their misteps. GPLing is a good first step, but isn't SWF still proprietary? Why didn't you release the Actionscript compiler? Why aren't you launching all platforms simultaneously? Why won't this technology make my bed for me in the morning?

Labels: