前文 今年は Linux生誕30周年だった。 Linuxが誕生から30年--写真で振り返る、30の重大イベント 30TH ANNIVERARY OF LINUX github で管理されている Linuxソースコードのヘッダコメントでリーナス・トーバルズ氏のクレジットを見かけると、ちょっと感動するよね（小学生並感想）。90年代にトーバルズ氏が書いたコードが今でも世界中の人々によってメンテナンスされ続けているんだなと。 色々と思うところもあり駄文を投稿する。 Linux という名前の OS は存在しない 分かっている人には何を今更って話だけど。 GNU/Linux名称論争 LinuxとGNUシステム 忘れられたLinuxの男 Linux - Wikipedia 狭義にはUnix系オペレーティングシステムカーネルであるLinuxカーネルを指し とあるが、そもそも Linux が OS の名称として公式に宣言・定義されたことなど無いのでは。単純に多くの人々が勘違いしそう呼んでいるだけで。いわゆる バズワード。 Linux界の巨人 Debian では GNU/Linux の呼称を採用している。 Raspberry Pi OS も Debian系だから同様だね。 一方で、面倒臭ぇなぁとも受け止められているテーマでもある。（というかそれが大半の意見か） 要するに Linuxカーネルを採用している OS だから Linux でいいだろと。 しかしそうなると、FreeBSD、NetBSD、OpenBSD といった所謂 BSD系と呼ばれる物ってどうなんだろう。Linux の一派と捉えている人も多いみたいだが、採用カーネルは Linux じゃないよね。 じゃあ何かと言えば、BSD は BSD。Linux ではない。（※1） 面倒臭ぇなぁ。じゃぁ UNIXクローン = Linux でいいだろ、となると……。 Linux は UNIXクローンとして開発を開始したものではない ここまでくると最早屁理屈というか、今となっては状況も異なるだろうが、Linux とは元々はそういったもの。 MINIX をベース、書き換えたものが出発点だから、MINIXクローンということになる。MINIX は UNIXクローンだから、Linux は UNIXクローンのクローンとも言える。 因みに、非アップル製スマホに搭載されている OS は、あまり Linux と呼ばれることはない。そう、Android だね。 Linuxカーネルを採用しているが、あまり Linux一派に見られないのも面白い。というか Android は Android、ちょっと特殊な立ち位置。そこら辺を分かっていれば、自ずと「ディストリビューション」という言葉の意味が理解できる。 ディストリビューション (distribution)とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 Linux は堅牢なシステムではない それは根本的、構造的な弱点を抱えているから。 「嘘乙、自分は業務で Linxサーバを運用しているが、チョー安定してるし」といった声も聞こえてきそうだけど。 それは限定的な運用しか経験していないから、個人の趣味レベルで Linux を触ったことがないから堅牢という印象を受けるのでは。 例えば、個人利用なら、やれ内蔵ストレージが足りなくなったから外付けHDD を増設したり、内蔵無線LAN の規格が古いから新しい USBドングルの無線LAN を追加したり、等々、HW構成の変更は個人利用 PC ならよくある。それがパソコンの面白さでもあるし。 そして質の悪いドライバを引いたりすると途端に泣きをみる。下手すると起動さえままならない。 一方業務レベルの話になると、サーバであったり組み込み系だったりとか。HW要件は限定されている。それを前提に調整していれば、そりゃ安定しているわな。所謂運用でカバーってやつ。 話を個人利用、ドライバの話に戻す。 それってドライバが悪いのでは、とも言えるが、それがシステムに深刻な影響を及ぼすのは、ドライバを含めた構成方法の問題。 それが前述、根本的、構造的な弱点。Linux がモノリシックカーネルであるから。Linux が公開された当初、MINIX作者であるアンドリュー・タネンバウム氏が強く非難したのが正にその点。 アンドリュー・タネンバウムとリーヌス・トーヴァルズの議論 - Wikipedia タネンバウム氏が Linux を非難する一方、薦めたのが GNU Hurd。理由は勿論マイクロカーネルを採用していたから。 自分は OS についてソフトウェア工学的な高等教育を受けた人間ではないし（そもそも文系人間だし）、正直 OS、カーネルの難しい話にはついていけない。 しかし、Linux で質の悪い（カーネル）ドライバばカーネルに悪影響を及ぼす、最悪クラッシュさせる、という問題はドライバを含めたカーネル構成（モノリシックカーネル）、構造的な問題であり、一方、カーネルは最小の構成とし（マイクロカーネル）、ドライバ類はレイヤーを分ける、という構造であれば影響を受けない（受けにくい、堅牢）ということは理解できる。 特に BUFFALO WI-U3-866DS(rtl8812au) の件では本当に苦労させられ Linux の構造的問題を実感した。 しかし、モノリシックカーネル vs マイクロカーネル の対比はそんな単純な問題でもないらしい。OS界（オープンソース界）のサグラダ・ファミリアこと GNU Hurd が何時までたっても完成しないのは、マイクロカーネルが原因とのこと。 GNU Hurd - Wikipedia 一方、ストールマンは、開発の遅れはマイクロカーネルのデバッグが予想以上に難しかったためであり、LinuxがHurdに比べ早く開発できたのは、Linuxがモノリシックカーネルであることによるとし、自分の戦略的なミスであったと述べている また、Windows NT も当初はマイクロカーネルこそが至高のカーネルと目指したものの難航し、結局ハイブリッドカーネルに落ち着いた、なんて話が 「闘うプログラマー」 内の一節で出てきたような。 そもそもモノリシックカーネルかマイクロカーネルかなんて話は今となっては前時代的で、ハイブリッドカーネルが落としどころ、モダンな考えらしい。 阿久津良和 氏の「ハイブリッドカーネル」の説明がおかしいので、正しいハイブリッドカーネルを説明します。 また Linux が当初 x86系列のプロセッサーに密着していたこともケチをつけられた。 特定の CPU を対象としていることだけではなく、そんなんじゃ将来性ないよってことで、これも「外れた予言」だが、それに対して先見性が無いというのは違うと思う。 x86系は電卓上がりなどと揶揄され、建て増しに次ぐ建て増し、屋上屋を重ねる設計でなんせ汚い。一方モトローラの 680x0シリーズは出自が違う、設計が綺麗。 というのが当時 CPU に対してアセンブラレベルの知識を持っていいる人間の認識だった。 それがまさかこんな状況になるなんてねぇ。 いつまで経っても完成しない GNU Hurd と世界を席巻することになった Linux の違いは選択する道の違いもあっただろうし、リーダーの求心力（※2）やその時代の流れもあっただろうし。 それを含めて OS、カーネルの世界ってのは難しいものだね。 ただ個人的な想いとして。 90年代に GNUの洗礼を受けた人間、GCC（GNU C Compiler）や GNU EMacs に強い衝撃を受けた世代としては、どうしても GNU には夢を見てしまう。GNU Hurd には頑張って欲しいよ、ホント。 それとこの手の話で思い出すのが、UNIX 以上に UNIX らしいと言われた Plan9。（※3） UNIX の後継、問題解決という位置付けで UNIX開発のオリジナルチーム、ドリームチームが集結し開発。 と鳴り物入りだったが結果はどうだったか。 Plan9 の内部コードとして設計された UTF-8 は今となっては Web等の世界では標準だったり、Plan9 の功績の一部は UNIX にフィードバックされたりと、それなりに結果は残しているんだろうけど。 少なくとも、UNIX は Plan9 に取って代わられた、なんてことは起こらなかった。 というかそもそも UNIX 自体がもうアレという状況だったりするし。 虫の息の商用UNIXたち・・・。おそらく10年後は・・・・。 UNIX を語る上で、UNIX とは OS ではない、一つの考え方、思想・哲学だ、なんて話がよく挙がる。「UNIXという考え方―その設計思想と哲学」 なんて書籍まで出ている。 確かに、普及成功した OS は優れた設計思想に基づいているものだが、かといって優れた設計思想、高尚な志しならば成功する、という単純な話でもない。OS を俯瞰しているとつくづく考えさせられるし、そもそも OS って何なんだろうね、って話に行きつく。 これ なんかを眺めていると単発で消えた OS から脈々と系譜を重ねるものまで様々。 繰り返しになるが、で、その違いはどこから？ と考えさせられる。設計思想だけではなく、搭載されたハードのセールス等々、様々な要因があるんだろうけど。興味は尽きないよな。 Linux とは何か IT系というかシステム開発系というか。そんな業種に携わっていると、自分もそうだが業務で UNIX / Linux に触れる機会は多い。そして、その方面なら結構詳しいよって人も多い訳だけど、いざ会話してみると UNIX V6 も通じなかったりして温度差を感じることが。 どうやら、ユーザーランドを触った経験しかないのに、「自分は詳しい」と思い込んでいるように見える。 確かに、カーネルドライバの開発に携わっているとかでもない限り、カーネルの知識なんて必要ないし、業務で求められるものはユーザーランドの知識で事足りるのも事実。 ただそれだけで、「自分は詳しい」と思い込んでいる人は、Linux 上のユーザーランドを Linux そのものと思い込んでいる節があり、それは違うだろっていう。 孫悟空がお釈迦様の掌で行ったり来たりしただけで、それがこの世の世界すべてと思い込んでいる話を彷彿とさせる。 平たく言えば井の中の蛙大海を知らず。 そして今年は PC 生誕40周年でもあった 40 years of the PC 日本で「PC」と言えば NEC の PCシリーズを指すが、海外（米国）では IBM PC を指す、などとかつて言われていた。40周年の「PC」は勿論この IBM PC のこと。というかもう 40年も経つのか……（遠い目）。歳を取る訳だよ。 Linux にも通じる話で、まさか IBM PC（というか互換機）一色の時代が来るとは、と。 当時の世相を反映するものとして忘れられないのが当時アップルが打った意見広告。 Apple's Welcome IBM Seriously Ad Windows95発売の際に出した秀逸な意見広告も面白かったし、こいついっつも意見広告だしてんな。 IBM PC に対するものの可笑しさは、GAFA の一員と知られる巨大企業に成長した現在のアップルしか知らない世代にはちょっとピンと来ないのでは。 当時のアップルはまだ創業5年程度、駆け出しのベンチャー企業だった。それが天下の IBM に対してこの意見広告というビッグマウスっぷり。 創業当時のエピソードとして Apple][ のヒットが神話化されているが、逆に言えばそれしか良い点はなくその前後は商業的に失敗している。Apple III なんかは FD が溶けたなんて伝説まで残っている。 2年後に出荷される Apple Lisa も、ジョブズ氏の隠し子から命名されたらしい、なんてゴシップばかりが先行しやはり失敗。 その後 Macintosh が世に出る訳だが、これも当初はマシンスペックが低く使い物にならないレベルだった。何せ当時のアップル製品は高額だったので売れなかった。 トム・クルーズ主演「ミッション:インポッシブル」（1996年）にアップル製品が登場していたが、当時はアップルの再建こそがミッションインポッシブル（不可能な指令）だよな、などと茶化されていた。そういえば中々完成しない Apple Newton なんてものもあった。とにかく経営は迷走傾く一方だったというね。 話を IBM PC 登場の時代に戻すと、駆け出しのベンチャー企業だったとはいえ、コモドール等と並び個人用、ホビー用コンピュータ市場を牽引開拓してきた、という自負が当時のアップルにはあったと思う。そうした市場の成長があったからこそ、いよいよ IBM も参入、となった訳で。 当時のアップルと IBM のサイズ感はアリと巨人。しかし、アップルにしてみれば、こっちの世界じゃ自分がセンパイ、焼きそばパン買ってこい、5秒でな、ぐらいの勢いだったのでは。 つまり、満を持してといえば聞こえはいいが、IBM のパソコン事業への参入は時期としてかなり遅かった。 それこそ日本でも既に大手家電メーカがパソコンを出していて（いわゆる 8ビットパソコンですな）それなりの市場が形成されつつあり、そんなガラパゴス市場に IBM とはいえ入り込むことは難しかった。また本国米国でも、いかにも IBM が出した面白みのまったくないパソコンというのがギーク評だった。 他社の後塵を拝していた IBM がシェア拡大を目論んだ方針が HW仕様の公開、互換機の製造許可。それにより、パーツ単体で購入し組み上げると IBM に高い金を払わなくても済む、同等のものが割安で手に入るという自作文化や価格競争が生まれた。 やがて IBM 自身のシェアまで喰われる事態となり、IBM は パソコン事業から撤退。正に焼肉定食弱肉強食の世界。 IBM も当時はシェアが喰われていくことに危機感を覚え、HW仕様の公開を辞めブラックボックス化した時期もあったり等、上記のような単純な話でもなかったようだけど結果としてはそんなところということで。 そもそも工業製品なんてそんなもの、って話かもしれないが。 しかし、IBM が汎用機の斜陽と共にコンピュータ事業が衰退していき、今となってはサービス会社みたな様相ってのが。かつて米ソ冷戦時代、国家の威信、面子をかけ膨大な費用を投じたアポロ計画。そのアポロ計画に採用されたのが IBM System/360。 恐ろしいのが、System/360 の開発費はアポロ計画を超える予算だったという。そして System/360用 OS開発の中の人が書いたのがソフトウェア工学、ソフトウェアプロジェクト管理の古典 「人月の神話」。銀の弾などないのだよ。（※4） そんな巨人っぷりを多少なりとも知っていると、現在の IBM はちょっと残念。当時を忍び、映画「2001年宇宙の旅」の中で IBM のロゴを探す大会もまた一興（※5）。 補足 ※1 今となっては Linux = 無償、UNIX = 有償（プロプライエタリ）という棲み分けだが、UNIX も黎明期は無償だった。 逆に言えば初期の UNIX はその程度（？）のものだった。ソースは全て合わせても約1万行。一方 Linux Kernel のソースコートは1,000万行を超えると言われている。 初期の UNIX にはネットワーク関連の機能は無かったし、UNIX の代名詞、viエディタも無かった。それを追加したのが BSD の連中であり、それが UNIX にフィードバックされる等して UNIX は拡張成長していった。だから今でも BSD は UNIX の一翼を成す存在となっている。 macOS も実は BSD系だったりする。 ※2 ストールマンの奇人変人っぷりは有名だが、トーバルズ氏もかなりエキセントリックな性格。 最近では 反ワクチン派の主張に激怒 が記憶に新しい。それにしても Windows 7 発売日にニッコニコで記念撮影 していた件は今見ても笑える。リーナス先輩、そんなトコで何やってるンすかー。お茶目な人だよな。実はそれが Linux 成功の鍵だったって話も。 ※3 そもそもこのネーミングセンスがギークであり、ダメだろそれ、とも。 もっとも UNIX の命名とて、これじゃ Multics ならぬ Unics、→ UNIX というふざけた経緯があるし、これがベル研のノリなのかも。 ※4 というか狼人間じゃなくても銀の弾なんか撃ち込まれたらひとたまりもないよな。 ※5 劇中内に登場するコンピュータ等は当初 IBM が全面協力していたが、コンピュータが人間に対して反乱を起こす（殺人を犯す）という脚本内容を知り撤退した、という話は有名。これにより、劇中で多数使用されていた IBM のロゴは全て削除された、とされているが、現在知られているだけでも三か所で IBM のロゴが確認できるらしい。探してみようぜ。 それはそうと、月面で調査チームがモノリスを取り囲む件で、宇宙服のヘルメットに撮影中のキューブリック監督が映り込んでいるという指摘があるが、ドコよ？

