自然界ってのは安定しているようで実は常に変動しています。
餌が増えればそれを食べる捕食者がじわじわと増え、捕食者が増えるにつれて今度は餌が減り始めます。餌が減ると捕食者が減るので…の繰り返しです。
この現象はロトカ・ヴォルテラの方程式として知られていて
つまり被食者と捕食者の関係は位相差をもつ周期関数として近似できます。

実例としては
- アオキアミとクジラの例
- ウサギとヤマネコの例
などがよく本に載っています。

複数の時系列の関係を周期性だけなく、位相も考慮して捉える考え方はとても重要です。
実際、ロトカ・ヴォルテラの方程式は生物学だけはなくて、経済学における景気動向の予測や、コロナ対策にも登場します。
興味がある人は、ロトカ・ヴォルテラの方程式を調べてみてください。面白いですよ。

ちなみに日本の個人情報保護法では
個人情報とは「生存する個人の情報」と定義されていて
亡くなった人（故人）の情報は保護対象となっていません．

具体例をあげるとマスコミが故人の情報（事実）を報道する場合は個人情報保護法が適応されません．

ただし虚偽の情報を報道した場合は名誉毀損罪となる場合があります．
判例があり，故人に対する遺族の想いが侵害されたから名誉毀損罪という解釈だったと思います．

つまり日本国内において今回の技術で故人の声を模倣したりそれを商業利用する場合などは，
遺族の了承をあらかじめ取っておく必要がありそうです．上記の判例があるので，了承なしだと裁判でほぼ確実に負けると思われます．

よくあるバグですね．

データベース(SQLやCSV)で「ワクチン接種の有無」という項目をつくり
値は，有，無，NULL，の３値となるような設計&実装をします
つまり，不明の場合はNULL，確定した場合は有or無， です．

これを２値と勘違いして，「有」と「それ以外（つまりNULL or 無）」と集計したり
SQLで　 SELECT * FROM hogehoge WHERE "ワクチン接種の有無" == TRUE　などとクエリを書いてしまう
と，今回のようなバグが発生します．

ワクチン接種の有無，という一見２値のような項目名に対して，データは３値になるという「矛盾」が
混乱を招くのでしょう．（今回の場合は，日付の入力がある or 無い(=NULL) or 不明(=NULL)の３状態を
接種済みと未接種(=NULL)の２状態に誤分類したバグ）

NULLに関わるバグ・不具合はデータベース界隈では頻繁に生じています．
プログラムやデータベースをいじったことがある人なら同種のバグに遭遇し，
「NULLは糞」「NULLなんて許容したやつは誰だ？」と苛ついた経験がある人も多いはずです．

私は，仕様書などでNULLを見かけたら
- NULLは諸悪の根源！
- 集計する際，デバッグする際は必ずNULLの有無を確認！
と肝に銘じてから実装や集計を始めるようにしていますが，それでも先日NULLで１箇所失敗していました．

よくあるミスなので，本件も寛大に受けて止めてあげてください．NULLが悪いんです．NULLが．

後輩が「絵が可愛い」と力説するので、一緒に個展を見に行ったことがあります。

不覚にも少し気に入った絵があったので一つ購入してみたら、作者さんがやってきて
5分ぐらい時間をかけてイラスト付きでサインを書いてくれました。
雑談しながら楽しそうにペンを動かす、感じのいい人でした。

ただ個展といっても売約済の作品はほとんど無く、とても盛況とは言えない雰囲気で
作者さんも複雑な気持ちだったんじゃないかと思います。

気になって論文斜め読みしましたが
「データ分析業」という業種は，例えば「データ入力」をおこなう業種だと定義されてました．

入力と分析では業務内容が大きく異なるように感じます．

論文は退屈だと見做される職業の1位は「データ分析業」と言っていますが
我々は「データ入力業」が1位だと解釈すべきかもしれません．（元論文はこの点ちゃんと説明できてない雰囲気だったので精読するのは諦めました）

googleのpage rankの論文が 1998年、会社としてのgoogle設立も同じぐらいです。

1992年なら page rank の特許を先に出せるだろうし、検索エンジンで確実に一儲けできそうです。

# あとはビットコインが登場したら「こっそり」買い占めたい。

「バッテリー取り外し」が義務化されたら、今あるスマホは全部バッテリーを抜かれて、ただの文鎮になりますね。(充電ケーブル繋げば使えるけど…)

正しくは「バッテリーの取り外しや交換が可能な設計」を義務化だと思います。

https://dirtypipe.cm4all.com/ にて、発見者の Max Kellermann 氏が詳細な報告をまとめてくれてます。

彼が最初に不具合を遭遇したのは、2021年の4月。
彼は CM4all と言うホスティングサービスの保守を担当しており、2021年4月に顧客からファイル破損のレポートを受け取ったそうです。
何かおかしいと感じた彼は、その後３ヶ月間で37ファイルが破損するなどファイルが頻繁に破損していることを突き止め、
カーネルの不具合を疑いはじめます。

その後の試行錯誤を経て実証コードが完成したのが2022年02月19日。(技術的な詳細は割愛します。詳しくは彼の説明を読んでください)

これはセキュリティホールでもあると言うことで 、2月20日に Linux kernel security team にレポートを送り、
2月21日にセキュリティホールの詳細は伏せて、LKMLに修正パッチを投稿、
2月23日にバグ修正版のlinux-5.16.11 がリリースされています。
実証コードがしっかりしているので、レポートが送られてからリリースまで話がとんとん拍子に進んでいます。

