I'm wondering about VBI/CC support in the new SDK. If it's possible to grab raw VBI data from, say,/dev/vbi (or parsed text CC data from somewhere else), I'd be really interested in buying several of these devices and doing some hacking to integrate them into the video cluster work we've been doing.
A quick grep of the source suggests that VBI chunks are getting passed through to v4l2. Is this supposition correct, and has parsing CC out of the VBI stream been something that any folks (inside or outside of Plextor) have implemented/tested much?
I was at the oral arguments this morning, and
since I have press credentials, I was able to
take lots of notes.
My summary
tries to cover all of the main points the Justices raised in their questioning of both sides.
I was a bit discouraged by how
much attention the Justices paid to problems
with Lessig's Article I arguments, and how
little -- none at all -- they paid to the claim
he makes in the brief (and mentioned briefly
during the questioning) that the birth of a new technology
regime (the Internet) should have a profound
impact on how we craft copyright law.
I don't think there's much grounds for
guessing which way the court will go on this
case. Certainly the people in the pressroom and
in the lawyers' lounge today weren't making
many predictions. Lessig's argument is so
narrowly constructed, and the copyright clause of
the constitution is both so clear in intent and
non-specific in its wording, that the court
really could go either way. Certainly four
justices had to think the possibility is there
to decide for the petitioners
or the Court wouldn't have taken the case.
But there was a lot of hard questioning of
Lessig, today, and I didn't think he was
able to definitively reframe any of the
issues that the Justices were concerned about.
There have been a lot of thoughtful comments on this story. It's
true that Zimbabwe's immediate economic problems -- plumeting
agricultural production, inflation, industrial collapse, an exodus of
skilled workers -- are the result of a corrupt and repressive regime
that is determined to hold onto power at all costs. But it's also
worth considering how difficult it would be to solve the country's
problems even were a democratic and functional government in
place.
Like most African countries, Zimbabwe's foreign debt load is
enormous (US$1 billion; the country has a GDP of roughly US$5
billion). Even if the country were to somehow turn itself around and
bring production back up to pre-turmoil levels, the debt ratio is
almost unbelievable. And the country has been terribly affected by the
AIDS epidimic. It is estimated that one quarter of the adult
population is infected with HIV/AIDS. There are predictions that
within a decade, half of Zimbabwe's children will be orphans.
And what do you do about land ownership? The violence against
white farmers is indefensible, and Mugabe's cynical manipulation of
that violence is vile. But the problem is serious. At independence (in
1980), perhaps half the country's farm land was owned by 1% of the
population. These (white) farmers had been on the land for
generations, and believed that the land belonged to them -- legally,
morally, emotionally. But this economically- and racially-skewed
distribution didn't come about by accident. The colonial government
systematically expropriated and "re-settled" the "native"
population. Most of this redistribution happened this century, so
we're not talking about ancient history, here. And even if you choose
not to think about the problem in historical terms, how do you build a
free and egalitarian society in an agricultural economy with such
unequal land ownership?
I work at allAfrica.com. We distribute news about Africa, most of
it from African newspapers and magazines. If you want to understand
what's going on in a country, it's worth reading the local press
occasionally. We have half a dozen Zimbawean papers, from across the
political spectrum. (Which is a polite way of saying that one of them
is controlled by the ruling party. We don't make judgements about a
newspaper's integrity; we try to get as many "read-on-the-street"
papers as possible and let readers make their own judgements.)
You can take a look at our Zimbabwe
headlines page. Here are some stories relating to the issues I've mentioned:
XML::Comma -- a perl-based framwork
on
Zope or Cocoon 2?
·
· Score: 2, Informative
I'm one of the developers on a GPL'ed, perl-based XML
web-app framework. It's called XML::Comma, and
the basic idea is to provide an abstraction
that make it easy to deal with very large collections of
structured information -- particularly
in a web-development context.
XML::Comma is the platform for allAfrica.com and for
www.democrats.org. Both of those sites
have "document collections" numbering in the
hundreds of thousands. (For AllAfrica the
most complex part of the job is managing
a news-feed that pushes 500 stories a day
through the system into an archive of 300,000
articles. For democrats.org the problems
revolve more around user-customization and
credit-card transaction processing. Very
different systems, but the Comma API tries
to expose a unified set of tools for
dealing with both, and more besides.)
Zope is great, AxKit is great. Cocoon is
great too, although my personal opinion is
that there's a lot more "friction" when
developing in Java than in Perl and Python.
Sometimes certain kinds of friction are
helpful: for large teams of
only-moderately-experienced
programmers, for example, Java's static
typing can help you hold the chaos at bay. But
in lots of web-systems-development contexts the
emphasis is on getting new sets of features
built as quickly as possible, and there's
a strong pressure to be in "permanent protyping"
mode. You can prototype a lot faster in Perl
or Python than in Java, and experienced
programmers can write clean, self-documenting
stable code without static typing and
a Beans API.
The XML::Comma website is
xml-comma.org.
There's an in-depth user's guide there.
Check it out and let us know what you think.
> Perl is for system administrators and system
> administrators-cum-developers, not real
> software development. Look at java. Look at
> PHP.
Mmmm. I write large-scale web applications for a living, and I do it in Perl. By large-scale, I mean sites that are expected to support hundreds of thousands of page-views per day, serve hundreds of thousands of distinct users per month, and collate hundreds of thousands of distinct chunks of content into dynamic pages.
My company is a high-end development shop. We generally bid on projects that will take six to nine months to complete, and we only do jobs for clients who understand how we work and why. Part of our approach is to use very small teams of extremely experienced web developers. We usually deploy four programmers on a project. Other companies that bid against us sometimes use several times that many people on a single development team. Another part of our approach is to build everything on top of our open-source development framework. That sometimes used to be a tough sell ("what, give software away for free, heaven forfend") but these days, most customers are pretty receptive to the twin "more eyeballs means better code" and "you're not locked into our closed, proprietary product" arguments.
We also generally build small clusters of dual-processor Athlon or PIII machines, whereas our Java- (Oracle-, IBM -, BEA-, etc) wielding colleagues often specify absurdly-expensive hardware.
Perl is flexible, complete, performs relatively well and has an extroardinary base of skilled developers and re-usable components (CPAN). We couldn't work as quickly or write code that is as concise and maintainable using any other currently-available language/approach. Most of the lines of code that we write actually go into Perl modules, with HTML::Mason templates handling the dynamic web-page generation. We can push Mason out of the way and use straight mod_perl for small, defined tasks. And we can easily integrate C code into our Perl frameworks in places where performance is really, really critical (though those places are rare, as when push comes to shove, one is almost always waiting on the database).
There are lots of things that aren't "right" about web development. The package that results from gluing HTML and program logic together in a stateless execution environment is sometimes a little lumpy, and unavoidably so. There's no magic bullet toolkit, and (as with other specialized programming arenas, like graphics or embedded systems) a lot of hard-won, domain-specific knowledge goes into the development of a fast, reliable, maintainable web app.
The Perl/Apache/Mason combination that we use is far from perfect. But it's better -- for us -- than any of the alternatives.
I really like Java, and have written big systems in that language, too. If for some reason I had to manage a very large team of programmers, or had to manage a team with a large percentage of less-experienced programmers, I would use a Java-based solution. Java is a more rigid language than Perl, and the structure that the language provides would be a useful management tool in those contexts. But for my small teams of skilled hackers, Perl is more productive. (We have an extensive, evolved, self-imposed "structure," so we don't need the language to impose one on us -- in fact, it gets in the way.)
I would never use PHP for the kind of work we do. PHP just isn't the kind of powerful, flexible, complete environment that Perl is.
Zope and Python are really neat. I'm a fan of the work that folks on that side of the fence are doing. But Python+Zope don't offer us anything new that Perl+Mason+Comma don't. I also like Perl more than Python (which is a subjective preference), and think that the Perl development environment is more mature (which is a subjective judgment).
So don't listen to the folks who tell you to dump Perl. You should certainly consider all of your options and make an informed decision about core tools, but anyone who thinks that Perl is just a "scripting" language, or that it doesn't scale, hasn't been paying attention.
To finish this up with a little more specific advice to the original poster: You mentioned "150+ perl CGIs" in your question. You should consider moving away from the CGI model, if possible. Take a look at HTML::Mason, which is a very good embedded-perl environment. You can build solid, consistent application layers using Mason as a base. Also, I couldn't agree more with the folks recommending writing perl modules and requiring complete regression tests for each module. There are lots of ways to write tests, but in perl-land one of the easiest is to simply make a t/ directory down your module tree, write a bunch of scripts in that directory named <some-test>.t that print out a series of "ok <n>\n" lines, and use make test or Test::Harness::runtests() to invoke them.
I would agree with the posters who have recommended HTML::Mason
(http://www.masonhq.com). Here's why:
You can't have everything. For a given amount of money spent on
web-server hardware, you can balance some combination of 1) fast, 2)
dynamic, and 3) maintainable/extensible. For most software development
work, the third consideration is by far the most important. And even
for situations where efficiency is critical and labor is cheap, the
third consideration is still the most important <laugh>.
HTML::Mason is the best of the present possible worlds. Its
"component"-based system lets you build extremely, granularly dynamic
web sites. Code reuse is so simple and natural that you might even
find yourself practicing it. And you can do anything from Mason that
you can from Perl, so there's no lack of power or flexibility.
And Mason has a big advantage over ([most/all]?) other embedded
perl solutions: pretty good built-in cache control. Even if you don't
care about maintainability, there's still an inherent trade-off
between serving pages quickly and serving them dynamically. The only
practical way to turn the knob on this trade-off is to do some kind of
caching -- preferably in a highly configurable fashion. Mason does per-page and per-component caching with a
few (relatively) simple calls.
Benchmarks are only useful if they approximate your usage patterns
pretty exactly, and there are almost certainly no such benchmarks out
there that will satisfy you. The consensus on the Mason list is that Mason
pages will serve about 2-3 times slower than similar pages coded in
straight mod_perl. That speed difference is way, way, way more than
made up for in efficiency of development (which includes things like the edit/test cycle, minimized debugging, code reuse, etc).
And other than caching, there's very little Mason-specific
performance tuning. Most everything you do to make Mason run well is
really an effort at making mod_perl run well. Once you have a nice,
two-tier mod_perl system set up, and are caching as many Mason
components (or pages) as is practical, you are, in my experience, much
more likely to be running short of memory than running out of CPU. We
serve about 200,000 Mason page-views per day from each of our 1G of
ram, dual PIII-750 boxen. We cache almost all of our pages at the
whole-page level for at least 30 seconds at a time, but we do serve a
fair number of entirely-dynamic or heavily-customized pages. And we
only bog down our processors when users do lots of archival searching,
which unfortunately isn't something we can blame Mason for.
The xmodmap extensions to XFree can be extensively customized, although there's not much documentation around about how to do so.
The critical command is 'xkbcomp', which lets you dump, compile, and activate keyboard rulesets.
My right-hand problems relate almost entirely to the clicking, not to the moving, of the the rodent, so I've mapped four buttons on my Goldtouch keyboard to:
Pointer_EnableKeys - Toggles mouse emulation mode so that the relevant keys can send mouse events.
Pointer_Button1 - Sends a button one click event.
Pointer_Button2 - Sends a button two click event.
Pointer_Drag_Dflt - Toggles down/up state of default button, for dragging (always button one for me).
The most important lines in my.xkb file are the following: key <NMLK> { [ Pointer_Drag_Dflt ] }; key <SCLK> { [ Pointer_EnableKeys ] }; key <INS> { [ Pointer_Button1 ] }; key <DELE> { [ Pointer_Button2 ] };
Combined with lots of keyboard shortcuts for WindowMaker, this fix has basically eliminated all of my right-hand problems. My left ulnar (pinky to elbow) problems have proved much less tractable, unfortunately.
Neil Stephenson sure seems like a hacker to me. He describes himself in the "Command Line" essay as a long-time Mac programmer, and writes that he's been a Linux user since 1995. (Not to mention his mention that he acquired one of the first BeBoxen, which we can assume he didn't buy under the illusion that he was getting a better television-typewriter on which to peck out his novels.)
He wrote the best article ever to appear in Wired Magazine (okay, so maybe that's a low bar; how about "probably the best major-publication tech article I've read"), which is about the whos/hows/whys of large-scale fiber projects. That article demonstrated Stephenson's firm grasp of the technical -- in addition to the social and historical -- issues at hand. ("Mother Earth Mother Board." Cover story for December 1996, http://www.wired.com/wired/archive/4.12/ffglass.ht ml)
Finally, and to me most importantly, Stephenson's two novels that revolve around digital technologies and information manipulation ring unfailingly true, from the throwaway descriptions of how programming works (Hiro in the lifeboat building a motorcycle mostly by taking bits and pieces of old code and repurposing them), to effortless explanation of means and mechanism (the dog with an atavistic protect-the-boy impulse inside a crenellated, heat-diffusing body; Nell's book creating Turing World for her), to large-scale examination of the idea that computers offer us powerful new ways to conceptualize that activity which most defines and shapes us as humans, the manipulation of abstract symbols (the Babylonian/ur-language theme of _Snow Crash_; the info/bio/nano-tech merging conceit in _The Diamond Age_.)
All three of the above strengths were sadly lacking in, for example, "The Matrix," which was much and loudly praised here.
As eagerly as I await my copy of _Cryptonomicon_, I would be even more interested to learn that a collection of Stephenson non-fiction was in the offing. My favorite part of "Command Line" was actually the short digression about Disney World. I'm betting there's a draft of something as amazing as the DFW "E Unibus Plurum" essay that Stephenson cites somewhere on one of his (many) hard drives.
Slashdot Mirror
Thanks! I'll order a couple of the M402U units and then maybe try to help hack VBI support into the driver.
I'm wondering about VBI/CC support in the new SDK. If it's possible to grab raw VBI data from, say, /dev/vbi (or parsed text CC data from somewhere else), I'd be really interested in buying several of these devices and doing some hacking to integrate them into the video cluster work we've been doing.
A quick grep of the source suggests that VBI chunks are getting passed through to v4l2. Is this supposition correct, and has parsing CC out of the VBI stream been something that any folks (inside or outside of Plextor) have implemented/tested much?
I was at the oral arguments this morning, and since I have press credentials, I was able to take lots of notes.
My summary tries to cover all of the main points the Justices raised in their questioning of both sides.
I was a bit discouraged by how much attention the Justices paid to problems with Lessig's Article I arguments, and how little -- none at all -- they paid to the claim he makes in the brief (and mentioned briefly during the questioning) that the birth of a new technology regime (the Internet) should have a profound impact on how we craft copyright law.
I don't think there's much grounds for guessing which way the court will go on this case. Certainly the people in the pressroom and in the lawyers' lounge today weren't making many predictions. Lessig's argument is so narrowly constructed, and the copyright clause of the constitution is both so clear in intent and non-specific in its wording, that the court really could go either way. Certainly four justices had to think the possibility is there to decide for the petitioners or the Court wouldn't have taken the case. But there was a lot of hard questioning of Lessig, today, and I didn't think he was able to definitively reframe any of the issues that the Justices were concerned about.
The government of Zimbabwe has agreed to accept the corn, with the proviso that it be milled either before being shipped, or immediately on arrival.
AllAfrica story
Financial Gazette story
There have been a lot of thoughtful comments on this story. It's true that Zimbabwe's immediate economic problems -- plumeting agricultural production, inflation, industrial collapse, an exodus of skilled workers -- are the result of a corrupt and repressive regime that is determined to hold onto power at all costs. But it's also worth considering how difficult it would be to solve the country's problems even were a democratic and functional government in place.
Like most African countries, Zimbabwe's foreign debt load is enormous (US$1 billion; the country has a GDP of roughly US$5 billion). Even if the country were to somehow turn itself around and bring production back up to pre-turmoil levels, the debt ratio is almost unbelievable. And the country has been terribly affected by the AIDS epidimic. It is estimated that one quarter of the adult population is infected with HIV/AIDS. There are predictions that within a decade, half of Zimbabwe's children will be orphans.
And what do you do about land ownership? The violence against white farmers is indefensible, and Mugabe's cynical manipulation of that violence is vile. But the problem is serious. At independence (in 1980), perhaps half the country's farm land was owned by 1% of the population. These (white) farmers had been on the land for generations, and believed that the land belonged to them -- legally, morally, emotionally. But this economically- and racially-skewed distribution didn't come about by accident. The colonial government systematically expropriated and "re-settled" the "native" population. Most of this redistribution happened this century, so we're not talking about ancient history, here. And even if you choose not to think about the problem in historical terms, how do you build a free and egalitarian society in an agricultural economy with such unequal land ownership?
I work at allAfrica.com. We distribute news about Africa, most of it from African newspapers and magazines. If you want to understand what's going on in a country, it's worth reading the local press occasionally. We have half a dozen Zimbawean papers, from across the political spectrum. (Which is a polite way of saying that one of them is controlled by the ruling party. We don't make judgements about a newspaper's integrity; we try to get as many "read-on-the-street" papers as possible and let readers make their own judgements.)
You can take a look at our Zimbabwe headlines page. Here are some stories relating to the issues I've mentioned:
You mention the interfaces in Minority Report...
That stuff was done by this guy. His non-movie work is perhaps even cooler,
given the constraints of building things that actually work:
Luminous Room
I'm one of the developers on a GPL'ed, perl-based XML web-app framework. It's called XML::Comma, and the basic idea is to provide an abstraction that make it easy to deal with very large collections of structured information -- particularly in a web-development context.
XML::Comma is the platform for allAfrica.com and for www.democrats.org. Both of those sites have "document collections" numbering in the hundreds of thousands. (For AllAfrica the most complex part of the job is managing a news-feed that pushes 500 stories a day through the system into an archive of 300,000 articles. For democrats.org the problems revolve more around user-customization and credit-card transaction processing. Very different systems, but the Comma API tries to expose a unified set of tools for dealing with both, and more besides.)
Zope is great, AxKit is great. Cocoon is great too, although my personal opinion is that there's a lot more "friction" when developing in Java than in Perl and Python. Sometimes certain kinds of friction are helpful: for large teams of only-moderately-experienced programmers, for example, Java's static typing can help you hold the chaos at bay. But in lots of web-systems-development contexts the emphasis is on getting new sets of features built as quickly as possible, and there's a strong pressure to be in "permanent protyping" mode. You can prototype a lot faster in Perl or Python than in Java, and experienced programmers can write clean, self-documenting stable code without static typing and a Beans API.
The XML::Comma website is xml-comma.org. There's an in-depth user's guide there. Check it out and let us know what you think.
Mmmm. I write large-scale web applications for a living, and I do it in Perl. By large-scale, I mean sites that are expected to support hundreds of thousands of page-views per day, serve hundreds of thousands of distinct users per month, and collate hundreds of thousands of distinct chunks of content into dynamic pages.
My company is a high-end development shop. We generally bid on projects that will take six to nine months to complete, and we only do jobs for clients who understand how we work and why. Part of our approach is to use very small teams of extremely experienced web developers. We usually deploy four programmers on a project. Other companies that bid against us sometimes use several times that many people on a single development team. Another part of our approach is to build everything on top of our open-source development framework. That sometimes used to be a tough sell ("what, give software away for free, heaven forfend") but these days, most customers are pretty receptive to the twin "more eyeballs means better code" and "you're not locked into our closed, proprietary product" arguments.
We also generally build small clusters of dual-processor Athlon or PIII machines, whereas our Java- (Oracle-, IBM -, BEA-, etc) wielding colleagues often specify absurdly-expensive hardware.
Perl is flexible, complete, performs relatively well and has an extroardinary base of skilled developers and re-usable components (CPAN). We couldn't work as quickly or write code that is as concise and maintainable using any other currently-available language/approach. Most of the lines of code that we write actually go into Perl modules, with HTML::Mason templates handling the dynamic web-page generation. We can push Mason out of the way and use straight mod_perl for small, defined tasks. And we can easily integrate C code into our Perl frameworks in places where performance is really, really critical (though those places are rare, as when push comes to shove, one is almost always waiting on the database).
There are lots of things that aren't "right" about web development. The package that results from gluing HTML and program logic together in a stateless execution environment is sometimes a little lumpy, and unavoidably so. There's no magic bullet toolkit, and (as with other specialized programming arenas, like graphics or embedded systems) a lot of hard-won, domain-specific knowledge goes into the development of a fast, reliable, maintainable web app.
The Perl/Apache/Mason combination that we use is far from perfect. But it's better -- for us -- than any of the alternatives.
I really like Java, and have written big systems in that language, too. If for some reason I had to manage a very large team of programmers, or had to manage a team with a large percentage of less-experienced programmers, I would use a Java-based solution. Java is a more rigid language than Perl, and the structure that the language provides would be a useful management tool in those contexts. But for my small teams of skilled hackers, Perl is more productive. (We have an extensive, evolved, self-imposed "structure," so we don't need the language to impose one on us -- in fact, it gets in the way.)
I would never use PHP for the kind of work we do. PHP just isn't the kind of powerful, flexible, complete environment that Perl is.
Zope and Python are really neat. I'm a fan of the work that folks on that side of the fence are doing. But Python+Zope don't offer us anything new that Perl+Mason+Comma don't. I also like Perl more than Python (which is a subjective preference), and think that the Perl development environment is more mature (which is a subjective judgment).
So don't listen to the folks who tell you to dump Perl. You should certainly consider all of your options and make an informed decision about core tools, but anyone who thinks that Perl is just a "scripting" language, or that it doesn't scale, hasn't been paying attention.
To finish this up with a little more specific advice to the original poster: You mentioned "150+ perl CGIs" in your question. You should consider moving away from the CGI model, if possible. Take a look at HTML::Mason, which is a very good embedded-perl environment. You can build solid, consistent application layers using Mason as a base. Also, I couldn't agree more with the folks recommending writing perl modules and requiring complete regression tests for each module. There are lots of ways to write tests, but in perl-land one of the easiest is to simply make a t/ directory down your module tree, write a bunch of scripts in that directory named <some-test>.t that print out a series of "ok <n>\n" lines, and use make test or Test::Harness::runtests() to invoke them.
I would agree with the posters who have recommended HTML::Mason (http://www.masonhq.com). Here's why:
You can't have everything. For a given amount of money spent on web-server hardware, you can balance some combination of 1) fast, 2) dynamic, and 3) maintainable/extensible. For most software development work, the third consideration is by far the most important. And even for situations where efficiency is critical and labor is cheap, the third consideration is still the most important <laugh>.
HTML::Mason is the best of the present possible worlds. Its "component"-based system lets you build extremely, granularly dynamic web sites. Code reuse is so simple and natural that you might even find yourself practicing it. And you can do anything from Mason that you can from Perl, so there's no lack of power or flexibility.
And Mason has a big advantage over ([most/all]?) other embedded perl solutions: pretty good built-in cache control. Even if you don't care about maintainability, there's still an inherent trade-off between serving pages quickly and serving them dynamically. The only practical way to turn the knob on this trade-off is to do some kind of caching -- preferably in a highly configurable fashion. Mason does per-page and per-component caching with a few (relatively) simple calls.
Benchmarks are only useful if they approximate your usage patterns pretty exactly, and there are almost certainly no such benchmarks out there that will satisfy you. The consensus on the Mason list is that Mason pages will serve about 2-3 times slower than similar pages coded in straight mod_perl. That speed difference is way, way, way more than made up for in efficiency of development (which includes things like the edit/test cycle, minimized debugging, code reuse, etc).
And other than caching, there's very little Mason-specific performance tuning. Most everything you do to make Mason run well is really an effort at making mod_perl run well. Once you have a nice, two-tier mod_perl system set up, and are caching as many Mason components (or pages) as is practical, you are, in my experience, much more likely to be running short of memory than running out of CPU. We serve about 200,000 Mason page-views per day from each of our 1G of ram, dual PIII-750 boxen. We cache almost all of our pages at the whole-page level for at least 30 seconds at a time, but we do serve a fair number of entirely-dynamic or heavily-customized pages. And we only bog down our processors when users do lots of archival searching, which unfortunately isn't something we can blame Mason for.
Yours,
Kwindla
The critical command is 'xkbcomp', which lets you dump, compile, and activate keyboard rulesets.
My right-hand problems relate almost entirely to the clicking, not to the moving, of the the rodent, so I've mapped four buttons on my Goldtouch keyboard to:
- Pointer_EnableKeys - Toggles mouse emulation mode so that the relevant keys can send mouse events.
- Pointer_Button1 - Sends a button one click event.
- Pointer_Button2 - Sends a button two click event.
- Pointer_Drag_Dflt - Toggles down/up state of default button, for dragging (always button one for me).
The most important lines in mykey <NMLK> { [ Pointer_Drag_Dflt ] };
key <SCLK> { [ Pointer_EnableKeys ] };
key <INS> { [ Pointer_Button1 ] };
key <DELE> { [ Pointer_Button2 ] };
Combined with lots of keyboard shortcuts for WindowMaker, this fix has basically eliminated all of my right-hand problems. My left ulnar (pinky to elbow) problems have proved much less tractable, unfortunately.
- Kwin
Neil Stephenson sure seems like a hacker to me. He describes himself in the "Command Line" essay as a long-time Mac programmer, and writes that he's been a Linux user since 1995. (Not to mention his mention that he acquired one of the first BeBoxen, which we can assume he didn't buy under the illusion that he was getting a better television-typewriter on which to peck out his novels.)
t ml)
He wrote the best article ever to appear in Wired Magazine (okay, so maybe that's a low bar; how about "probably the best major-publication tech article I've read"), which is about the whos/hows/whys of large-scale fiber projects. That article demonstrated Stephenson's firm grasp of the technical -- in addition to the social and historical -- issues at hand. ("Mother Earth Mother Board." Cover story for December 1996, http://www.wired.com/wired/archive/4.12/ffglass.h
Finally, and to me most importantly, Stephenson's two novels that revolve around digital technologies and information manipulation ring unfailingly true, from the throwaway descriptions of how programming works (Hiro in the lifeboat building a motorcycle mostly by taking bits and pieces of old code and repurposing them), to effortless explanation of means and mechanism (the dog with an atavistic protect-the-boy impulse inside a crenellated, heat-diffusing body; Nell's book creating Turing World for her), to large-scale examination of the idea that computers offer us powerful new ways to conceptualize that activity which most defines and shapes us as humans, the manipulation of abstract symbols (the Babylonian/ur-language theme of _Snow Crash_; the info/bio/nano-tech merging conceit in _The Diamond Age_.)
All three of the above strengths were sadly lacking in, for example, "The Matrix," which was much and loudly praised here.
As eagerly as I await my copy of _Cryptonomicon_, I would be even more interested to learn that a collection of Stephenson non-fiction was in the offing. My favorite part of "Command Line" was actually the short digression about Disney World. I'm betting there's a draft of something as amazing as the DFW "E Unibus Plurum" essay that Stephenson cites somewhere on one of his (many) hard drives.