はじめに 実行中のスクリプトに対して更新処理を行ったところ想定外の処理が発生して、ファイルシステム上のデータが消失するといった事故があったので、改めてinodeの挙動を確認した結果を纏めました。 inodeに関する挙動については知りたい方は参考サイトに載せたサイトをご覧ください。 環境 Ubuntu20.04で動作を確認しましたが、他のLinux OSでも大差ないと思っています。 ちなみにUbuntu20.04は、MacOS上でVagrant+VirtualBoxを利用して立ち上げています。 確認結果 cpコマンド、mvコマンドを中心に実行結果を記載します。 なお、ファイルの配置状況は以下のようになっています。 vagrant@ubuntu2004:~$ ls -li total 8 70233 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test01.txt 70089 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test02.txt 1. cpコマンドによる単純コピー cpコマンドでtest01.txtをコピーして、test03.txtファイルを作成します。 vagrant@ubuntu2004:~$ ls -li total 12 70233 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test01.txt 70089 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test02.txt 19210 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:04 test03.txt 当然ですが、test03.txtのinode(19210)は、test01.txtのinode(70233)と違う値となります。 2. cpコマンドによるファイルの上書き cpコマンドでtest01.txtをtest02.txtに上書きします。 vagrant@ubuntu2004:~$ cp test01.txt test02.txt vagrant@ubuntu2004:~$ ls -li total 12 70233 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test01.txt 70089 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:05 test02.txt 19210 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:04 test03.txt 実行の結果、test02.txtのinode(70089)は変化しません。 同じinodeですが、ファイルの中身は変更されている状態となります。 実行中のスクリプトに対して、cpコマンドでファイルを上書きすると、実行中のスクリプトの動作が変更されますので注意が必要です。 3. mvコマンドによるファイルの上書き mvコマンドでtest01.txtをtest03.txtに上書きします。 vagrant@ubuntu2004:~$ ls -li total 8 70089 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:05 test02.txt 70233 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test03.txt 実行の結果、test03.txtのinodeはtest01.txtのinode(70233)を引き継ぐ形となります。 上書き前のtest03.txtのinode(19210)から変化するため、スクリプトが実行中の間は上書き後のファイル(inode:70233)を読み込むことはありません。 これはディレクトリエントリからtest03.txt(inode:19210)をアンリンクするだけで、実行中のスクリプト自体は残っているためです。もし実行中のスクリプトをどうしてもファイルの上書き変更したい場合は、mvコマンドを使う方法が安全だと思われます。 なお、スクリプトの実行が終了した状態で他のプロセス等からも参照されていない状態となったら元のファイルが削除されます。 4. mvコマンドによるファイルリネーム mvコマンドでtest02.txtをtest04.txtにリネームします。 vagrant@ubuntu2004:~$ mv test02.txt test04.txt vagrant@ubuntu2004:~$ ls -li total 8 70233 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:02 test03.txt 70089 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:05 test04.txt 実行の結果、test02.txtのinode(70089)は変化しません。 5. vimコマンドによるファイル内容の変更 vimコマンドでtest03.txtの内容を変更して、保存します。 vagrant@ubuntu2004:~$ vim test03.txt vagrant@ubuntu2004:~$ ls -li total 8 70234 -rw-rw-r-- 1 vagrant vagrant 14 Dec 29 15:10 test03.txt 70089 -rw-rw-r-- 1 vagrant vagrant 7 Dec 29 15:05 test04.txt 実行の結果、test03.txtのinodeは変化します(70233→70234)。 これはvimが一旦別で書き出した後、リネームしてファイルを上書きするためだと思われます。 そのため、ちょっとした変更だけなら実行中のスクリプトをvimコマンドで修正しても問題ないと思われます。 もしinodeを使い回したい場合は、backupcopyをyesに設定すれば良いと思います。 6. rsyncコマンドによるファイルの上書き rsyncコマンドでtest03.txtをtest04.txtに上書きします。 vagrant@ubuntu2004:~$ rsync test03.txt test04.txt vagrant@ubuntu2004:~$ ls -li total 8 70234 -rw-rw-r-- 1 vagrant vagrant 14 Dec 29 15:10 test03.txt 69766 -rw-rw-r-- 1 vagrant vagrant 14 Dec 29 15:34 test04.txt 実行の結果、test04.txtのinodeは変化します(70089→69766)。 test03.txtのinodeとは全く違った新しいinodeがtest04.txtに振られています。 あまりrsyncでファイルを上書きすることはないかもしれませんが、mvコマンド以外にも実行中のスクリプトを上書きする方法があることは覚えておいてもいいのかなと思っています。 まとめ 確認結果を以下に纏めます。 # 処理 inodeの状態 1 cpコマンドによる単純コピー 新規inodeが割り当てられる 2 cpコマンドによるファイル上書き inodeは変化しない 3 mvコマンドによるファイル上書き 元ファイルのinodeを引き継ぐ 4 mvコマンドによるファイルリネーム inodeは変化しない 5 vimコマンドによる内容変更 inodeは変化する(新規inodeを割り当て) 6 rsyncコマンドによるファイル上書き 新規inodeが割り当てられる 実行中のスクリプトを変更する必要が出てきた場合は、cpコマンドによるファイル上書きだけは避けましょう。 参考サイト inodeから見たmvやcpの動き

