brainstorms

Monday November 21, 2005

a quote about SUN and portability, circa 1991

found this one amongst my notes from york university. i recall that it is from a 1991 technical note of another computer company now long gone. [alas, i do not recall the author.]

I understand that, from the beginning, Sun tried to ensure their kernel was portable by making sure that every release would run on their Vax. This surely added a little time to their release cycle, but it even more surely saved them a lot of time when they introduced their 386-based and SPARC-based systems.

we are still that Sun...

[do not ask me about this technical note. it too is long gone]

Monday November 07, 2005

open source and aging nerds...

robert x. cringely has some interesting thoughts about a computing industry transition towards open source as baby-boomer nerds age. from his Changing the Guard:

Imagine 100,000 engineers and programmers leaving the U.S. work force every year for the next 18 years, because that's what is going to happen. Some of those people will find other careers, but most of them will be motivated less by money than they were earlier in their lives. Most of them will want to remain active. And once a nerd always a nerd, so I think many of them will gravitate to Open Source.

cringely has a good point. that gravitation to open source can be helped and accelerated; perhaps some of us maturing nerds can get together and start planning...

Wednesday October 05, 2005

a proposal for r6rs [scheme] arithmetic

william clinger and michael sperber's preliminary proposal for r6rs arithmetic is a very good read for language implementors. [almost a textbook example of how to do these things]

This SRFI proposes to revise section 6.2 ("Numbers") of R5RS by:

• requiring a Scheme implementation to provide the full tower, including exact rationals of arbitrary precision, exact rectangular complex numbers with rational real and imaginary parts, and inexact real and complex arithmetic
• defining fixnum arithmetic (parameterized by precision)
• defining flonum arithmetic (inexactly)
• defining new procedures for performing exact arithmetic
• defining new procedures for performing inexact arithmetic
• describing the external representation and semantics of 0.0, -0.0, infinities and NaNs for systems that implement inexact real arithmetic using IEEE binary floating point
• changing the specification of eqv? to behave more sensibly with inexact numbers
• defining Scheme's real numbers to be the complex numbers whose imaginary part is an exact zero
• adding an external representation for inexact numbers that expresses the precision of a binary floating point representation
• defining procedures for some new operations, including integer division and bitwise operations remainder on real numbers,
• restricting the domains of some R5RS procedures
• clarifying the semantics of some R5RS procedures
• possibly changing the semantics of some R5RS procedures

there is a reference implementation in r5rs scheme.

related links:
scheme requests for implementations
r5rs [ps]

Friday September 23, 2005

state of the onion: cooked

wohoo. another state of the onion full of wall-idation. just imagine the excitement around python and ruby circles for their yearly dose of comic relief. my favorite observation:

Cats know how to get into and out of places they're not supposed to be able to get into and out of. Cats seem to know how to levitate, and to pass through supposedly impermeable barriers. Even the stupidest cat knows how to make you think they're reading your mind, but it's all a trick.

[one good thing about larry is that even when he is obscure, thin and fragmented [read deep], he is still funnier and somewhat wiser than people like graham.]

Tuesday September 13, 2005

mjr: six dumbest ideas in computer security

marcus's latest essay six dumbest ideas in computer security is a great read. highly recommended.

Let me introduce you to the six dumbest ideas in computer security. What are they? They're the anti-good ideas. They're the braindamage that makes your $100,000 ASIC-based turbo-stateful packet-mulching firewall transparent to hackers. Where do anti-good ideas come from? They come from misguided attempts to do the impossible - which is another way of saying "trying to ignore reality."

Thursday August 04, 2005

differently clued quote of the day

from joel's latest and otherwise [mildly] interesting essay hitting the high notes:

Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.

narrischkeit, really. joel knows a lot about software, but apparently his classical music knowledge, such as it is, is deeply informed (or deformed) by peter shaffer's mostly fictional amadeus. he could have bothered to listen to something by salieri since watching that movie [or the play] so that he actually knew what he was talking about. [alas, wikipedia, enlightening though it may be, is no substitute for actual listening. serious classical music stations cover salieri with some frequency...]

