  |
はてなキーワード: システムコールとは
フリーレンが集めてるしょーもない魔法は、pipとかnpmに上がってるしょーもないパッケージ
っていうのを集めてる
魔法の解析はリバースエンジニアリングのことで、フリーレンはその天才
で、魔法は単純なプログラミングコードではなくてLLMをベースにしたコードになっていて
魔力っていうのはそのLLMのモデルの大きさ
長い年月をかけてLLMを追加学習させることで魔力を増やしていくが人間はそのモデルの大きさを誇ろうとしない
魔力の揺らぎはLLMの出力の微妙な違いのことで、LLMのモデルが大きいと
「単純な答えのように見えるけど微妙に違っていて実は大きなモデルなのでは？」
と気付く
AIなのでLLMしか取り柄が無く、モデルの大きさでマウントを取り合うのが魔族
ただ人間と違って死ぬことがないので魔族の使うプロンプトエンジニアリングはまるで理解できず
人間が再現できないLLMベースのプログラミングコードは「呪い」として扱われてる
してませんね。
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
これだとどう？
比較の話ですが、nodeやらpythonやらに比べたら「実際にそのプロダクションで使っているコマンド」のアップデートの頻度はずっと小さいですよ。
今までにされた検証は遥かに多く、コマンドのソースコードは遥かに小さいので、当たり前ですが。
命に関わらないシステムを動かしてるWeb系の業界想定ならRustで書くのが非生産的なのは同意だけど、なんで危険になるのか知りたいね。
コードを読んだ人数も実際に動作検証された回数も1桁単位のその場その場で作られたコードよりも、
長年にわたってメンテナンスされ、膨大な人数の技術者に読まれ、億を優に超える回数で、特殊なケースを含めて様々なパターンで実行された小さなコードの方が信頼性が高いからですね
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 3273 | 警察が嫌がる苦情の入れ方（警察にとってダメージの大きい苦情の入れ方） ｜ 元警察官による暴露ブログ | k-satu.work |
| 1365 | 【激安】ボロいい温泉宿→「食事はうまい＆温泉は極上…オススメあり」 | onsenzanmaiblog.com |
| 895 | 【アメリカの楽しい家庭のおやつ】 ｜ 【公式】dancyu (ダンチュウ) | dancyu.jp |
| 778 | ジャニーズ事務所に対する当社の対応について ｜ 重要なお知らせ ｜ 株式会社コーセー 企業情報サイト | corp.kose.co.jp |
| 771 | 「それならやめましょう」と言ってくれた店員さんとの話 - インターネットの備忘録 | hase0831.hatenablog.jp |
| 687 | 昨日からバズりまくっている動画（iPadが演奏中にフリーズ）でピアノを弾いている本人にお話を聞いてみた ｜ office yamane | officeyamane.net |
| 679 | 藤島ジュリー景子『Mステ』へ他社男性アイドル出演について「今回はしょうがないですけど、これが続くようなら対応を考えます」と圧力…反省ゼロが露見 ｜ The Audience | the-audience-news.com |
| 633 | コラム ｜ 岐阜大学大学院医学系研究科脳神経内科学分野 | www.med.gifu-u.ac.jp |
| 629 | 【ジャニーズCM企業一覧】誰がどこに出てる？契約解除になるスポンサーは？2023年 ｜ R30ブログ | gohantublog.com |
| 611 | ジャニーズ性加害の次は女性アイドルの枕営業を明るみにすべき！ テレビが黙殺してきた芸能界の性的搾取を今こそ問いただす時 - まいじつ | myjitsu.jp |
| 577 | 1,000行で作るオペレーティングシステム | seiya.me |
| 577 | 4年半勤めた会社を辞めた話 - 工学系チキンによる工作ブログ | woodencaliper.hatenablog.com |
| 570 | Linux システムコール 徹底入門 | www.kimullaa.com |
| 565 | 錯視，幻視ー脳のなかの幽霊たち | www.bri.niigata-u.ac.jp |
| 552 | 山口達也と非生産 by 非公開: 田房永子｜LOVE PIECE CLUB（ラブピースクラブ） | www.lovepiececlub.com |
| 529 | (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book | t2y.hatenablog.jp |
| 526 | 【9/29追記】NURO光に申し込んだら4ヶ月弱待たされた挙げ句解約しろと言われた件 - Yebisu303’s diary | yebisu303.hateblo.jp |
| 514 | 教員のなり手不足解消「正直、名案はない」 盛山文科相就任会見 | www.kyobun.co.jp |
| 511 | テレビはどうしてジャニーズ事務所とここまでグダグダの関係なのか｜More Access! More Fun | www.landerblue.co.jp |
| 475 | 君は青いギターが呪物になる過程を見たことはあるか？／大槻ケンヂ「医者にオカルトを止められた男」｜webムー 世界の謎と不思議のニュース＆考察コラム | web-mu.jp |
| 467 | 第1話 / インターネット・ラヴ！ - 売野機子 ｜ FEEL web｜マンガの数だけ愛がある | feelweb.jp |
| 464 | 【速報】ホンダが「モトコンパクト」を発表！ 電動でモトコンポが再来、価格は1000ドル（約15万円）以下！ ｜ Webikeプラス | news.webike.net |
| 449 | "真打落語家"蝶花楼桃花 | rikkyogeinokenkyu.wixsite.com |
| 427 | DJ SODAさんの再来日にネット民驚愕！ 挑発的・性的な私服で「公然わいせつ」「入国禁止にして」の大合唱 | nnjnews.net |
| 424 | 教科書制作からYouTuberに転身し、ヒットを連発。人気チャンネル「ゲームさんぽ」の着眼点 | hatawarawide.jp |
| 415 | ニュース詳細｜ハロー！プロジェクト オフィシャルサイト | www.helloproject.com |
| 402 | ネット・ゲーム依存対策の学習シート 誤りを指摘する公開質問状に香川県教委は「回答せず」 ｜ KSBニュース ｜ KSB瀬戸内海放送 | news.ksb.co.jp |
| 395 | 第1ステージで起きてしまった事故の経緯 - ツール・ド・北海道2023 大会キャンセル 詳報 | www.cyclowired.jp |
| 383 | 【お詫び】弊社販売車両が転売されてしまったため、トヨタ車 全車種の新規販売受付見合わせ。※トヨタ車以外は継続販売。 | www.sankoh-jp.com |
| 381 | 内部告発【前編】洲本市元課長の不正行為～東京アンテナショップ元店員たちの証言と録音データ「現市長は知っていたはずだ…」～サンテレビニュース | sun-tv.co.jp |
9x→XP（2k）で動かなくなったアプリが多々あったのは確かだけど、それはファイルアクセスの権限の問題というよりは、アプリがパフォーマンス最重視で設計されていたりレガシーコードが悪さしたりして古いシステムコールを多用してたのが原因だったのではないかなと思う（起動した瞬間にハングアウトしたり画面が化けたりするゲームがあったことを覚えている）
XPSP2でファイアウォールがOSのデフォルト機能として搭載されたけど、それはアプリのインターネットアクセスを規制するためのもので管理者権限での実行を制約するものではなかったはず
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
この記事はよく調べてあるなぁと思う反面，事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが，空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから，安易に『UNIX 哲学』とかいうな」という主旨には大賛成である。
初期の UNIX の歴史について興味がある向きには次の書籍をお薦めする。
Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)
和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが，原書は The Unix Heritage Society (tuhs) で PDF が無償公開されているので，英語が苦にならないのなら読んでみるといい。
また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』（1989, Prentice Hall）を読めば80年代終りの UNIX の状況（XENIX についてもしっかり言及されている）や利用者目線での雰囲気もある程度判るだろう。
元記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ，当時は設計の基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。
https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date
ほぼ毎号のように出現していたのが判るだろう。
もっとも猫も杓子も「哲学」を振りかざしていたわけではないし，UNIX の開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT＆T の定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事で言及されているマキルロイの Forword の初出がこれで，ネットのアーカイブから PDF が入手できる。
この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本（全172ページ），第二部が UNIX に関する（Preface や Foreword を含む）論文22本（全416ページ）となっている。さて前述の PDF は OCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX の論文なのだ。もちろん論文の性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイの哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白い。UNIX の開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが，それまでにない新しい考え方に基づいた OS を開発しているという意識があれば，そういう言葉を選ぶのが自然な時代だったことは間違いない。
UNIX が認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい，あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが，そんなたいしたものではない。マキルロイの論文に影響を受けた布教のためのああいう説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本で最初期の UNIX 解説本のひとつである，村井純・井上尚司・砂原秀樹『プロフェッショナル UNIX』（1986，アスキー）には冒頭次のような一節がある。
オペレーティング・システムは，コンピュータを使うものにとっての環境を形成する基盤であるから，そのうえで生活する者の個性を尊重し，より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが，UNIX のオペレーティング・システムとしての個性ではないだろうか。
「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能のコマンド群のことで，これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性を尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが，たまたまガンカースだったというだけのことである。
そしてじつは UNIX の場合，布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが，その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。
UNIX は PDP というミニコンピュータ（ミニコン）上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は，もちろん場所によって違うわけだが，マアおおよそ学校の教室くらいの大きさだ。長机が何列か並んでおり，そのうえにはブラウン管ディスプレイとキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校にコンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器はコンピュータではなくコンピュータに接続するための端末装置（ターミナル）だ。端末装置のキーボードで打った文字がコンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 Unix 系 OS で CLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置のエミュレータで，もともとは実体のある装置だったわけだ。
さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥や洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっともコンピュータが何台もあるわけではない。この箪笥が CPU でそっちの洗濯機がハードディスク，あの机に置かれているタイプライタが管理用コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて，なんてミニ！」という時代のお話だ。
端末装置それぞれから（USB のご先祖様の）RS-232 という規格のアオダイショウみたいなケーブルが伸び，マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び，root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。
結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは，マアどうでもいい。
当時の UNIX の評価を一言で表すと〝自由で不安定な OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由。さらに他のメインフレームやミニコン用 OS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロ用 OS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番のディスりだった。UNIX の落とし方，みたいな情報がなんとなく廻ってきたものだ。
こういった雰囲気を鮮やかに伝えてくれるのが，高野豊『root から / へのメッセージ』（1991，アスキー）だ。当時アスキーが発行していた雑誌『UNIX MAGAZINE』に連載されていた氏のエッセイの1986年11月号から1988年10月号掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器で1980年ごろから UNIX サイトのスーパーユーザを務めており，日本では最古参の一人である。この本の中で高野氏は繰返し UNIX の自由さと不安定さに言及している。すこし長くなるが，その中の一つを引用しよう。
CPU は，システムにとって重要な共有資源であるが，この CPU を実質的に停めてしまうことが UNIX ではいとも簡単にできる。たとえば，cc コマンドを10個くらい同時に走らせてみたらよい。VAX-11/780 といえども，同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが，他に与える影響が無視できなくなる。つまり，てきめんに vi のカーソルが動かなくなる。あるいは，すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり，タイムアウトでログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると，UNIX は破壊されたに等しい。真夜中，独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし，20人30人と多数の人間が使っているときに勝手をやられると非常に困るのである。当人の仕事が遅れるのは自業自得だとしても，そのとばっちりで他のエディタまで止まってしまうと，もはやどの仕事も進行しなくなる。
ディスクについても同様なことがいえる。UNIX では，ファイルシステムを使いはたすまで大きなファイルを自由に作ることができる。したがって，自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと，コンソール・タイプライターにエラー・メッセージが出力されるが，夜中にそれが発生して，コンソール・タイプライターが一晩中エラー・メッセージを打ち続け，朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい，ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると，それをしでかした本人のプロセスは当然のこととしても，同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい，わずかでも仕事を先に進めようとする意図も完璧に打ち砕かれてしまうのである。
そして，こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンドを10個くらい同時に走らせ」たり「自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイトの利用者全員に UNIX の設計の基本的な考え方を理解してもらうことが，自分のために必要だった。UNIX の伝道がより苛烈だった理由のひとつがここにあるのだ。
ミニコン上で誕生した UNIX は 4.3BSD（1986）で最高潮を迎える。注意したいのはミニコン時代の UNIX は Research UNIX と CSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX と記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT＆T から UNIX のライセンスを購入し，そのうえでカリフォルニア大学バークレー校（UCB）から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研で発明された UNIX を外部の人たちも含めみんなで改良し，それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。
もっともそういう70年代風味の牧歌的風景はミニコン世界限定の話であった。BSD そのものはミニコン用のものしかなかったが，そのコードを受け継いだ BSD 系 Unix や AT＆T が推し進める System V などがワークステーション市場を舞台に80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で，PC 用 Unix であるマイクロソフトの XENIX も当然参戦した。ミニコン世界が牧歌的だったのは，ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争はあくまでも標準という聖杯を争う戦いであり，AT＆T と BSD 系 Unix の Sun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。
こうしたミニコン UNIX からワークステーション Unix への転変は Unix そのものや文化にも変化をもたらした。まず激しい競争は Unix の高機能化を加速した。商品として判りやすい惹句が「あれもできます，これもできます」なのは誰もが知っている。もちろん安定性を増すために quota のような利用者の自由を制限する機能も含まれていた。またワークステーション Unix は現在の Unix 系 OS と同様同時に一人が使うものであり前述の布教の必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』（1993，オーム社）を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unix のシステム管理の入門書だ。この本ではたんに知識を羅列するかわりに架空のソフトウェアハウス（開発会社）を舞台に新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており，そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。
当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイの論文の結論部分に書かれたそれは，1973年に出版されたイギリスの経済学者エルンスト・シューマッハーの著作の題名で，中学生の英語力があれば十分に理解できる平明な一文だ。
Small is beautiful.
マキルロイは『人月の神話』を引いて一定の留保をつけてはいるものの，これが UNIX 哲学の背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•cs のアンチテーゼである UNI•x にとって，これ以上のスローガンがあるだろうか？
ひるがえって現在の Unix 系 OS をみれば，ブクブクと肥え太ったシステムコール，全容を俯瞰するだけでも一苦労するライブラリインターフェイス，一生使うことのないオプションスイッチまみれのコマンド群。UNIX が仮想敵とした OS そのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ，コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ，歴史書を飾る一項目になっただけだ。ただ現在「UNIX 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。
リーナスがLinuxを開発したというのは、どれほど「技術的に」すごい偉業だったのでしょうか？
生越 昌己
回答日時: 2022年4月23日 · 執筆者は841件の回答を行い、180.3万回閲覧されています
なんか呼ばれてる気がした。
「技術的に」はどうってことないものです。別の回答で私の書いた記事が引用されているので、その辺の歴史的なことはそっちを読めばわかると思います。「やればできる」範囲のことです。実際、あの記事には書きませんでしたが、そのちょっと前くらいに私の知人(日本人)がフルスクラッチのUNIX互換マイクロカーネルOSを独力で書いてます。これも彼に言わせれば、「教科書通りに実装しただけ」とのことです。なお、UNIX系OSの実装は、いくつか教科書が出ています。また、「NET2」という4.3BSDのフリー(ってことになっていた)な部分のコードも公開された後です。つまり、参考にするものは結構あったんです。
実はOSそのものは、「技術的にすごい」必要はないです。もちろん、いろんな点で「技術的にすごい」ことをする必要性のあるところはありますが、「普通の実装」であれば「教科書通りに実装しただけ」で作れます。「ぼくのかんがえたさいきょうのプロセスモデル」なんてものは必要ありませんし、「マイクロカーネル技術」なんてのも、あればあったでメリットありますが、なければなくても困りません。UNIXのその辺は普通の人達が思っているよりもずっと単純で、実装もそんなに難しいものではありません。ですから、特に「何かの互換品を作る」というのであれば、動かすだけであればそんなに大変ではありません。バランス感覚が要求されて難しい部分は既に他人が実装しているわけですし、「教科書」や「参考コード」はいっぱいありましたから。
Linuxが凄かったのは、一つは「運」です。多くの人が求めているタイミングで、まがりなりにも動くものを出すことができた。これは多分最大最強の「すごいこと」です。
Linuxがリリースするちょっと前に、AST(Andrew Tanenbaum
)はMinixの「次のバージョン」についての「やらないことリスト」を作っていました。野良で作られたMinix386を使っていた人達を始めとする「MinixがもっとUNIXになって欲しいと思っている人達」は、それを見てガッカリしたものです(私も)。Minixを実用品にしようとする流れに完全に背を向けた形で「教材としてのOS」に力点を置いたもので、ASTの立場を考えれば当然とは言え、いろいろ残念な思いをしました。Linuxがリリースされたのは、そのショックから覚めやらぬ時期だったので、それを見た人達は、まさしく
ｷﾀ――(ﾟ∀ﾟ)――!!
その次に凄かったのは、「それを実用品に持って行けた」ことです。「動く」ということと「実用品になる」ことの間には、とんでもなく深い「谷」があります。これを超えるのは、「運」も大事だし「技術」も不要じゃないんですが、それだけでできるものでもありません。そもそもLinus自身が「最初はそんなつもりはなかった」的なことを言ってますからね。それでもどこで気が変わったか、あの「隙だらけのカーネル」でも、なんとなく実用品として使えないことはない程度にはなっていた。
そして、「隙」も凄かった。Ver 0.01のカーネルなんて、本当に隙だらけ。たとえば、システムコールのエントリテーブルがあるのですが、その先の「実装」部分には「未実装」ってコメントが1行書かれているだけなんて状態だったのです。これは結構後の版でもありました。でも、その「隙」ゆえに、多くの人に愛され、「俺が何とかしてやろう」と思わせる。当然意図したものじゃないにせよ、これがなかったら「今」はなかったかも知れない。
等々、いろんな「凄さ」はありますが、それは技術そのものではありません。「凄さ」は別のところにあったのです。
独自に似たものを作ってた人達(私も含まれる)が、一斉に自分の作っているものを投げ出して協力しようと思うくらいには「凄く」また、「隙」があったんですから。「マイクロカーネルこそが」とか、まぁとりあえずマトモに他人の使える自前実装作ってから言ってよね。ちなみに当時の私はMach
をいろいろいじくってました。Ver 3.0になっていろいろいじれるようになってて、MS-DOSの上からbootする版を作った人がいたんで、「これでユーザ空間でOS書けるじゃん」って。
そんなわけで、「ぼくのかんがえたさいきょうのOS」を作らなかったのが、Linusの偉かったところ。愚鈍に「どうにかこうにかUNIXとして使える程度のもの」をちゃんと作っていいタイミングでリリースした。そこが全ての始まり。
「毒にも薬にもならない昔話」とはこのことではないだろうか。
老人ならせめて1行くらいは誰かの役に立つ言葉がにじみ出るものだが・・・
そういう生き方としてきたということだろう。
プログラミングで食っていくためには、他の職業と同様に様々なスキルが必要になる。単に技術的な面だけに絞っても、以下のようなことが出来なければ話にならない。
プログラミングスクールなどを卒業したゴミには、(1)〜(2)もしくは(1)だけを以て「自分はプログラミングが出来る」と勘違いしている奴が多い印象がある。
"なんでこんな10年古いクラッキング情報に無言ブコメがたくさんついてんだろう。 みんなそんなにハッカーになりたいのかね"
https://b.hatena.ne.jp/miz999/20200909#bookmark-4691121887536574818
を見て、ちょっと期待しながらIDに紐づいてるブログを開いたけど
GASに関する実務記事だけで、あーこの人口先だけハッカーな人かーって少し残念だった。
とりあえず、倫理的ハッキング、Ethical HackerはCertified Ethical Hackerっていう認定資格があって
v10まで改定していて比較的歴史もあるから、ハッカーなりたいけど、何から勉強したらわからないって人はそこから手をつけるといいよ。
ハッカー業界のIPA資格だから、どんなに素敵なエンジニアでも基本情報技術者資格を持ってないと信用されないのと一緒だよ。
あ、ソーシャルハッキングも手法として一章割いて紹介されているけど、そこは試験で実践はしないよ。
ハッキングは対象システムの意図しない動作を、意図的に引き起こすバグを見つけることがその第一歩だけど(正確な定義は違うけどー)
それ関連でいえばここ十年で一番驚いたのはsyzkallerっていうファジングツールだね。
「Linuxカーネルのファジングツールsyzkaller / Linux kernel fuzzing tool syzkaller」のNTTデの藤井さんの資料がわかりやすいよ。
https://speakerdeck.com/fujiihda/linux-kernel-fuzzing-tool-syzkaller
300以上あるLinuxのシステムコールを適当に叩いて、システムをクラッシュさせたら、再現用スクリプトを自動的に作成までしてくれる優れものだよ。
Googleの人が作ったらしいけどソースコードは正直異星人か100年先の未来人が降りてきてわざわざ作ってくれた感じがするよ。僕には理解できなかったよ。。。
プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。
JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightとかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScriptに改名されたり、規格を話すときはECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースのオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。
Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。
Javaは初期のころオートボクシング / アンボクシングもなく、ストイックなオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコードも簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である。
PHPはWebネイティブな言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能や初期化していない変数を最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列と数字を臨機応変に切り替える機能もあり(今もそうかは知らん)、数字と文字の比較を比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。
C#はHello Worldくらいしか書いたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。
C++は黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーションで腱鞘炎になることもない。PC Unixにも最初から環境がインストールされているか、簡単にインストールできるので毛嫌いせず使うとよいと思う。
Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。
TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。
Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるから、カーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。
これ以下のランキングのもその気になったら書こうかな。
MastodonはAGPLで開発されており、AGPLに則れば誰しもが自由に参入し使用することができるということは前回のエントリで言及させてもらった。
つまりコレはMastodonへ接続するいわゆるクライアントアプリケーションを作成する自由も認められていることとなる。
そのMastodonクライアントアプリケーションの1つとしてiOS向けに提供されている「Mast」という実装が存在する。
Mast - App Store
MastはiOSでは比較的高品質なMastodonクライアントアプリケーションとして知られ、多くのMastodonユーザから支持されている。
App Store上では¥600で提供されている有償ソフトウェアだが、ソースコードはGPLv3ライセンスの元にGitHubで公開されているので誰しもがMastを自由に使用することができるというフリーソフトウェア運動の一環として非常に好ましい姿勢であると見られてきた。
ShihabM/Mast - GitHub
GNUを代表格に自由を重んじるフリーソフトウェア運動へ関わるFLOSSなユーザはMastには¥600を支払う価値があるとし、景気よく¥600を支払ってMastを利用した。
GitHubからソースコードをcloneし、Xcodeでプロジェクトを作成、コンパイル＆ビルド、iOS端末実機で動かすなんてことは¥600支払った(女性かも知れないが)彼らのスキルからすると簡単すぎる手順であり、何なら自動化すらできるだろう。
スタバでMacbookを用いて1回ドヤリングするよりも彼らはMastの理念に感銘しMastに¥600を支払うことへ価値を見出したのだ。
そんなMastの製作者Shihab MehboobはGab問題で揺れるMastodonの創始者Eugen Rochkoの提言へ賛同しMastへ禁じ手たるアップデートをしてしまった。
Mastを購入したユーザに同意せずMastを起動するたびにMastodonサーバへ対してユーザに無断でGabをドメインブロックするシステムコールを送信するアップデートを施したのである。
つまりどういうことか？と言えばMastは¥600で購入するマルウェアと化したのだ。
百歩譲ればMastがスタンドアロンな機能としてGabとの通信が不可能になるアップデートを施すのならまだ擁護のしようはある。
しかし、今回のMastのアップデートは無断でMastodonサーバへGabをドメインブロックするシステムコールを送信してしまっているのだ。他人のサーバを無断で操作してしまっているのだ。
このMastの振る舞いは情報技術者へ問えば100人が100人とも「マルウェア的振る舞いであることは疑いようがない」と言うだろう。
しかも¥600支払っているのである。別に¥600が惜しいわけではない。フリーソフトウェア運動としてShihab Mehboobの生活の足しになればと思って多くの者は¥600を支払ったのである。
¥600支払ったユーザへ対して明確すぎるShihab Mehboobの背信行為が今回大炎上しているというわけだ。
勘違いしてならないのは、この件は別に北米の極右が集うとされるGabを擁護するためフリーソフトウェア運動を標榜する者たちが声を荒げているわけではないということだ。
GNU宣言を読めば理解できるように、フリーソフトウェア運動はコンピュータの制御権は個別のユーザへ対して帰属するべきということを一貫して主張しているだけなのである。
Gabのブロックは個別のユーザの価値観で決定されるべきであって、AGPLを冠するMastodonの創始者Eugen RochkoやGPLを冠するMastの製作者Shihab Mehboobが強制すべきではないと主張しているのだ。
Eugen RochkoやShihab Mehboobが歩もうとしているのは疑いようもなく言論統制への道であり、それはリベラリズムが憎む道でありGabが歩んでいる道でもある。
だからこそ今回のMastのアップデートは許されるべきではないとされ、Eugen RochkoやShihab Mehboobはフリーソフトウェア運動を標榜する者たちから反論が起きている。
コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。
数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。
複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと
いったものができた。
（カプセル化）
アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた
（ブラックボックス化）
複数のクラスやコード、データをひとまとめにするにモジュールができた。
（カプセル化）
プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。
IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。
（ブラックボックス化）
（操作の簡略化）
Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。
カトラークラスのエンジニアが数十人、数十年かけて磨き上げた Linux カーネルにかなうわけねーだろ。
もはやFreeBSDは人手不足で、Meltdown, Spectre にも満足に対応できない有様。
カーネルがごちゃごちゃしてたのは v3 初期までで、その後、徹底的な抽象化・#ifdefによる機能の分離化、CPU依存の排除をしたおかげで、configでオプションを最小化したら恐ろしいまでに小さいサイズのカーネルになる上に、オレオレCPUへの移植もそれほど大変でなくなった。LLVMのSSAなどの技術をBPFが取り込んだおかげで、カーネル内のモニタリングも perf関係からの置き換えの目処がたったら、そのあたりの余計なコードも削ぎ落とせる夢がある。
おかげでconfigオプションが数千にもなってしまったが、ディストリビューションも多様化してくれたお陰で、自分の用途に合わせたカーネルの選択に困ることもあまりない。WindowsやMacでも Linux システムコールラッパがほぼ完全に動くようになり、「Write Once, Run Anywhere」をVMを介さないで実現する POSIX以来の夢がいま正に実現しようとしている。
以前iOSに存在したWebkitの脆弱性を使うことでSwitchのジェイルブレイクができたそう
Old Apple Security Flaws Mean the Nintendo Switch Is One Step Closer to a Jailbreak - ギズモード
http://gizmodo.com/old-apple-security-flaws-mean-the-nintendo-switch-is-on-1793210884
What do Nintendo Switch and iOS 9.3 have in common? CVE-2016-4657 walk-through
https://www.youtube.com/watch?v=xkdPjbaLngE
そのジェイルブレイクをしたうちの一人のツイートによると、FreeBSDが動いていると聞いていたけれど、システムコールはBSDとは違っていたとか。
I heard that the Switch runs FreeBSD. But it actually doesn't look like BSD looking at syscalls. Maybe just nintendo weirdness?
Linux用のシステムコールをリアルタイムでWindows用システムコールに変換してるらしい。
apt-getも使えるからubuntu用のユーザーモード内で完結するプログラムはほぼすべて動くっぽい。
ubuntuの人も「10000を超えるUbuntuのパッケージがapt-getでインストールできる」って言ってるみたい。
Cドライブが/mnt/cとかにマウントされてるのはFUSE使ってるのかな？
bash on windowsは現状ユーザースペースしかないので、むしろ.netライブラリ触ってシステムも弄れる
powershellと比較しちゃうとpowershellの便利さを際立たせるだけにしかならんと思う。
でも、.net CoreをLinuxに移植するのもがんばってるみたいだから、将来的にはどっちも似たようなこと
出来るようになると思う。
Linuxでもコマンド結果がテキストじゃなくてオブジェクトで返ってくるようになると夢が広がるよね。
メタデータ拾うのにいちいち別のコマンドで取り直す必要なくなるって結構便利だから
でもこの辺はWindowsとUNIX界隈の文化の違いみたいなもんだから、どっちが良い悪いって話じゃなくて
どっちが自分に合うか、って話だね。
現状Web系の開発者が、基本的なツールとWindowsの親和性の低さが原因でWindowsではなくMacを選択していることが
B2Bをメインに据えているMicrosoft的には脅威だったんだと思う。
エンドユーザーの市場はGoogleの焼き討ちのおかげで金にならなくなったから
ビジネスユーザー獲得をがんばってるのに、そのなかで勢いある市場がWindowsに拒否反応示してるのを改善したいんだろう。
今やプログラミングといえば、Webなどで使われるような高水準スクリプト系言語中心のアプリケーションプログラミングが主流だ。
そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である。
そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。
少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。
大学で初めて触ったC言語しかもポインタ分からないで止まっているような奴に、電文の再配信プログラムを任せたのだから。
客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。
このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。
勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。
あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。
コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなものは絶対に必要である。
その時のルールは「gccのオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。
というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様はコンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しかも言語仕様以外の環境依存要素が山積していると来たもんだ。
そんな言語でシステムコールだらけのコードかつ複数のファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかもマルチプロセスでシグナルもあるよ！とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。
仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。
後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。
そこまで凄い良書なのになんで絶版になったんだか。
いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。
シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか！と途方に暮れたこともあった。
そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。
結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分の仕事ぶりには全く満足していない。
無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッド、malloc()、可変長引数は遂に習得できなかった。
こういうプログラムって、どうやったら正しく動かせるんだろ。
このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が
Cはとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理（たとえばメモリ管理）を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、あなたの時間をずっと効率的に使う言語を使うほうが賢明でしょう。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
あと、あれほど苦手だったポインタについても、「ポインタが理解できないと永久にC初心者」というのを嫌でも理解した。
あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ。
・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。
それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件に助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分は
「配列とポインタと構造体しか使わないで済むなんて、なんて楽な仕事なんだ！」と左うちわでのんびり過ごし、しかも高評価をいただいて帰ってこれた。
