「システムコール」を含む日記 RSS

はてなキーワード: システムコールとは

2024-05-22

anond:20240522183030

異性もAPIとかシステムコールがあれば、今頃モテモテになれたかもしれないのに…😔

2024-04-12

フリーレンの世界プログラミング魔法となった世界

フリーレンが集めてるしょーもない魔法は、pipとかnpmに上がってるしょーもないパッケージ

「こんなパッケージ何の役に立つんだよ」

っていうのを集めてる

魔法の解析はリバースエンジニアリングのことで、フリーレンはその天才

で、魔法は単純なプログラミングコードではなくてLLMをベースにしたコードになっていて

魔力っていうのはそのLLMのモデルの大きさ

長い年月をかけてLLMを追加学習させることで魔力を増やしていくが人間はそのモデルの大きさを誇ろうとしない

魔力の揺らぎはLLMの出力の微妙な違いのことで、LLMのモデルが大きいと

「単純な答えのように見えるけど微妙に違っていて実は大きなモデルなのでは?」

と気付く

魔族はLLMを使うAIプログラム

AIなのでLLMしか取り柄が無く、モデルの大きさでマウントを取り合うのが魔族

ただ人間と違って死ぬことがないので魔族の使うプロンプトエンジニアリングはまるで理解できず

人間再現できないLLMベースプログラミングコードは「呪い」として扱われてる

女神様の魔法」はOSシステムコールのこと

ドキュメントを読んで使うけれど原理は分かっていない

僧侶システムコール専門家

ゼーリエはGitHub管理者フランメはベンチャー初期メンバー的なやつ

未だにフランメが書いたCronコード勝手に動いたりしてる

聖杖の証はドングルキー管理者権限を渡された人が持つやつ

2024-01-07

anond:20240107194508

標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、

入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます

Linuxシステムコールの話と勘違いしてない?

してませんね。

 

そんな事無いよね。Linuxサーバ保守とかでパッチノートとか読んだこと無い?

インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど

これだとどう?

比較の話ですが、nodeやらpythonやらに比べたら「実際にそのプロダクションで使っているコマンド」のアップデートの頻度はずっと小さいですよ。

今までにされた検証は遥かに多く、コマンドソースコードは遥かに小さいので、当たり前ですが。

 

命に関わらないシステムを動かしてるWeb系の業界想定ならRustで書くのが非生産的なのは同意だけど、なんで危険になるのか知りたいね

コードを読んだ人数も実際に動作検証された回数も1桁単位のその場その場で作られたコードよりも、

長年にわたってメンテナンスされ、膨大な人数の技術者に読まれ、億を優に超える回数で、特殊なケースを含めて様々なパターンで実行された小さなコードの方が信頼性が高いからですね

anond:20240107192735

標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、

入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます

Linuxシステムコールの話と勘違いしてない?

高級言語インタプリタほど頻繁なセキュリティアップデート必要ない

そんな事無いよね。Linuxサーバ保守とかでパッチノートとか読んだこと無い?

インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど

これだとどう?

すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です

命に関わらないシステムを動かしてるWeb系の業界想定ならRustで書くのが非生産的なのは同意だけど、なんで危険になるのか知りたいね

噛み合わないポイントはここらへんにあるかもね

2023-10-05

[]2023年9月滅多にホットエントリを出さなドメインからホットエントリ

