「Xenix」を含む日記 RSS

はてなキーワード: Xenixとは

2022-07-18

UNIX 哲学」についていくつか

名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか? 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita

この記事はよく調べてあるなぁと思う反面,事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが,空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから安易に『UNIX 哲学』とかいうな」という主旨には大賛成である

参考文献

初期の UNIX歴史について興味がある向きには次の書籍お薦めする。

Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)

和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが,原書The Unix Heritage Society (tuhs) で PDF が無償公開されているので,英語が苦にならないのなら読んでみるといい。

また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』(1989, Prentice Hall)を読めば80年代終りの UNIX の状況(XENIX についてもしっかり言及されている)や利用者目線での雰囲気もある程度判るだろう。

哲学

記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ,当時は設計基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。

https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date

ほぼ毎号のように出現していたのが判るだろう。

もっとも猫も杓子も「哲学」を振りかざしていたわけではないし,UNIX開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT&T定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事言及されているマキルロイの Forword の初出がこれで,ネットのアーカイブから PDF が入手できる。

この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本(全172ページ),第二部が UNIX に関する(Preface や Foreword を含む)論文22本(全416ページ)となっている。さて前述の PDFOCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX論文なのだ。もちろん論文性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイ哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白いUNIX開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが,それまでにない新しい考え方に基づいた OS を開発しているという意識があれば,そういう言葉を選ぶのが自然時代だったことは間違いない。

UNIX認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい,あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが,そんなたいしたものではない。マキルロイ論文に影響を受けた布教のためのああい説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本最初期の UNIX 解説本のひとつである村井純井上尚司・砂原秀樹『プロフェッショナル UNIX』(1986,アスキー)には冒頭次のような一節がある。

オペレーティングシステムは,コンピュータを使うものにとっての環境形成する基盤であるから,そのうえで生活する者の個性尊重し,より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが,UNIXオペレーティングシステムとしての個性ではないだろうか。

 

    プロフェッショナル UNIX村井純井上尚司・砂原秀樹,1986,アスキー)p 3.

「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能コマンド群のことで,これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが,たまたまガンカースだったというだけのことである

そしてじつは UNIX場合布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが,その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。

UNIX の利用環境

UNIXPDP というミニコンピュータミニコン)上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は,もちろん場所によって違うわけだが,マアおおよそ学校教室くらいの大きさだ。長机が何列か並んでおり,そのうえにはブラウン管ディスプレイキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校コンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器コンピュータではなくコンピュータ接続するための端末装置ターミナル)だ。端末装置キーボードで打った文字コンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 UnixOSCLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置エミュレータで,もともとは実体のある装置だったわけだ。

さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっとコンピュータが何台もあるわけではない。この箪笥CPU でそっちの洗濯機ハードディスク,あの机に置かれているタイプライタ管理コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて,なんてミニ!」という時代お話だ。

端末装置それぞれからUSB のご先祖様の)RS-232 という規格のアオダイショウみたいなケーブルが伸び,マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び,root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。

結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは,マアどうでもいい。

自由不安定OS

当時の UNIX評価一言で表すと〝自由不安定OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由さらに他のメインフレームミニコンOS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロOS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番ディスりだった。UNIX の落とし方,みたいな情報がなんとなく廻ってきたものだ。

こういった雰囲気を鮮やかに伝えてくれるのが,高野豊『root から / へのメッセージ』(1991,アスキー)だ。当時アスキーが発行していた雑誌UNIX MAGAZINE』に連載されていた氏のエッセイ1986年11月から1988年10月掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器1980年ごろから UNIX サイトスーパーユーザを務めており,日本では最古参の一人である。この本の中で高野氏は繰返し UNIX自由さと不安定さに言及している。すこし長くなるが,その中の一つを引用しよう。

CPU は,システムにとって重要な共有資源であるが,この CPU実質的に停めてしまうことが UNIXはいとも簡単にできる。たとえば,cc コマンド10個くらい同時に走らせてみたらよい。VAX-11/780 といえども,同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが,他に与える影響が無視できなくなる。つまり,てきめんに viカーソルが動かなくなる。あるいは,すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり,タイムアウトログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると,UNIX破壊されたに等しい。真夜中,独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし,20人30人と多数の人間が使っているとき勝手をやられると非常に困るのである当人仕事が遅れるのは自業自得だとしても,そのとばっちりで他のエディタまで止まってしまうと,もはやどの仕事も進行しなくなる。