最初の不具合から約一年、地道な調査と修正パッチまで投稿してくれた Max Kellermann 氏の貢献はもっと多くの人に知られるべきです。
興味がある人は是非 https://dirtypipe.cm4all.com/ で彼の報告を読みましょう。

また今回の不具合はセキュリティホールだけでなく、ファイルの破損を引き起こします。

ファイルが破損する条件も具体的に記載されていますので、気になる人はMax氏の報告に目を通しておくべきだと思います。

C89からC11だと間に C99があります.

C99で標準化された機能でカーネルコードに影響がありそうなものは
- 可変引数マクロ． __VA_ARGS__ 使うやつ
- designated の初期化. struct A { int hoge; int fuga}; A a = { .hoge = 1, .fuga= 2}; って書けるやつ
- 可変長配列
- サイズゼロ配列
- for (int x=0; x<10; ++x) って感じでローカル変数が宣言できるやつ
などがあります．

最後の for文内でローカル変数が宣言できる機能が，今回のC89からC11に移行するきっかけになった新機能です．
LKMLの議論だと，全部のメールを読んだわけではありませんが流し読みした感じでは
C89からC99に移行しようと言う話になって，どうせならC11にしたら？って流れになってました．

ただし上記のC99機能は以前からgccなどたいていのコンパイラでは実装済みになっていて(確か GCC 5.0あたりで実装された)
例えば，サイズゼロ配列や designated 初期子は既存のlinuxカーネルでも多様利用されています．
ですから厳密にはC89だけではlinuxカーネルはコンパイルできません．

次にC11で標準化された機能でカーネルコードで役に立ちそうなのは
- _Generic キーワード．c++ でいうtemplate関数みたいなtype genericなマクロが書ける
- stdalign.h ．アラインメントを指定する修飾子が使える
です．

特に _Genericキーワードはかなり強力で，よりセキュアで実行速度が速いコードが簡単に実装できるようになります．今後の展開が楽しみです．

正しくは「改行の直後」じゃなくて「行の先頭」だと思います．
例えば，接続直後なら "~." って打つだけで切断されます．改行は不要です．

openssh のman page (ネット上で見るならhttps://man.openbsd.org/ssh)を確認すると
確かに

The escape character must always follow a newline to be interpreted as special.

と書いてあります．しかしよく読むと以下の記述もあります

The escape character is only recognized at the beginning of a line.

たぶん前者の記述は間違っています．newlineがなくても良い場合があるからmustではありません．
後者の記述のほうがより正しい説明だと思われます．

前頭稜じゃなくて前頭葉の間違いでは？　

前頭葉ってのは大脳の一部です．動物が相手の気持ちを予想したり，相手と会話したり仲良くできるのは前頭葉のおかげです．
前頭葉の大きさを重量比で比べると，人間は30%，チンパンジーで10%，犬で7%，猫は3%になると言われてます．
この数字から，猫は犬よりxxxなんだ，と悪口を言われたりもしてます．

> Stack Overflowにはエクセルを勝手に起動してCSVに変換するVBスクリプト

それ12年前の話ですよ．今時エクセルファイルが直接読み書き出来ない処理系なんてありません．

例えば python なら2行で実装できます．

import pandas as pd
pd.read_xlsx(入力となるエクセルのファイル).to_csv(出力ファイル名)

これだけ．

そもそもデータアナリストを名乗るならエクセルなんて使ってる場合じゃありません．
エクセルを起動するのはせいぜい納品されたエクセルファイルを目視で確認するときぐらいです．

今後、同様の話が日本中で出てくると思います。

まず高齢化そして人口減と続くから、地域密着型の内需産業(?)は先細りして最後は撤退、って流れは避けられません。
夕張市みたいな感じで企業撤退→雇用減・税収減→財政難→破綻となる都市がどんどん出てくるでしょう。怖いっすね。

残念ながら私は使ってやる側でも捨てる側でもありません「作る側」の人間です

私はgithubで複数のリポジトリを無償公開していて，それなりの品質で無償サポートを継続しています．
また他プロジェクトのバグを見つけ修正できた場合は，できるだけpullリクエストを送るようにしています．
理由は，その活動が自分の顔となり，自分の評価につながるからです．

例えばlinuxのカーネルソースには私の名前が載っています．この一言が言えるかどうかで転職や仕事は大きく変わります．
つまり私は「今までの活動の履歴は，将来の自分の評価につながる」と言うことを主張したいのです．
金が欲しいならgithubのリポジトリなりオープンソースの成果を武器にして，良い職に就けばいいのです．

周りが「使ってやるとか」「捨てる」と言う話ではありません．それは受け身の発想です．
githubをどう活用すれば自分が幸せになるか？自分を「使ってくれる」のは誰か？作る側の人間は，能動的にそれらを考え行動するべきです．

ではソースコードを「破壊」したらどうなるか？自分の評価が下がるに決まってます．だから「自殺行為」と表現しました．
表現が過激だと感じた方がいらしたら，ごめんなさい．でもそれくらい「破壊」はクリエイティブな活動をする人間がやってはいけない事だと私は思っています．

自暴自棄になるとソースコードに八つ当たりするような人は，会社としては一番採用したくないタイプの人間です．キレると何をするか判らない，そんな奴と一緒に仕事なんて無理．

ライブラリ破壊は，オープンソースに対する問題提起ではなくて，今までのキャリアを全て無駄にする愚かな自殺行為でしかないと思います．
この作者さん，今までなら採用面接で「私が作者です」と言うだけで「弊社でも以前から使ってます！採用！」となる知名度・貢献度だったのに
非常に勿体無いことをしでかしてます．人生，転がり落ちる時は一瞬なのです．うまく復帰できるといいのですが…職業プログラマとしては終わったかも知れません．