ここ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 yamaneofficeyamane.net
679藤島ジュリー景子Mステ』へ他社男性アイドル出演について「今回はしょうがないですけど、これが続くようなら対応を考えます」と圧力反省ゼロが露見 | The Audiencethe-audience-news.com
633コラム岐阜大学大学院医学研究科神経内科学分野www.med.gifu-u.ac.jp
629ジャニーズCM企業一覧】誰がどこに出てる?契約解除になるスポンサーは?2023年R30ブログgohantublog.com
611ジャニーズ性加害の次は女性アイドル枕営業を明るみにすべき! テレビ黙殺してきた芸能界性的搾取を今こそ問いただす時 - まいじつmyjitsu.jp
5771,000行で作るオペレーティングシステムseiya.me
5774年半勤めた会社を辞めた話 - 工学チキンによる工作ブログwoodencaliper.hatenablog.com
570Linux システムコール 徹底入門www.kimullaa.com
565錯視幻視ー脳のなかの幽霊たちwww.bri.niigata-u.ac.jp
552山口達也と非生産 by 非公開: 田房永子LOVE PIECE CLUB(ラブピースクラブwww.lovepiececlub.com
529(翻訳) ビッグテックプロジェクトマネジメントスクラム不在の謎 - forest bookt2y.hatenablog.jp
526【9/29追記NURO光に申し込んだら4ヶ月弱待たされた挙げ句解約しろと言われた件 - Yebisu303’s diaryyebisu303.hateblo.jp
514教員のなり手不足解消「正直、名案はない」 盛山文科相就任会見www.kyobun.co.jp
511テレビはどうしてジャニーズ事務所とここまでグダグダ関係なのか|More Access! More Funwww.landerblue.co.jp
475君は青いギターが呪物になる過程を見たことはあるか?/大槻ケンヂ医者オカルトを止められた男」|webムー 世界の謎と不思議ニュース考察コラムweb-mu.jp
4671話 / インターネット・ラヴ! - 売野機子FEEL webマンガの数だけ愛があるfeelweb.jp
464【速報】ホンダが「モトコンパクト」を発表! 電動でモトコンポが再来、価格は1000ドル(約15万円)以下! | Webikeプラスnews.webike.net
449"真打落語家"蝶花楼桃花rikkyogeinokenkyu.wixsite.com
427DJ 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

2023-05-12

anond:20230512113028

そんなに色々考慮するくらいなら素直にmkstemp使え(どんな言語でもこれに準じたシステムコールはあるはず)と言いたいところだけど

今のはてなだとmkstempって何?って言われそう

2022-09-06

anond:20220906222204

9x→XP(2k)で動かなくなったアプリが多々あったのは確かだけど、それはファイルアクセス権限問題というよりは、アプリパフォーマンス最重視で設計されていたりレガシーコードが悪さしたりして古いシステムコールを多用してたのが原因だったのではないかなと思う(起動した瞬間にハングアウトしたり画面が化けたりするゲームがあったことを覚えている)

XPSP2でファイアウォールOSデフォルト機能として搭載されたけど、それはアプリインターネットアクセス規制するためのもの管理者権限での実行を制約するものではなかったはず

Program Filesフォルダ設定ファイルを保存するのが容認されなくなたのはVISTAになってからじゃないか

2022-07-18

UNIX 哲学」についていくつか

名著「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ページ)となっている。さて前述の PDFOCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX論文なのだ。もちろん論文性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイ哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白いUNIX開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが,それまでにない新しい考え方に基づいた OS を開発しているという意識があれば,そういう言葉を選ぶのが自然時代だったことは間違いない。

UNIX認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい,あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが,そんなたいしたものではない。マキルロイ論文に影響を受けた布教のためのああい説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本最初期の UNIX 解説本のひとつである村井純井上尚司・砂原秀樹『プロフェッショナル UNIX』(1986,アスキー)には冒頭次のような一節がある。

オペレーティングシステムは,コンピュータを使うものにとっての環境形成する基盤であるから,そのうえで生活する者の個性尊重し,より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが,UNIXオペレーティングシステムとしての個性ではないだろうか。

 

    プロフェッショナル UNIX村井純井上尚司・砂原秀樹,1986,アスキー)p 3.

「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能コマンド群のことで,これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが,たまたまガンカースだったというだけのことである

そしてじつは UNIX場合布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが,その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。

UNIX の利用環境

UNIXPDP というミニコンピュータミニコン)上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は,もちろん場所によって違うわけだが,マアおおよそ学校教室くらいの大きさだ。長机が何列か並んでおり,そのうえにはブラウン管ディスプレイキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校コンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器コンピュータではなくコンピュータ接続するための端末装置ターミナル)だ。端末装置キーボードで打った文字コンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 UnixOSCLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置エミュレータで,もともとは実体のある装置だったわけだ。

さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっとコンピュータが何台もあるわけではない。この箪笥CPU でそっちの洗濯機ハードディスク,あの机に置かれているタイプライタ管理コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて,なんてミニ!」という時代お話だ。

端末装置それぞれからUSB のご先祖様の)RS-232 という規格のアオダイショウみたいなケーブルが伸び,マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び,root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。

