Compiling git on fresh Ubuntu 7.0.4

Note to self: packages I had to install for “make all doc” to work for git 1.5.3.8.

$ history | grep install

   36  sudo apt-get install curl
   41  sudo apt-get install libcurl
   49  sudo apt-get install tk8.4
   53  sudo apt-get install cpio expat
   55  sudo apt-get install zlib
   61  sudo apt-get install build-essential
   66  sudo apt-get install zlib1g-dev 
   72  sudo apt-get install asciidoc
   75  sudo apt-get install xmlto
Advertisements

John Galt, meet Paul Graham

From the Arc tutorial, line 372

arc> (is 'a 'a)
t

(for those who don’t get the joke, don’t worry, it wasn’t that funny. Neither was Ayn Rand.

Installing Arc on Mac OS X

Installing the Arc language on Mac OS X is trivial, assuming you have the right version of MzScheme.

Install MzScheme 352 with MacPorts

Arc requires MzScheme, version 352. The install instructions warn: “Don’t use the latest version. There is said to be some bug/feature in it that breaks Arc.” The version of mzscheme in MacPorts is 371, so we have to tweak the portfile, and the only historical versions of mzscheme I can find portfiles for are 201 and 360. There seem to have been some major build changes between 352 and 360, so I frankensteined the portfile for version 201. You can find my version here. I’m running 10.4.11 on my dev machine, and I haven’t tested anything else.

Thanks go to bitshaker.com for the instructions on setting up a local port repo.

  1. mkdir /Users/Shared/dports/lang/mzscheme
  2. Edit /opt/local/etc/macports/sources.conf to look like this:
    # To enable your local ports repository, uncomment and customize the
    # following line to point at your local dports directory
    # Example: file:///Users/landonf/misc/macports/dports
    #
    # To get macports from the macports rsync server use:
    # rsync://rsync.macports.org/release/ports/
    file:///Users/Shared/dports
    rsync://rsync.macports.org/release/ports/
      
  3. Download this portfile and copy it to /Users/Shared/dports/lang/mzscheme/Portfile
  4. Update the ports index:
    portindex /Users/Shared/dports
  5. When you run port list mzscheme, you should have an entry for mzscheme @352
  6. Install with:
    sudo port install mzscheme @352
  7. Is mzscheme the right version? Does it run?
    $ mzscheme
    Welcome to MzScheme version 352, Copyright (c) 2004-2006 PLT Scheme Inc.
    > (+ 1 2 )
    3
    (exit)
    $
      

Download Arc and run it with mzscheme

Download http://ycombinator.com/arc/arc0.tar and untar it somewhere useful on your system. ~/src/ perhaps?

$ tar -xv arc0.tar
$ cd arc0
$ mzscheme -m -f as.scm 
Use (quit) to quit, (tl) to return here after an interrupt.
arc> (+ 1 2)
3
arc> (quit)

http://arclanguage.org/install

"Tables are the [lisp] lists of html"

Paul Graham:

Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means. But this sort of ambiguity is not always an error.

Zed Shaw:

I may never do another CSS only layout again. I’m starting to wonder how … we got sucked into that crap, especially if the only way to really get a good looking layout with CSS and div tags is with mountains of stylesheets, html, and sometimes some damn javascript.

I’m not kidding about the javascript. I’ve seen people desperately trying to force their square-peg 3 column layout through the CSS round hole resort to javascript tricks to force the columns in the right spots.…

It’s not gauche to do what’s easiest and nobody’s going run you out of Designer Town (population 100) with sharpened pitchforks and blazing torches.

Insincere apologies to Zed for the bowdlerization.

Arc, at last

Arc, a long-awaited dialect of Lisp, is finally available to the public for testing. As the man says:

“Arc is still fluid and future releases are guaranteed to break all your code. In fact, it was mainly to aid the evolution of the language that we even released it.”

Graham has been influential in encouraging the curious to try out a lisp of one sort or another. Since I first read his articles about Common Lisp and began tracking the infuriatingly undocumented progress of Arc, several new lisps have appeared. Here is wealth, and may Arc enrichen us further.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

The planned security model for CouchDB

While CouchDB currently has no authentication or authorization facilities, a general outline of the plans exists here:

http://incubator.apache.org/couchdb/docs/overview.html

It seems databases will have admin accounts. Full stop. No baked-in facility for user accounts. Administrators have two powers:

  1. manage design documents
  2. create other admin accounts

The Technical Overview doesn’t say, but I assume admins can also manage all documents.

Regarding non-administrative users, as I understand the plan, CouchDB will provide a rudimentary authentication delegator that accepts a login and password. “The user credentials are input to a javascript function, and the function returns a list of [reader-names] for the user, or an error if the user credentials are wrong.” I read this as meaning that the authenticating/authorizing javascript function is determined by the developer.

Write access, called “Update Validation” in the Technical Overview, is also handled dynamically by javascript: “Both the user’s credentials and the updated document are given as inputs to the validation formula, and can be used to implement custom security models…” Developers are free to implement custom authorization models, such as “author only”, where users must be listed in an author field in the document.

Read access is granted by a simplified ACL system. A CouchDB document may have a “reader list”, which specifies a list of “reader-names”. These reader-names need not correspond to user login names, so they are effectively the equivalent of groups (i.e. you can give one or more users the same reader-name). A user’s possession of a reader-name is determined by the javascript function that authenticates user logins.

Documents without a reader list are world-readable. Documents protected by reader lists are viewable only by users who possess one of the reader-names on the list. Read protection on documents applies to view results as well: “Documents that are not allowed to be read by the user are dynamically filtered out of views, keeping the document row and extracted information invisible to non-readers.”

The Technical Overview does not address this directly, but the _all_docs view must follow the same rules. That is, all unprotected documents show up in the results for all users, but protected docs only show up for users possessing the correct reader-names. The javascript functions that bind it all together will probably need administrator privileges.

Some interesting points:

  • The plans for write access allow developers to write their own authorization schemes, but the planned read access will be hard-coded to use document-based ACLs.
  • By default, document names (i.e. DocIds) are 128 bit UUIDs generated by the server. Depending on the algorithm used to generate them, these could be unguessable.
  • If the _all_docs view was not available, users would not be able to find any documents without knowledge of the (unguessable) DocIds.
  • The authentication javascript, upon success, is supposed to return a list of reader-names, but I don’t see that anything would prevent it from returning a list of DocIds.

I think we have the germ of a capability system here, even with the inflexible reader access.

Comments? Scathing refutations?

The planned security model for CouchDB

While CouchDB currently has no authentication or authorization facilities, a general outline of the plans exists here:

http://www.couchdbwiki.com/index.php?title=Technical_Overview#Security_and_Validation

It seems databases will have admin accounts. Full stop. No baked-in facility for user accounts. Administrators have two powers:

  1. manage design documents
  2. create other admin accounts

The Technical Overview doesn’t say, but I assume admins can also manage all documents.

Regarding non-administrative users, as I understand the plan, CouchDB will provide a rudimentary authentication delegator that accepts a login and password. “The user credentials are input to a javascript function, and the function returns a list of [reader-names] for the user, or an error if the user credentials are wrong.” I read this as meaning that the authenticating/authorizing javascript function is determined by the developer.

Write access, called “Update Validation” in the Technical Overview, is also handled dynamically by javascript: “Both the user’s credentials and the updated document are given as inputs to the validation formula, and can be used to implement custom security models…” Developers are free to implement custom authorization models, such as “author only”, where users must be listed in an author field in the document.

Read access is granted by a simplified ACL system. A CouchDB document may have a “reader list”, which specifies a list of “reader-names”. These reader-names need not correspond to user login names, so they are effectively the equivalent of groups (i.e. you can give one or more users the same reader-name). A user’s possession of a reader-name is determined by the javascript function that authenticates user logins.

Documents without a reader list are world-readable. Documents protected by reader lists are viewable only by users who possess one of the reader-names on the list. Read protection on documents applies to view results as well: “Documents that are not allowed to be read by the user are dynamically filtered out of views, keeping the document row and extracted information invisible to non-readers.”

The Technical Overview does not address this directly, but the _all_docs view must follow the same rules. That is, all unprotected documents show up in the results for all users, but protected docs only show up for users possessing the correct reader-names. The javascript functions that bind it all together will probably need administrator privileges.

Some interesting points:

  • The plans for write access allow developers to write their own authorization schemes, but the planned read access will be hard-coded to use document-based ACLs.
  • By default, document names (i.e. DocIds) are 128 bit UUIDs generated by the server. Depending on the algorithm used to generate them, these could be unguessable.
  • If the _all_docs view was not available, users would not be able to find any documents without knowledge of the (unguessable) DocIds.
  • The authentication javascript, upon success, is supposed to return a list of reader-names, but I don’t see that anything would prevent it from returning a list of DocIds.

I think we have the germ of a capability system here, even with the inflexible reader access.

Comments? Scathing refutations?