|
YS FLIGHT SIMULATOR Version 20181124
YSFLIGHT.COM内のプログラムはすべてがオープンソースでは無いですが、オープンなものについては、以下のURLからダウンロードできます。
https://github.com/captainys/public
YSFLIGHT.COM内からダウンロードできるプログラムを実行しようとしたとき、コード署名されていないプログラムである、とする警告が出るかもしれません。コード署名は本来セキュリティを向上する目的で発明されたものですが、今は僕のような個人プログラマーを駆逐する目的に使われています。以前は、コード署名は法外に値段が高いだけでしたが、今はいくらお金を払っても個人には発行されなくなりました。プログラムを自由に公開する権利の明らかな侵害ですが、僕には何もできません。できることと言ったらここに何が起きてるのか書くぐらいです。別に趣味プログラムを公開できなくなったとしても、困りはしないんですが、なんともつまらない世の中です。
FM TOWNS内蔵CD-ROMリバースエンジニアリングプロジェクト
FM TOWNSの内蔵CD-ROMの代わりにSCSI CDドライブを使うドライバ YSSCSICD.SYS, SYSDRV.EXE
FM TOWNSの延命を目指すプロジェクト進行中。
FM TOWNS内蔵CD-ROM→SCSI CD-ROM BIOSリダイレクタ Ver. 0.5
いろいろ書かなきゃならないことが多いけど、とりあえず、公開だけ先にした。
https://github.com/captainys/FM
コンパイルしたYSSCSICD.SYSもアップロードしちゃった。20日でここまで来れるとは夢にも思わなかった。ものすごい分量の逆アセンブルを読んだ気がする。
(続きを読む)
僕は平均よりうまいスポーツと言ったらボウリングしか無いんだけど、自己ベスト更新。11月21日の試合で、1ゲームスコア277、3ゲームトータル770で、どちらも自己ベストを更新した。練習中のハイだと290、USBC非公認試合だったら289があるけど、今回はUSBC公認リーグで出したのが大きい。9フレーム目、オイルの削れに対応してコースをずらすかどうか迷ったんだけどずらさなかったら1本残して、パーフェクトは逃した。
277、770というのは、富士通FM77ユーザとして正しいスコアであった。後で考えたら整数演算で770を3で割ると256になるので3ゲーム平均もプログラマーとして正しいスコアであった。
次の目標は、シーズンアベレージ200と、聖域とされるパーフェクトゲームおよび3ゲームトータル800。
なお、これが僕の今シーズンのボウラーヒストリー。
内蔵CD-ROMドライブが故障したFM TOWNSを外付けSCSI CD-ROMドライブで救済するCDSD.SYS, CDISC2.SYSというドライバがあって、CDSD.SYSがもともとバグっててFM TOWNSで使えない問題は僕がデバッグしたけど、それでもなぜか起動しないプログラムが多かったが、その原因のひとつを究明した。修正版のCDISC2.SYSもダウンロードできるようにした。
修正前は起動できなかったSplatter Houseと飛翔鮫が、修正後のCDISC2.SYSでは起動できることを確認。時間の都合で他は確認できていないが、多分他にも修正版で起動できるようになったソフトは多いと思う。
現在、起動用フロッピーディスクイメージをYSFLIGHT.COM内で公開できるようにしたいんだけどCDSD.SYSの再配布条件がソースコードは再配布可能だけどバイナリは再配布禁止となっていることからできない。そこで、現在CDISC2.SYSから直接SCSIをアクセスするようにできないか検討中。
大体落ち着いたけど今日もWindows 10の破壊的アップデートからの復旧は続く。誰一人として周期が早すぎる必要もないアップデートを欲しがってないことをソフトウェア業界は理解するのだろうか。
FM77AVキーボードの赤外線信号のほぼ完全なキャプチャについに成功！
いつになったらソフトウェア企業はユーザがアップデートを望んでいないことを学習するのだろうか。本来ユーザが嫌がることを続ければユーザが減るはずなのに、業界全体で悪行を続けるからいつまでたっても直らない。
iPhoneを数日放置すると、こうなる。
セキュリティアップデートが必要なのはわかる。だけど、見た目をちょっと変更したとか使い方をちょっと変更などただの迷惑でしかない。個別のアプリケーションを選択してアップデートするのは面倒だが、全アップデートをかけると当分終わらない。アプリケーションのアップデートはスパムメールと同じレベルの迷惑になってきた。これからは不必要にアップデートを送りつけてくるアプリケーションは削除することにした。
もう一回言うけど、ソフトウェア開発者、いらないアップデートやめれ。
自分もプログラマーだけど、自分は研究のスポンサーに納入するコードは極力アップデートなんて必要ないようにテストする。もちろん、大学みたいな少人数体制では完璧なテストなんて無理なのだが、それでもできる限りの努力をする。今のソフトウェア業界には、不完全なものをリリースして後から修正すればいいという風潮が蔓延しているようだ。情けない話だ。プログラマーとして恥を知れと言いたい。
マイクロソフトはWindows Vistaでユーザにアップデートを強要したことでユーザを無くした。それから学んだものと思っていたが、そうでもなかったようだ。今日はWindows 10を渋々アップデートしようとした。アップデートしたい理由はこれ以上ゼロになりようがないぐらいゼロだったのだが、リリース1809のサポートを打ち切るとマイクロソフトが脅迫するので仕方なくアップデートすることにした。だが、実は1809以降、メジャーアップデートがことごとく失敗していたので、今回も失敗するのではないかと思っていた。
思った通り、何度やってもこれ。
対策をいろいろ検索して、Windows UpdateのFixをやってみた。
直ったと言ってるけど失敗する。
誰がアップデートのプログラム書いたんだか知らないけど、何をMigrateしようとして失敗してるのかユーザにわからなくしてある。setuperr.txtというファイルに何が失敗したか記述があるとする説もあったのだが、setuperr.logというファイルしか見つからず、しかもゼロバイトのファイルだった。僕が使ってるすべてのWindows 10で失敗するので、おそらく僕が入れてるアプリケーションのひとつがひっかかっていると思われるのだが、どれだか特定できない。
結果は大災害だった。いろいろ対策を試しているうちにデスクトップ機のフロントパネルのUSBポートが使えなくなった。キーボードとマウス以外のすべてのUSB機器をはずすと成功したというのを見たとき何度も抜いたり刺したりしてるうちに静電気でも飛んでしまったのかもしれない。一台外付けハードディスクも同じ影響か反応が亡くなった。ThinkPad X1 Yoga3は、何度かトライしているうちに、Undoing Changesの表示の後リブートを繰り返し、二度と起動できなくなった。
最初ブートオプションがUEFI Onlyになっていた影響でインストール用USBドライブからの起動ができなかったときは一度まだ一年もしないPCの廃棄も覚悟した(山のように情報がつまったディスクつなげたままテックサポートに送り返すか$3000あきらめて情報漏洩を防止するか)が、UEFIとLegacy両方ブートにしたところインストールUSBから起動して希望が出たが、今度はGPTパーティションにインストールできないというメッセージが出てやっぱり廃棄を覚悟したが、隣の同僚がUEFIブート可能なWindows 10のインストールディスクが作れるということで作ってくれてインストールが始まったのでふたたび希望を持ったところで、ファイルが足りないというエラーが出てやっぱり廃棄を覚悟したが、https://superuser.com/questions/1488225/error-code-0x80070022-when-installing-windows-10 なんでもMicrosoftのメディア作成ツールのエラーの問題でRUFUSなるプログラムを使えば大丈夫ということで、それで再インストールができた。マイクロソフトはメディア作成ツールの問題を放置したままリリースしていたわけね。重要なファイルはすべてDドライブにあるのでCドライブが全消しになったがデータ復旧の手間は省けた。一応毎朝重要ファイルはZipに固めて四台のドライブにバックアップしているからロスは無いはずなんだけど、展開する手間が面倒。
とりあえずThinkPad X1 Yoga3の廃棄処分は避けることができたが、さらにアップデートへの憎悪が増した。今のコンピュータは僕がプログラミングを勉強してた頃とくらべてすごいことができるようになった。だけど、欲しかったのはこれじゃない。とにかくソフトウェア業界はユーザに対するアップデートハラスメントをやめてほしい。
と、言ったところで何も変わらない。世の中どんどん悪くなる。とりあえず僕は小さな抵抗として不要なアップデートを送りつけてくるアプリをiPhoneから削除しようと思う。アップデートは迷惑だ。
FM TOWNS内蔵CD-ROMのリバースエンジニアリングプロジェクト開始。
最近何か新しいものを勉強しようと思って、FPGAプログラミングを勉強している。結構Verilogもわかってきたと思う。まだ細かいところとか、良い書き方とか、背後にある理論とか理解してないことは多いけど。とりあえず、PCでタイプした内容をFM77AVに赤外線キーボード信号を使って送り込むことに成功した。リストはそのうちアップロードする予定。
あとArduinoのインラインアセンブラプログラミングも結構わかってきて、ArduinoのUSBケーブルを使わずに外部のRS232Cと115.2Kbpsで通信できるようになった。ネット上にチュートリアルと書いてある情報を結構見つけたけど、どれもチュートリアルになってない。そのうちとりあえずわかったことをまとめてアップロードしよう。
トランプ大統領がピッツバーグにスピーチのためにやってきたので、Air Force Oneを撮ってみた。
地元のテレビ局WPXIによると大統領は東部時間14:30分到着予定でスピーチが15:30からとのこと。
大統領がやってくるときは、臨時飛行制限空域 (Temporary Flight Restriction)が出るので、Skyvector.comで確認したところ1745Z〜2245Z、東部時間では13:45〜18:45。
スピーチがダウンタウンで15:30開始とすると少なくとも空港には15:00には着陸しないと間に合わない。
だとすると13:45〜15:00の間にピッツバーグ上空を通るはず。風は西風。Runway 28L, 28C, 28Rのどれかを使うはず。だとすればほぼ大学〜ダウンタウン直上を高度3000ftぐらいで通過するかもしれない。
戦闘機だったら小さくて話にならんけどBoeing 747なら望遠で撮れるのではないか。
というわけで無線機でピッツバーグアプローチの周波数をスキャンしながら待つ。前回来た時はVHFで一般に公開されているアプローチの周波数で交信していたから、今回も多分聞けるはず。
そして、14:31、無線にAir Force Oneが聞こえる。周波数は123.95だった。その2〜3分後、4発エンジンの特徴的な機影が見えてきた。最初ほぼ自分の位置に向かってくるようなアングルに見えた。直上だとお腹しか撮れない。が、まもなく機体左側面が見えた。そのままの進路だとやや側面が順光で見える経路になりそう。
ピッツバーグアプローチよ、まだヘディングの指示を出してくれるな、と祈りながら待つ。
果たして、Air Force Oneは自分の位置からほぼこれ以上望めないアングルで上空を通過していった。直後にHeading 210の指示が出て左にバンクしたけど、この指示があと10秒か20秒早かったら僕の位置からほぼ真横が見えるアングルでバンクしながら通過したと思うのだが、これ以上を望むのは贅沢というもの。だけどダウンタウンのどこかからは機体がほぼ真横から見えていたはず。
その時の写真がこれ。さすがにパイロットは見えないけど、あのコクピットには恐るべき責任を背負ったパイロットが座っている。あの飛行機を飛ばすってのはどういう気分なんだろう？
当初ズームは全開にしない方針だったが、真っ青な背景にくっきりと機体が見える。いくらなんでもこの絶好のコンディションなら純正テレコン＋純正50-200mmなのに望遠全開にしたらピンとをはずしまくるE-5と言っても外さないだろう。そう思ってベストアングルになる直前、ズームを全開に伸ばした。が、いくらなんでもこのコンディションで外さないだろうと思った僕が甘くて、この前後はややピンボケだった。
さすがにE-5には衰えが見えてきたなあ。いつ買ったんだっけ？と、思ったら2012年か。もう7年も使ったんだな。たしか$2500ぐらいだったから年換算だと大雑把に$360。払った金額に見合った分ぐらいは使ったな。Pentax *istDS2を使ってた時は3フレーム毎秒の連射とか、フィルムカメラと比べてありえないぐらい遅いオートフォーカスとか、劣るカメラ性能はスキルを磨いて対抗する、と、思ってたけど腕が磨けるほど多く航空ショーに行けないもんな。毎年シーズンオフになるとせっかく上がってきた経験値がだんだん下がり、春にはまたゼロから練習しなおして、割と腕が上がってきたかと思ったぐらいのタイミングでシーズン終わっちゃう。
でも一枚いいアングルのが撮れたから良かった。そのうちこのBoeing 747-400ベースのVC-25も引退するとのことだから、一枚撮りたいと思ってた。
さすがにE-5だときつくなってきたから、貯金しよう。
ラトローブ、防府北、デイトン、トレド、クリーブランドの写真などアップロードした。なお、昨日アトランタでSnowbirds #5が墜落したけど、搭乗員は脱出して無事とのことで本当に良かった。残念ながら機体は失われてしまったが、その機体は与えられた究極の任務、搭乗員の生命を守ること、を果たしたと言える。墜落機の機体によくやったと言ってやりたい。機能も同じ機体が5番機として飛び上がったのかはわからないけど、とりあえずラトローブで撮ったSnowbirds #5を下に置いてみる。
サブスクリプション型のソフトウェアだとユーザが払う金額が低くて済むと思ってる人はよく考えた方がいい。ソフトウェア売ってる会社がなぜサブスクリプション型にしたがるのかというとユーザが結局多く金を払うからだ。
買い切り方だとユーザはどのぐらいの頻度でメジャーバージョンアップ版を買うか選ぶことができた。だから年間どのぐらいの金額をどのソフトウェアに投資するか選ぶことができた。サブスクリプション型ではユーザに選択権は無い。
今はサブスクリプション型ソフトウェアを普及させるために月額を低く抑えているかもしれないけど、ユーザがサブスクリプションから逃れられなくなった時点でがっぽり値段を釣り上げてくると見て間違いない。
中には良心的な値段で常に安定したソフトウェアを提供してくれるところもあるだろうけど、アップデートするたびに新しい問題が発生するソフトウェアが大発生、ユーザはいろいろサブスクライブしているうちに気が付いたら月々数万円払ってるという状況しか目に見えない。
しかもユーザはソフトウェアを所有しないから、優れたソフトウェアが次の世代まで残らない危険もある。何もいいことが無い。
少なくともサブスクリプション型ソフトウェアに僕が求めるのはデータファイルを一般的なデータ形式にエクスポートできることだ。JSONでもCSVでもなんでも他のプログラムから読める形式ならいい。C++なりPythonから読めればあとは勝手にこっちでどうにかする。自分は特定のソフトウェア環境に拘束されることだけはしたくない。
僕は考え方が古いんだろうね。基本的にコンピュータはスタンドアロンで動作するべきだと思ってるし。ネットワークがあったら便利だけど切れた時に何もできなくなるんだと役に立たないと思ってる。買ったソフトウェアでもダウンロードしたソフトウェアでもハードウェアとバックアップメディアを大事に保管していれば長く使えるべきだと思ってる。それはユーザの権利だと思ってる。また、給料もらって仕事で書いてるコードは別だけど、プログラマーが趣味で書いたコードは自由に公開する権利があるべきだと思ってる。
だけど、PlayStoreもAppStoreもGoogleなりAppleなりに都合が悪いアプリケーションは勝手に消してしまうことができる。そして、実際そういう事例は起きている。ユーザにしてみると使っていたアプリケーションがある日突然消滅して使えなくなる。プログラマーにしてみると自分が書いたコードを公開する権利を奪われる。
削除しないにしても、iOSやAndroidのバージョンが上がった時、気軽に古いAPIを削除したり変更したりするから古いバージョンのプログラムが動かなくしてしまう。わしが若かった頃はメーカーが公式に決めるAPIはもっと重みがあってのう、気軽に変更するなどもっての他じゃった。それが、今Appleに至ってはOpenGLの対応をそのうちやめるなんて開発者を脅してる始末。別に、未公開のAPIを使ってるプログラムだとか、間違った使い方をしてるプログラムまでサポートし続けろと言ってるわけではない。APIの仕様に厳密にしたがって書かれたコードはOSのバージョンが上がっても使えて然るべきだと言っている。また、CPUとかハードウェアが大きく変わってしまった時なども古いバイナリが使えなくなるのも仕方ないのは理解できる。CPUが64ビットになったのにいつまでも32ビットアプリケーションをサポートし続けるのが難しいのも理解できる。ただ、別にCPUが変わったわけでもないハードが大規模に変わったわけでもないのに気まぐれでAPIの仕様を変えて古いコードを動かなくするのはアプリケーションの大虐殺だよ。と、思う。
Webアプリはサーバーさえあれば公開できるかも知らんけど、公開してる人がサーバー代払い続けないといつか使えなくなるし、と言うか、僕はそんなのばっかりだな。ブックマークしてたサイトを使おうと思ったら亡くなってることが多すぎる。
仕方ないからWindowsだけ対応しておけばいいかと思えば今度はコードサインしてないとせっかくダウンロードしてくれたユーザが実行しようとした時ほとんど脅迫じみた警告メッセージが出るし。プログラムの出どころを明らかにしなくてはならないことには大賛成だ。ただ、昔はコードサインを買おうと思ったら法外な値段を払わなくてはならなくて、今は仮に法外な値段を払う覚悟を決めたところで個人には売ってくれない。別に公的機関でもなんでもない企業が、何の法律にも縛られず、誰のプログラムを信用するか勝手に決める権限を持っている。
残された方法は完全オープンソース。しかし、どう言う形態でプログラムを公開するかってプログラマーが決めるべきものだと思う。自由にプログラムを公開したければ全ソースコードを公開しろとプログラマーに強制するってのも間違ってる。
あるアプリケーションを公開してもいいのか悪いのか、法律に抵触するのかしないのか、それを利害関係の発生しうる企業が判定する権限を持っていると言うのは異常なことだと思うし、プラットフォームを開発して売ってる企業がバージョンアップの名目で気軽に勝手にアプリケーションを使えなくしてもいいと言うのも異常だと思うし、コードサインを誰に売っていいのか悪いのか公的機関でも無いサーティフィケトオーソリティが判断するのも（販売・管理を業務にするのはいいと思うけど）そもそもありえない。ユーザの権利、プログラマーの権利の根幹に関わるような決定権がなんのルールもなく私企業の勝手に委ねられている野放し状態が良い状態とは全然思えない。
野放しになってたのはテクノロジーの発展を優先するためと言う名目だと思うけど、確かにその方が金は儲かる。そして最初のうちはその金が再投資されてテクノロジーの発展を進めてきただろうこともわかる。だけど、最近そんなにテクノロジー発展してる？ただ速くなってるだけで、「これは新しい！」と思うようなテクノロジー出てないと思う。AIだって1990年より前からあった技術がコンピュータが速くなって実用化できたってだけで、本質的に進んだように見えないし。マシンラーニングは何か発見があって新技術が出たと言うよりは、おお！こんなことにも使えるぞ、って言う感じでアプリケーションが開拓できてるだけに見えるんだけど。ある意味技術が成熟してきたと言うことだから、さすがにユーザの権利・プログラマーの権利を真剣に考える時なんじゃ無いのかね。
自動車は売ったら走り続けている限りメーカーは責任を持たなくてはならない。なぜコンピュータはハードウェアが完全に動作していてもメーカーは責任を放棄していいのか。と、自動車会社に勤める知り合いが言っていた。
というようなことをApple Arcadeのリリースの話を読みながら(ドラクエ5と7のセーブデータがロストした後で)考えた。多分、Apple Arcadeには超大作やゲーム史に残る傑作が出てくるんだと思う。それはメーカーがサポートをやめて、そのうちOSのバージョンが上がってきたら使えなくなるんだろうな。僕は気に入ったゲームは時間が経ってからまた起動してみたくなることもあるから、サブスクリプション型のゲームで気に入ったのに出会ってしまったら後に後悔しそうで手が出せない。うちには奇跡的にプレイステーション１が残ってて、実家から持ってきたFM-7, FM TOWNSがあって、ヤフオクで落としたFM77AVとFM77AV40を動態保存してるから、時々昔のゲームを起動してみたくなったらできる。だけど、サブスクリプション型のゲームだと30年後まで動態保存するのは格段に難しくなりそうだ。ユーザにとっても損失だし、開発に携わった人たちにとっても自分の仕事が残らないのは損失なんじゃないかな。
ただ残念なだけじゃなくて、実害も出始めてるのかもしれない。最近ソフトウェアの品質が急降下しているように思う。しがない大学の研究員が片手間で書いてるプログラムかよ、と思うようなものが製品になってる。そもそも、プログラム書いたってプラットフォームの都合でいつまで実行できるかわからないんだから、長く使えるプログラムを書こうという意識が欠落しているように思う。というか、そもそも安定したプログラムを書こうとさえ思ってないんじゃないだろうか。どうせリリースしてからアップデートすればいい、という意識なんだろうか？そういう種類のアプリケーションもあるけど、世の中には何か破壊的な問題が起こってからアップデートするのでは手遅れな場面というのはたくさんある。案外ボーイング737のMCAS問題も根っこはこの風潮にあるんじゃないのかね？
iCloudにセーブしてあったはずのドラクエ5とドラクエ7のデータが消えてた。やっぱりiCloudはゴミくずだった。
真面目な話、これが医療記録だったら、何年もかけて作ってきた大事な作品だったら、何百ものビジネスコンタクトだったらと思うとぞっとする。iCloudは信用するべきではない。というか、もともとSandbox外にデータを持ち出してバックアップ・リストアができないから信用してなくて大事な情報はiCloudには置いてないけどね。最低3重にバックアップが取れないシステムは信頼しないことにしている。iCloudはおもちゃ以外の用途には怖くて使えないと思っていたけど、やっぱりそうだった。
DropboxとOneDriveみたいなクラウドファイルストレージだったら毎朝スクリプトでZipにしてバックアップしてるから大丈夫だけど。そしてZipファイルは年に最低一度はBlueray Discに焼いて暗くて涼しくて乾燥した場所に保管している。それができないiCloudみたいなのはまったく信用できない。
あ、そういやiOS用のNamco ArcadeでXeviousとDragon Busterの回数無制限プレイをin-app purchaseしたんだけどこれも消滅してたっけ。これ返金してくれないのかな。昔はコンピュータのハードウェアとメディアを大事に保管してればいつまでもソフトウェアが使えたのに、最近は消えちゃうんだもんな。こんなのは昔期待してたコンピュータの姿とぜんぜん違う。最近のコンピュータを取り巻く環境はどんどん悪くなってる。昔は良かったというわけじゃなくて、自分が昔コンピュータがこうなればいいと思ってた形から乖離してしまったのが残念だ。
学生さんとか大事なデータを無くして初めてバックアップの重要性を学習するんだよな。せめて人生変わるほど大事なデータを亡くす前に気付いてくれればいいけど。
月曜まで日本にいた。今回は、2月に亡くなった義父の初盆ということで、東京に二泊、我が妻の実家に最初三日滞在し、その後今年は弘前にまだ帰ってなかったので弘前に帰ってきた。
成田エクスプレスから
今回の旅行は最初から最後まで天候に悩まされた。出発前日の8月7日。アメリカ東部は激しい嵐に見舞われてニューヨーク付近の航空便が大混乱だったらしい。しかしピッツバーグは平穏だったから自分のフライトには影響が無かろうと思ったら、次の日朝8時のフライトだというのに、前日夜10時ごろになって突然United Airlinesからテキストが入ってピッツバーグ→シカゴ便がキャンセルになったとのこと。そして、翌日も翌々日も日本に飛ぶ空席が無いとのこと。唯一の可能性は、クリーブランドまたはアクロンから朝シカゴに飛ぶフライトだという。クリーブランドなら車で2時間。朝7時のフライトの2時間前に空港に着くにはピッツバーグを遅くとも朝の3時に出なくてはならない。が、それ以外だったら初盆に間に合わないからそもそも帰国の目的が無くなってしまう。
いったんはクリーブランド発で行く覚悟を決めて、クリーブランド発への変更をオンラインで「Accept」ボタンを押した。が、そのとき帰りの飛行機をクリーブランド行きに変更してくれるのか心配になったのでチェックインまで進む前にトータルの旅程がどう変わったのかをいったん確認してみたところ、
。。。。飛行機だけじゃなくてUnitedのコンピュータシステムも混乱していたようだ。僕がクリーブランドからシカゴに飛んだなら、どうやってピッツバーグ発のUAL 2818に乗れってんだ？こうなると電話で解決するしかない。電話したが2時間待ちとのこと。多分2時間待ってもつながらないか、途中で回線が切れる。この時点でほぼ絶望した。
が、先に帰国していた我が妻が機転を利かせて、日本のUnited Airlinesに電話してみてくれた。なんと、あっさりクリーブランドからシカゴへの飛行機を旅程から削除してくれて、僕は朝7時半発のUnited Airlines 2818便でニュアーク経由で飛べることになった。安心したものの、4時間後にクリーブランドに向けて運転するつもりになってグラスに半分残ってた白ワインを捨ててしまったのがもったいなかった。
アメリカでは国際線は2時間前、国内線は1時間前までに空港に来ることを推奨されている。が、国内線でも2時間前までに来た方がいい。この日も5時には駐車場に車を入れて5時半までには空港ターミナルにいた。空港ターミナルは、ありえない人数でごった返していた。あとでわかったのだが、前日ニュアークやニューヨークへ向かった機体が悪天候のため次々にピッツバーグにダイバートしていたらしい。そのうちいくつかは夜のうちにニュアークに向かったらしいが、かなりの乗客がピッツバーグで一晩過ごしたらしい。そして、その乗客が最終目的地に飛ぶために空港に殺到していた。空港のセキュリティチェックポイントはゾンビ映画のようであった。もちろん僕はそのうちの一匹のゾンビだったわけだが。もしも、空港到着が出発1時間前だったら多分飛行機乗れなかった。
このときわかったのは、どうやら本来自分が乗るはずだった飛行機がキャンセルになったのとほぼ時を同じくして、ニュアークからピッツバーグにダイバートした機体がその日のうちの再トライを断念して翌朝出発としたらしい。もちろん、最終目的地がニュアークだった人はそのまま同じ機体に乗っていけばいいが、ニュアーク経由ピッツバーグ着だった人はそのままピッツバーグで降りてしまった。あるいは最終目的地がピッツバーグから車で2〜3時間の距離の人は別の交通手段で最終目的地に向かったかもしれない。ピッツバーグから最終目的地まで直行便がある人はわざわざニュアークを経由せずに直行したかもしれない。そういうわけで、もともとニュアークに向かっていた機体に空席が発生した。そこでUnited Airlinesは僕のフライトをシカゴ経由からニュアーク経由に変更したのだが、多分ほぼ同時に僕がクリーブランド発をAcceptしてしまったためありえない旅程が発生した、ということだったようだ。
しかし、新たに割り当てられた2818便は7時半発の予定だったが待てど暮らせど出発しない。機長さんが途中でアナウンスして、できるだけ多くの人を乗せていきたいからあと15分ぐらい待ってほしいとのこと。チェックインカウンターもセキュリティチェックポイントもゾンビ映画だったからなかなか搭乗予定の人が全員ゲートまで来れないらしい。しかも、前日のフライトのチケットを持っている人は再チェックインの手続きが必要だったらしくゲートのカウンターでも長々と手続きしていた。結局50分遅れで出発した。2時間あるはずだった余裕は1時間10分になった。
と、思ったのだがニュアークも大混乱。前日着陸できなかった機体が次々に着陸してきている影響か地上業務にも遅れが発生していて、成田行きの79便は機内食の積み込みが遅れて出発は40分遅れた。飛行機が変更になって唯一ラッキーと思ったのは本来の予定より30分早い午後1時半に到着することになっていたので初日少しだけ有効に使えるかと思ったらその30分も消滅した。たった30分だけど、この30分で通勤ラッシュをぎりぎり回避できるかと思っていた希望は無くなった。
しかし、United 2818便というのは本来どこからニュアークに向かっていたのか？疑問になった。機内WiFiに課金しなくてもUnited Airlinesのサイトだけはアクセスできたので2818便について調べてみた。すると、なんと2818便は飛行する曜日も行先もてんでんばらばら、臨時便に割り当てられる番号だった。こうなるとますます気になってフライトステータスで前日ピッツバーグにダイバートしたフライトのうちエアバス319を使っているのが無いか調べようとしたがUnitedのフライトステータスではそこまで確認できなかった。
日本に着いてから調べたところ、どうやらニュアーク、ニューヨーク付近は午後2時ごろから4時ごろが最も荒れていたらしい。フライトのキャンセルはほぼ真夜中まで続いていたけど、おそらくはストームが去った後も機材のやりくりがつかなくなった影響が残ったんだと思う。かなりの到着便が別の空港に目的地を変更していた。そのうち、Unitedの子会社が飛ばしているフライトを除いてピッツバーグにダイバートしたのは4機あったらしい。
他にもUnitedの子会社が飛ばしているフライトがピッツバーグにダイバートしていたが、いずれもRJだった。僕が乗ったのはエアバス319だったから該当するのはナッシュビル発の飛行機だった以外は考えられない。考えてみると日付が変わったのに同じ便名で運航すると出発が遅れたりした場合航空管制のデータベースに同じ便名の飛行機が2機同時に飛行している状態になるので、2818便に便名を変更した理由はわかったが、むしろどうして次の朝離陸した557便が同じ557便として離陸したのかよくわからなかった。確か、ピッツバーグを出るとき、隣のゲートにいたのはUAL 755でBoeing 737だと思ったんだけど、どうやらUAL 557でBoeing 757だったようだ。僕の記憶力はかなりあてにならなくて、そのうちボケても誰も気が付かないのではないかと思う。
せっかく帰国するから少しは楽しまなきゃということで最初の二日間は東京に泊った。最近、秋葉原京急EXをよく使っている。東京駅経由で来るとき大荷物で山手線二駅移動がきついけど、羽田空港に行くならリムジンバスがある。いや、羽田到着だったらリムジンで秋葉原の駅まで行けたんだけど。成田空港だと不便。成田空港は早いところ航空自衛隊成田基地にして首都防衛の要にすればいいのに。
最近電子工作とか趣味が増えたので、秋葉原では電子部品とか買い込んだ。日本にいたころは、秋葉原で電子部品買ってる人が天才に見えたもんだったが、最近は自分もある程度電子回路の意味がわかるようになってきた。作れるのはまだ限定的なものだけど、自分が秋葉原で電子部品を買っているという事実がおもしろい。もちろん大半のものはピッツバーグでも普通にDigikeyとかから買えるんだけど、補充しようとしてた抵抗とかコンデンサとかいくつか敢えて買わないでおいて、秋葉原のマルツと秋月電子と千石通商で買ってみた。あと、気になっていた「ハンダしゅっ太郎」を買ってしまった。ときどき取り付ける部品間違えて「あ！」となることがあるので、これからはやり直しが少しは楽になるかもしれない。
一応Beep秋葉原とか駿河屋とかその他レトロゲームショップも回ったけど、やはり一年ぐらい間を空けないととくに目新しいものはなかった。6月に来たばっかりだし。
あと、紀伊国屋で本を買い込んだ。僕は電子書籍が悪いとは思っていないが、DRMがすべてをダメにしている。DRMに汚染された書籍は販売元が消滅したら読めない。日本では既にそういう事案が発生してるし。それどころか既に買ったはずの電子書籍が販売元/出版元の都合で一方的にユーザのデバイスから削除されるという事態も発生している。DRMを廃止しない限り電子書籍は将来まで残らない。今から100年後、DRM付き電子書籍はすべて読めなくなっているだろう。そもそも著作権法が著作者を守るようにできていて著作物を守るものではない点に問題がある。著作物も守るように改正するべきだ。例えば多く金を払ったらDRMフリーの電子書籍をPDFなど一般的なフォーマットで購入できる仕組みができない限り電子書籍は失敗する。いや、ここで言ってる失敗ってのは後世に絶対残らないって意味で。
将来に残らないって話だと、今のスマホゲームの品質はレトロゲーマーから見るとありえないぐらいの高いレベルになってるけど、何年も残らないのがもったいないね。コンピュータプログラムには芸術品としての側面があると思ってるけど最近の人はそうは思わないのか、というか生まれたときからコンピュータに囲まれてるから空気のようなものになってるのかね。
我が妻の実家、福岡への移動はスムーズだった。この旅行中、8回飛行機に乗った中で、時間通りに出たのはこのフライトと、最終日青森から羽田に飛んだフライトの2本だけだったと思う。ここまで飛行機に遅れられた旅行も最近無かった。本当にひさしぶり、数十年ぶりに盆踊りを見た。
が、福岡から弘前への移動は台風10号に振り回された。Uターンのピークは8月15日だろうと見て8月14日の飛行機を取っていたのだが、8月15日に直撃が予想される台風を避けて一日早く移動する人が空港に殺到したらしく、チェックインには長い行列ができていた。しかも、今回全日空を主に使ったのだが青森には羽田から日本航空しか飛んでいない。預ける荷物は日本航空まで引き継いでくれるのだが手続きに時間がかかって、ゲートに着いたときには既に搭乗が始まっていた。が、結局この飛行機も30分ぐらい遅れたんだったかな。2時間あったはずの乗り継ぎの余裕は1時間半になった。
そして、羽田空港では日本航空のカウンターに荷物の引継ぎがあったことを伝えるように言われたのだが、これがまた行列。ギリギリで間に合った、良かった。と、思ったら青森便は出発が20分遅れとのことで実は余裕を持って間に合っていた。ここまで飛行機が送れる旅行も最近無かった気がする。
羽田→青森乗ったとこ
青森空港に着いて気が付いたんだけど伊丹経由にすれば全日空だけで青森まで行けたのね。ただ、全日空にこだわりがあるわけでもないので次回は日本航空だけにしてもいいんだけど。
弘前は、暑かった。結局、我が妻の実家の福岡にいる間は初盆でひっきりなしにお参りの人が来てうちの中にいた影響かまったく時差が取れていなくて、弘前に戻った次の日は台風の影響で出歩かなかった上に、寝る部屋にエアコンが無いのにフェーン現象で気温が高くて熟睡できなくて、最終日まで時差が取れなかった。毎朝4時ごろ目が覚めていた。
最近弘前に帰省してもアメリカの休みと日本の休みのタイミングが合わないからあまり友達にも声をかけたりしてなかったんだけど、今回はお盆だったから声かけてみればよかったな。手遅れだけど。
弘南鉄道大鰐線
ピッツバーグに戻ったらすぐ試合だったから練習に行ったけど、自分のボール使わないとやっぱりコントロールが定まらない
今回は航空祭を見に行くこともなかったのでカメラ機材も持ってきてなくて、小さなバッグふたつとバックパックで来たけれど、お土産を出した後では日本で買ったものを詰め込んでも余裕があった。荷物をカバンに詰め込むときは圧縮しすぎないように注意することが重要だ。圧縮しすぎると、まず表面の陽子と電子が吹き飛んで中性子だけの核が残る。さらに圧縮を続けると密度が上がりすぎてついにはその重力場から光さえも逃げ出すことができなくなってしまう。だが、今回はそこまで圧縮しなくてもすべての物資を詰め込んで、さらに「機動警察パトレイバー」全巻(1巻だけ初版第2刷だけど残りは全部初版第1刷)と、復刻版の「エリア88」全巻を捨てられる前に回収してきた。「究極超人あ〜る」も全巻どこかにあったはずなんだけど発見できなかったな。もうすぐ本は全部捨てるって言ってたから救い出すことができんかった。
最終日は青森から羽田に飛んで、リムジンで成田に移動して、シカゴ行全日空12便。リムジンの1.5時間さえなければ何か有効に使えたかもしれない。成田空港は早く航空自衛隊成田基地にすればいいのに。
成田空港で見かけたJALのエアバス350
成田空港では乗るはずの飛行機がゲートにいたが、右エンジンを開けて整備していた。結局35分遅れで出たんだったかな? シカゴでは一応3時間ぐらい乗り継ぎ時間があったけど、シカゴもバケーションから帰る乗客で大混乱だった。ピッツバーグ行のはずのゲートに着いたらシャーロット行と表示が出ていたので焦って職員に聞いたら、ターミナル全体で表示を変更するシステムがフリーズしてしまったとのこと。ゲートに着いた時はピッツバーグ行搭乗時間直前だったのだが、結局ピッツバーグ行も出発が遅れた。ここまで飛行機に遅れられた旅行も最近は無かった気がする。
ただ、今年はこれで4度ピッツバーグと日本の間を往復してすべて全日空またはUnitedに集中させたから、来年は一年だけ全日空のブロンズ会員にアップグレードになった。ブロンズだと大した特典は無いんだけど、既にその微妙な特典は有効らしく、最後のシカゴ→ピッツバーグ便は搭乗順がZone 2 (エコノミーで一番最初)だった。我が妻のチケットはZone 3だったが、混んでいるようだったので早く機内に入って荷物棚を確保することはできた。結果的に荷物棚には余裕があったからあまり意味なかったけど。空港のバゲージハンドラーは破壊の専門家だ。彼らはパンチ・キック・ラリアット・関節技・投下・火炎・氷結・その他あらゆる手段を使って荷物を破壊する。荷物の中にカメラでも入っていようものなら出てくるときは素粒子レベルまで粉々になって出てくることは間違いない。だから荷物棚を確保するのは重要だ。
日本にいる間時差が取れなかったおかげでピッツバーグに戻ってから大して時差に悩まされることが無かったのは救いだった。
使ってるThinkPad Yoga 3rd Gen、頻繁にトラックパッドの物理ボタンを押しても無視される問題があって相当イライラしながらボタンを連打していたのだが、手のひらを指と誤認しないためのPalm Checkなる機能が物理ボタンにまで影響を与えてた。
物理ボタン押したときはPalm Check関係ないだろうが。この部分のコード書いた奴は自分の愚かさを恥と思っていい。いや、はっきり物理的に押してんだから。誤認するわけなかろうが。ここまで愚かなコード書くやつがプログラマーとして給料もらってんのか。馬鹿じゃなかろうか。
Settings -> Touch Pad を開いて右の方の Additional Settings というのを開くと Mouse Properties なるダイアログが開いて、さらに Advanced Settings なるボタンがあるからこれをクリックすると、 Synaptic Control Center というのが出てきて、Palm Check Threshold というのがあるのだが、これがほとんどMaxになっていたのでほとんどMinまで下げたらよくなった。
ちなみに、その後、放っておいても勝手にPalm Check Thresholdが最大近くなるまで引きあがってしまう現象が発生して、ボタンが無視されるようになるたびに再設定しなくてはならないことがわかった。スクリプトから設定を変更できるならいいものをいちいちマウスでクリックしなくてはならないとは。
ビーバーから夜間アプローチ、夜間着陸の訓練に飛んできた。(飛んだのは 7/9)
上はそのときのビデオ。まさにタイトーのミッドナイトランディング。というか、レトロPCゲーマーとしては The Cockpit。 (続きを読む)
YS FLIGHT SIMULATOR 20周年！
10周年記念からさらに10年が経過した。YSFLIGHTはもともと博士候補試験の勉強中の息抜きのために始めたプロジェクトだった。最近はスマホやゲーム機で優れたフライトゲームが多くあるから最盛期ほど盛り上がってないかもしれないけど、一応ゆっくりだけど今でも開発は続けている。
FM TOWNSを使ってた頃は３Dゲームをいくつも作って1000本とかいうオーダーのダウンロードがあった。当時フリーのゲームソフトで1000回ダウンロードされるというのはすごいことだった。だけどYS FLIGHT SIMULATORは世界中からダウンロードされて、ダウンロードカウントだけ見たら100万回のオーダーを超えている。ただ、同じ人が何度もダウンロードすることもあると思うんで、100万人かどうかはわからないんだけど。
アップロードしてみたらユーザが作る機体やマップのクオリティの高いことに衝撃を受け続けた20年でもあった。YSFLIGHTを盛り上げてくれているユーザの皆さんには非常に感謝しているので、ひきつづきYSFLIGHTをよろしくお願いします。心苦しいんだけど機体の作成とかマップのデータ構造に関する質問はほとんど答える時間が取れない。けど既にオンラインでものすごく詳細な解析情報があるから多分僕に効くよりそっちの方が速いと思う。
せっかくだから20周年記念で何か特別なことをしたいのだが、例えば手をつけたままできあがってない新機能をひとつでもふたつでも完成させるというのも手なんだけど、途中で止まってるのはやっぱり理由がある。大体メジャーな理由としては、やってみたら案外難しかった、後方互換性が維持できなくなる、難しくはないんだけど書かなきゃいけない分量が多すぎる、とかいうパターンが多い。少なくとも20周年記念機体データとか作ろうかな。
僕は、最近のソフトウェア開発のトレンドについて危機感を持っている。ソフトウェアが消耗品のように扱われてるのは正しくない。ソフトウェア・アズ・サービスって言いだした奴を絶対許さない。悪いけどソフトウェアはサービスではない。ソフトウェアは製品であると同時に芸術作品としての側面も持っている。傑作は将来まで保存されるべきであって、ティッシュペーパーのように使い捨てられるべきではない。安定したプログラムを書くためには、コードを再利用して、多くの入力を与えて頑強性を高めていくべきだ。そして、プログラムが安定してくると徐々に更新は不必要になってくる。更新が無いのはプログラムが捨てられたからではなくそのプログラムの目的を達成しつつあるからであるべきだ。コンピュータ界には数多くの素晴らしい成長があった。だけど同時に誤った考え方も広がっている。
YSFLIGHTは傑作というほどのものではないかもしれない。だけど僕はYSFLIGHTを誰でもいつでも戻ってこれるプログラムにしたい。誰かが今日YSFLIGHTをプレイするのをやめるかもしれない。だけど、何年かしてその人がまた久しぶりにYSFLIGHTで飛んでみようと思ったとき、YSFLIGHTをダウンロードして飛び上がって簡単にトラフィックパターンを回れるように維持しておきたい。しばらく離れていた人も、「ああ、このプログラムまだあるんだ」と思って久しぶりにダウンロードしてまたちょっと使ってもらえるようなソフトウェアを目指して引き続きメンテナンスしていこうと思ってる。
このあいだ製作に成功したFM-7用純正品互換RS232Cカードは、実は38400bpsまで行けることが判明した。
富士通純正品は19200bpsが最大ということになっている。純正品は82年ごろ製造のIntel 8251Aチップを使っている。多分、8251Aは本当に19200bpsが最大なのだと思う。
これに対してOKIの互換チップ82C51Aは38400bpsまで保証している。また、Intel製でも手元にある82C51Aチップは90年製造で富士通純正品のRS232Cカードが生産されてから8年も経過しているようだ。これなら実はIntel製P82C51Aも38400bps行けるのではないかと思って実験してみた。
(続きを読む)
なお、上空で真空パックする作戦は失敗したので、あきらめて真空パック機を買ってきた。上空で済むなら$80節約できると思ったのにな。(ちなみに、飛行機レンタルは1時間で$150ぐらい。飛行機操縦する理由を探してただけだろうって言われるとその通りなんだけど。)
この週末、もうすぐ日本に帰国される訪問研究員の人と我が妻の友達とその息子さんを乗せてナイアガラの滝に飛ぶはずだった。離陸地のビーバーの天気は曇り。しかし、最近Garmin 1000搭載のセスナに乗るようになって、雲が500ftもあればIFRアプローチで降りる自信がある。最初G1000は難しいと思っていたけど慣れてしまったらなんとアプローチの撃ちやすいことか。最近、G1000のセスナ以外が空いていないこともあって気が付いたら最近G1000しか操縦してない。
ナイアガラ付近の天候は快晴。風も穏やかでまったく着陸に支障はない。
ヤングスタウン、アクロン、はやや雲が低いものの離陸時刻までには上がってくるとの予報。万が一ダイバートが必要になった場合もGPSアプローチで降ろす自信があった。
(続きを読む)
RS232Cカードは成功したものの、自分はハードウェアの素人であることに変わりはない。FM-7に煙を吹かせてしまった場合に備えて、FM音源カードの再生産を前に、FM-7を一台増強することにした。
ヤフオクで5000円ぐらいで動作品と称するFM-7を落札した。それが届いた。よほど几帳面な人が使っていたのだろう。綺麗にGRAPHキーのシールが貼ってあって、プラスチックの黄ばみも無い。ミゾにホコリが貯まっていさえしない。綺麗なハードだった。これが動かないはずが無いだろう、と、思いながら電源を投入してみたのだが状況が良くない。
(続きを読む)
これ、実際トライしたのは去年の年末のことだけど。
YSFLIGHT.COMのトップを見てくれてる人だったら、僕が趣味で富士通製レトロPC、FM-7シリーズとFM TOWNSシリーズの動態保存に取り組んでるのは知ってると思う。もともと数枚だけなぜかずっと保存してあったフロッピーディスクが手元にあったけど、最近アメリカからでもヤフオクから買えるようになったんで、結構レトロゲームを落としている。
最近そういうゲームの復刻版が出ていたり、メジャーなタイトルだと少し検索すれば著作権的にどうかと思うけどディスクイメージがダウンロードできるものもある。ただ、復刻版にしても著作権者に無断でアップロードされてるイメージにしても、元のソフトウェアを完全に再現していない可能性が高い。とくに、コピープロテクトは解除済みである可能性が高い。僕としては当時のコピープロテクトも貴重な技術資料だと思うので、できればコピープロテクトを含めて昔のタイトル、せめて思い入れのあったタイトルだけでも保存しておきたいと思っている。できればそのうちコンピュータの歴史を保存してるようなところで恒久的に保存してもらえるといいんだけど。日本では、ゲーム保存協会 (あ、今年の分の年会費＋募金しなきゃ)ががんばってるけど、こういう資料は各地に分散して多数保存するのがいいので、アメリカにも保存の拠点ができるといいとか思っている。
(続きを読む)
2019/04/16
ピッツバーグでは日本人・日系人の有志がNorth Parkに桜の植樹を続けている。今年で10周年とのことで、先々週セレモニーがあった。そのときはまだ桜が咲いていなかったのだが、ぼちぼち咲いたろうというタイミングで空から花見に行ってきた。四季の移り変わりを空から見ることができるのはパイロットの特権と言える。(続きを読む)
富士通レトロPC:
FM-7用FM音源カード、リバースエンジニアリング＆再生産プロジェクト開始！
FM-7用Emergency勝手にジョイスティック対応パッチ
2019/04/05
富士通レトロPC: 大技！RS232C経由でFM-7実機でディスク版ソフトを起動！
時には昔の実機を使おう
まさか成功すると思わなかったのが成功した。始めてから起動するとこまでたった4日でできると思わなかった。その後サーバーのパラメータとか追加するのでさらに4日ぐらいかかったけど。(続きを読む)
富士通レトロPC: FM77AVキーボードエミュレータも更新
なお、FM77AVキーボードエミュレータがコンソール無しモードでコンパイルするとなぜか大半のキーを送り損ねるという問題が発生したので、コンソール付きモードでコンパイルしなおしたやつをアップロードした。
BONDIC
この間買ってきて既に首振りフラワー2個の修理に成功。多分接点を絶縁する目的とかにも使えると思う。
AA
これまでに聞いた話でいくつか気になった点。
という話を聞いたけど、自動操縦にフィードするのに迎え角センサーが二個しかなかったのか？初めてコンピュータコントロールを本格的に導入してデジタルフライバイワイヤを実現したのはF-16だったけどコンピュータを3台搭載していた。そして3台それぞれに対気速度をフィードするセンサーがあった。AOAはどうだったか知らんけど。一台が故障しても多数決で出力を決めることで自動操縦の信頼性を高めていた。だけど、737Maxではそんな大事なMCASに入力を与えるセンサーが2個？パイロットが見るための情報だったらどっちが間違ってるか判断できるからいいんだけど。我々は計器をクロスチェックしてどの計器が壊れてるか識別するように訓練受けてるんで。2個だと片方ダメになったときどっちを信用すればいいかわからないので、自動操縦としては冗長性は無いに等しい。このデザインはどうかと思うなあ。ますますボーイングらしくない。
というか、左右の入力が違ったら自動操縦は自主的に切れるべきかもね。
今、プログラミングのトレンドで非常に危惧していることがある。いい加減なプログラムを公開してあとからアップデートすればいいという風潮がプログラミング界をむしばんでる。断言するけど誤ったやりかたと言える。いい加減なプログラムを公開して、しばらくユーザを実験台にして不具合報告が上がってきたら対応するようなアプローチは、一般ユーザが使うプログラムでもするべきではない。風潮というのは恐ろしい。こんな誤った考え方が航空機メーカーのソフトウェア開発部隊にまで広がっているのだとしたらこの先次々に墜落事故が起こる鴨しれんね。そうでなくてこの機種だけ、たまたまだったらいいんだけど。
2019/03/12
ボーイングらしからぬ事故？
昨日事故が起きたばかりだからエチオピア航空の737-300MAXの事故原因がライオン航空の事故原因と同じものであるかどうか、まだ調査を待たなくてはならないけれど、ただ、仮に違う事故原因だったとしても背景にはこれまでのボーイングらしくない設計思想があるかもしれない。
インドネシアのライオン航空事故で思い出したのは、1994年にあった名古屋空港での中華航空のエアバス300-600Rの事故だった。あの事故の原因は明らかなエアバスによる設計ミスだった。ゴーアラウンドモードで、自動操縦はピッチトリムをコントロールするが、パイロットはエレベータをコントロールできてしまった。1994年4月26日、無意識にゴーアラウンドレバーを引いてしまったパイロットは、自動操縦が機首を上げたので、着陸を続行するために操縦輪を押して機首を下げようとした。ところが、エレベータの機首下げ入力のため機首を思うように上げることができない自動操縦はエレベータトリムをどんどん機首上げに向けてしまった。ある時点でパイロットの入力では対応できなくなり、エアバスはパイロットがどれほど操縦輪を押しても機首を下げられなくなった。で、ストールして墜落。パイロットの入力と自動操縦の入力が混ざる状態に入る場合があるというのが事故原因だった。
一方、設計ミスと思われたくないエアバスは先手を打ってパイロットエラーであると発表した。エアバスは一貫して、パイロットはミスを犯す可能性があるから、緊急時は自動操縦の判断を優先するべきである。従ってこの事故はエアバスの設計に起因するものではない、と主張した。
工学博士号持ってなくても、エアバスの主張がおかしいことは理解できる。緊急時にパイロットの判断を優先するか、自動操縦の判断を優先するか、これには議論の余地がある。自動操縦もパイロットもどちらもミスする可能性があるから、最後はどっちかに賭けるしかない。我々は事故を完全にゼロにはできない。できるのは事故の発生確率をゼロに近づけることだけだ。だから、エアバスは自動操縦が正しい方に賭けた、というのであれば、設計ミスとまでは言えない。
まあ、仮にエアバスが正しいとしよう。だとしても、だったらパイロットからの入力を混ぜたらダメだろ。パイロットの操縦ミスによる事故を防止するのが目的であればパイロットからの入力は遮断するべきで、逆にコンピュータの動作エラーによる事故を防止したいならパイロットからの入力があった場合は自動操縦を遮断するべきであった。だが、ゴーアラウンドモードでは混ぜてしまった。だから、明らかなエアバスの設計ミスだった。
なぜか、事故調とかもその宣伝を受け入れてパイロットによる操作ミスで訓練を徹底するのが今後の事故防止に必要という結論を出してたんじゃなかったかな。ちょっとちょっと、Ph.D Mechanical Engineeringとして言わせてもらうとただの設計ミスだから。エアバスの責任がかなり高いから。コンコルドの飛行を継続しておけばよかったものを。(時系列無視)
多分事項調査委員の誰かが金持ちになったんだと思う。そしてエアバスは知らないところでこっそり改修を加えたかなんかしたのかもしれない。この事故後同様の事故は起きていない。
←アメリカAmazonからなんか買うときはよかったらこのAffiliate Link使ってください。
この名古屋空港の事故に対して、ボーイングの反応はこうだった。ボーイングは緊急時はパイロットを信用する。ボーイングの機体はパイロットからの強い機首下げ入力があったのであれば自動操縦を解除するようになっているから名古屋空港中華航空機事故と同様の事故はボーイングの機体では発生しない。
はずだった。
実際学会とかでボーイングの人と何度か話したことがあった。ボーイングはパイロットが大好きだから緊急時にはパイロットを信頼する。パイロットはエアバスがやってるみたいなサイドスティックが嫌いだからやっぱり操縦輪が正面にあった方がいい。ボーイングの機体は操縦輪に強い力が加わると自動操縦は解除されて機体はパイロットの入力に従うようになる。ボーイングは常にパイロット中心で考えてる。とかいう話を聞いた。
だけどライオン航空の事故が起きた。そのときのボーイングの反応は、まるで中華航空機事故のときのエアバスとそっくりだった。パイロットの訓練を徹底するように。いや、違う。ただし、これは設計のミスとまでは言い切れない。緊急時はパイロットがエラーを起こすかもしれないから一貫して自動操縦を優先するというのであれば、それ自体は正しいのだが、問題は制御コンピュータが間違っている場合もあるということだ。
プログラマーとして言わせてもらうと、プログラマーもミスを犯すんで、自動操縦システムのプログラムにエラーがある可能性は十分高くて、したがって自動操縦を信用すれば大丈夫とはぜんぜん言い切れない。人間だと緊急時に対応して違った対応を取ることもできるが、自動操縦のシステムが間違ってたら地上に降りてくるまで更新できない。いや、上空にワイヤレスで更新プログラム送って更新するって怖くてできんでしょ。機械学習？機体が遭遇した未知の飛行状態が、既知の飛行状態のインターポレーションであれば割とよく対応すると思うけど、エクストラポレーションだったらどんな挙動するかわからん。
だから僕は昔のボーイングの設計思想の方が正しいと思ってた。
ところが、このライオン航空の事故では、パイロットが必死に操縦輪を引いて機首上げ操作をしているにも関わらず、自動操縦が強行に機種を下げた。飛行機は、自動操縦から機種を下げろと言われ、パイロットからは機首を上げろと言われた。実はストール寸前などではなくて自動操縦が間違ってるのかもしれない。でも、パイロットがストール寸前なのに間違って機首を上げようとしているのかもしれない。航空事故史にはストール寸前の飛行機の機首をさらに引き起こそうとして落ちた事故は数多い。飛行機は自動操縦を信じた。というか、信じるように作られていた。結果的に自動操縦の根拠となったストール寸前の状態では無くてパイロットが間違っていた。運が悪かった。
だから、必ずしもこれは設計ミスではない。自動操縦とパイロット。どっちもエラーを起こす。どっちを信用するのかは、デザインフィロソフィによって違うので、パイロットより自動操縦が信用できると思ったなら、そういう設計は「ミス」とまでは言えない。僕は嫌いだけど。
かつてのボーイングのパイロット中心のデザインンフィロソフィであればライオン航空の事故は起きなかったのではないかと思う。ボーイングが、自動操縦優先、パイロット軽視に変化しているのだったら、僕は残念な気がする。
2019/03/03
YSFLIGHT Demo for Androidをリリースしようと思ったが
YSFLIGHTカーネルをAndroidで走らせることに成功したのは数か月前だから、試しにデモだけバージョンでも.APKファイルをリリースしようと思った。
Android Studioの新しいバージョンをインストールしたら、予想通り前のバージョン用に作ったプロジェクトはコンパイルできなくなっていた。旧バージョンで作ったプロジェクトをビルドするユニットテストもしてないんだろうな。まるで大学院生のような開発の仕方だ。
最近、バージョンを頻繁に上げるのが良いことであるという風潮があるけど、超新星爆発寸前の赤色巨星並みの巨大な間違いで、頻繁に何か変えなくちゃならないのは何かが悪いからだ。機能が洗練されてきて当初の目的の達成に近づいたプログラムは安定するからアップデートする必要が無い。したがって、頻繁にアップデートを繰り返す上に何も安定しないAndroid Studioはゴミと言える。
Android Studioだけじゃないんだよね。もう「アップデートするな！」とメガホン持って叫びたい。十分な時間をかけて安定して頻繁なアップデートを必要としないコードを書くべきだ。最近の、作りかけでリリースして頻繁なアップデートでごまかす風潮は有害と言える。今の無茶苦茶な開発の仕方は僕が習ってきたやり方ではない。僕の考え方が時代遅れなのかもしれないけれど、いい加減なソフトウェアをリリースすることが流行なんだったら時代遅れで結構だ。
エラーメッセージを検索して解決が見つかったのでビルドはできるようになった。Googleには迅速にエラーメッセージから解決を探せるようにするのではなく、もともとこの問題を作らないでほしかった。
が、デバッグモードだから異常に遅い。リリース版APKファイルを作ってみたら -unsigned.apk というのができてしまって実行時にサインされてないと文句を言う。またCode Signatureだよ。とにかく、セキュリティの名のもとに個人開発者にプログラムを書かせなくするための仕組みだからな。
一応、開発用シグネチャを作ってコンパイルすることができたのだが、試してみようとすると何度やっても -unsigned.apk を実行しようとする。強制的に -unsigned.apk を削除してみたが、ファイルが見つからないと言い出す。同じディレクトリにお前がたった今ビルドした ysflight_release.apk があるのがなぜ見えない?
というところで今日は11時過ぎてしまったので断念。後日再度トライする。
2019/03/02
ナイト・ソロを追加。飛んだのは既に一か月前だけど。
久しぶりに単独の夜間飛行に出た。ログブックによると2013年の11月30日以来の夜間単独だったようだ。
本当は我が妻を乗せて飛ぶはずだったのだが、我が妻は風邪でダウン。フライトをキャンセルするかとも思ったのだが、我が妻の風邪はほぼ回復してきたようだったので、とりあえず単独で飛んできた。
自家用操縦士免許を取ったら夜間飛行に出てもいいことになっている。だけど本当にナイトに自信がついたのは計器飛行証明を取得してからだった。夜間飛行はかなり計器飛行に近い。地平線見えないし。だけど、今だったら計器だけに頼って夜でも飛べる自信がある。
(続きを読む)
2019/02/23
去年駿河屋からFM-7用Plazma Lineを買ったとき、リストアするためにヤフオクでSanyoのデータレコーダMR33DRを落とした。そのときの記述によると、データレコーダはモーターが回るもののそれ以上の機能は確認できなかった、とのことだったのだが、データレコーダが故障すると言えば大体モーター回りのようなので、モーターが回るなら大丈夫だろうと思って手に入れて、例によってBuyee.jpによって太平洋を越えた。
で、届いて試したところ、確かにモーターは回る。だが、音が出ない。スピーカーからもイヤフォンジャックからも音が出ない。予想外であった。仕方ないのでPlazma Lineは、WAV録音した波形にフィルターをかけてデータを抽出して再現に成功したのだが、もしもデータレコーダが使えたならもっと楽だっただろうになあ、と、思ったままその後何本も同じプログラムでテープ版ソフトの抽出と実行に成功してきた。
しかし、ここ最近RS232Cカードを作ってみたりハードウェアをいじくったり結構やってきたので、今なら修理できるかもしれん！と、思って再挑戦してみた。スピーカーもイヤフォンジャックも音が出ないということは、テープの磁気ヘッドに近いところに問題があるに違いない。この手のハードウェアでモーターの次に壊れそうな部品と言ったら、稼働部品であるボリュームレバーの半固定抵抗ではないか、と、見ていた。実は、今のホンダフィットに乗る前、日産セントラ(日本でいうところのサニーらしい)に乗っていたとき、空調ファンが全力だと回るけど、その手前の強度1〜4だと回らないという現象が起きたことがあった。まさに半固定抵抗が電気を通さなくなってしまって、抵抗をバイパスする全力モードだけ回っていた。
(続きを読む)
2019/02/15
エアバス380生産中止なのか。そんなもん作らずにコンコルド近代化改修するべきだったな。コンコルドを無理やり引退させたバチが当たったんじゃ。
渋々LinuxのVMをUbuntu 16にアップデートしようとしたらデスクトップがぶっ壊れた。アイコンもメニューも出なくなりCtrl+Alt+TでTerminalも開かなくなった。コンソールモードに入って設定をいじって直せるほどLinuxは詳しくない。バックアップのUbuntu 14に戻してもいいんだけど、Ubuntu 16にしようと思ったら全消し再インストールするしかなさそうだ。定期的にこの余計な手間が発生するのはなんとかならんもんなんだろうか。
Linuxは相変わらず脆い。いつまで経っても脆い。更新に失敗して簡単に壊れるんだから、そもそもOSを更新してほしくない。セキュリティの更新はしてほしいけど、メジャーバージョンアップはしてほしくないんだよね。誰かOSの新バージョンを楽しみにしてる人がいるんだろうか？僕はそういう人を一人も知らない。OSのメジャーバージョンアップは、ときどき不必要にドライバモデルを変えてまったく問題なく動作しているハードウェアを使えなくするわ、頼みもしないカーネルの更新でソフトウェアを殺すわ、何もいいことが無い。ハードウェアに革新があったならそれもやむを得ないと思うけど、ここ数年なんかあったっけ？基本的に同じハードが速くなってるだけだと思うんだけど。OSのメジャーバージョンアップは僕にしてみりゃただの嫌がらせだ。ユーザに嫌がらせを続けてたらそのうち誰も使わなくなる。
2019/02/06
FM-7/77実機でRS232CからT77形式のテープ版ソフトを読み込んで実行(セーブもできる)ユーティリティ更新。オプションで8バイト先読みバッファを使ってFM-7/77実機にテープ版ソフトを5倍速ぐらいで送り込んで実行できるようになった。まさにテクノロジーの無駄遣い。
2019/01/29
FM-7/77実機でRS232CからT77形式のテープ版ソフトを読み込んで実行(セーブもできる)ユーティリティ公開。
2019/01/24
FM-7/77シリーズ用純正品互換RS232Cカード製作プロジェクト成功
案外あっさり成功。実機FM-7で動作も確認できた。
実は、カードの制作に成功だけでなく、BIOSをオーバーライドしてRS232C経由でテープ版ソフトを起動することにも成功した。BIOSオーバーライドコード、サーバーコードは間もなくYSFLIGHT.COMで公開予定。
2019/01/15
YSFLIGHT SIMULATOR 20181124バージョン公開！
お待たせしました！
富士通FM-7/77用RS232C経由ディスクイメージ書き戻しユーティリティ
なお、今日FM77AV40で動作を確認した。
FM77AV/AV20/AV40実機用赤外線ワイヤレスキーボードエミュレータ更新
実機でF-BASICのプログラムをタイプさせてみたら一行入力するたびにWAITを入れないと次の行の行番号を取りこぼすことに気が付いたので、F-BASICプログラム入力用に別のボタン [Auto-Type (BASIC)]を追加してみた。
2019/01/13
YSFLIGHT SIMULATOR 20181124バージョン公開！
実はDownload.comの方には早々に公開されていたようなのだが、Vectorの方にやっと登録された。
YSFLIGHTユーザの皆さまには、実行時に署名されていないプログラム云々という警告メッセージが多分Windows 8になったあたりから、出ていたと思う。表向きの理由は、セキュリティを高めるためということになっている。誰が書いたプログラムなのか、その後誰かの手によって改変されていないか、それが確認できないプログラムは実行させないという趣旨だった。
情報セキュリティは非常に重要な問題で、実行ファイルの出どころをはっきりさせること自体は良いことだ。悪意のあるプログラムを実行したことによって被害を受ける事件は後を絶たない。そのような事件の責任は当然悪意のあるプログラムを書いた本人にあるべきで、僕はそんなやつは一生刑務所に入っていればいいと思う。
だがセキュリティ問題を利用して利己的な目的を達成しようとする者がいたとしたら、もっと軽蔑してもいい。残念ながらコード署名を発行する認証オーソリティは、誰の利益のためにそうしているのかなんとなくわかるけど、セキュリティ問題を利用して個人プログラマーを排除しようとしている。
コード署名はもともと年間500ドルとかいうレベルでとても手が出なかった。しかし、長いことYSFLIGHTを使ってくれているユーザから懸念のメールをいただいた。実際自分としてもできることならコード署名が欲しいと思っていたので、ときどき手の届く値段でコード署名を買うことができないか探していたのだが、今回COMODOという認証オーソリティが年間$179でコード署名を発行してくれることがわかった。そこで申し込んだのだが、返ってきた返事は、コード署名は個人開発者には発行しないということだった。
他の主要な認証オーソリティも調べたのだが、どうやら認証オーソリティは結託して個人開発者へのコード署名を発行しないことにしたらしい。だから、仮に僕が思い切って年間数百ドルを支払ってコード署名を買おうとしても、買うことができない。何故こんなことが許されるのかわからないけど、認証オーソリティはすべて個人プログラマーを意図的に排除しようとしている。
そのようなわけなので、残念ながらYSFLIGHT.COMからダウンロードできるプログラムに署名することができない。そして、僕にはできることが何もない。残念だけど、奴らの思い通りに個人でフリーソフトを書いて発表するようなプログラマーは絶滅するだろう。 できることと言ったら、ここに現状を書いて知ってもらうぐらいしかできない。
2019/1/6
YS FLIGHT SIMULATOR 20181124バージョンがなぜかVectorに登録されない現象発生中。
ビーバーから飛んできた。
富士通FM TOWNSを動態保存してる人で、SCSIハードディスクあるいはハードディスクエミュレータを内蔵しようとしてる人、ちょっと待った！
内蔵SCSIアダプタケーブルを噛ましているだろうか？FM TOWNS 20F以降の機種では本体内に内蔵SCSIハードディスクを接続するためのコネクタが出ている。まるで標準のSCSIコネクタであるかのような50ピンだ。
しかし、このコネクタにSCSIデバイスを直結してはいけない！直結したら多分煙を吹く。
昔はたくさんあったSCSIケーブルも最近は入手するのも難しい。SCSI2SDみたいなハードディスクエミュレータだとターミネーターパワーで駆動するから電源ケーブルを接続しなくてもいい。だったら内蔵コネクタに直結したくなってくるが、この一見標準SCSIコネクタに見えるコネクタ、実は標準SCSIコネクタのうち使われていないGNDライン8本を詰めて、1ピンから8ピンに電源を出している。標準SCSIコネクタの2,4,6,8ピンはデータピンだから、そこに12ボルトかけたら煙を吹く可能性がある。
Comments are welcome.
Send E-Mail to:
 |