結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは,マアどうでもいい。

自由不安定OS

当時の 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 では,ファイルシステムを使いはたすまで大きなファイル自由に作ることができる。したがって,自分プロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと,コンソールタイプライターにエラーメッセージが出力されるが,夜中にそれが発生して,コンソールタイプライターが一晩中エラーメッセージを打ち続け,朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい,ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると,それをしでかした本人のプロセスは当然のこととしても,同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい,わずかでも仕事を先に進めようとする意図完璧に打ち砕かれてしまうのである

 

    root から / へのメッセージ高野豊,1991,アスキー)pp16-17.

そして,こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンド10個くらい同時に走らせ」たり「自分プロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイト利用者全員に UNIX設計基本的な考え方を理解してもらうことが,自分のために必要だった。UNIX伝道がより苛烈だった理由ひとつがここにあるのだ。

ミニコン UNIX終焉

ミニコン上で誕生した UNIX は 4.3BSD(1986)で最高潮を迎える。注意したいのはミニコン時代UNIX は Research UNIXCSRG 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のものミニコンのものしかなかったが,そのコードを受け継いだ BSDUnixAT&T推し進める System V などがワークステーション市場舞台80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で,PCUnix であるマイクロソフトXENIX も当然参戦した。ミニコン世界牧歌的だったのは,ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争あくまでも標準という聖杯を争う戦いであり,AT&TBSDUnixSun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。

こうしたミニコン UNIX からワークステーション Unix への転変は Unixのもの文化にも変化をもたらした。まず激しい競争Unix の高機能化を加速した。商品として判りやす惹句が「あれもできます,これもできますなのは誰もが知っている。もちろん安定性を増すために quota のような利用者自由制限する機能も含まれていた。またワークステーション Unix現在UnixOS と同様同時に一人が使うものであり前述の布教必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』(1993,オーム社)を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unixシステム管理入門書だ。この本ではたんに知識を羅列するかわりに架空ソフトウェアハウス(開発会社)を舞台新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており,そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。

UNIX 哲学背骨

当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイ論文結論部分に書かれたそれは,1973年出版されたイギリス経済学者エルンストシューマッハー著作題名で,中学生英語力があれば十分に理解できる平明な一文だ。

Small is beautiful.

マキルロイは『人月神話』を引いて一定留保をつけてはいものの,これが UNIX 哲学背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•csアンチテーゼである UNI•x にとって,これ以上のスローガンがあるだろうか?

ひるがえって現在UnixOS をみれば,ブクブクと肥え太ったシステムコール,全容を俯瞰するだけでも一苦労するライブラリインターフェイス,一生使うことのないオプションスイッチまみれのコマンド群。UNIX仮想敵とした OSのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ,コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ,歴史書を飾る一項目になっただけだ。ただ現在UNIX 哲学」を語るならそうした背景は理解していなければならないし,どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。

2022-05-04

リーナスLinuxを開発したというのは、どれほど「技術的に」すごい偉業だったのでしょうか?

生越 昌己

, 日本Linux協会で元会長 (2001~2002年)

回答日時: 2022年4月23日 · 執筆者は841件の回答を行い、180.3万回閲覧されています

なんか呼ばれてる気がした。

技術的に」はどうってことなものです。別の回答で私の書いた記事引用されているので、その辺の歴史的なことはそっちを読めばわかると思います。「やればできる」範囲のことです。実際、あの記事には書きませんでしたが、そのちょっと前くらいに私の知人(日本人)がフルスクラッチUNIX互換マイクロカーネルOSを独力で書いてます。これも彼に言わせれば、「教科書通りに実装しただけ」とのことです。なお、UNIXOS実装は、いくつか教科書が出ています。また、「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行くらいは誰かの役に立つ言葉がにじみ出るものだが・・・

そういう生き方としてきたということだろう。

PCWatchの山田祥平さんに似た臭いを感じる。

2022-05-02

anond:20220502093008

APIOSシステムコール、WebAPI、不変なもの

ライブラリ:何かの問題解決に特化してる、動画エンコードデコードとか

フレームワーク:数行でアプリ全体ができてしまいような雛形がある、ライブラリをチョイスして統合してある

呼び出し順として

フレームワーク

ライブラリ

