JavaScriptを有効にすると、ここにメニューを表示します。
2019

ysflight.com

Please enable JavaScript to display links.

YS FLIGHT SIMULATOR Version 20181124

YSFLIGHT.COM内のプログラムはすべてがオープンソースでは無いですが、オープンなものについては、以下のURLからダウンロードできます。

https://github.com/captainys/public

YSFLIGHT.COM内からダウンロードできるプログラムを実行しようとしたとき、コード署名されていないプログラムである、とする警告が出るかもしれません。コード署名は本来セキュリティを向上する目的で発明されたものですが、今は僕のような個人プログラマーを駆逐する目的に使われています。以前は、コード署名は法外に値段が高いだけでしたが、今はいくらお金を払っても個人には発行されなくなりました。プログラムを自由に公開する権利の明らかな侵害ですが、僕には何もできません。できることと言ったらここに何が起きてるのか書くぐらいです。別に趣味プログラムを公開できなくなったとしても、困りはしないんですが、なんともつまらない世の中です。

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

Sanyoのデータレコーダを修理しようとするが失敗

去年駿河屋から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コネクタのピン配列

富士通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: 

Back to http://www.ysflight.com