[related reading: peter brown's detailed critique, "amadeus" and mozart: setting the record straight. esp. see schubert's tribute to the kapellmeister]

Friday April 08, 2005

macs and essayists

earlier i had blogged about graham's mac essay and made a few points contra his romantic hand-waving. mac fan john gruber also has a discussion of that essay here with lots of self-quotes. gruber also takes on our tim bray for his unswitch essay. [he even compares stock charts. now there is an innovative argumentative technique!]

The core difference between Mac OS X and the old Mac OS isn’t that it is flat-out better, but that it is good in (mostly) all the ways the old Mac OS was good, and but is also good in entirely different ways. It is the Mac and it is Unix, at the same time.

[what a nicely twisted, diplomatic sentence. a more blunt, accurate version would have said it is good in the ways old Mac OS was awful. would a venn diagram help?]

[musical recommendation: tbd.]

a loss of bitkeeping...

recent news about the bitmover's plans to phase out the free bitkeeper product came as a bit of a shock. [there is a detailed kerneltrap article on this, and has already been slashblotted, so i will not bother re-iterating the details.] now here is an interesting challenge: what makes bitkeeper special [says a regular bk user] and can it be cloned [without running into any patent troubles with bitmover] for the open source community? i expect there will be some fun times ahead in the source code control area. [i am reminded of that great line from the golem lectures about a negative gradient]

I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world ;) -- linus

[musical recommendation: julian bream, guitar recital: wonderful, thoughtful pieces by sor, turina, de falla and torroba]

[linus mentions monotone in his message; latest version does not configure on stock sol10 due to libboost_unit_test_framework failure. clunk.]

Friday April 01, 2005

all the best hackers i know...

All the best hackers I know are gradually switching to Macs.

so opens another charming paul graham essay titled Return of the Mac.

