補足。その昔、FDDは外付けだった。PC98の頃でも、3.5in FDD を外付けってのも珍しくはなかったが、
この頃は外付けFDDにマイコンをひとつ載せて(8049とか8051もあったかな)、そいつに765の面倒を見させてた
PC88世代ではすでに、FDD側もZ80にして、そこそこRAMも持たせて、
プログラムをダウンロードして自律的に実行できるようになってた
アセットをFDに詰め込むためには、セクタサイズを大きくすべく、765を直接操作するのは避けて通れない知識だった
メインZ80との間は双方8255で、8bit x3. ハンドシェイクの設計も使いこなしの範疇だった

久々にスラドで読みたい記事が読めてtamacoさんに感謝。

オークも、エルフやトロール、ゴブリンとかと同じく、トールキン以降でイメージが固定化されたけど、ベイオウルフや失楽園にも出てくる怪物(？)の名前だからな。
エルフやゴブリンなんかと同じく、トールキンが再定義しなおしたようなものだが、同様に名称自体は昔からあるもの。
ホビットは、名称も含めてトールキンオリジナルだから、そのあたりの差だろうね。

トールキンの名称含めてオリジナルなのに、いたるところで使われてきた単語で、ホビット以外で有名なのはミスリル。
こっちは映画化された頃からケチをつけてまわるようになったので、ゲームとかのリメイク作品では名前を修正したりしてることが多い。

追加されてるけど？

https://edition.cnn.com/2021/11/03/tech/nso-group-us-blacklist/index.html

スラド民に「赤っ恥を晒す前にせめてググれ」と言うのはやはり無理なのかな。

これ、実際に日本に向けて発送してきた時点で買った奴は犯罪成立なので。
関税法第109条「10年以下の懲役若しくは3千万円以下の罰金、又はこれらの併科」

関税法の罰則規定では「輸出入してはならない貨物（今回の場合は贋金）を輸出入したら犯罪」しかも「輸出入に着手した時点で犯罪」となってる。
買った奴はおふざけ気分でやったのかも知れんけど、贋金流通は「金融に対するテロ」と同じだからねぇ。

予備罪と判断されても「5年以下の懲役若しくは500万円以下の罰金、又はこれらの併科」なので。

どこのソフトハウスだったか忘れましたが、
新人で入ったら、3日(1日だったかな)でZ80のニーモニック覚えろ
と言われたという話があったように、アセンブラができて当たり前の時代でしたね。

私は、プロテクト外すためにZ80 のアセンブラを覚えました(てへ)
お金がなかったので、自分でアセンブラを作ったなー。

その当時はアマチュアでプログラム組んでいましたが、
自己書き換えや、ディスク側のCPU を使うとか、普通にやっていましたね。

今では通用しないプログラム技術ゆえ、こういったことは、忘れ去さられていく話なんでしょうね

破裂するだけの圧力になったDME蒸気が破裂後、酸素と混ざってそれに着火しちゃうんですよ。
つまりは、気化爆弾って奴ですね。

中国共産党により言論封殺できない不具合がみつかったため、使用を中止して削除することを推奨します。

COCOA v1.4.0 が起動しない · Issue #517 · cocoa-mhlw/cocoa

に書かれている通りで、まず半年以上前に

_preferencesService.SetValue(preferenceKey, new DateTime().ToString());

とかいうクソコードが入っていたが原因その1。JavaやJavaScriptと勘違いしたのか現在時刻を取得するつもりでnew DateTimeを呼んでいるように見えるけど、C#では時刻の最小値が初期値に設定されるので、古いバージョンから使い続けている利用者は利用規約の最終同意日時が「1/1/0001 12:00:00 AM」になっていた。そもそも引数の中でnew DateTimeする時点で有り得ないし、ド素人がプログラムしていたと思われる。

で、そうとも知らないkeijiがスラドでも取り上げられた日付フォーマットの問題（接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合）を修正するためにv1.4.0でJST(UTC+9)からUTCに直すマイグレ処理を追加したのが原因その2で、「1/1/0001 12:00:00 AM」からマイナス9時間しようとしてエラーを吐いて無事死亡。

利用規約の最終同意日時がおかしいことに誰も気付かなかったのは、利用規約の更新があっても再確認を行わないという仕様をなぜか放置していたのと、当時の担当者がデータ仕様をドキュメント化していなかったせいで、一カ月前にkeijiがデータ仕様をドキュメント化した際にも見落としてしまった。

2つのマイグレ処理が絡んだ問題なので表面的なテストやストア審査では見抜けなかったのは同情の余地があるけど、コーディング能力や開発速度が低すぎるし、大金積んだ国策アプリの品質じゃない。

githubのコメントを読みましたが、違うみたいですよ。

1. Xamarinがそういうタイムゾーン周りの問題を抱えていることを認識していたので、回避するために、JSTからUCTへの変換を処理を、標準関数を使用せずに自前で作成していた。
2. 過去のバージョンで、利用規約同意日（JST）の設定ファイルへの保存方法を変更していたのだが、その辺りの変更経緯を正しく認識していなかった。
3. したがって、バージョンアップを特定の経緯で行った（あるバージョンを飛ばすなど）環境では、開発者が想定していなかった値が設定ファイルに書き込まれていたが、気がついていなかった。
4. 想定していなかった日付をJSTからUTCに変更しようとして、エラーになって、起動しなくなっていた。