特注のケーブル開発のアルバイトの話があった。

といっても数が出ないので希望価格で提供するとなると開発費を負担して頂かないとご希望の単価では単年度で消却できそうもない。

まともに開発するとハードウェアはすぐに出来たとしてもファームウェアとWindows上のサポートソフトウェアの開発に人と期間を要する。

どっかで出来合いの中国製品でもあれば紹介したいところだが、用途が用途だけに世の中に同じものは無い。

一応技術的な算定をしてそれなりの根拠でソフト開発費一千万円を提示させて頂いたが、それを受けてお客様は腰が引けたらしく急遽別方法が無いか真剣に再検討し始めた模様。

開発するのはケーブルのハードウェアだけでソフトウェアは不要だと思っていたふしがある。実際それ以前に検討して採用寸前まで行ってある理由で使えないことがわかりドタキャンした案があったらしい。それは確かにただのワイヤーケーブルだけで接続できる。しかしPC本体側に内蔵されている専用チップとそれ用のソフトウェアがプレインストールされたシステム。外付けに転用できないというのが不採用の本当の理由だと思われる。

高く売れるなら自社製品として開発してもおもしろいかもしれない。けど高いとすぐにより安いカウンターテクノロジー製品が採用されるので結局は損をすることになるかもしれない。

ソフトウェア開発の仕事では他人の書いたソースコードをどうしても読まないといけない時がある。それが危険に身をさらす場合があることは一般には知られていない。

自分の書いたコードだけ読むまなければならないのはデバッグ等で常なので問題ない。

ソースコードというのは書いた人の脳の神経回路のコピーのようなものなので、書いた人によって回路が違うのは当然。正常な精神状態の持ち主が書いたソースコードであれば整然と整理されていて問題ないが、そうでない人が書いたコードだとしたらどうだろう。

他人のソースコードを読むという行為は、読む側の脳の神経回路に他人の神経回路をコピーすることを意味する。もし、異常な回路をコピーしたとしたら、身体的に危険を及ぼす恐れがある。

前任者が体調不良になり連絡がまったく取れなくなってしまったというWebサービスシステムの尻ぬぐいを引き受けた時のことである。

さっそく実際のコードを拝見したのだが、テストサーバーとライブサーバーの２つがあって、テストサーバーで変更を試して欲しいとのこと。実際に２つのサーバーのコードを見たところ違和感が走った。通常はテストサーバーに新しいコードがあり、ライブサーバーには動作確認された枯れたコードがあるはずだが逆になっていた。

おそらく前任者は時間に迫られテストサーバーで試す時間を惜しんでライブサーバーにどんどん新しい変更を適用していたと察する。

私の任務は、前任者のバックログを出来るだけ消化するというもの。それ以外に前任者が変更途中のままにして動かなくなってしまったものを変更以前の動作に戻して欲しいというのもあった。

要望された問題点をすべてスプレッドシートに整理して未解決問題のステータスを入れて一覧化しひとつひとつ調査を開始することにした。

調査を進める中で前任者が残したソースコードを読み取り、前任者が何をやろうとしていたのかを知る必要があった。その過程で危険に身をさらすことになるとは思いもよらなかった。

脳の回路にショートがあったとしたら、それをコピーしてもショートする。当然である。ソースコードには理解しがたい矛盾のあるコードが随所に見られた。それらコードが書かれた整然とした理由を追及しようとしたところ強烈な鬱状態に襲われた。

おそらく前任者が強烈なプレッシャーの中で同時に様々のことを考慮しながら変更やデバッグのための仕掛けを施したと思われるが、そこに尋常では考えられない論理的な矛盾が明らかになったのである。

昔SF映画で「２００１年宇宙の旅」に出てくるコンピュータHAL9000が互いに矛盾する２つの密命を受けたために発狂し宇宙飛行士を殺害しようとする話を思い出した。

前任者が依頼主から命じられた複数の任務に相反する矛盾があることが鬱状態に襲われた原因であることに気づいた。

前任者は優秀な学生アルバイトで、わずかな時間給で新しいシステムを一人で書き上げていったらしい。しかし完成が近づいてデモや試験運用がはじまった途端に、とんでもない要望が寄せられ、前任者にその解決が任されてしまった。その中に相反する要望があれば、どれを優先するか、どちらかを我慢してもらうしかないのだが、優秀なだけに果敢に両立を試みた痕跡（新しい行を書いてはコメントアウトした残骸）が多くみられる。