API(WebAPIでも同じ)

みたいなイメージがある

2022-04-21

anond:20220421080021

DOSの頃はOS機能を呼び出すのをシステムコールと言って、Windowsの頃になるとAPIと言って、最近言語ライブラリAPIと言うようになったな。

anond:20220421080021

具体例がわからんが「ほぼ」ならシステムコールじゃないんだろ?

「XXをシステムコールって呼ぶのは違和感がある」って言い方もできない?

ほぼ、システムコールの事をAPIと呼ばれると、もにょっとする。

おっさんから

2020-10-28

なぜ素人自分プログラミングができると勘違いしてしまうのか

プログラミングで食っていくためには、他の職業と同様に様々なスキル必要になる。単に技術的な面だけに絞っても、以下のようなことが出来なければ話にならない。

  1. 少なくとも1つのプログラミング言語が書ける(当たり前)
  2. その言語の主要なライブラリパッケージ管理ツール自動テストツール等の周辺ツールについても深く理解している
  3. ソート木構造のような基礎的なアルゴリズム理解しており、プログラム計算量を見積もれる
  4. HTTPSSL/TLSRDBMSSQLOSシステムコールファイルシステムメモリ管理などのアプリケーションよりも低レイヤーの基礎技術理解している
  5. 「Code Complete」「Clean Code」などに書いてあるようなソフトウェア設計ベストプラクティス理解している

プログラミングスクールなどを卒業したゴミには、(1)〜(2)もしくは(1)だけを以て「自分プログラミングが出来る」と勘違いしている奴が多い印象がある。

2020-09-09

"なんでこんな10年古いクラッキング情報に無言ブコメがたくさんついてんだろう。 みんなそんなにハッカーになりたいのかね"

https://b.hatena.ne.jp/miz999/20200909#bookmark-4691121887536574818

を見て、ちょっと期待しながらIDに紐づいてるブログを開いたけど

http://miz999.hatenablog.com/

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年先の未来人が降りてきてわざわざ作ってくれた感じがするよ。僕には理解できなかったよ。。。

2020-05-22

anond:20200521225730

プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。

JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScript改名されたり、規格を話すときECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。

Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。

Javaは初期のころオートボクシング / アンボクシングもなく、ストイックオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコード簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である

PHPWebネイティブ言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能初期化していない変数最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列数字臨機応変に切り替える機能もあり(今もそうかは知らん)、数字文字比較比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。

C#Hello Worldくらいしかいたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。

C++黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーション腱鞘炎になることもない。PC Unixにも最初から環境インストールされているか簡単インストールできるので毛嫌いせず使うとよいと思う。

Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。

CSS...はプログラミング言語なのか?そうか。

TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。

Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるからカーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。

これ以下のランキングのもその気になったら書こうかな。

2019-07-13

MastodonGab論争〜燃え上がるMast〜

前回のエントリ

anond:20190706150428

大騒ぎとなったMastの振る舞い

MastodonはAGPLで開発されており、AGPLに則れば誰しもが自由に参入し使用することができるということは前回のエントリ言及させてもらった。

まりコレはMastodon接続するいわゆるクライアントアプリケーション作成する自由も認められていることとなる。

そのMastodonクライアントアプリケーションの1つとしてiOS向けに提供されている「Mast」という実装存在する。

Mast - App Store

https://apps.apple.com/jp/app/mast/id1437429129

MastはiOSでは比較的高品質Mastodonクライアントアプリケーションとして知られ、多くのMastodonユーザから支持されている。

App Store上では¥600で提供されている有償ソフトウェアだが、ソースコードGPLv3ライセンスの元にGitHubで公開されているので誰しもがMastを自由使用することができるというフリーソフトウェア運動の一環として非常に好ましい姿勢であると見られてきた。

ShihabM/Mast - GitHub

https://github.com/ShihabM/Mast

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ドメインブロックするシステムコール送信するアップデートを施したである

これには2つの問題がある。

  1. アップデート以前にMastを購入したユーザはMastの振る舞いへ対して同意していない
  2. Mastからシステムコール送信であるMastodonサーバはShihab Mehboobの所有物ではない

まりどういうことか?と言えばMastは¥600で購入するマルウェアと化したのだ。

