はじめてのにき

_ 半年

https://mofmoffox.hatenablog.jp/entry/2020/06/05/232311

いたときから、選考に時間かかるの申し訳ないなあと思ってた。

ただ、雑に扱われた、は外から見るとそうなるのわかるんだけど、僕の感覚ではむしろ、人事的処理を丁寧にやりすぎてて(採用だけでなく昇進なども)、オーバーヘッドが大きくなりすぎて、遅くなってる、と感じてたかなあ。

やまあそれにしたってもっと早く返事できるのなんかがんばれよ感はあるけど

(11:54)

_ systemd

https://github.com/systemd/systemd/issues/3302

一行 2k までしか fgets で読んでないから、 2k 越えのぶんが次の行として解釈されるみたいな話だと思う。このレベルの有名&重要OSSでこんなことやってるってすごいなあ、という気持ちがある。 C やめて C++ 使った方がいいんじゃないかな……

(12:07)

_ gnome-control-center

が空っぽ問題

XDG_CURRENT_DESKTOP=GNOME gnome-control-center

で良いみたい

(10:30)

_ セキュリティの人

大学の時、「セキュリティの人は変わった、気難しい方が多い。やっぱり攻撃とかを考えてると性格が悪い考えかたをしていくことになるのかな」などと先生が言っているのを聞いて、そんなもんかな、と思っていた

会社で働くようになって、多くはないけど、関わったセキュリティ専業の人は、全て良い人だった。グーグルは押しなべて平均より性格の良い人が多い集団だったと思うけど(おかげで僕は「貧すれば鈍する傾向が強い」の確信度を高めた)、その中で見ても良い人達だったように思った。

まあ偶然いい人ばかりと会ってたのかもしれない。実際、プロダクトを作っている人の「セキュリティレビューが厳しくて〜」みたいな愚痴だかなんだかを聞いた記憶も結構ある

けど、僕としては、ローンチを止める強い権限を持つだけに、好ましくないコミュニケーションをしていると仕事にならない、て感じなんじゃないかなあ、と思っていた。というのは、セキュリティというのはどこまでいってもトレードオフで、「薄い確率でセキュリティやばいからローンチできない！」て言い続けると永遠にローンチできないことになるので、そのあたりをちゃんと理解している人は、かなり丁寧に、問題点を整理しつつ、お互いの妥協点を探ってくれる印象があった。

たとえば、このシステムは A と B が良くなくて、 A は簡単だからなおしてほしい、 B は本当は X を使うのがスジなのだけど、それは結構大変でローンチが遅れてしまうから、とりあえず現状でいいけどハック Y を入れてゴマかえば attack surface はだいぶ減るから、ローンチ後に全力で X に置き変えてね、みたいな

逆に、セキュリティ本職でないけど詳しい人がセキュリティのアドバイスをしてくれてたこともあって、まあその人個人の資質が大きいのだろうけど、その人は原則論的な主張が強くて、やりにくいこともあった。その人はとても優秀なのにも関わらず、なかなか昇進できなかったのだけど、まあそのコミュニケーションスタイルのせいだろうなあ……と思っていた

なんだろうな、個人的には、実際のプロダクトに密接に関わる、完璧ではないが、費用対効果のうまい落としどころを探す……みたいなセキュリティが結構好き

(11:47)

_ discourage

長年、日本語ではなんというのかさっぱりわからん単語の一つだったのだけど、今日検索したら「水をさす」というのが出てきて、なるほどー！と思った

improve もよくわからんとずっと言ってるのだけど、それは「いや、改善でしょ？」と言われる。まあそうかもしれんのだけど、改善と improve 、割と語感違うくない？ improve の方が軽いというか……

(22:26)

_ 特許

僕は今でも https://reservoir.tumblr.com/post/68943475/971006-%E5%B0%91%E5%B9%B4%E3%81%AF%E8%8D%92%E9%87%8E%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%99-id-indexhtmlv-112 を信奉する中二心を維持しているので、防衛的特許と言われてようがなんだろうが、特許と言われただけで心拍数が上がる感じがある

(11:56)

_ UNIX 哲学