ディスクについても同様なことがいえる。UNIX では,ファイルシステムを使いはたすまで大きなファイル自由に作ることができる。したがって,自分プロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと,コンソールタイプライターにエラーメッセージが出力されるが,夜中にそれが発生して,コンソールタイプライターが一晩中エラーメッセージを打ち続け,朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい,ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると,それをしでかした本人のプロセスは当然のこととしても,同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい,わずかでも仕事を先に進めようとする意図完璧に打ち砕かれてしまうのである

 

    root から / へのメッセージ高野豊,1991,アスキー)pp16-17.

そして,こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンド10個くらい同時に走らせ」たり「自分プロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイト利用者全員に UNIX設計基本的な考え方を理解してもらうことが,自分のために必要だった。UNIX伝道がより苛烈だった理由ひとつがここにあるのだ。

ミニコン UNIX終焉

ミニコン上で誕生した UNIX は 4.3BSD(1986)で最高潮を迎える。注意したいのはミニコン時代UNIX は Research UNIXCSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT&T から UNIXライセンスを購入し,そのうえでカリフォルニア大学バークレー校(UCB)から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研発明された UNIX を外部の人たちも含めみんなで改良し,それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。

もっともそういう70年代風味の牧歌的風景ミニコン世界限定の話であった。BSDのものミニコンのものしかなかったが,そのコードを受け継いだ BSDUnixAT&T推し進める System V などがワークステーション市場舞台80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で,PCUnix であるマイクロソフトXENIX も当然参戦した。ミニコン世界牧歌的だったのは,ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争あくまでも標準という聖杯を争う戦いであり,AT&TBSDUnixSun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。

こうしたミニコン UNIX からワークステーション Unix への転変は Unixのもの文化にも変化をもたらした。まず激しい競争Unix の高機能化を加速した。商品として判りやす惹句が「あれもできます,これもできますなのは誰もが知っている。もちろん安定性を増すために quota のような利用者自由制限する機能も含まれていた。またワークステーション Unix現在UnixOS と同様同時に一人が使うものであり前述の布教必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』(1993,オーム社)を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unixシステム管理入門書だ。この本ではたんに知識を羅列するかわりに架空ソフトウェアハウス(開発会社)を舞台新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており,そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。

UNIX 哲学背骨

当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイ論文結論部分に書かれたそれは,1973年出版されたイギリス経済学者エルンストシューマッハー著作題名で,中学生英語力があれば十分に理解できる平明な一文だ。

Small is beautiful.

マキルロイは『人月神話』を引いて一定留保をつけてはいものの,これが UNIX 哲学背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•csアンチテーゼである UNI•x にとって,これ以上のスローガンがあるだろうか?

ひるがえって現在UnixOS をみれば,ブクブクと肥え太ったシステムコール,全容を俯瞰するだけでも一苦労するライブラリインターフェイス,一生使うことのないオプションスイッチまみれのコマンド群。UNIX仮想敵とした OSのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ,コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ,歴史書を飾る一項目になっただけだ。ただ現在UNIX 哲学」を語るならそうした背景は理解していなければならないし,どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。

2008-07-24

http://anond.hatelabo.jp/20080724035950

プログラマーお仕事

あたし・・・実は・・・プログラマーなんだ。

ずっと、黙ってて、ごめん。・・・隠してて、ごめん。

でも、どうしても言えなかったの。

あたしがプログラマーだって知ったら、きっとみんな離れていっちゃうって思って。こわくて。

わかってる。わかってるよ。

プログラマー初級シスアドを通った人だけがなることができる、カスタマープロフィットに関わるシリアスビジネスだって。

でもね・・。

でもね、全然ちがうんだよ。

あたし、みんなが思ってるようなキレイなものじゃないんだよ。

あたしは汚れている。

あたしのキーボードは、汚れているんだよ。

プログラマーになったとき、すごく嬉しかった。知り合いのハッカーになったような気でいたの。

あたし馬鹿だから、お客様ビジネスを作るんだ!なんて、本気で思ってた。