私は、相反する現在使われていない機能をばっさり削除して、使われている機能への要望を実現するというだけだった。

技術者でないと発言力のある利用者から寄せられる要望で相反して同時には満たすことのできないものを区別することができない。経営者や営業はそれがわからないから利用者側の味方になって技術者に無理難題を押しつけることが避けられない。学生アルバイトだとしたらそれに抵抗することはほぼ困難だろう、自分の命を絶つ以外に選択肢は無かったのだろう。

これは小説のネタではなく実話である。

期末が近づくと毎年恒例の他人の尻ぬぐいアルバイトの依頼が相次ぐ。

有名メーカーも技術の空洞化は著しく、その傾向は年々強まる一方だ。組み込み機器のファームウェア開発も外部委託は当たり前、それも複数候補を入札で最も安い金額のところを選ぶというもの。当然ながら実力、経験の豊富なところは安い見積もりは出さないから、必然的に落札するのは実力、経験とも皆無のところ（もっとも技術力のないところ）になる。

今回はデバイスを変えたらシステムが立ち上がらなくなったという障害に関するもの。

その程度なら普通は開発担当者が原因を切り分けられて当然なのは昔の話。ソフトウェア開発は外部委託業なので、発注元が明示的にソフトウェアにこれこれこいう不具合の原因があるから、こう直せと指示しない限りがんとしてうごかないらしい。

不具合の原因は当然ながらハードウェアとソフトウェアのどちらにも可能性があるから、ソフトウェア開発業者はハードウェア原因説が主張できるかぎり一方的に責任を押しつけられることをこばむ。

昔のソフトウェア開発者ならば、たとえあらぬ因縁をつけられても黙々と調べて真犯人を突き止めるのだが。そういう気概のある技術者は居ないらしい。

そうやって開発が宙に浮いてしまって開発そのものが中止になったりするものも多いが、今回はもう量産Goを出している矢先の障害だけに解決が急がれている。

国産MPUで量産基板なのでJTAGとかのデバッグ手段はそもそも使えない。開発時のラージボード（評価基板）ならROMエミュレーターをつないでトレースするということもできるだろうけど、回路そのものが量産と違っているのでソフトそのものが動かないらしい。

ロジアナで障害発生前後をトレースするにも信号が取り出せない（信号がすべて内層を通っているのでプローブをあてられない）

あとは問題のブートローダがGPLのオープンソースを使っているので、それを調べて条件を列挙するしかない。

または以前に別の尻ぬぐいでやったようなfixtureを自作してロジアナでトレースできるようにする必要がある。

立ち上がらないというのだから条件は絞り込まれるはずである。

こういったケースがごく一部の例外であることを願う。

しかしこれをやり遂げても、貰えるお金は時間当たりにするとファミリーレストランでアルバイトした方が全然割りが良いというのも情けない話だ。とりあえず先々の食費に充当できる程度。路上生活を回避できるものでは到底ない。

あといくつ寝ると、路上生活♪

アルバイトの仕事でとある組み込み装置のLinuxサポートを引き受けたのだが、問題なく先月末に納品してほっとしていたら忘れたころに「動かなくなった」というメールが

どうやら中国製のタッチスクリーンパネルのドライバを入れたらこちらの装置とのやりとりができなくなったらしい。

ばかな、本来は責任範囲外だが、再現環境をお預かりして調べてみたところ驚愕の事実が発覚。

問題の中国製タッチスクリーンパネルのソフト（というかデバイスはUSBシリアル変換なので、ユーザランドのサーバーデーモン）がこちらのUSBシリアルデバイスノードを先にオープンして受信データを横取りしているらしい。こちらも似たような方式なので横取りされるとおかしなことになる。

問題のタッチスクリーンパネルのソフトをバイナリダンプすると/dev/ttyS0,/dev/ttyS1,/dev/ttyUSB0とタッチスクリーンデバイスが接続されるポートが決め打ちされて変更できない。複数のUSBシリアル装置がつなることをまったく想定していないらしい。

仕方ないので、こちら側はデバイスノードはハードコーディングではなく設定ファイルで任意のデバイスノードに変更できるので、udevルールファイルを作ってデフォルトのttyUSB?ではなくユニークな名前でデバイスノードが作成されるようにして難なきを得た。

