BSD Unix: Power to
the people, from the code
How Berkeley hackers built the
Net's most fabled free operating system on the ashes of the '60s -- and
then lost the lead to Linux.
By Andrew
Leonard
期限付手形喜びによって、
大学院に通うために1975年に、
バークレー(カリフォルニア)に着いた、
左翼急進主義の伝説的な中心地は、
端のまわりで少しからかわれました。
21年来のプログラミング神童が、
ローカルの代替のweekliesから爆破するヘッドラインをちらりと見た場合、
彼は何種類の狂気の混乱に彼自身を入れたかとちょうど思ったかもしれません。
サンフランシスコでは、
パティー・ハーストが、
新聞相続人がシンビオン解放軍の解放軍隊のための機関銃を携帯していた間に
犯された銀行強盗に対する審理中でした。
オークランドでは、天候地下が、国防省の建物の爆撃をやり損ないました。
カリフォルニアのバークレー・キャンパスの大学上のCIAの新人募集の
信頼できるお化けさえ、印抗議を越えるものを生成しませんでした。
Berkeley was burned out, its radical energy wasting away in infantile
terrorism, conspiracy theorizing and drug overdoses. The
Free Speech Movement
that had galvanized
the university in the '60s belonged to another geological age. Ken
Thompson, co-creator of the Unix operating system, graduated from Berkeley
in 1966 with a degree in electrical engineering. He returned to the
university from Bell Labs for a sabbatical in 1975. But the campus on
which he had once walked to class through clouds of tear gas had changed.
That year, says Thompson, Berkeley "had turned into the most politically
apathetic place I'd seen."
バークレーは燃え尽きました
(幼児のテロリズムで衰えて、(共謀)理論付けて、
薬過剰服用その根本的なエネルギー)。
刺激を与えた言論の自由移動 '60年代の大学は別の地質時代に属しました。
ケン・トムプソン(Unixオペレーティング・システムの共同創造者)は、
電気工学中の程度を持った1966年のバークレーを卒業しました。
彼はベル研究所から大学に1975年に一年間の有給休暇のために戻りました。
しかし、彼が以前持っていたキャンパスは催涙ガスの雲によって
分類するために歩きました、変わりました。
その年、トムプソンは言う、
バークレーは「私が見た最も政治的に無感覚の適所へ乗り入れた。」
But it was the right place for Joy. "He never looked at those
[alternative] papers," says John Gage, a close friend of Joy's during the
Berkeley years and later at Sun Microsystems, a company co-founded by Joy.
Today, Joy calls himself a "staunch Democrat" and has recently carved out
a new niche as a techno-skeptical
doomsayer,
but in the '70s he was, by his own description, "not an activist." Joy chose
to attend UC-Berkeley instead of Stanford or MIT not because he was
attracted by its politics or countercultural reputation but because the
computer science department's hardware was so obsolete that he figured
he'd have no choice but to confine his research efforts to studying
computing theory -- which was exactly what he wanted to do.
しかし、それは喜びに適切な場所でした。
「彼はそれらの[選択肢]紙を見ませんでした」
とジョン・ゲージ
(バークレーの年中の、およびその後サン・マイクロシステムズ
(喜びによって共同設立された会社)の喜びの親しい支持者)が言います。
今日、喜びは彼自身を「信頼できる民主党員」と呼び、
テクノ懐疑的な災厄予言者として最近新しい地位を開拓しました、
しかし、'70年代に、彼は自分の記述によりました、「ない、活動家。」
喜びは、彼がその政治か反文化的な評判によって引きつけられたのでではなく、
電子計算機科学部のハードウェアが非常に旧式だったので、
計算する理論(それはまさに彼が行いたかったことだった)の
勉強に彼の研究努力を制限する以外、ないだろうと彼が考えたので、
スタンフォードまたはMITの代わりにUCバークレーを伴うことに決めました。
But theory turned out not to be Joy's forte. He started hacking code
and never stopped. "His goal was to build something that worked,"
recalls Gage. And so he did. During his seven years at Berkeley, Joy and a
few other graduate students and staff researchers spearheaded an intensive
software development effort that culminated, most famously, in a radically
improved version of AT&T's Unix, known simply as Berkeley Unix or,
more commonly, as BSD,
*
for Berkeley Software Distribution.
しかし強音声に喜びのでないために生産された理論。
彼はコードを叩き切り始め止まりませんでした。
「彼のゴールはが動かしたものを構築することでした。」
はゲージをリコールします。したがって、彼は行いました。
彼の7年中に、バークレーでは、
喜びおよび他の数人の大学院学生およびスタッフ研究者が、
AT&の根本的に改善されたバージョンで、
最も有名に最高点に達した集中的なソフトウェア開発努力の
先頭に立ちました;バークレー・ソフトウェア配布で
単にバークレーUnixあるいはより一般にBSDとして知られていたT's Unix。
Talk about your killer apps! Berkeley Unix worked so well that DARPA
*
chose it to be the preferred "universal computing environment"
linking together Arpanet
*
research nodes, thus setting in place an essential piece of infrastructure
for the later growth of the Internet. An entire generation of computer
scientists cut their teeth on Berkeley Unix. Without it, the Net might
well have evolved into a shape similar to what it is today, but with it,
the Net exploded.
あなたのキラー・アップのことだって!
バークレーUnixが非常にうまくいった、
それにより、
インターネットの後の成長のために
適所に本質的な1片のインフラストラクチュアをセットしますので、
DARPAはそれアルパネット研究ノードをともにリンクする好ましい
「普遍的な計算する環境」に選びました。
コンピューター科学者の全世代は、
バークレーUnixでそれらの最初の経験を積みました。
それなしで、ネットは、よく、
今日のその状?ﾔに似ている形へ発展したかもしれません。
しかし、それで、ネットは爆発しました。
How did the small group of Berkeley programmers pull off such a feat?
Well, for one thing, there was Joy, a programmer around whom legends
accrue like so many iron filings stuck to a magnet. He could read at age
3, play chess at 4 and, during his oral exams, invented a "sorting
algorithm"
*
on the fly that so stunned his examiners, one of them later compared the
experience to "Jesus confounding his elders."
バークレー・プログラマの小集団はどのようにそのような功績を取り外しましたか。
1つには、さて、喜び
(非常に多数が磁石に突き刺されたやすり屑にアイロンをかけるように、
伝説が生じるプログラマ)
がありました。
彼は3歳に読むことができ、4でチェスをプレーし、
彼の口頭の試験中に、「ソートするアルゴリズム」を発明しました。
急いで、それはそのように彼の試験官を茫然とさせました、
それらのうちの1つは、
その後「彼の年長者を困惑させるイエス」と経験を比較しました。
But too much focus on Joy, a favorite target for business magazine
hagiography,
obscures the larger picture. Berkeley's most important contribution was
not software; it was the way Berkeley created software. At Berkeley, a
small core group -- never more than four people at any one time --
coordinated the contributions of an ever-growing network of far-flung,
mostly volunteer programmers into progressive releases of steadily
improving software. In so doing, they codified a template for what is now
referred to as the "open-source software development methodology." Put
more simply, the Berkeley hackers set up a system for creating free
software.
しかし喜び
(ビジネス・マガジン聖人列伝の好きな目標)
の上のあまりにも多くの焦点、
より大きな絵を不明瞭にします。
バークレーの最も重要な貢献はソフトウェアではありませんでした;
それはバークレーがソフトウェアを作成した方法でした。
バークレーでは、小さな中核グループ(決してない、4人を越えていつでも)が、
しっかりとソフトウェアを改善する進歩的なリリースへ広範囲な、
ほとんどボランティアのプログラマの
常に成長しているネットワークの寄付を調整しました。
の中で、非常に行って、それらは、
今「オープン・ソースソフトウェア開発方法論」と呼ばれるもののための
テンプレートを成文化しました。
より単に置かれて、バークレー・ハッカーは
フリー・ソフトの作成のためにシステムをセット・アップします。
BSD itself wasn't originally free software. Joy sold it, with the
University of California's blessing, at a nominal cost only to people or
institutions that had already purchased licenses permitting them access to
the source code of AT&T Unix (although, in practice, Joy's efforts to
verify whether would-be buyers really did own licenses may not have been
overly vigorous). But in spirit, Berkeley Unix was indeed free: As Dennis
Ritchie, Thompson's collaborator in creating Unix, observes, anyone who
wanted to hack on Unix usually had access to the source code, one way or
another. And if those hackers sent their modifications to Berkeley, and
they were deemed good enough, they became part of a code base maintained
by programmers who wanted nothing more than for their software to be
widely used, for as low a cost as possible.
BSDはそれ自身もとはフリー・ソフトではありませんでした。
喜びは単に植民する名目上のコストで、
カリフォルニアの祝福の大学と、それを売りました。
あるいは、それらを許すライセンスを既に購入した機関は、
AT&T の Unix ソース・コードにアクセスします;
(実際上、自称の買い手が実際にライセンスを所有したとしても、
確認するべき喜びの努力は過度に活発ではなかったかもしれませんが)。
しかし、精神では、バークレーUnixが確かに暇でした:
デニス・リッチー(トムプソンのUnixの作成中の共同者)が観察するとともに、
Unixの上で叩き切りたかった誰でも
通常ソース・コードに何とかしてアクセスしました。
また、それらのハッカーがバークレーへ彼らの修正を送り、
彼らが十分によいと考えられたならば、
それらはできるだけ低いコストのために、
それらのソフトウェアが広くまさに使用されたかったプログラマによって
維持されたコード・ベースの一部になりました。
Berkeley Unix has morphed through multiple phase shifts since its
inception some 20 years ago, from the Joy-dominated era of the late '70s
and early '80s to the more collaborative period that began after Joy's
departure to Sun in 1982. But in the early '90s, after a bitter
confrontation with AT&T, BSD finally did
become
freely redistributable," and descendants of BSD -- led by FreeBSD,
*
but also including OpenBSD
*
and NetBSD
*
--
are vigorous participants in the contemporary battle for operating-system
supremacy. Yahoo, arguably the world's busiest Web site, runs on FreeBSD.
And yet, despite its proud heritage, BSD's current status doesn't quite
match up to its early fame. A victim of schisms within its own developer
community, bruised by the battle with AT&T and wounded by the
defection of Joy to Sun, BSD is currently a small player, especially as
compared with Linux. Linux-based operating systems have seized the public
imagination.
バークレーUnixは複合の過程を通り抜けて変形させました
'70年代および'80年代の初めの終わりの喜びに支配された時代から
1982年に喜びのサンへの出発の後に始まった、
より協力的な期間まで約20年前のその初め以来変わります。
しかし、'90年代の初めでは、AT&Tとの苦しい対決の後に、
BSDが最後になりました。
自由に再分配することができる」またBSDの子孫
--
FreeBSDによってリードされた、
また、OpenBSDとNetBSDを含んでいること
――
同時代の戦いの活発な参加者はオペレーティング・システム最高のためにいますか。
Yahoo、恐らく世界の最も忙しいウェブサイト、FreeBSDの上で走ります。
しかし、その誇れる遺産にもかかわらず、
BSDの現在のステータスはその初期の評判に全く等しいとは限りません。
それ自身の開発者コミュニティー内の分裂の犠牲者、
特にLinuxと比較して、AT&Tとの戦いによって痛められ、
かつ、サンにとっての喜びの離脱によって傷つけられて、
BSDは現在小さなプレーヤーです。
Linuxベースのオペレーティング・システムは公の想像をとらえました。
BSD patriots argue that the battle is far from over, that BSD is
technically superior and will therefore win in the end. That's for the
future to determine. What's indisputable is BSD's contribution in the
past. Even if, by 1975, Berkeley's Free Speech Movement was a relic
belonging to a fast-fading generation, on the fourth floor of Evans Hall,
where Joy shared an office, the free-software movement was just
beginning.
戦いが遠くにあるBSD愛国者は議論します、
BSDは技術的に優秀で、したがって結局勝つでしょう。
それは、将来が決定することです。確実なことはBSDの過去の貢献です。
喜びがオフィスを共有したところで、
1975年までに、バークレーの言論の自由移動が、
エヴァンス・ホールの4階に、
速く衰える生成に属する遺物だったとしても、
フリー・ソフト移動はちょうど始まりましょうとしていた。
The connection between the two movements is clear, if not direct. By
demonstrating the power of cooperative software development, and by
strengthening the software backbone of the Internet so it could further
nurture such development, BSD helped enable the creation of a medium that
will do more to spread free speech than anything hitherto constructed.
Power to the people, from the code.
2つの動作の関係は明らかです(直接でないにしても)。
協同のソフトウェア開発の力の実証によって、
およびそれが促進することができたように、
インターネットのソフトウェア背骨を強くすることによって、
そのような開発を養育する、
BSDは、従来構築されたものすべてより言論の自由を広げるために
もっと役立つミディアムの生成を可能にすることを支援しました。
コードからの人々への力。
Many nice, upper-middle-class Berkeley backyards boast a
redwood patio, possibly a hot tub, perhaps a vegetable garden complete
with thriving rosemary bushes and marauding raccoons. Bob Fabry's backyard
has a radio tower that wouldn't look out of place at a major Air Force
base. Capable of telescoping upward to a height of 100 feet, and built
mostly by Fabry himself -- the hub that rotates the antenna was scavenged
from a 1940s airplane propeller -- the radio tower looms beside Fabry's
home like a not-so-miniature Eiffel Tower. One look at it and you realize
you are in the presence of a very dedicated geek.
多くのよく、
上部の中流のバークレーの裏庭が
アメリカスギ・テラス
(恐らくホットタブ(恐らく繁栄するローズマリー潅木の完備した野菜の庭、
略奪するアライグマ))を誇ります。
ボブFabryの裏庭は、
主な空軍基地の場所に警戒しないラジオ放送塔を持っています。
100フィートの高さに上方へはまりこむことができ、
ほとんどFabry彼自身
(アンテナを回転させるハブは1940年代飛行機プロペラから掃除されました)
によって構築することができる、
ラジオ放送塔はFabryのそれほど小型でない
エッフェル塔のような家のそばにぼんやりと現われます。
非常に専心的なオタクの面前であなたがいることを悟ります。
Fabry takes his ham radio "hobby" seriously. He once even helped
organize a trip to the uninhabited wilderness of
Heard Island,
about 1,000
miles north of Antarctica, just to set up a ham radio station for a few
days so amateur-radio enthusiasts all over the world could enjoy the
pleasure of exchanging radio signals with the faraway station.
Fabryは彼のハム・ラジオ「趣味」を真剣に受けとめます。
彼、アマチュアのラジオの熱狂家が遠いステーションで
無線信号を交換する楽しみを世界中で楽しむことができたように
数日間ハム・ラジオ放送局を単にセット・アップするために
南極大陸の約1,000マイル北のハード島の無人の荒野への旅行を
組織することをかつてさらに支援します。
But Fabry's most impressive achievement scales far beyond his tower or
his expeditions. He is the Berkeley computer science professor who
orchestrated the creation of Berkeley Unix. Not that he wrote a lot of code
--
that honor belonged primarily to Joy and the other members of
Fabry's Computer Science Research Group, an all-star band of programmers
whose roster included names like Sam Leffler, Kirk McKusick, Mike Karels
and Keith Bostic. But while Joy and others were hacking for 36 hours at a
stretch, improving file systems,
*
networking performance, memory utilization and a hundred other arcane but
crucial elements of Unix, Fabry was running interference -- maneuvering
through the formidable bureaucracies of the University of California and
AT&T, dealing with departmental politics and backbiting and, most
important, writing the grant proposals that brought a steady flood of
DARPA money into Berkeley.
しかし、
Fabryの最も印象的な達成は彼のタワーあるいは彼の遠征のはるか向こうに計ります。
彼はバークレーUnixの生成を組み合わせたバークレー電子計算機科学教授です。
だからといって、彼が多くのコードを書いたわけではありません。
――
その?ｼ誉は第1に喜びに属しました。
また、Fabryの電子計算機科学の他のメンバーはグループ、
その登録簿がサムLefflerのような名前を含んでいた
プログラマのオールスターのバンド、
カークMcKusick、マイクKarelsおよびキースBosticを研究します。
しかし、ファイル・システム、ネットワークの実行、
メモリ利用およびUnixの100の他の不可解であるが重大な要素を改善して、
喜びと他のものが伸張で36時間叩き切っていた間、
Fabryは妨害を実行していました
――
カリフォルニアとAT&Tの大学の恐ろしい官僚政治による演習;
部門の政治との取り引きおよび陰口、
そして、最も重要、
バークレーへDARPA金の安定した洪水をもたらした許可提案を書くこと
Fabry was personally responsible for bringing Unix to Berkeley. His
reasons were simple, and offer an early example of the pragmatist bent
that has characterized BSD development ever since.
Fabryは、バークレーへUnixを持って来ること個人的に原因でした。
彼の理由は単純で、
その後ずっとBSD開発を特徴づけた現実主義者傾向の初期の例を提示します。
Unix was cheap. AT&T had been forced to practically give it away
for free by government order. But Unix was also, fundamentally, a hack
designed to work on cheap hardware. Back in 1969, Thompson wanted to get a
computer game called Space Travel working on a castoff PDP-7. So what did
he do? He wrote an entire operating system that made it possible. Kind of
like using a nuclear missile to hammer a nail
--
but then that's often
standard operating procedure for obsessed hackers.
Unixは安かった。AT&Tは、
政府命令で実際に無料でそれを授与することを強いられました。
しかし、Unixはさらに基本的にありました
(安いハードウェアに作用することを目指した荒傷)。
1969年には、トムプソンは、
捨てられたPDP-7に作用する宇宙旅行と呼ばれるコンピューターゲームを得たかった。
そうすると、彼は何を行いましたか。
彼は、それを可能にした全オペレーティング・システムを書きました。
類似のことの種類、爪を打つために核ミサイルを使用すること
――
しかし、その後、それは取りつかれたハッカーのための
多くの場合標準の操作の手続きです。
Fabry was entranced by Unix's affordability, along with the ease with
which it could be adapted to different computer hardware. In addition to
his academic research focus on operating systems, he was involved in
setting up computing resources for the UC-Berkeley student body. In the
mid-'70s, this could be an expensive proposition. Typically, operating
systems that would allow multiple users of a mainframe
*
to work at individual terminals were designed only for extremely expensive
computers. The costs per user could easily reach $50,000 a
terminal, which made such systems impractical for pedagogic
purposes. But Unix, used in combination with a relatively inexpensive
PDP-11
from DEC, ended up costing closer to $5,000 "per seat."
Fabryは、
それが異なるコンピューター・ハードウェアに適応されるかもしれない
容易さに加えてUnixのaffordabilityで有頂天になりました。
オペレーティング・システム上の彼の学術的な研究焦点に加えて、
彼はUCバークレー学生総数のために
計算する資源をセット・アップすることに関係していました。
'70年代中頃に、これは高価な提案でありえます。
典型的には、メインフレームの多数のユーザが
個々のターミナルで働くことを可能にするオペレーティング・システムは、
非常に高価なコンピューター用にのみ設計されました。
1人のユーザ当たりコストは容易に50,000ドルに達するかもしれません、
ターミナル(それはそのようなシステムを教育学の目的には非実用的にした)。
しかしUnix、使用された、1つの、比較的安いPDP-11
「1つの座席当たり」5,000ドルに接近して結局コストがかかった(DECから)こと。
Even better, a $99 license fee bought you access to the Unix source
code -- to the blueprints, the magic recipe, the key that unlocked all
hidden mysteries. For researchers, teachers and students, this was
priceless. Researchers working on cutting-edge operating system technology
could experiment with already existing source code and modify it for their
needs; students who wanted to learn how an operating system really worked
could find out by getting their hands dirty with the code. Duane Adams,
the DARPA contract "monitor" who administered the Berkeley Unix contracts,
notes that the availability of source code was an explicit reason why
DARPA chose Berkeley Unix instead of contending aspirants like DEC's
*
VMS.
*
Never mind that VMS had been designed from the bottom up for the DEC VAX
computers that were the most popular hardware for Arpanet nodes; VMS was a
closed, proprietary system. You couldn't get in and muck about, so it just
wasn't attractive to researchers.
さらによりよく、
99ドルのライセンス料金は、
あなたにUnixソース・コードへのアクセスを買ってやりました
――
青写真に、マジックのレシピ(秘密のミステリーをすべて解き明かしたキー)。
研究者、教師および学生にとって、これは貴重でした。
最先端のオペレーティング・システム技術を処理する研究者は
既に既存のソース・コードで実験し、
彼らのニーズのためにそれを修正することができました;
オペレーティング・システムがどのように実際に働くか知りたかった学生は、
それらの手をコードで汚くすることにより見つけ出すことができました。
デュアン・アダムズ(バークレーUnix契約を処理したDARPA契約「モニター」)は、
ソース・コードの有効性が、
志望者がDECのVMSが好きであると主張する代わりに、
DARPAがバークレーUnixを選んだ、
明示的な理由だったことに注目します。
アルパネット・ノード用の最もポピュラーなハードウェアだった
DEC VAXコンピューター用に底からVMSが設計されたと
気にかけないでください;
VMSは閉じて所有者のシステムでした。
中に入りのらくらすることができませんでした。
したがって、それは研究者にちょうど魅力的ではありませんでした。
DARPA was also recognizing reality. Prominent researchers, hungering
for the magnetic tapes carrying Berkeley's latest distributions like so
many desperate junkies, demanded that DARPA adopt Berkeley Unix because
that's what they were already using.
DARPAはさらに現実を認識していました。
非常に多くの絶望的な麻薬常習者のように
バークレーの最新の分配を運ぶ磁気テープを渇望する著名な研究者は、
それが、それらが既に使用していたものであるので
DARPAがバークレーUnixを採用することを要求しました。
"What was driving DARPA," says Fabry, "was that almost all of their
contractors were telling them that they were running Berkeley Unix and it
was superior to anything else available."
「DARPAを運転していたこと」が
「ほとんど、それらがバークレーUnixを実行しており、
それがほかに利用可能な何でもより優秀だったとそれらの契約者が
すべて彼らに伝えていたということだった」とFabryは言います。
As one popular explanation has it, Unix's source code became widely
available through a lucky accident -- as an unanticipated consequence of
the consent decree that forbade AT&T from commercializing its
non-telephony-related inventions. But that's only a part of the story.
Unix was always more than just a bit player in a showdown between the
world's largest government and the world's biggest corporation. Unix was,
at least in the mind's eye of scientists like Fabry, "a thing of beauty."
And from the very beginning, Unix benefited from a communal vibe that
spread directly from its creators, Ritchie and Thompson.
1つのポピュラーな説明がそれを持っているとともに、
Unixのソース・コードは幸運な事故によって広く利用可能になりました
--
非電話術に関連するその発明を商業化することをAT&Tに禁止した
同意判決の期待しない結果として。
しかし、それは物語の一部だけです。
Unixは常に単に世界の最大の政府と世界の最も大きな企業の間の対決での
端役を越えるものでした。
Unixは、少なくともFabryのような科学者の想像の中で、「美のもの。」
また、まさに始めから、Unixは、
その創造者、リッチーおよびトムプソンから直接広がった、
公共の感じから利益を得ました。
Fabry recalls grasping the hidden wonders of Unix one week in 1975 when
Thompson conducted a "reading" of Unix over several successive nights.
Fabryはトンプソンが導いた時1975年にUnixの秘密の驚異を
1週理解することを思い出します、
1つの、いくつかの連続の夜のunixを「読んで知る」こと。
"The first meeting of the West Coast Unix User's Group had about 12 or
15 people," recalls Fabry, a mild man, now 60 years old, who clearly
delights in his 25-year-old memories. "We all sat around in Cory Hall and
Ken Thompson read code with us. We went through the kernel
*
line by line in a series of evening meetings;
he just explained what everything
did ... It was wonderful."
「西海岸Unixユーザグループの第1回会は約12人あるいは15人の人々を持っていた」、
今Fabry(穏やかな人)を60年リコールする、
古い、?N、明白に25年来の彼の記憶中の喜び。
「私たちはすべて私たちと、コリー・ホール
およびケン・トムプソン読み取りコードの中で無為に過ごしていました。
私たちは核を通り抜けました。一連の等しくする会でのラインによるライン;
彼は、すべてが何を行ったかちょうど説明しました...それは素晴らしかった。」
The reading of the code: Thompson's primeval act of deconstruction was
an initiation into the Unix cabala, a ritual passing down of code lore.
Fabry may have brought the first physical manifestation of Unix to
Berkeley, but Thompson's reading embedded it in Berkeley's soul. Eric
Allman,
*"
who was later to write sendmail,
*
the open-source-software mail transport program that still shuttles the
vast majority of Internet mail across the Net, was an undergraduate at
Berkeley when he attended the readings. He still has his marked-up
"listings," reams of cheap, flimsy computer paper with notes scribbled on
them, detailing the obscurities of the C programming language and other
Unix arcana.
コードの読書:
トムプソンのディコンストラクションの原始時代の行為は、
Unixカバラ(コード知識を下へ通過する儀式)へ開始でした。
Fabryは、バークレーへUnixの第1の肉体的表示を持って来たかもしれません。
しかし、トムプソンの読書はバークレーの魂にそれを埋め込みました。
エリックAllman、彼が読書に参加した時、
誰がsendmail
(ネットを横切ってまだ大多数のインターネットメールを
左右に動かすオープン・ソースソフトウェアメイル輸送プログラム)
を後に書くかは、
バークレーの大学生でした。
彼はまだ印のあるアップ「リスト」、
Cプログラミング言語の不明瞭を詳述して、
それらに書きなぐられたノートを備えた
大量の安く薄弱なコンピューター紙および他のUnix大神秘を持っています。
"The really bizarre thing is that Ken Thompson did a free tutorial on
Unix kernel internals," recalls Allman, "and everyone fit into a rather
tiny room." Today, you'd need to rent a ballroom.
「実際に奇妙なことは、ケン・トムプソンが
Unix核内部上の自由な教本を行ったということである」、
Allmanをリコールする、
「そして皆、やや小さな部屋に入る。」
今日、舞踊場を借りる必要があるでしょう。
Fabry marched against the Vietnam War while he was a graduate student
in Chicago, and notes proudly that in his entire 12-year tenure at
Berkeley he never once wore a tie. But although some historians have later
described the Berkeley hackers as freedom fighters
--
especially in the
context of their battle with AT&T (which came well after Fabry had
retired)
--
neither Fabry nor the hackers themselves saw what they were
doing in such explicit ideological terms. But when I ask Fabry if there
was ever a moment when the goal crystallized in his head that software
should be free, he turns the question around:
彼がシカゴで大学院学生で、
バークレーでの彼の12年の任期全体では、
彼が一度もタイを着用していなかったことに高慢に注目する間、
Fabryはベトナム戦争に対して進みました。
しかし何人かの歴史家はバークレー・ハッカーを自由の戦士と
その後評しましたが
――
特にAT&T(Fabryが退いた後、それはよく来た)との
それらの戦いの情況の中で
--
Fabryもハッカー彼ら自身も、
それらがそのような明示的なイデオロギーの用語に
何を行っているか分かりませんでした。
しかしゴールが、ソフトウェアがそうであるべき
彼の頭の中で結晶した時、瞬間がかつてあったならば、
私がFabryを尋ねる場合、自由、彼は、次のもののまわりの質問を回します。
"Where did it come from that code should cost money? I think that's the
fair question," says Fabry. In the mid-'70s, most programmers had grown up
in an era where software was usually included with hardware and not
considered a separate revenue source or proprietary intellectual property.
Joy saw his work on Unix as research, to be shared with the rest of the
academic research community the same way professors had been sharing the
fruits of their labors for thousands of years. Ritchie and Thompson wanted
their software to be used
--
they did everything in their power to help
the Berkeley programmers fix bugs and make improvements.
「それはどこから来ましたか、コードはコストがかかるべきです?
「私は、それが公平な問題であると思います」とFabryが言います。
'70年代中頃に、ほとんどのプログラマは、
ソフトウェアがハードウェアで通常含まれており、
個別の収入出所あるいは所有者の知的財産と考えられなかった時代に成長しました。
喜びは、同じ方法教授がそれらの労働の産物を共有した
学術的な研究コミュニティーの残りと共有されるために研究として
Unixの彼の研究を見ました、何千もの年。
リッチーとトムプソンは、
彼らのソフトウェアが使用されることを望みました。
――
それらは、バークレー・プログラマがバグを直し、
かつ改良を作るのを助ける力でのあらゆることをしました。
None of them saw himself as a crusader. But a trickle of idealism still
occasionally leaked out.
それらのどれも改革運動家として彼自身に会いませんでした。
しかし、理想主義の滴りはまだ時々漏れました。
"I think the spirit in which we were putting this all together was much
the spirit that was picked up later by the Free Software Foundation and
the various people who were trying to build 'software for the people,'"
says Fabry. "The idea is that there is no duplication cost for software,
so it ought to be basically free, and we were all working together to try
to produce this ideal system that we would all love to have, and love to
be able to use ourselves. That was the goal of a lot of people, and of
course that was the original goal of Ken Thompson and Dennis Ritchie in
starting Unix."
「私、私たちがこれをすべて入れていた精神が
非常にフリー・ソフトウェア・ファウンデーションによって
その後拾い上げられた精神、
および構築しようとしていた様々な人々だったと思う
「人々のためのソフトウェア、
「"Fabryは言います。
「その考え、ソフトウェアのための複製コストがないということである、
したがって、それは基本的に自由であるべきです、
また、私たちはすべてこの理想的システムを生産しようとするために
ともに働いていました、それ、私たちはすべてするでしょう、
持つべき愛および私たち自身を使用することができる愛。
それは多くの人々のゴールでした。
また、もちろん、それはUnixを始める際に
ケン・トムプソンおよびデニス・リッチーのオリジナルのゴールでした。」
Fabry retired at age 43, tired of the DARPA treadmill and eager to
focus his energy on his ham-radio tinkering. But Berkeley Unix's record of
success still thrills him.
Fabryは、
DARPA踏み車に飽きており、かつ、
ハムラジオ下手な修繕をするこ?ﾆに
彼のエネルギーを集中させるのに熱望していて、
43歳で退きました。
しかし、バークレーUnixの成功のレコードはまだ彼をぞくぞくさせます。
"Berkeley Unix was clearly the most successful university software
project that has ever gone on," says Fabry in a rare moment of
assertiveness, before backtracking slightly. "I don't know, I haven't been
keeping up since 1983 and maybe there's been something since then, but I
believe that that was true at the time. We had literally thousands and
thousands of installations, and a whole generation of computer science
students all around the world grew up on Berkeley Unix. It set a standard
for operating systems that people are still having trouble doing better
than. It was also the first efficient networking solution; for years it
was the only game in town, the basis of Internet development. It really
was one of the things that the people who made the Internet what it is
today built on. There were battles that had been solved that didn't have
to be solved again in order to do whatever new part that they wanted to
do."
わずかに引き返す前に、
断定的のまれな瞬間のFabryは
「バークレーUnixは明らかにかつて進んだ最も成功した
大学ソフトウェア・プロジェクトだった」と言います。
「私は知りません、私は1983年以??a以来
および恐らくそこについていっていません、
その時以来何かだった、
しかし、私は、それがその時に真実だったと信じます。
私たちは何千もの装置を文字通りに持っていました。
また、電子計算機科学学生の全世代が世界中で
バークレーUnixは好きになっていきました。
それは、人々がまだより上手に行うのに苦労している
オペレーティング・システムのために標準を定めました。
さらに、それは最初の効率的なネットワークのソルーションでした;
何年も、それは町、インターネット開発の基礎のただ一つのゲームでした。
それは実際にもののうちの1つでした、
それ、インターネットをそれが今日上に作ってやられるものにした人々。
解決された戦いがありました、
それは行うためには再び解決される必要がなかったこと、
新しい部分は何である、彼らは行いたかった。」
"Bill codes like a demon." -- John Gage
"His code was ugly." -- Kirk McKusick
"Bill Joy was a fabulous marketer." -- Eric Allman
"Bill was superb. He was the epitome of what one would like to see in a graduate student. -- Bob Fabry
"He had an infectious enthusiasm about him, where he would just get the people around him to do stuff. And he had an incredible drive to get his oftware out so that other people would use it." -- Kirk McKusick
"Berkeley Unix was the work of many talented developers. Bill Joy's particular genius was in integrating the work of these many contributors from many different organizations." -- Rob Gurwitz
"Bill's really smart." -- Sam Leffler
Gage's eyes twinkle as he recalls one of his favorite Bill Joy stories.
The scene, he says, is in a boardroom high up in a building overlooking
Washington, D.C. The time is the early 1980s. In attendance are some
representatives from DARPA, some employees of BBN
*
(a Boston company that received the original DARPA contract to build the
Arpanet) and a few Berkeley hackers, including Joy.
彼が好きな紙幣喜び話のうちの1つをリコールするとともに、
ゲージの目は光ります。
場面がワシントンD.C.を見下ろす建物で重役会議室に高くあると彼は言います。
時間は1980年代の初めです。
出席では、喜びを含むDARPA、BBN
(アルパネットを構築するオリジナルのDARPA契約を受け取ったボストン会社)
の何人かの従業員および数人のバークレー・ハッカーからの何人かの代表がいます。
At issue was an annoying problem that had been bothering DARPA. DARPA
had given Berkeley a major contract to enhance Unix so that it would be
suitable for DARPA's network of research sites. It had also decided that
Berkeley Unix should incorporate TCP/IP
,*
a specification for how Arpanet machines would interconnect. Devised by
Vinton Cerf and Bob Kahn, TCP/IP (Transmission Control Protocol/Internet
Protocol) was -- and still is today -- the basic method by which computers
talk to each other across the Internet.
問題では、DARPAを悩ましたうるさい問題がありました。
DARPAは、バークレーにそれがDARPAの研究サイトの
ネットワークにふさわしいだろうようにUnixを増強する主な契約を与えました。
さらに、それは、バークレーUnixがTCP/IPを組込むと決定しました。、
アルパネット・マシンがどのように相互に連結するだろうかための明細。
Vinton Cerfおよびボブ・カーンによって考案されて、
TCP/IP(伝送コントロール・プロトコル/インターネット・プロトコル)は
コンピューターがインターネットを横切って互いに話しかける、
基礎的な方法でした(まだ今日ある)。
But DARPA had given BBN the contract to implement the TCP/IP
protocol,
*
to write the all-important TCP/IP "stack."
*
Joy had been instructed to plug BBN's stack into Berkeley Unix. But Joy
refused to do so. In his opinion, BBN's TCP/IP wasn't good enough. So he
wrote his own high-performance TCP/IP stack.
しかし、DARPAは、
BBNにTCP/IPプロトコルをインプリメントする契約を与えました、
必須のTCP/IP「スタック」を書くこと。
喜びは、バークレーUnixにBBNのスタックを差し込むように命じられました。
しかし、喜びは、そうすることを拒絶しました。
彼の見解では、BBNのTCP/IPが十分にはよくありませんでした。
したがって、彼は自分の高機能TCP/IPスタックを書きました。
As Gage tells it, "BBN had a big contract to implement TCP/IP, but
their stuff didn't work, and Joy's grad student stuff worked. So they had
this big meeting and this grad student in a T-shirt shows up, and they
said, 'How did you do this?' And Bill said, 'It's very simple -- you read
the protocol and write the code.'"
「ゲージがそれを伝えるとともに、
BBNはTCP/IPをインプリメントする大口契約を持っていたが、
それらの材料が作動しませんでした。
また、喜びの卒業生学生材料は作動しました。
したがって、それらはTシャツに
この大きな会およびこの卒業生学生を持っていました、
現われる、また、彼らは言いました、
「どのようにこれをしましたか。」
また、ビルは、
「それは非常に単純です--プロトコルをコードを読み書きします。
」と言いました。」
"That really frosted the BBN guys."
「それは実際にBBN奴を霜で覆いました。」
Well, sure. In programming lingo, a flat statement like "Read the
protocol and write the code" is, to borrow some modern slang, a major dis.
But did Joy really say the words? And did BBN's code really not work?
さて、確か。
ちんぷんかんぷんをプログラムする際に、
水平なステートメント、
のように「プロトコルをコードを読み書きしてください」
ある現代の俗語(主なdis)を借りるためにあります。
しかし、喜びは実際に単語と言いましたか。
また、BBNのコードは実際に働きませんでしたか。
No and no, says Rob Gurwitz, the BBN programmer who wrote BBN's
implementation of TCP/IP. Gurwitz says he was at all the DARPA steering
committee meetings that handled TCP/IP matters during that era, and he
doesn't remember ever hearing Joy make such a statement. Gurwitz, who says
he worked closely with Joy and Sam Leffler on the integration of TCP/IP
into Berkeley Unix, also says Joy's version of TCP/IP was not a direct
replacement for BBN's code. Joy's stack was designed to maximize
performance
over local area networks that had wide bandwidth connectivity -- like an
Ethernet
*
network designed to serve an entire university campus, for example.
Gurwitz's version was built to operate on the much narrower 56Kbps
telecommunication lines that made up the Arpanet's backbone.
ない、そしていいえ、
ロブGurwitz
(BBNのTCP/IPのインプリメンテーションを書いたBBNプログラマ)は言います。
Gurwitzは、
その時代にTCP/IP問題を扱ったすべてのDARPA運営委員会会合に
彼が出ていたと言います。
また、彼は、喜びがそのようなステートメントを行なうのを
常に聞?｢たことを覚えていません。
バークレーUnixの中へのTCP/IPの統合上のGurwitz
(この人は彼が緊密に愉快に働いたと言う)
およびサムLeffler、さらに喜びのTCP/IPのバージョンが
BBNのコードのための直接の置換ではなかったと言います。
喜びのスタックは、実行を最大限にすることを目指しました。
広い帯域幅接続を持っていたローカル・エリア・ネットワーク上に
--
イーサネットのように例えば、
ネットワークは大学キャンパス全体に役立つつもりでした。
Gurwitzのバージョンは、
アルパネットのバックボーンを構築した
はるかに狭い56Kbpsテレコミュニケーション・ライン上で
作動するために構築されました。
Nonetheless, the Berkeley hackers were (and are) convinced that their
implementation was superior, and they continued to resist all attempts by
DARPA to force them to include the BBN version in Berkeley Unix, even
though, according to Gurwitz, several DARPA sites continued to use BBN's
version for years. As is the case with most programming disputes, the
deeper one delves into the TCP/IP spat, the more
"Rashomon"-like
the search for truth becomes.
それにもかかわらず、
バークレー・ハッカーはそうでした(そしてある)それを確信させた、
それらのインプリメンテーショ??aインプリメンテーション優秀でした、
また、それらは、たとえGurwitzによれば、
いくつかのDARPAサイトが何年もBBNのバージョンを使用し続けたとしても、
バークレーUnixにBBNバージョンを含めることを
それらに強いるDARPAによる試みすべてに抵抗し続けました。
ほとんどのプログラムする論争の場合であるように、
より深いものはTCP/IP貝の子を徹底的に調べます、
より多くの物「Rashomon"のよう。真理の捜索はなります。
So why is the squabble important? For at least three reasons.
そうすると、口論はなぜ重要ですか。少なくとも3つの理由のために。
First, the incorporation of TCP/IP into Berkeley Unix can be, and often
is, singled out as the most important innovation that made the Internet
function efficiently. Joy and other Computer Science Research Group
*
veterans argue that their version of TCP/IP was crucial, because only it
was technically good enough to satisfy researchers who wanted to
communicate with each other and get work done on their local networks as
well as on the Internet.
最初に、バークレーUnixの中へのTCP/IPの編入はそうでありえます、
またインターネットを効率的に機能させた最も重要な革新として選抜されて、
多くの場合あります。
喜びおよび他の電子計算機科学はグループを研究します。
ベテランは、それだけが互いと通信し、
インターネットと同様にそれらのローカル・ネットワーク上でも
仕事を行いたかった研究者を満足させるのに技術的に、
十分によかったので、TCP/IPの彼らのバージョンが重大だったと主張します。
The TCP/IP stack, one could argue, was the original Promethean gift of
fire to the mortals of the Net. And when the Internet suddenly boomed in
the '90s, Berkeley Unix scaled up right along with it -- a testament, says
Kirk McKusick, to the quality of its design. To this day, BSD advocates
contend that the networking performance of BSD, which can still be traced
all the way back to Joy's TCP/IP code, outclasses the best that
Linux-based operating systems can do.
TCP/IPスタック、一つは議論することができました、
ネットの人間への火のオリジナルのプロメテウスの贈り物でした。
また、インターネットが'90年代に急に急激に景気づいた時、
バークレーUnixはそれと共にちょうど率に応じて拡大しました
--
カークMcKusickはその設計の質に、
遺言と言います今日まで、BSD主張者は、
BSDのネットワークの性能(それは喜びのTCP/IPコードまで
今までどおり途中ずっとさかのぼることができる)が最上に勝ると主張します、
Linuxベースのオペレーティング・システムはできます。
Second, the TCP/IP stack played a deciding role in settling the legal
battle between AT&T and the University of California. The breakup of
the AT&T monopoly in 1984 finally permitted AT&T to commercialize
Unix. For years, as Unix became the preferred language of the Net and
academia, AT&T had steadily increased licensing fees from the original
$99 all the way up to $250,000. But AT&T wasn't the only interested
party. In the early '90s, BSDi,
*
a spinoff of Berkeley's CSRG, started selling its own version of Berkeley
Unix, and the University of California had been selling its version for
years. In 1992 AT&T sued both the University of California and BSDi,
claiming that BSD Unix included proprietary AT&T code.
次に、TCP/IPスタックは、
AT&Tとカリフォルニアの大学の間の法廷闘争を解決する際に
決め手の役割を果たしました。
AT&Tを最後にUnixを商業化することを許された
1984年のAT&Tの独占の分解。
何年も、Unixがネットおよび学究生活の好ましい言語になるとともに、
AT&Tはオリジナルの99ドルからの許可する料金をしっかりと
途中ずっと250,000ドル以内増加させました。
しかしAT&Tはただ一つの利害関係者ではありませんでした。
'90年代の初めでは、BSDi(バークレーのCSRGのスピンオフ)が、
バークレーUnixのそれ自身のバージョンを売り始めました。
また、カリフォルニアの大学は何年もそのバージョンを売りました。
1992年には、AT&Tが、BSD Unixが所有者のAT&Tのコードを含んだと主張して、
カリフォルニアの大学およびBSDiの両方を訴えました。
Unfortunately for AT&T, the version of Unix that the company was
then pushing, System 5, turned out to incorporate large chunks of code
originally written by BSD hackers -- including the TCP/IP stack. Berkeley
released all its code under an extraordinarily liberal license --
basically, users could do anything they wanted with BSD code as long as
they retained the University of California copyright. But AT&T had
stripped the UC copyrights and begun marketing the software as its own.
Hackers like McKusick were peeved.
AT&T(その後、会社が押していたunixのバージョン)のために不運にも、
システム5、BSDハッカーによってもとは書かれたコードの大きな塊を
組込むために生産された
――
TCP/IPスタックを含んでいることバークレーは、
非常に豊富なライセンスの下のそのコードをすべてリリースしました
――
基本的に、ユーザは、カリフォルニア著作権の大学を保持した限り
彼らはBSDコードでほしかったものをすべてすることができました。
しかし、AT&TはUC著作権を裸にしており、
それ自身のものとしてソフトウェアを出荷し始めました。
McKusickのようなハッカーはいらいらしました。
"We had written this code and they were claiming it was theirs," says
McKusick, "and that they had the rights to it, and we just flat out didn't
believe it. And it pissed us off that they were basically taking our work,
that they hadn't paid a penny for, but that they had made money off of
because of all the damn licenses that they had sold, and they were now
trying to claim it was theirs."
「私たちはこのコードを書きました。
また、それらは、それがそれらのものであると主張していました」
とMcKusickが言う、
「そして、それらは、それへの権利を持っていました、
また、私たちは、ちょうど全速力でそれを信じませんでした。
また、それはそれから私たちを小便でぬらしました、
それらは基本的に私たちの仕事をとっていました、
それらは1枚の1セント銅貨を払っていませんでした、
のために、しかし、それらは急いで去りました、
売ったすべてのdamnライセンスのために、
また、それらは、それがそれらのものだったと主張しようと今していました。」
The University of California's lawyers seized upon the opening,
countersuing AT&T for copyright violation. After the requisite legal
scurrying, the two sides came to a settlement, the terms of which both
sides are forbidden to comment on. That settlement, along with a concerted
effort by BSD hackers to rid their code of any AT&T "taint," freed the
operating system of its last proprietary vestiges.
カリフォルニアの弁護士大学は、
開始(著作権妨害のためのcountersuing AT&T)を??pしました。
必要に法的に急いだ後に、2つの側は、
居留地(両側が上にコメントすることを禁止される用語)にできました。
その解決は、任意のAT&T「腐敗」を
それらのコードから除去するBSDハッカーによる協力に加えて、
その最後の所有者の証拠のオペレーティング・システムを解放しました。
Third, even if Joy did not piss off his fellow programmers by saying
"Read the protocol and write the code," no one who knows him well will
deny that it is the kind of thing he could easily have said. Joy's
colleagues and professors are unanimous in describing him as a
fundamentally nice guy. But like so many great hackers, Joy is also almost
unconsciously arrogant. And that arrogance has been, historically, a key
part of the BSD legend. As a general rule, programmers tend to have a high
opinion of themselves. And as a class, Unix programmers are well known for
demonstrating their own special blend of high-priest orneriness. But BSD
Unix hackers, with some notable exceptions, are especially virulent in
their self-assuredness. They aren't wrong very often, and when they are,
convincing them of that fact requires several armies and quite a bit of
heavy artillery. Indeed, the easiest explanation for why BSD hackers watch
in dismay while Linux-based operating systems sweep the world is that,
for years, subsections of the BSD community have been endlessly imitating the
mulishness that marked Joy's original reluctance to compromise on
TCP/IP.
第3に、喜びが、「プロトコルをコードを読み書きしてください」
と言うことにより彼のプログラマ仲間から小便をしなかったとしても、
彼を知っている者は誰もそれが、
彼が容易に言ったことができる考えの種類であることをよく否定しないでしょう。
喜びの同僚および教授は、
彼を基本的によいガイと評することに意見が一致しています。
しかし、非常に多くの偉大なハッカーのように、
喜びはさらに無意識に尊大です。
また、その尊大は歴史上BSD伝説の重要な部分でした。
概して、プログラマは、
それら自身に関する高い評価を持つ傾向があります。
また、クラスとして、Unixプログラマは、
司祭長癇癪の自分の特別の混合の実証で有名です。
しかし、BSD Unixハッカーは、いくつかの顕著な例外を除いて、
それらの自信において特に有毒です。
それらはあまり多くの場合間違っていません。
また、それらがそうである場合、
それらにその事実を確信させることは
いくつかの軍隊および全く重砲のビットを要求します。
確かに、Linuxベースのオペレーティング・システムが世界を通過している一方、
なぜBSDハッカーが当惑して見るかの最も容易な説明は、
何年も、BSDコミュニティーのサブセクションが
TCP/IPについて妥協する喜びのオリジナルの抵抗を
マークした強情さを際限なく模倣していたということです。
Of course, if anyone ever had a right to be arrogant, it would be Bill
Joy. When the University of California received new computer terminals
advanced enough to allow a cursor to be mapped to a particular point on
the screen, Joy promptly, and speedily, wrote a text editor, vi,
*
that took advantage of the new capabilities. Vi is still widely used today,
standard equipment on nearly all Unix installations.
もちろん、もし誰かにはかつて尊大な権利があれば、
それは紙幣喜びになるでしょう。
カリフォルニアの大学が新しいコンピュータ端末を受け取った時、
カーソルがスクリーン上の特別のポイントに写像されることを可能にするために
十分に進んだ、喜び、速やかに迅速に、テキストエディターおよびviを書いた、
それは新しい能力を利用しました。
Viは広く用いられている今日(ほぼすべてのUnix装置上の標準の設備)です。
If the compiler Joy was using didn't satisfy him, he wrote a new one.
If the backspace key didn't work correctly in Unix, he rewrote the source
code. And so on.
コンパイラー喜びが使用していた場合、
彼を満足させなかった、彼は新しいものを書きました。
バックスペース・キーがUnixで正確に働かなかった場合、
彼はソース・コードを書き直しました。など。
"Bill's very good at taking something," says McKusick, "saying, 'OK,
this is what I have, this is where I want to get to, what's the shortest
path from here to there?' His code was ugly, unmaintainable,
incomprehensible, but by golly it only took him two weeks to do an
incredible amount of functionality. Someone asked me once to compare
myself to Bill Joy, and I said, "You know, there's really nothing that
Bill's done that I couldn't have done, but what Bill did in a year would
take me 10.'"
「何かをとることで非常によいビル」はMcKusickと言います、
「言う、「OK、これは私が持っているものです、
これは私が到着したい場所です、最短のパスは、
ここから何までそこにありますか。」
彼のコードは醜かった、維持できない、不可解、
しかしによって、まあ、法外な量の機能性を行うことには、
彼は2週単にかかりました。
誰かが、紙幣喜びと私自身を比較してくれるように私に以前依頼しました、
また、私は言いました、「知っています、
ビルがもたらされることは何も実?ﾛにありません、
私は行うことができなかったでしょう、しかし、
ビルが一年で行ったことは私に10をとるでしょう。「"
"He was just very good at reading a large body of code and wrapping his
mind around it," recalls Fabry. "So he could do major reorganizations of
code in a single weekend. I saw him do major reorganizations of the kernel
several different times. In the beginning it took him just a few days,
while later on it might take him a month. It was wonderful."
Joy called me once on his cellphone. It was Feb. 14, and he was in a
grocery store in Monterey, Calif., stocking up on food before heading over
to the annual TED (Technology, Entertainment, and Design) conference.
Never one to waste a spare second, he decided to combine two chores -- my
questions about his Berkeley days and his own need for sustenance. The
result gave me a close glimpse at one of Joy's more famous qualities --
his ability to multitask. While answering a question from me, he would
simultaneously talk to the cashier or a counter person without skipping a
beat. In the middle of a sentence, out would pop the words "fruit salad"
or "yogurt with raisins."
Like Unix itself, famous for its ability to perform simultaneous tasks,
Joy could allocate portions of his brain to separate jobs at the same
time, without appearing to shortchange any of them.
I learned later that his performance wasn't as awe-inspiring as I first
thought. Joy, I was told, decides what he thinks about something and then
rarely changes his mind; instead, he stores away his thoughts on the
subject and is able to regurgitate them on demand, without wasting any
fresh brain cells.
People who've worked with Joy say his ability to compartmentalize made
him difficult to deal with on occasion. The stories of shouted arguments
ringing through the hallways of Berkeley's computer science department are
legion. But Joy's stubborn single-mindedness also made him an excellent
leader. Berkeley Unix thrived in large part because Joy held his code to
the highest possible standard and refused to compromise. Leffler, Joy's
second-in-command for most of the heavy lifting involved in pushing out
the first versions of Berkeley Unix, says he and Joy had a
responsibility not to compromise. The U.S. Department of Defense
was paying for BSD, and its prospective users encompassed the cream of the
computing-science crop.
Intriguingly, Joy doesn't subscribe to the fundamental credo of the
Linux movement -- the belief that the strength of open-source software is
its ability to tap the energy and enthusiasm of a vast network of
volunteer programmers. Linux is built on an egalitarian ethic: Perhaps not
every programmer will write great code, but together, all those eyeballs
and all those keyboard-pounding fingers will incrementally make their way
toward greatness.
But Joy doesn't believe that having more programmers equals better code.
"Most people are bad programmers," says Joy. "The honest truth is that
having a lot of people staring at the code does not find the really nasty
bugs. The really nasty bugs are found by a couple of really smart people
who just kill themselves. Most people looking at the code won't see
anything ... You can't have thousands of people contributing and achieve a
high standard."
Joy even disputes the commonly held conception that BSD set the model
for demonstrating how a large software project could be built via
contributions by a widely distributed network of programmers.
"Almost no fixes came in from anywhere else," says Joy, referring to
Berkeley Unix. "In fact, most of the stuff I got back was not that great.
Remember, there wasn't a real swift network at that time. In later years
you got stuff back, but I didn't get much stuff back during that time that
I was doing."
Joy may be overstating the case. Leffler and McKusick, while conceding
that 90 percent of outside contributions did not meet Berkeley's
standards, state authoritatively that significant portions of BSD code
came from outside Berkeley. And after Joy's 1982
departure
to Sun, the percentage of outside contributions began to rise, in tandem
with the rise of the Net. Joy may be overreacting against the new
generation of open-source hackers, many of whom frequently fail to
acknowledge (or even be aware of) Joy's contributions to the software
ecology that underlies the entire free-software movement. Joy says that
when he boots
*
Red Hat Linux, he sees boot-up messages scroll by that he personally wrote 20
years earlier. Joy would much rather talk about his current passions,
Sun's Java and Jini, and when he's asked about Linux, he sometimes lets
traces of annoyance slip through. Who are these punk hackers, some of whom
weren't even alive the first time Joy rewrote the Unix kernel?
"If I had to rewrite Unix from scratch, I could do it in a summer,
easily," says Joy. "And it would be much better. A much, much better job.
The ideas are old."
But if an increase in the number of programmers doesn't ensure an
increase in the quality of code, then why do Linux-based operating systems
dominate the market today? And if Joy rejected most contributions from
outside Berkeley, why does BSD enjoy a reputation for pioneering the model
for collaborative open-source software development?
"BSD was Bill Joy, initially," says McKusick. "He did the
distributions and talked about them and pushed them out. He would give
talks, and, inevitably, at the end of the talk he would say, 'And if you
have any cool stuff, come talk to me.'"
But, Eric Allman hastens to interject, Joy did not invent the concept
of freely redistributing software at Berkeley. That "seemed to be an ethos
that permeated Berkeley in general," recalls Allman, who had worked in the
early '70s on a database project called INGRES that was widely
redistributed. And after Joy was gone, that ethos, says Allman,
continued.
It is a gorgeous spring Sunday in March. McKusick, Allman and I are
sitting around an outdoor table in the backyard of "Chez Oxford," the
north Berkeley cottage that Allman and McKusick have lived in for nearly
20 years. The first warm sun after a month of nearly continual rain is
beaming down upon us, combining happily with a stream of selections from
Chez Oxford's copious
wine cellar.
Allman and McKusick can use some relaxing. Allman's company, Sendmail,
is in the midst of a hectic round of financing and has just released a
major upgrade. McKusick, meanwhile, has sent the entire BSD community into
a tizzy by orchestrating a merger between BSDi, a spinoff from the CSRG
that sells a proprietary version of BSD, and Walnut Creek CD-ROM, the
largest distributor of the FreeBSD distribution. Plans are even afoot for
the migration of some code from BSDi's proprietary BSD/OS into the
completely free FreeBSD. Interpretations of the merger's significance vary
wildly. To some, it's a concession that BSDi's proprietary offerings are
making no headway against the Linux onslaught. To others, the merger is a
hopeful sign that the days of BSD splintering are over: The community is
re-forming again, readying itself for a new round of sparring with other
operating-system upstarts.
If Joy was the heart of BSD, then McKusick is its soul, the keeper of
the Berkeley Unix flame. After Joy's 1982 departure, Leffler lingered
around Berkeley long enough to complete the delivery of BSD 4.2 to DARPA,
and then also left academia for the more lucrative embrace of Lucasfilm
and, later, Silicon Graphics. McKusick, who had until then been juggling
his dissertation with various BSD tasks that Joy talked him into doing,
picked up the reins.
To this day, McKusick says proudly, he is one of the only original BSD
developers who subscribes to developer mailing lists for all the
major BSD spinoff distributions. Every night at 2 a.m., one of his
computers downloads that day's modifications of FreeBSD and recompiles the
system, keeping him excruciatingly up to date. If anyone can claim a
comprehensive perspective on BSD's evolution over time, it is
McKusick.
Like his fellow BSD coders, McKusick disavows revolutionary fervor or
Berkeley radical ambitions.
"The contribution that we made, ultimately," says McKusick, "was in
developing a model for doing open-source software ... We figured out how
you could take a small group of people and coordinate a software project
where you have several hundred people working on it."
McKusick outlines an organizational model that grew up in the wake of
the departure of Joy and Leffler. At the center, there is a "core group"
--
a set of programmers who control access to the code, by granting or
revoking the right to modify or "commit" new code to the code base.
Spreading out from them are the "committers" who have that right.
Extending out beyond the committers are the general community of
developers who submit changes, bug reports and fixes to the committers.
Most of today's high-profile open-source projects, such as the Apache Web
server and the GNU project, use a similar form of organization. Linux is
the major exception. There is no core for Linux -- just Linus Torvalds,
followed by a tier of trusted "lieutenants."
"The committers," says McKusick, "were a group of people we trusted to
commit stuff that were responsible for things. The notion was that you
didn't have all these autocratic controls ... Now, you could have snuck in
and committed something to the kernel, some kind of trapdoor even. I won't
say we wouldn't have been none the wiser, because we did in fact keep
close tabs on what was going on in the kernel, but we didn't need to tell
people not to do that; we didn't have to administratively keep them from
doing things they shouldn't be doing. We had set up a culture as well as a
structure."
Still, 90 percent of the contributions were thrown away; the rest, as
McKusick likes to say, "were peed upon to make them smell like
Berkeley.
"The trick is that ultimately you find that small nugget of people who
are the really good ones, and that's why we have this whole hierarchy,
that's why we still have a hierarchy today," says McKusick. "Yes, there
are thousands of developers, most of whom honestly couldn't paint
themselves out of a wet paper bag if their life depended on it ... But you
still give them a place; you don't just dismiss them."
The circle has widened constantly, McKusick notes. Today, FreeBSD has a
core of 16, surrounded by nearly 180 committers and thousands of
developers. Even so, FreeBSD is dwarfed by the development community
contributing to Linux-based operating systems. Which raises the obvious
question, one that McKusick has heard hundreds of times over in recent
years: How did Linux-based operating systems overtake BSD?
There are some obvious answers. In the early '90s, as the power of
personal computers grew steadily, many Unix aficionados began seeking a
way to run Unix on their PCs. There were two contenders at the time,
386BSD, a version of BSD created by William and Lynne Jolitz for computers
built around Intel "x86" microchips, and Linux-based operating systems.
But the AT&T suit, combined with the slow pace of development on
386BSD, placed the whole BSD effort under a cloud. No one knew if AT&T
would succeed in quashing BSD altogether. Linux, in combination with the
GNU utilities, was protected by the ironclad GNU General Public License --
all the code was free and always would be free.
By the time the AT&T suit was resolved, the snowball ride to Linux
was underway. And the future development of BSD after 386BSD did little to
persuade hackers to change their minds. Developers dissatisfied with the
pace at which 386BSD incorporated new patches split off and founded
FreeBSD
and NetBSD in 1993. Not long after, an internal dispute within the NetBSD
core resulted in the spawning of OpenBSD. Meanwhile, McKusick and other
members of the CSRG founded BSDi.
McKusick shrugs off the widely held perception that the BSD community
is irreparably shattered. In addition to the just-merged FreeBSD and BSDi,
he declares, there are only two other major distributions of BSD, each of
which has its own particular focus. NetBSD specializes in porting BSD to
different computer architectures. OpenBSD concentrates on security
issues.
And how many Linux distributions are there? asks McKusick, rolling his
eyes. Fifteen, 20?
I point out that all the Linux distributions share the same kernel,
which is overseen by the strong, and generally impartial, centralizing
presence of Torvalds. BSD has no center.
McKusick looks a little wistful.
"This is somewhat egotistical," he says. "But I believe that had I been
willing to act as the figurehead ... I could have kept the community from
splitting. I had basically been in that position for 10 years, maybe 15,
and I had really felt that the time had come to pass the mantle on to
other people. I had a certain view of the way things ought to be done, and
at some point you want to get new blood. Honestly, what I really thought
was going to happen was, I knew that things would explode and there would
be a lot of different [distributions], and I figured most of them would
die off, and one would become the evident new one. And in some ways that
really has happened. I mean FreeBSD has, at least by seats, 80 percent of
the market, and the other two are interesting, but they are really out in
the noise."
Depending too much on a centrally unifying force, suggests McKusick,
isn't necessarily a strength. "What happens when Linus Torvalds either
dies, gets tired or otherwise steps away from it all? It's a huge weight.
He's done, in my mind, a terrible job of building something that lives
beyond him. If I got hit by a bus, BSD wouldn't really be affected a
lot."
As proof of his assertion, he notes that Torvalds does not rely on a
source code control software
*
program to administer changes to the Linux kernel. Instead, Torvalds
reviews each major patch by plugging it into his own development system.
But what happens if something goes wrong? How do you roll back to before
the changes? Where is the institutional memory, as embodied by software,
that will keep a project going when the original leader leaves?
When I e-mailed Torvalds after this discussion for a response, he
dismissed the problem.
"The purely technical side of keeping track of the sources can be
handled by source control packages," says Torvalds, "but at least, in my
opinion, they actually tend to favor the approach of 'Let's put this in
now; if it turns out to be a mistake, we can always revert it because we
have source control.' And of course, nobody ever actually does clean up
anything. Or hardly ever. So I think the real problem in computer
science is to have quality control before it even hits the distribution,
and so far there isn't any other package than the human brain that can do
that job."
Torvalds' answer is interesting, if only because the confidence that it
reveals echoes the strength of Joy's belief in his own abilities. Perhaps
Linux will not be able to develop BSD-like organizational structures until
after Torvalds leaves the scene.
Ultimately, the disagreements over organizational strategy between the
BSD and Linux camps are petty when compared with the similarities. As
McKusick is quick to stress, "The important thing is to be open source,
not whether Linux or BSD wins out."
And in that context, one can indeed see BSD, from the Joy era through
the McKusick era and beyond, as part of a continuum feeding energy and
enthusiasm into the current Linux upswing. Even during the earliest days,
Joy, as McKusick notes, wanted other people to contribute "cool things."
Ever since then, the trend line has been one in which the circle of
contributors has widened steadily. BSD demonstrated how to bring people
into the process -- by making them part of the process and by giving them
credit for their contributions. As Keith Bostic,
*,
the leader of the drive to create a version of BSD that included no
proprietary AT&T code at all, likes to say, "There is no end to the
world of good you can do by giving people credit."
Because what happens? You end up creating tools that everyone can use
to be even more productive, to create even-greater structures that
encourage collaboration, which in turn unlock even more creativity. That's
the essence of free software, and it goes beyond what kind of license
protects the software, or whether source control software is employed, or
even how arrogant the top developers might be. By opening up the code,
Berkeley widened the pool of software possibility.
Gage
*
didn't contribute to the code in Berkeley Unix, but he spent plenty of
time hanging around the computer rooms in Evans Hall, gabbing with Joy and
pondering the political implications of the computer revolution. Gage, a
mathematical statistics graduate student at Berkeley, was also a hippie
radical from way back -- involved in both the Free Speech Movement and the
antiwar protests. He was a delegate for Bobby Kennedy at the Democratic
Convention in 1968 and deputy press secretary for presidential candidate
George McGovern in 1972.
After three hours in Gage's favorite Berkeley coffee shop exploring
what the Internet means for individual liberty and what role Berkeley Unix
played in catalyzing the Internet's growth, Gage rolls his memories back
to perhaps the single most-famous moment in Berkeley's history of
activism.
He starts quoting the speech Mario Savio gave on the steps of the
administration building overlooking Sproul Plaza. He hunches over the
table, his eyes blazing with a sudden visceral intensity:
"'There is a time when the operation of the machine becomes so
odious,'" declaims Gage, "'makes you so sick at heart, that you can't take
part; you can't even passively take part, and you've got to put your
bodies upon the gears and upon the wheels, upon the levers, upon all the
apparatus, and you've got to make it stop. And you've got to indicate to
the people who run it, to the people who own it, that unless you're free,
the machine will be prevented from working at all!'"
Gage grins. Berkeley Unix, he proposes, offered a different way forward
from the painful agony of hurling oneself into the operation of a demonic
crankshaft. Berkeley Unix, with its source code available to all who
wanted it, was the "gears and levers" of the machine. By promoting
access to the source code, to the inner workings of that machine, the
free-software/open-source movement empowered people to place their hands
on the gears and levers, to take control of their computers, their
Internet, their entire technological infrastructure.
"The open-source movement is a free speech movement," says Gage.
"Source code looks like poetry, but it's also a machine -- words that
do. Unix opens up the discourse in the machinery because the words
in Unix literally cause action, and those actions will cause other
actions."
Savio is dead. The Free Speech Movement is half-forgotten. Few, if any,
of its participants would have predicted at the time that a network of
computers might prove to be free speech's greatest friend and best weapon.
Indeed, Savio's "machine" was in part a metaphor for what he saw as the
dehumanization inherent in information technology: The University of
California was IBM, the students were punch cards, both literally and
figuratively, fed into the machine, not to be folded, spindled or
mutilated.
The Berkeley Unix hackers, by helping to unleash the power of the
Internet, rehumanized the "machine." Those "words that do" instigated
connectivity and provoked communication. Somewhere, Savio is smiling.