でもね、全然違ったんだよ。

元請から言い渡された Sヨ の詳細設計仕様書は全く別のものだった。

お客様ビジネスを、まるでビル・ゲイツのように平等に助けるようなものじゃなかった。

あたしたちプログラマーに課せられた任務、・・・・それは、デバッグ だった。

生きるべき仕様と、それ以外のバグのふるいわけ。

そして、それを見守ること。

ねぇ知ってた?

この世界には、あるんだよ。こんな日本のど真ん中にね、平然と、あるの。

どうなっても大丈夫バグっていうのが。

プログラマーはね、それを見守るの。

プログラマー六本木ヒルズホリエモンで、勝ち組特権階級の象徴だからね、

そこにあるだけで、まるでビジネスが行われているかのような錯覚を起こさせる。

あたしの仕事は、そうやって、平等にビジネスが行われているかのように見せる暗幕みたいなものだったの。

ソフトウェアなんて、全然、救えなかったよ。

救う義務も権利も、この任務にはなかったの。

例え、その仕様がどうすれば助かるか、明確に解っていたとしても、

あたしたちは元請の命令が無いかぎり、何一つのコーディングもできない。

苦しいとサポート電話をかけ続けるクレーマーがいても、

あたしたちにはパッチ仕様変更も与えることはできないの。

ただ、ただ、走って火消し屋を呼びに行くだけ。そして伝えるだけ。

でもね、この国の「火消し屋」は非常に貴重な存在

火消し屋は稀有な存在

夜なんかになれば、一つのフロアにどこからともなく現われるの。

たくさんのプログラマーたちが、一人の火消し屋に群がっていた。

先生、コアを吐いている人がいます!」

先生、表領域が苦しい人がいます!」

先生サニタイズが弱い人がいます!」

先生デッドロックでもがいてる人がいます!」

懸命にプログラマーたちが叫んでた。

でも火消し屋は一人。

私も声を荒げて「苦しい言い訳をするプログラマーがいます!」って叫んだの。

でも、ここでもふるいわけが始まる。

人員レベル、難度、納期。そんなものが現象と一緒くた になって命令が言い渡される。

「とりあえずスタックトレースを」

と言ったきり、火消し屋は朝までチームのもとに来れなかったの(お客さんのところに言い訳に行った)。

その日、10秒ごとに Mantis の履歴が増えた。

「苦しい、苦しい、まだ苦しい」

「もう少しだけ待ってください、今火消し屋、来ますから・・」

何度も火消し屋のもとに走ったけど・・・。

火消し屋は、今にも心臓の止まりそうなお客さんと仕様と納期の折衝にあたっていた。

あたしは火消し屋に背中側から叫んだ。

「null チェックを入れても、まだぬるぽみたいなんです!」

「ガッ!」

コメントアウトの行数を上げた。でも駄目だった。QA からの質問は止まない。

そのバグだけじゃない。