しかしデバイスノード名をハードコーディングするとはどういうことだ＞中国人Linux技術者

まだまだだな中国人

定収入もなくなっていつかは路上生活をしないといけないと覚悟をきめているのだが、期末になると何故か予算消化のためのアルバイトの仕事が来る。

これで路上生活を数ヶ月遅らせることができるのでそれはそれで幸いなのだが、納期が超短い。

昔なら１ヶ月とか３ヶ月とかもらって当然な組み込みソフトの開発も一日でとか要求される。さすがに一日はないだろう。

まあ、ソフトウェア開発者は社会の必要悪なので、必要ないならこしたことはないが、しかたなく仕事を出す、仕事が終わったらもう居てもらっては困るという感じ。

もともとソフトウェアはハードウェア開発者が責任放棄した結果生まれたダークサイドなので、本来はハードウェア開発者が責任を持たねばならないはずだが、なにか問題が起きると「ソフトウェアの不具合」とか責任転嫁する。そういう意図で生まれた職業なのだから仕方がないのだが。

かつて大英帝国でバベッジの解析機関の開発で資金集めのために貢献したバイロンの娘で才能豊かなエイダ嬢はガンのために若くして亡くなったが、バベッジが解析機関開発ベンチャー企業のCTOだとすればエイダ嬢はさながらCEOだった。最近エイダ嬢がバベッジの解析機関製作に必要な資金を集めるために書いた貴族向けの紹介文（「解析機関についてのスケッチ 1842年」）の翻訳（「電磁波を拓いた人たち　日本人も歩んだ４００年の度」福田益美著　アドスリー刊）を読む機会があったがうかつにも涙が出て止まらなかった。今のソフトウェア開発者の過酷な労働事情を知ったらエイダ嬢は卒倒しているかもしれない。泣いたのは確かに若い日にコンピュータに見せられた時に思い描いた夢と同じだったからなんだけどね。

とりあえずアルバイトの仕事は日中冬季オリンピックの中継放送をラジオで聞きながら進めた。聞いている方よりも実況中継しているアナウンサーや解説者が異常に興奮しているのに驚いた。いろいろドラマがあって思い出深いものになるのかもしれない関係者にとっては。

同時期にトヨタが最新機種でリコールを世界中で行って、とうとう来たかと思った。トヨタも例外ではなく、「ソフトウェアの不具合」と公然と責任転嫁をしているのには、トヨタ終わったなと思った。日本的な勘と経験の世界の限界が来ていることにトヨタさえも気が付いていないということだ。

今回のブレーキシステムの問題でも数理的な知識がある技術者なら問題の条件を引き起こすのを最初から割り出すことが出来ただろう。もしかして知っていても握りつぶしていたのかもしれない。

現代はソフトウェアも勘と経験に頼らずに、数理的に絶対見逃してはならないショーストッパー条件を割り出すことができる。トヨタはそれが出来る技術者を雇っていなかったというべきだろう。ソフトウェア技術者は必要悪で居ないほうがいいという考えだったに違いない。

安全性とかセキュリティとかの問題では数理的な知識が無いと勘と経験では追いついていけない世界であるのを古い人間は理解できないのである。

そう、ボルツマンが言ったように「理論は経験を超える」というのをトヨタの中の人には知って欲しい。

経験至上主義と戦ったHeavisideも理論を残していったが、一方の経験史上主義者は人とともに朽ちて何も残さなかった。

やはりトヨタもスーパーコンピュータが必要なのだ（違う）

なんだろね、Linux関係の仕事だと引き受けるところが無いのかな、またしてもLinuxがらみのアルバイト。

一応若い人がやっているけど進まないらしい。

移植するのにどうすればいいかわからずに立ち止まっているらしい。

アーキテクチャは既に移植済みだが、既存のとは一部ハードウェア構成が異なるらしい。

ということで何も手つかずでうんうんうなっていて毎日何もしない二人の若いエンジニア（の卵かな）

私からのアドバイスは、とっととロードして起動してみろ、それだけ。

ICEも用意されている贅沢な開発環境、昔はコンソールTTYしかなくてもやったぞ。と言うのは止めた。

しかし、起動の仕方を知らないらしい、そんなことするつもりもなかったから調べてもいないらしい。

なんというていたらく。肝心のところは全部他人頼みで、自分達の存在意義がまったく無いのに気づいていないとは。