百歩譲ればMastがスタンドアロン機能としてGabとの通信不可能になるアップデートを施すのならまだ擁護のしようはある。

しかし、今回のMastのアップデートは無断でMastodonサーバGabドメインブロックするシステムコール送信してしまっているのだ。他人サーバを無断で操作してしまっているのだ。

このMastの振る舞いは情報技術者へ問えば100人100人とも「マルウェア的振る舞いであることは疑いようがない」と言うだろう。

しかも¥600支払っているのである別に¥600が惜しいわけではない。フリーソフトウェア運動としてShihab Mehboobの生活の足しになればと思って多くの者は¥600を支払ったのである

¥600支払ったユーザへ対して明確すぎるShihab Mehboobの背信行為が今回大炎上しているというわけだ。

これは自由vs自由の論争である

勘違いしてならないのは、この件は別に北米極右が集うとされるGab擁護するためフリーソフトウェア運動標榜する者たちが声を荒げているわけではないということだ。

GNU宣言を読めば理解できるように、フリーソフトウェア運動コンピュータ制御権は個別ユーザへ対して帰属するべきということを一貫して主張しているだけなのである

Gabブロック個別ユーザ価値観で決定されるべきであって、AGPLを冠するMastodon創始者Eugen RochkoやGPLを冠するMastの製作者Shihab Mehboobが強制すべきではないと主張しているのだ。

Eugen RochkoやShihab Mehboobが歩もうとしているのは疑いようもなく言論統制への道であり、それはリベラリズムが憎む道でありGabが歩んでいる道でもある。

からこそ今回のMastのアップデートは許されるべきではないとされ、Eugen RochkoやShihab Mehboobはフリーソフトウェア運動標榜する者たちから反論が起きている。

これが今現在最も先進であるとされる分散SNSが抱えている問題現在進捗である

2018-10-12

プログラミング本質カプセル化ブラックボックス

コンピュータマシン語命令文もデータも数値で表す。これは今も昔も同じ。

数値だけでは人間管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ

(わかりづらい数字人間理解やす英単語に置き換えた)

アセンブラも規模が大きくなると人間には管理しずらくなる。

そのため人間言語により近い高水言語が生まれた。

if や for などで制御をわかりやすくした。

複数の処理をひとまとめで扱うサブルーチン関数プロシージャ・ファンクション

いったものができた。

(処理の流れをわかりやすくした、構造化、カプセル化

複数データをひとまとめで扱うレコード型や構造体生まれた。

カプセル化

コードデータをまとめて扱うクラスができた。

カプセル化抽象化

アプリケーションからOS機能を呼ぶシステムコールAPIが生まれ

ブラックボックス化)

複数クラスコードデータをひとまとめにするにモジュールができた。

カプセル化

プログラムを外部から操作するRPC、CORBA、SOAPRMIができた。

リモートから操作ブラックボック化)

WebAPIアーキテクチャーを超えての疎結合が進む

さらなるブラックボックス化)

IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。

ブラックボックス化)

CIツールサーバ数台〜数百台を1人で扱えるようになった

操作の簡略化)

DockerWEB/DB/KVSなどをまとめてコマンド1つで扱えるようになった。

カプセル化抽象化

プログラミングとはわかりづらいマシン語人間にわかやすくするのが本質

カプセル化ブラックボックス化・操作の簡略化は正義

2018-03-26

https://anond.hatelabo.jp/20180201132629

カトラークラスのエンジニアが数十人、数十年かけて磨き上げた Linux カーネルにかなうわけねーだろ。

もはやFreeBSD人手不足で、Meltdown, Spectre にも満足に対応できない有様。

カーネルがごちゃごちゃしてたのは v3 初期までで、その後、徹底的な抽象化・#ifdefによる機能の分離化、CPU依存排除をしたおかげで、configオプションを最小化したら恐ろしいまでに小さいサイズカーネルになる上に、オレオレCPUへの移植もそれほど大変でなくなった。LLVMSSAなどの技術をBPFが取り込んだおかげで、カーネル内のモニタリングも perf関係からの置き換えの目処がたったら、そのあたりの余計なコードも削ぎ落とせる夢がある。