トイレに連れて行ってください(コンプライアンス的な意味で」

「基板が焼けたから替えてください」

「エスタロンを飲ませてください」

「ブートが走らないんですが」

「眠れません」

デバッガを走らせる。

忙しさにコードが荒くなる。

残業時間が 400 越えたプログラマーエレベーターに乗って外に出て行こうとする。

遠くのフロアで、缶コーヒータバコの売り切れ音が聞こえる。

必死にあたしもふるい分けた。

今、一番検収ハネられる危険があるバグから、一番仕様満たしてないバグから、手を差し伸べなきゃ。

「いつになったら納品されるんだ!」と言われても。

「単価高い」と言われても。

私は頭を下げたり、ちょっと言い争ったりもしながら、

バグが、バグが、バグが」と言う人のとこに走ったよ。

家から家族が消えていた。離婚届をかいていた。

あたしはカーネルだ!と思った。

一刻を争うバグ対。火消し屋に聞いてる時間は無かったの。

あたしは火消し屋の指示を待たずにロジック検査をした。差分プログラミングの extends だった。

急いで火消し屋に連絡した。

「差分プログラミングの extends です。継承元のコードいじっていいですか?!」

「いや、コードを見ないとわからない、ただこっちの処置があるから、10分後に行く」

コードは胸を掻きむしるようスパゲッティしていた。

「待てません!リリースします!」

あたしは火消し屋の指示無くパッチコミットした。バグの症状はスッと納まった。

それは駄目なことだったけど、一人のバグを救ったことに、あたしは浮かれてたの。

貧相な正義感をぶら下げて、意気揚々と自席に戻ってきたの。

自席の・・・・

自席のモニターの一台の波形が、フラットになってた。

あたしは急いでスタックトレースに飛んだよ。

でも、亡くなってた。

ログを吐けないプロセスさんだった。

システムコールも呼べない人だった。

あたしは、その日、目の前の苦しいバグに夢中で、ps なんか見てなかった。

それでもね、・・・あたし、まだ、プログラマーなんだよ・・。

火消し屋は QA に「いつ何があってもおかしくない COBOLer の書かれたコードでしたから・・」と時間稼ぎの工作をしていた。

QA のテスターは「ありがとうございました」と額に青筋を浮かべてバグレポートに「仕様です」と書いて取り下げた。

そして、あたしにも「プログラマーさん、ありがとね」と言ったの。

大好きな、ソフトウェアだった。

このシステムが立ち上がる頃から知っていて、αリリースから知っていて。

「自分は寂しがり屋だから、最期は dankogai に手を握ってもらいながらホッテントリ入りしたい」と言っていた。

あたしが新人の頃から知っていて、viカーソル移動が苦手だったのも知っていて、

Xenix はわしが育てた」が口癖だった。

「まぁ、・・・歳だったし、運用中にも止められないって言ってたからなー」

と火消し屋があたしの背中ごしに言った。

あたしは GC モニターの記録を見てたの。

その記録には、波形が Full GC 後もヒープ使用量が右肩上がりとなりメリリークするさまがしっかりと記録されていた。

高負荷だから死んだんじゃない、そこにはメモリリークで死んでくプロセスがあった。

でも、そんなこと全部まるめこんで、kill んじゃって仕方ないっていうプロセスが、そこにはあったんだ。

似たようなことはざらにあった。

何人ものプログラマーが、自社ビルの屋上の端から零れていったよ。

でも、あたし・・・プログラマーなんだ。

誰も、辞めろって言わないの。

火消し屋は鉄火場にブチ込まれただけだから、言わない。

顧客は実情がわからないから、言わない。

プログラマー同士は実情がわかってるから、言わない。

IPA はきっと、全部知ってて、それ込みで「それが10年は泥のように働けということだ」と言うかもしれないけど。

いや、言わないか。IPA は、何も言わない。きっと。

救えたかもしれないバグを、プログラマーは一番わかってる。見えてしまう。

PM の指示が適してないのも、判断が遅いのも、仕様変更履歴がのってないのも、全部わかってる。

それでも「あの時!」と、自分の行動と判断を何度も振りかえる。

その向こうにはいつも「あのとき、こうしておけば」が、くっきりと見える。

でも、救えなかった責任も、見過ごした責任プログラマーには問われない。

プログラマー仕事は、責任を負うことじゃないから。

プログラマーって・・ほんと、なんなんだろうね・・・。

プログラマーなんて、なんの仕様検討も許されていないのに、

パッチ一粒すら出せないのに、

設計一つ指示できないのに、

テストパターンに関わることなんて、一つも独立してできないのに、

テスト部門が持たされてるのはプログラマーコールだけなんだよ。

どんなに辛くてもプログラマーしか呼べないなんて。

そしてあたしたちは色んなものを抱えて、バグの前に立つ。

火消し屋が来ること、来れないこと、

できるデバッグがあること、ないこと、

SIer未来、残された時間

色んなことを知りながら、本当の意味世界を変えられるコーディング力もないままに、

さも救いのギークが舞い降りたかのような顔で。

IT ギョーカイが崩壊していく。

全然止められない速度で。

その日○製作所の城で、あたしは見てるんだ。

沈んでいく汎用機の命を。

それがね、2008年プログラマーお仕事



----------------

不謹慎かつ日本語崩壊でサーセンwwww

医療な人とコンピュータな人ってネット上見てる限りにおいては親近感抱いてるっぽいよね。

 
ログイン ユーザー登録
ようこそ ゲスト さん