脇からああだこうだ言いながら、ロードして起動させてみた。

あっさり立ち上がった。といってもファイルシステムが無いのでinitが起動できないというところで止まるけど。

今度はまたいちいち小言を言いながらFlashにカーネルとファイルシステムを書き込ませた。しかしここでブートローダーに問題があって、自分自身が格納されているFlash領域を書き換えてしまうことが発覚。なんだよ、一度も試してなかったのか、Flashへのイメージ書き込み。

急遽その問題解決が先決ということにして、こちらは先に退散して体を休めることに。立ちっぱなしだと骨格を支える筋肉がやせ細っているので全身がガタガタになる。一日横になってた。

翌日原因が判明して直ったというので、今度はFlashに書き込んだLinuxを立ち上げてみることに。

ちゃんと立ち上がった、ログインプロンプトも出て、ログインして操作も可能だ。完璧じゃないか。

なんだよ、こんなことに１ヶ月も何もせずに立ち止まっていたのか。それ以上言うと禁止用語が出てくるので自重。

やればわかることをしないで一ヶ月無駄に過ごしたとは、あきれてものも言えない。依頼主になんと言い訳するのか。

とりあえず何も変更せずに立ち上がったというのは依頼主には内緒にしておこう。どうせこれからいろいろ直さないといけないのだから。

有る程度経験を積んでいるはずな若いエンジニアは、典型的な自分が正しいという束縛に陥っている。新しい知識が必要なのに、それを自ら得ようとしないで悶々と自己ループに陥っている。時間はたっぷりあったのに何一つ試してみようと思うことが無かったのはもはや病気だ。

自分が到達しなければならない仕事の目標へのシナリオを描くということすらしない、周囲から鞭打たれて嫌々作業をさせられることにすっかり慣れてしまっているというのは情けない。もう一人は、依頼した作業はまったく手をつけず、自分のやりたい作業をどっかから引っ張りだしてきてはそれを延々とやっている。どこでもいつでも暇つぶしのネタが出てくる魔法のポケットを持っているのか。

誰だよ日本のソフトウェアエンジニアをダメにしたのは。

落ち着いて調べれば答えはすぐ見つかった。

Linux Device Drivers, Third Edition

これのChapter 15: Memory Mapping and DMAに必要なことが全て説明されてサンプルコードまで載っていた。

考え方が理解できれば、似たようなコードをすこし書いておしまい。

無事PCI-Xバスとカーネルとユーザースペースからメモリをトリプルマップできるようになった。めでたしめでたし。

でも今日は昼間から予定外の来客続きでちっとも時間がとれなかった。食事まで付き合って、職場に戻って少し落ち着いてからやったらすぐ終わった。

なんだ簡単じゃないか。

終わってみればそう思える。

Linuxの仕事、思わぬ伏兵が最後に待ちかまえていた。

Linusがcomp.os.minixでLinuxの公開をアナウンスした時に居合わせた世代だけど、その頃は皆競ってフロッピー一枚に入ったLinuxのイメージをあちこちのPC AT互換機のフロッピードライブに入れて試しだしたのがLinuxブームの始まりである。

当時試したDELLのマシンはフロッピー制御のタイミングが早すぎてブートしなかったのを憶えている。いろいろとハードウェアの相性というかタイミングは千差万別だというのがわかった。

LinuxはPOSIXという当時IEEEとかが制定したUNIXのAPIや基本コマンド群の仕様を外部仕様として採用した。これは今も変わっていない設計思想である。しかし外側はそれで変わらないが中身は今もどろどろとサナギの様に変貌し続けて定まらない状態である。

Linux 0.99とか限りなく1.0に近づいていた頃はとても単純だったけど、PC AT互換機よりも手の込んだアーキテクチャをサポートしはじめた頃からどんどん巨大化複雑化して来た。

PC AT系のアーキテクチャはメモリが中央に固まりとしてどんとあって、バス上のデバイスやCPUがそれを共有するという、いわゆるUniform Memoryアーキテクチャであるのに対して、CPUを複数搭載した対称型マルチプロセッサシステムでは、それぞれのCPUの処理負荷が高くなるとメモリーアクセスの負荷がUniform Memoryアーキテクチャで一点に集中してCPUが互いのメモリアクセスを邪魔し合うということになり性能が出ないということが明らかになった。