[no this is not an april fool's joke]

even though some of graham's essays are as irritating to my critical faculties as wearing a wool sweater in a humid august afternoon, i will take it easy on this one; i have been using macs since 1984; these days all my photography goes through a dual-cpu g4 and i carry a g4 ibook with me everywhere. also, i too know some good hackers who made the switch.

on the other hand...

old mac as a canonical hacker's computer? that is romantic fiction, especially when all you had to work with was a tinkertoy operating system (for some loose definition of that term). i did spend a lot of (wasted) time and energy hacking on macs; (even wrote a lisp interpreter for macs, macclisp - pun intended) for an excitable unix+vms hacker, macs were painful to program. just take a look at that fun event loop! veni, vidi, vomui. early choices: relatively clunky c compilers (aztec, think) with imitation shells, pascal or basic. no really worthwhile lisp (until lightship scheme) that i could recall. there may have been a useful smalltalk. if only those sofas at cambridge could talk...

another thing: what are those hardcore OS hackers doing with their new macs? i would really enjoy seeing some groundbreaking new stuff coming out of OS X we can use on sol10, [free|net|open]bsd and linux. [so far everything seems to be going the other direction, including the hackers...]

[on the right is my cover graphic for computing news, york university, 1984]

[addendum: graham likes to talk about taste and design; it would have been worthwhile to see him analyse mac designs in depth. here, one way is to be dazzled by their industrial and usability designs and come up with the usual platitudes; another way is to analyse the os, various api and protocol designs (eg. appletalk gets the prize for cutest solution - perlman, interconnections, second ed.) and algorithms (eg. apple numerics) as well. why, we call this computer science.]

Friday March 04, 2005

solaris white album: essential papers

about a decade ago, a group now far, far away, put together the white album, a cherished collection of important technical papers authored by sun engineers until that time. with the release of solaris 10, i decided to revisit and revise that collection. here is a reasonably up-to-date version of the white album. it contains OS-related entries only, and many of the papers come from usenix. [which is of no surprise] almost all entries below are linked from citeseer to provide context and depth.[there are a few papers i could not locate in machine-readable form, but working on it. additions, corrections, suggestions welcomed.]

• Shared Libraries in SunOS
• Virtual Memory Architecture in SunOS
• SunOS Virtual Memory Implementation
• Realtime Scheduling in SunOS 5.0
• SunOS Multi-thread Architecture
• Beyond Multiprocessing: Multithreading the SunOS Kernel
• Implementing Lightweight Threads
• Symmetric Multiprocessing in Solaris 2.0
• Vnodes: An Architecture for Multiple File System Types in Sun UNIX
• Evolving the Vnode Interface
• Efficient User-Level File Cache Management on the Sun Vnode Interface
• Extent-like Performance from a UNIX File System
• Design and Implementation of the Sun Network Filesystem
• The Sun Network Filesystem: Design, Implementation and Experience
• Virtual Swap Space in SunOS
• Profiling and Tracing Dynamic Library Usage Via Interposition
• tmpfs: A Virtual Memory File System
• The Translucent File Service
• The Automounter
• The Automounter: Solaris 2.0 and Beyond
• The Autofs Automounter [i would appreciate a link to a postscript version of this paper, if it exists]
• Enhancements to the Autofs Automounter
• Removable Media in Solaris
• Zero-copy TCP In Solaris
• The Process File System and Process Model in UNIX System V [link not found]
• Evolution of the SunOS Programming Environment, Proceedings of the Spring 1988 EUUG Conference, Cascais, Portugal, 1988.

• Implementing Berkeley Sockets in System V Release 4
• Secure Networking in the Sun Environment, Usenix Conference Proceedings, Summer 1986
• Fast Consistency Checking for the Solaris File System
• System Isolation and Network Fast Fail Capability in Solaris
• CPU Time Measurement Errors
• Solaris Zones: Operating System Support for Server Consolidation
• Solaris Zones: Operating System Support for Consolidating Commercial Workloads
• The Slab Allocator: An Object-Caching Kernel Memory Allocator
• Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources
• Automatic Performance Tuning in the Zettabyte File System
• Existential QoS for Storage
• Postmortem Object Type Identification
• Dynamic Instrumentation of Production Systems
• FireEngine - A New Networking Architecture for the Solaris Operating System

[musical recommendations: we will not bother with the obvious, even if it is beatles. so it is a toss up between joss stone's the soul sessions and talking heads' sand in the vaseline, depending on the mood.]

[2006.03.06: added a few more papers.]

[2006.03.08: Gary Riseborough kindly supplied some of the missing links. thanks gary.]

[2006.03.09: added bmc's type ident paper]

Sunday February 27, 2005

sound of ipod: a story of reverse engineering

here is a really neat bit of ipod reverse engineering and seth david schoen's good discussion. [thanks peter!]

(2005-02-27 09:36:32.0) Permalink Comments [0]

Tuesday February 22, 2005

lenstra: all new designs should use SHA-256...

just ran into a new paper by arjen lenstra, now at bell labs: further progress in hashing cryptanalysis. abstract:

Until further notice, all new designs should use SHA-256. Existing systems using SHA1 or MD5 should confirm that they only need second pre-image resistance, not random collision resistance. Usage of MD5 in certificates should be discontinued unless the presence of adequate mitigating controls has been verified.

also includes a sketch of antonie joux's result about the concatenation of hash functions.

[musical recommendation while reading about the future of sha-N where N is 224/256/384/512: Trio - Mozart: The Late Symphonies (etc) / Bernstein, Vienna Philharmonic, 3cd set, Deutsche Grammophon. these Trio editions are a remarkable and affordable gift to classical music lovers.]

[surprising that this paper was not slash-blotted, not that it matters anymore]

(2005-02-22 10:45:51.0) Permalink Comments [1]

Wednesday February 16, 2005

alan kay in conversation

an interesting conversation with alan kay. here are some notes, re/paraphrased sentences or full quotes. marginal notes in [] brackets.

-----

kay repeats a strange land claim and mentions hewitt's "wonderful" (but mostly paper) planner as a "predecessor" to prolog. [similar but funnier version of this claim can be found in a SICP (steele/sussman) footnote.] here is a bit of history from Colmerauer and Roussel's The Birth of Prolog:

While attending an IJCAI convention in September ‘71 with Jean Trudel, we met Robert Kowalski again and heard a lecture by Terry Winograd on natural language processing. The fact that he did not use a unified formalism left us puzzled. It was at this time that we learned of the existence of Carl Hewitt’s programming language, Planner [Hewitt, 1969]. The lack of formalization of this language, our ignorance of Lisp and, above all, the fact that we were absolutely devoted to logic meant that this work had little influence on our later research.

very odd (be polite) commentary about "lack of software engineering" in the current pop culture. mention of low-pass filters; one cannot help but wonder about the density of his filter.

-----

early-binding languages lock you into stuff you've already done. you cannot reformulate things easily. [not clear what he means by "reformulate." what about early-binding OO languages? bertrand meyer would be dismayed]

a benchmark from 1979 Xerox PARC runs only 50 times faster today. [should be 40,000 to 60,000] a factor of 1,000 in efficiency has been lost by bad CPU architectures. [hah. time to dust off those old compilers and benchmarks.]

a lot of the success of various programming languages is expeditions gap-filling. Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term.

[smalltalk, lisp] have so many ways of dealing with problems that the early-binding languages don't have, that it's very, very difficult for people who like lisp or smalltalk to imagine anything else.

if the pros at Sun had had a chance to fix Java, the world would be a much more pleasant place. [Kay needs to say more, but does not]

most undergraduate degrees in computer science these days are basically Java vocational training.

you have to be a different kind of person to love C++.

the agglutinative languages tend to produce agglutinations and they are very, very difficult to untangle when you've had a new idea.

all creativity is an extended form of a joke. most creativity is a transition from one context into another where things are more surprising. there is an element of surprise, and especially in science, there is often laughter that goes along with the "Aha."

-----

ag·glu·ti·na·tive (adj)
1. adhesive
2. characterized by linguistic agglutination

ag·glu·ti·nate (v)
from latin agglutinatus, past participle of agglutinare to glue to, from ad- + glutinare to glue, from glutin-, gluten glue

(2005-02-16 18:57:49.0) Permalink Comments [0]

Thursday February 10, 2005

fdlibm, kahan paper etc.

sometimes things get too indirect for me. i was reminded of the great and free SUN fdlibm library through an interesting, if heavy recent paper (in progress) by kahan (thanks henry): How Futile are Mindless Assessments of Roundoff in Floating-Point Computation?

[i am not an FP geek, i hardly write any FP code, but as an educated programmer, i try to follow his arguments. his engineering perspectives and his relentless critique of mediocre implementations in the industry make kahan papers great fun to read.]

kahan quotes from this and other papers:

The longevity of inaccuracies in numerical software by and for numerical adepts has ominous implications: Numerical software does not have to be very complicated to be difficult to debug by experts, practically impossible to debug by amateurs.

Name-calling makes the caller feel better without enlightening him.

The essence of civilization is that we benefit from others' experience without having to relive it.

What runs too slowly won't get run.

If we keep no records of our mistakes, how can we learn to avoid more of them?

[music suggestion while reading kahan papers: donald byrd at the half note cafe volumes 1 & 2, blue note RVG edition.]

(2005-02-10 20:15:24.0) Permalink Comments [0]

Thursday January 20, 2005

papers in the pile: misuse of rc4, boehm on threads, etc

henry spencer forwarded this neat boehm paper: threads cannot be implemented as a library, HP tech report 2004-209.

from schneier's blog: The misuse of RC4 in microsoft word and excel. (ahahahahaha)

moffat and zobel, what does it mean to "measure performance"? (slides)

[moffat & zobel paper is especially important to me, because i am involved in performance measurement. In this paper, the notion of "experiment" is explored [...] Our intention is, as a case study, to explore the rigor that we believe is necessary in experimental computer science, in the hope that the lessons learnt in our experiments will be helpful to others.]

(2005-01-20 06:50:28.0) Permalink