Jason's Recent Weblog Entries

Running out of Time aka "Clock-Flew"
If you're running FreeBSD 5.2 on older hardware and find that the system clock is gaining from 1-3 seconds per second, take a look at the possible values for kern.timecounter.hardware. In particular, I needed

kern.timecounter.hardware=TSC

Category: /it           permanent link

vCheck Initial Release
I have put together a simple tool called vCheck which can probe a network service such as smtp or ssh and report whether or not the software running that service (e.g., Sendmail, OpenSSH) is up to date.

Category: /it           permanent link

DNS Turns 20, and some thoughts on DNS reliability and security
See my newly-posted introductory essay on the Domain Name System. This writing was occasioned by the 20th anniversary of DNS, and is just the start of a larger piece.

Category: /it           permanent link

Longhorn and the end of Taxonomy
I've always had a deep interest in file systems, and I'm particularly interested in "database-ish" filesystems such the future reiser FS and Microsoft's "WinFS". But I have to disagree with the boosterish conclusions of this recent "preview" of Longhorn/WinFS. I don't believe that database mechanisms will eliminate the need for directories and folders any more than automated card catalogs have obsoleted librarians or Google has obsoleted good web site design. Taxonomy, the art and science of classification, is a hard problem which will continue to demand human attention for many years to come.

Category: /it           permanent link

With One Arm Tied Behind Their Backs

The web and the Internet have been so successful (and so hyped) that they eclipsed all other kinds of software development. In that eclipse, we've lost sight of some of the things we learned about human-computer and programmer-computer interaction in the dawn of the PC era. History tends to repeat itself in the computer industry. Given that as a starting point, how can we expect the web to change over the coming decade?

First, what's wrong with the web at all? Operationally, the web uses a rigid request-response-display cycle with response times running to the seconds or tens of seconds. Design-wise, user interface elements are limited by the restrictions of HTML. The user experience of a web site shares more with minicomputer/mainframe "green screen" terminals than it does with the any modern graphical user interface: A panel (web page) is presented to the user, the user fills in or selects fields, a request is sent off to a server in the sky, and at some point a response is returned and painted onto the screen.

I'll elaborate on some of the consequences of this model:

• Usability has taken a big hit: HTML doesn't offer the rich set of tools and opportunities for feedback, reactivity, and careful formatting which a good user-interface design depends upon. Add-ons like Flash and client-side Java and modern versions of HTML (DHTML, CSS, etc.) offer relatively minor improvements but suffer from many incompatibilities limiting widespread use and in any case do not change the request-response-display cycle.
  
  
• Interactive response times have soared: Waiting taxes the attention span and forces us to multitask to retain efficiency when we might be better off focusing on the task at hand until it is completed. One widely-cited IBM study from 1982 found that reducing one particular system's response time from 3 seconds to 0.3 seconds resulted in a 100% increase in human productivity using the system. Another, more recent study found the same thing. And while both studies used programming tasks, I think we can apply those results generally. Notice that even the longer, 3 second, response time would be considered "quick" on the web! (other good references here)
  
  
• Persistance of interaction (and the lack of it) has hurt programmer productivity: The "stateless" request architecture of the web is great for fault recovery and simplifies the protocol considerably. However it makes a web programmer's job harder because it requires otherwise continuous processes to be broken up into many tiny chunks. This cuts programmer productivity and continues to be the source of many security and reliability problems today.

... to be continued ...

- why the web is a *good* applications platform after all
- when client software might nonetheless be a better choice
- explain the impact of XML on enabling better client-software connectivity and helping bridge the gap between fully-connected web applications and fully disconnected browser-based apps
- what does this suggest for future applications development?
- what am I doing now along these lines?

Category: /it           permanent link