そこで登場したのが、CPU毎にメモリを分離して、メモリを分断するというNon Uniform Memoryアーキテクチャ(NUMA)が登場。

でもNUMAの場合は周辺バスがCPUやメモリから遠ざかることになるので周辺デバイスがメモリやCPUとお話する場合に遠くて時間がかかるというペナルティがある。

それでも計算を早くするにはCPUに最も近いところにメモリを置くのが正解。それぞれのCPUは最寄りのメモリをアクセスする頻度が高くなればなるほど他のCPUを邪魔することなく理論的にCPUの個数に比例して処理能力も上がる。

そうしたちょっと逆説的なアーキテクチャも同じソースコードでサポートしなければならないので百年戦争のようなアイデアの戦いが今も続いている。ある人がある案をだせば別の人ももっと良い案を出して、新しい案が消えてはまた別の現れるという感じ。

久々にカーネルメーリングリストを覗いたらつい最近も今回悩まされた技術的な問題をどうゆう方向にもっていくか議論されていたようだ。

まあ、特定のアーキテクチャに関してはそれを使える人とメンテナンスやパッチを提供する人は自ずと限られるのでいずれは定まっていくのだろうけど、仕事となるとそれを待ってはいられない。

ここはオープンソースの良いところ、面倒だけどそれなりに労力を費やせば自分の好きなように修正して問題解決が出来る。

これがクローズドな商用OSだったら地獄だ。手も足も出ないだろう。

昔DECのVAX/VMSのパッチを考案しては米国DECに提案していたけど、「あ、その機能外すことにしたから」とか米国人らしい技術的な決定に唖然とすることも。日本人はなんとか機能は残してより良いものにと思うのだが、米国人は割り切りが早いので問題のある機能は削ってしまうのが一番というカルチャーの違いがあったり。

初期のVAX/VMSはそれ以前のミニコンピューターの主要な需要家だった組み込みシステムやリアルタイムシステム向けに設計されていた。売り文句もリアルタイム向きですからというもの。でも当時仮想記憶をサポートして汎用機並に大きなアドレス空間を消費する大型アプリケーション（ＣＡＤ、シミュレーター、画像処理）の要望が強くなり、次第に今で言うコンピューティングサーバーみたいな方向に進路を変えていった向きがある。決定的だったのは、V2まではスワップスペースがシステムの最大ワーキングセットサイズ＊最大プロセス数だったのが、プロセスの最大ワーキングセットサイズが可変になったのでスワップスペースのアロケーションも可変長に変わったことだった。これは何を意味するかというと、以前は最大ワーキングセットサイズ（１プロセスが使用できる最大仮想アドレスページ数）分のスワップスロットが最大利用可能なプロセス数分配列で用意すればよかったのが、可変になると全体でいくら用意してもフラグメンテーション（虫食い）状態になると全体のスワップスペース分の割に同時期に走行可能なプロセス数が制限されることになる。言い換えればV2まではどのプロセスも1stクラスで各自用に十分な個室が予約されていたのが、全員自由席、席取りは早い者勝ちということになってしまったのである。V3からそういうことになったのでいろいろ支障が出てきた。

組み込みシステムでは基本的にディスクへのワーキングセットの吐き出しは発生しないようにメモリは十分積んでいる。V2の頃は配列分ディスクスペースを用意していれば書き出されることはなくともプロセスがワーキングセットを最大値までのびのび成長させることは出来た。しかしアロケーションが可変長になると、動きはじめはワーキングセットが少ないけど、処理を重ねるたびにワーキングセットが成長し、それまでアロケートしていたスワップスペースがそれに合わせて拡張できない状況が発生し得る（前後に隣接して他のプロセスのスワップ領域がアロケートされて挟まれている場合）。

そうするとまだまだ伸び盛りなのに他にもっと大きなスワップ領域が空いていないとワーキングセット（アドレススペース）を拡大できないという問題が発生する。アドレススペースが拡張できないとページフォルトで処理が止まったままになってしまう、これはリアルタイムシステムではあってはならない事態。