おかげでconfigオプションが数千にもなってしまったが、ディストリビューション多様化してくれたお陰で、自分用途に合わせたカーネル選択に困ることもあまりない。WindowsMacでも Linux システムコールラッパがほぼ完全に動くようになり、「Write Once, Run Anywhere」をVMを介さないで実現する POSIX以来の夢がいま正に実現しようとしている。

結論FreeBSDは死んだ。

2016-03-31

bash on Ubuntu on Windows面白い

発表があったんで、情報探してみるといろいろ面白いな。


checksumが全く同じUbuntuバイナリがそのままWindowsで動く

Linux用のシステムコールリアルタイムWindowsシステムコールに変換してるらしい。

apt-getも使えるからubuntu用のユーザーモード内で完結するプログラムはほぼすべて動くっぽい。

ubuntuの人も「10000を超えるUbuntuパッケージapt-getインストールできる」って言ってるみたい。

Cドライブが/mnt/cとかにマウントされてるのはFUSE使ってるのかな?


powershell要らなくなる?

bash on windowsは現状ユーザースペースしかないので、むしろ.netライブラリ触ってシステムも弄れる

powershell比較ちゃうpowershellの便利さを際立たせるだけにしかならんと思う。

でも、.net CoreLinux移植するのもがんばってるみたいだから、将来的にはどっちも似たようなこと

出来るようになると思う。

Linuxでもコマンド結果がテキストじゃなくてオブジェクトで返ってくるようになると夢が広がるよね。

メタデータ拾うのにいちいち別のコマンドで取り直す必要なくなるって結構便利だから

その利便性をいろんな人が体験して欲しい。

でもこの辺はWindowsUNIX界隈の文化の違いみたいなもんだから、どっちが良い悪いって話じゃなくて

どっちが自分に合うか、って話だね。


コレ何のために作ったんだろう?

現状Web系の開発者が、基本的ツールWindows親和性の低さが原因でWindowsではなくMacを選択していることが

B2Bをメインに据えているMicrosoft的には脅威だったんだと思う。

エンドユーザー市場Googleの焼き討ちのおかげで金にならなくなったか

ビジネスユーザー獲得をがんばってるのに、そのなかで勢いある市場Windows拒否反応示してるのを改善したいんだろう。

今のMS基本的な行動指針って「たくさんのビジネス顧客を抱えるためにネガティブイメージを極力取り除く」って感じだよね。

2015-01-29

初めてじゃなかったCの思い出

今やプログラミングといえば、Webなどで使われるような高水スクリプト言語中心のアプリケーションプログラミングが主流だ。

そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である

そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。


今も昔も、基本的に難しい仕事無茶振りから始まるものだ。

少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。

大学で初めて触ったC言語しかポインタからないで止まっているような奴に、電文の再配信プログラムを任せたのだから


客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。

そうなるとC/C++くらいしか事実上選択肢がない。

このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。

勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。

あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。

その時点で相当ヤバいである


コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなもの絶対必要である

その時のルールは「gccオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。

というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様コンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しか言語仕様以外の環境依存要素が山積していると来たもんだ。

そんな言語システムコールだらけのコードかつ複数ファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかマルチプロセスシグナルもあるよ!とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。

仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。

後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。

そこまで凄い良書なのになんで絶版になったんだか。


いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。

シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか!と途方に暮れたこともあった。

そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。

結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分仕事ぶりには全く満足していない。

無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッドmalloc()、可変長引数は遂に習得できなかった。

こういうプログラムって、どうやったら正しく動かせるんだろ。


このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が

Cはとても高効率ですし、マシンリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルリソース管理(たとえばメモリ管理)を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります今日マシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシン時間を少し非効率に使っても、あなた時間をずっと効率的に使う言語を使うほうが賢明でしょう。

本物のプログラマアプリケーションプログラムなど書かず、まっさら金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。

と言っていたことは正真正銘の事実であると痛感した。

あと、あれほど苦手だったポインタについても、「ポインタ理解できないと永久にC初心者」というのを嫌でも理解した。

あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ


・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。

それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分

配列ポインタ構造しか使わないで済むなんて、なんて楽な仕事なんだ!」と左うちわのんびり過ごし、しかも高評価をいただいて帰ってこれた。

実は今までの案件で一番幸福感が最高だったのは内緒である

ログイン ユーザー登録
ようこそ ゲスト さん