本日の発表資料です #terminalnight
AI Agentツールとして見るとここに戻ると思ってる
単機能ツールのパイプ連結がAI時代に再評価されるの面白いな。原点回帰感ある
terminal night?
Emacsだと、マニュアル＆実ソースが即参照出来て、手元で何でも調べながら実装を進められる＆検索も高速で、コンピューターを自分のものとして使いこなす最強の環境って分かるんだけど、そんな感覚は遠くなったな
ls | mc だと、pipe(2) によるカーネル内パイプバッファの確保、2プロセス分の fork(2),execve(2)、さらにwrite(2)read(2)に伴うユーザー空間⇄カーネル空間のメモリコピーやコンテキストスイッチが発生する。すべてはトレードオフ
UNIX思想もマイクロカーネルも設計としては綺麗だけど現実にはsystemdが使われてるし、モノリシックカーネルが使われている
lsコマンドをオプションで多機能化させることへの是非は永遠のテーマだと思う。もし多機能化を頭ごなしに否定するなら、他のコマンドなどと連携せざるを得ないので記述が長くなり、listをlsと略記した恩恵が失われる。
“標準「エラー」出力という名前はやや直感的ではない。パイプ·フィルタとは関係ない情報はstderr(標準エラー出力)に出す。 迷ったら標準エラー出力に出す。 人が読むための途中経過などのinfoログも”
名は体を表すというように、コマンド名から連想できない機能はつけない方が良いのかね
Powershellのオブジェクトにパイプラインに流せる発想は凄く良いけど、シンプルに文法が書きづらいが惜しかったな。
CLIコマンドは、美しくて面倒くさいよりは、妥協が混ざっても覚えやすくて場面にあった出力できる方がいいなぁ。なんでもオプションでやろうとして肥大化するのはバランス悪いが。
まあsystemdはLinux限定で他のFree Unixはそんなもの採用してないので…/help2manはupstreamが実質Debianだったりする
おれはドザーだけど、キャリアの初期にUnix(Dec Ultrix)に触れることができて、会社のパイセンが思想強めのＵｎｉｘグルだったのが幸いだったと思う。/ rootから/へのメッセージを読み返したくなったが図書館に無い。
この本は自分で作る人の指南書であって、ツールやシェルコマンドも自分で書かないと何もないミニコン時代のプログラマ向け。Excel買うのは一瞬だから消費者はそれでいいよ。
利便性のため、別途専用スクリプト用意するなら最初から組み込んどけってのもわかる。RustでCLIが新たに作られているけど、みんなカラフルだね。UNIXが生まれたときと、今では状況が違うしなぁ
かつてのWindowsがこれとは正反対の文化でそこから生まれたのがRPAみたいな歪なもの
素朴ななforkよりも高速なスレッド、迷惑メール対策でSMTP認証、さらにあらゆる面でセキュリティ強化みたいに、時代の需要からシンプルさと自分の足を撃つ自由を失っていき仕方ないけど牧歌的な時代が懐かしくもある。
lsが段組するのは出力がttyのときだけでしょ？40年前からそうだったよ。
標準エラー出力は標準ログ出力と言う名前であるべきだったなとは思う。対話＝プログラミングというのだけは完全に間違いで、複雑なことをやるときは log を tail するわけで入出力は情報として対話には全く足りてない。
プラグインかビルトインか、マイクロかモノリシックか、みたいなバランスって難しいよね
lsなどのカラフル出力はいらね派
「UNIXという考え方」再考 | ドクセル
本日の発表資料です #terminalnight
AI Agentツールとして見るとここに戻ると思ってる
単機能ツールのパイプ連結がAI時代に再評価されるの面白いな。原点回帰感ある
terminal night?
Emacsだと、マニュアル＆実ソースが即参照出来て、手元で何でも調べながら実装を進められる＆検索も高速で、コンピューターを自分のものとして使いこなす最強の環境って分かるんだけど、そんな感覚は遠くなったな
ls | mc だと、pipe(2) によるカーネル内パイプバッファの確保、2プロセス分の fork(2),execve(2)、さらにwrite(2)read(2)に伴うユーザー空間⇄カーネル空間のメモリコピーやコンテキストスイッチが発生する。すべてはトレードオフ
UNIX思想もマイクロカーネルも設計としては綺麗だけど現実にはsystemdが使われてるし、モノリシックカーネルが使われている
lsコマンドをオプションで多機能化させることへの是非は永遠のテーマだと思う。もし多機能化を頭ごなしに否定するなら、他のコマンドなどと連携せざるを得ないので記述が長くなり、listをlsと略記した恩恵が失われる。
“標準「エラー」出力という名前はやや直感的ではない。パイプ·フィルタとは関係ない情報はstderr(標準エラー出力)に出す。 迷ったら標準エラー出力に出す。 人が読むための途中経過などのinfoログも”
名は体を表すというように、コマンド名から連想できない機能はつけない方が良いのかね
Powershellのオブジェクトにパイプラインに流せる発想は凄く良いけど、シンプルに文法が書きづらいが惜しかったな。
CLIコマンドは、美しくて面倒くさいよりは、妥協が混ざっても覚えやすくて場面にあった出力できる方がいいなぁ。なんでもオプションでやろうとして肥大化するのはバランス悪いが。
まあsystemdはLinux限定で他のFree Unixはそんなもの採用してないので…/help2manはupstreamが実質Debianだったりする
おれはドザーだけど、キャリアの初期にUnix(Dec Ultrix)に触れることができて、会社のパイセンが思想強めのＵｎｉｘグルだったのが幸いだったと思う。/ rootから/へのメッセージを読み返したくなったが図書館に無い。
この本は自分で作る人の指南書であって、ツールやシェルコマンドも自分で書かないと何もないミニコン時代のプログラマ向け。Excel買うのは一瞬だから消費者はそれでいいよ。
利便性のため、別途専用スクリプト用意するなら最初から組み込んどけってのもわかる。RustでCLIが新たに作られているけど、みんなカラフルだね。UNIXが生まれたときと、今では状況が違うしなぁ
かつてのWindowsがこれとは正反対の文化でそこから生まれたのがRPAみたいな歪なもの
素朴ななforkよりも高速なスレッド、迷惑メール対策でSMTP認証、さらにあらゆる面でセキュリティ強化みたいに、時代の需要からシンプルさと自分の足を撃つ自由を失っていき仕方ないけど牧歌的な時代が懐かしくもある。
lsが段組するのは出力がttyのときだけでしょ？40年前からそうだったよ。
標準エラー出力は標準ログ出力と言う名前であるべきだったなとは思う。対話＝プログラミングというのだけは完全に間違いで、複雑なことをやるときは log を tail するわけで入出力は情報として対話には全く足りてない。
プラグインかビルトインか、マイクロかモノリシックか、みたいなバランスって難しいよね
lsなどのカラフル出力はいらね派