実際にそういう事例や状況がいろいろなシステムで発生することが知られていたので、上司に命じられて対策を考えることにした。当時上司が考案したVAX/VMSにシステムの再起動の必要の無いランタイムにカーネルにパッチを施すことができる画期的な方法を考案したので私にその具現化の機会が与えられた、その方法をつかってスワップスペースが虫食い状態なったのを自動的に検出して、今でいうファイルシステムのデフラグメント処理みたいに、並べ替えをするコードをVAX/VMSカーネルに、今で言えばレトロウイルスを使った遺伝子操作と同じ方法だ。パッチは恒久的に施すのではなくメモリ上にのみ施す。システム起動後の任意のタイミングでパッチをあてるプログラムを自動起動するようにしておくだけ。

効果はてきめんでスワップスペースのフラグメント化ですくんだプロセスが出るとアロケーション状態を整理しなおして、大きな空きスペースを作り、成長したプロセスがそこにもっと大きなスワップスペースをアロケートして引っ越せるようにした。

まあ今のようにメモリが有り余る時代ではなく数MBも貴重だった時代なので、そういうことも有用だった。今ならディスク増やせばいいじゃんとかいう話になってしまう。当時は60MBでも大きい方だった。

なんの話だっけ。

ああ、Linuxの話ね。

これも仮想記憶に関係する根深い問題なのだけれども、カーネル中のデバイスドライバがアロケートしたメモリ空間をユーザーからもアクセスできるようにダブルマップするというのがVAX/VMSの時代から当然のごとくある。しかしLinux 2.6になってそれが大変やりにくくなってしまったらしい。というのもそれに絡んだ処理でDoS攻撃の標的になる脆弱性が見つかったらしいのもある。

でもページングとか仮想記憶の原理を知っていれば、ああなんだという方法なのだが、2.6カーネルでも出来るらしいし、数少ないけどそういうことをやっている既存のドライバもあるらしい。

それと同じことをやれば問題は解決。目出度し目出度し。まだ終わっていないけど。

朝だ徹夜だ！

そういう名前の作家が昔居た記憶が。「麻雀放浪記」昔読んだっけ。

もう夜だし、まだ一睡もしていない。

どうやら年号だけが常に2021年になるらしい。

下手に2008年に戻してファイルを作ったりしたのがまずかった。

このLinuxポートの日付の仕組みは別の機会に調べてみることにしよう。

ようやく仕事が進んで一難去ったかと思ったらまた伏兵が。

時々何もしなくてもシステムがフリーズしている。

いろいろ調べるとPCI-Xバスに挿しているアドインカードが割り込みを出しっぱなしになって固まっているように見える。

なにもしてないのに。

いや厳密にはちょっとだけ触っているのだが、それが変な誤動作を起こすはずもない。

クラッシュさせてどこで止まっているか調べると、アドインカードから滅多に発生しない割り込みがかかった先で止まっている。

ばかな。バスがフリーズしているのか。

そういえば、このアドインカード、持ってきた人が、「これ、修理上がり品なので、念のために新品も持ってきてますので、おかしかったら交換して使ってください」と言っていたのを思い出した。

そういえば、以前別の修理上がり品を動作チェックしていたら、修理依頼する前と変わらなかったという前科がある。

最初からちゃんと動作する新品（これは以前確認済み）に差し替えておけばよかった。

いろいろリスクを回避する機会があったのだが、無駄な時間を費やしてしまった。

これで明日でちょうどギリギリ作業終了。

暇が出来る。

原因不明の怪事件が続いて今週末納期の仕事がピンチに。

諦めようかと今何時だろうかと夜中にコマンドを叩いたら原因の一端は判明した。

このマシン、年号がめちゃくちゃだった(;´Д`)

一応dateコマンドで設定すると正しく2008年になるのだが、立ち上げ直すと必ず2021年になってしまう。

年号だけでなく、時刻もおかしい。立ち上げると何故か18時にリセットされる。

これがどういう結果をもたらすかというと、ファイルのタイムスタンプの時系列関係がめちゃくちゃになるということ。

どうりで、いくらソースコードを修正してビルドし直しても一向に変更前と変わらないわけである。立ち上げてすぐにソースコードを変更してビルドしても時計は2021年の18時にリセットされているので、時計が逆戻りしているのでビルドされてなかった。UNIX系というかLinuxも既にソースよりも新しいバイナリが出来ている時には無駄なビルドをしない。

だいたいにして立ち上げ時にLinuxはどこから時刻を拾ってくるんだっけ？

CPUが複数個ひしめいているサーバー機なのでカレンダークロックは無いのかもしれない。ネットワークで時刻合わせをするのが前提か。

ようやく先が見えた。やれやれ。