背景: 最近、Windows10でも日本語入力のIMEオフオンが「全角/半角」キーだけではなく、CapsLockキーでも変更可能になりましたね。実際にCapsLockキーに割り当てたら非常に効率良くなりましたので、プライベートPCのUbuntuでもCapsLockを利用することにしました。 この設定自体は、Kubuntu上の入力メソッドで簡単に変更できました。 なお、実行環境: Ubuntu 20.04.3 LTS, KDE Plasma:5.18.5 ですが、設定自体はディストリビューションなどに依存していないと思います。 問題発生: 初めはCapsLockのオフオンが快適でしたが、暫くしていると日本語のオフオンのCapsLockと本来のCapsLockとが競合するようになりました。意図せずに、大文字でロックされるようになり、使いづらさを感じてきました。どうやら、デフォルトではCapsLockを一度押すだけで、本来のCapsLock(大文字ロック)になってしまっています。 Windowsなどでは、そもそも大文字に固定したい場合には、Shift+CapsLockキーを押すことで固定できます。私は、そもそもCapsLockを使うことはありませんので、Shift+CapsLockにしたいと考えました。 デスクトップ環境に付属しているツールによっては、Shift+CapsLockに変更可能という情報はありましたが、私が利用しているKubuntuでは、該当のツールがなかったため、他の方法を模索し始めました。 解決したかったこと: Shift+CapsLockでCapsLockとし、 CapsLockは日本語入力専用にしたい。(Windowsに合わせたい) キーの入れ替えなどはややこしくなるので、避けたい 実施したこと 1. xmodmapコマンドでの確認 xmodmapコマンド ~/$ xmodmap xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock control Control_L (0x25), Control_R (0x69) mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb) lockというエントリーが気になります。ここにエントリーがあると、一度押しただけでロックされるようです。 特に何も設定しているつもりはないので、どこかにデフォルト値が入っていると思います。 デフォルト値がわかればそこを変えればよいのですが、今回は手っ取り早く、ユーザーの設定で上書きします。 2. .Xmodmapの作成と追加 そこで、以下のようにファイルを作成し、気になるlockを消す設定を入れます。 ~/.Xmodmap remove lock = Caps_Lock 一旦、これを再読込させ、動作確認をしてみます。 bash:xmodmapの再読込 ~/$ xmodmap ~/.Xmodmap 3. .bashrcへの追記 ただし、このままでは再起動などで消えてしまうため、.bashrcに入れておきます。 .bashrcの最下行に以下を追加 xmodmap ~/.Xmodmap 試しに再起動してみて、動作確認してみたところ、うまく動作することを確認しました。 これでまた、Ubuntu(Kubuntu)が快適になりました。