の、直交性のあるツールをたくさん作って、組み合わせて使いましょうてやつ、その哲学そのものは僕も好きだし、学ぶことの多い教えだとは思っている。なんだけど、自分の仕事に適用しようとしない方が良いと思ってるんだよな。というか、仕事で UNIX 哲学的にバラバラなツール群としてデザインされたものを見ると、げんなりするレベルなので、嫌いといっていいレベルかもしれない

なんでかっていうと、それが真に UNIX の10%程度にでもうまくいっているという例をほとんど見たことがないから、という気もする。 djb が例外くらいの気持ち

バラバラのツールでまとまった機能を実現させるのであれば、そのバラバラのツールが何を、どういうふうにやりとりするか、というのを統一しないといけない。 UNIX であれば行指向のテキストファイルをパイプでやりとりする、みたいな

また、どうすれば使いかたがわかるか、というのも統一しないとわけがわからなくなる。 Linux 環境であれば --help か man でまあだいたいわかる……が info とかを見た方が適切なものがあったり、 Linux 環境ですら完全にうまくいっているとも言えないように思う

もっと UNIX ツール群自体が微妙に感じる部分として、コマンドライン引数があると思う。 cp/diff -r と ls/chmod -R など、このコマンドは似た意味だけど違うオプションなんだなあ……となることは結構あると思う

コマンドライン引数の名前に整合性が取れてないけど、普段そんなに困ってないのは、 UNIX ツール群はそうはいってもおおむね整合性があって、単にたくさんの人がすごい回数使っていて、みんなが共通言語として記憶したから、なのかなあと思う。そして、そこに仕事のプロジェクトで UNIX 哲学を適用しようとするのを微妙に感じる理由がある気がする

仕事のプロジェクトだと、使う頻度も、使う人も UNIX ツール群と比べるとそんなに多くなくて、このプロジェクトのオプション体系はこういう感じなんだなー、というのを学ぶコストがペイしないように思う。 API 経由でモジュール群が連結されていても、プロジェクトごとのお約束とかを覚えたりするコストはどうしても発生するけど、プログラム言語がしばっているぶん、任意の文字列が与えられるオプションに比べると、流儀を覚えるコストは少ない、と感じる。 -help なのか --help なのか、複数入力与える場合は --input x --input y なのか --inputs=x,y なのか、構造化データを受け渡しするこのツールはタブ区切りを受けるのか JSON を受けるのか……などなど

あとたぶんもっと重要なこととして、コンポーネントごとにツールを分けて柔軟な組み合わせができるようになったとして、その柔軟性はなんのためなのか、というのがあると思う。特定の組み合わせでしか意味がないような組み合わせにたいして、ツールがわかれていると間違えて使いうる可能性を高めるし、適当なラッパなんかを提供して間違えないようにしたとしても、そもそもツールをわけるために払ったコストはいったい……ということになる

例としては、 uniq なんてのは sort の後で使われることがほとんどなので、 GNU sort には -u オプションがついてたりする。本来の UNIX 哲学的には微妙なんだろうけど。まあでも uniq は -c をつけたくなることがすごく多くて、これが sort に無いのでなんか結局 sort | uniq -c とやっている。話がそれるけど、 UNIX ツールの(たぶんあとづけの)利点として語られるパイプライン並列は sort+uniq の例では適用できなくて、たぶん、 uniq は速すぎて sort の中でやった方が余計な移動が無くて速いと思う

あとまあ C コンパイラのプリプロセッサとコンパイラとアセンブラのバイナリを分ける話。今時はプリプロセッサはコンパイラが内蔵していて、アセンブラも clang とかだとアーキテクチャによってはコンパイラが持っている。これ、 UNIX 哲学的には、合体させない方が良かった、ということになるんだろうか。あと、昔の UNIX のコンパイラだと、コンパイルフェーズすらバイナリがわかれていて、構文木を作るフェーズとコード生成するフェーズで別バイナリだったのだけど、これもそれが良かった、という主張になるんだろうか(当時はバイナリサイズの制約て話だったんじゃないかと思う)

なんか書くのあきてきた

とか言いつつ、最初に書いた通り UNIX 哲学それ自体はそれなりに好きで、 UNIX ツール群は大好きなんだけど。仕事で書くならライブラリたくさん作ってくっつけてく方が良い気がするんだよな

(08:59)