Googleの中国向け検閲入り検索アプリ、反対派従業員が社内で共有したメモで詳細がさらに明らかになる | スラド IT
https://it.srad.jp/story/18/09/27/0519258/

ワォ

異世界セマフォに感想を書いてもらってしまった、続きを書かねば……

1話が投稿されたきり2ヶ月更新なしの作品に感想を投げられる人、徳が高すぎない？

目を開けたその瞬間から #LATECH の運命を定められた星の下に生まれてきた

ほんま1限授業は人間らしい生活を阻害する悪弊やで

このアカウントは、notestockで公開設定になっていません。

「高度に発達した休暇は無職と区別がつかない」 #適当 #今日の適当

pseudo 学生気分

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

zsh が起動に 0.18 秒くらいかかるようになって嫌だったので高速化を試みているのだが、source される全ファイル (.zshrc 含む)を zcompile する等してみても相変わらず 0.16 秒くらいにしかならないので、 zshrc 分割行為そのものか外部コマンド呼び出しが致命的っぽい。つらい。

このアカウントは、notestockで公開設定になっていません。

source を全てインラインに展開してみたが、時間は変わらず。つらい。

なお zprof の結果:

num calls time self name
-----------------------------------------------------------------------------------
1) 19 136.13 7.16 92.07% 129.08 6.79 87.30% (anon)
2) 1 7.86 7.86 5.32% 7.86 7.86 5.32% compinit

この (anon) というのがどうも匿名関数の即時実行っぽくて、名前を付けてしまうと即時実行されないから構文が変わるし、面倒すぎる

zshrc の中でやってるの、 $PATH に追加するためのコマンド出力の取得とか、 TERM を見て設定 (キーバインドとか) を調整したりとか、エイリアス設定とか zsh のスタイル設定とかそんな感じなので、うーん

早くなったと思ったら、文法エラーで中断されていただけだった (投稿消した)

なんだろう、 && { foo } 形式も anon でカウントされてるのかな

num calls time self name
-----------------------------------------------------------------------------------
1) 4 137.59 34.40 91.44% 130.48 32.62 86.72% (anon)

anon 相当のものをほとんど消したら、やっと compinit が 41.86 % を占めるまでになった (というか結局 compinit -C が 0.1 秒近く使ってるのか……)

や、 compinit は 7.79 ms だぞ、やっぱり何かおかしい……

だいぶわかってきた、 ruby -e 'puts Gem.bindir' が 45.4 ms 食ってるのに、関数内に表示されないからコストが見えなくなっているだけだった

ということはつまり、今まで匿名関数を使っていたところに全て名前を付けてやれば、格段にプロファイルが正確になりそうだ

discourse.mstdn.jp があったじゃないですか

むしろ閉鎖的なプラットフォームである discord よりも discourse の方が参加はしやすかったはずだと思いますね

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

私は「参加せずに中身が見えない」というのは嫌ですね。特にオープンなソフトウェアについてのフォーラムやらだったりすると尚更

discord とか slack 、「お試しで中身を覗き見る」もできないし、「参加すると『参加しました！！！！』と全員に知らされる」とかも嫌だし、個人的には嫌いですね(まあ人々が使ってるし邪悪とまでは思わないので使うんですが)

雰囲気がどうとかでなく、機能というか仕様が嫌いなので、コミュニティの問題ではない

私は「私、登場！！！」みたいなことしたくないんですよ

だから、ああいったものは「構成員であるかどうかは明確である」ようなコミュニティに対して作られているツールだと思っていて、もっと緩やかな繋がりとか、消極的な人も呼びたいとか、そういう場合に使うものではないと思うんですよ

このアカウントは、notestockで公開設定になっていません。

GitHub の issue を読んだとき「○○さんが読みました！」とか知りたくもないし知らされたくもないじゃないですか、だからそういうオープンで緩やかな集団にはそれに適したツールを使うべきだと思うんですよ(そして discord は少なくともそういうツールではなさそう)

や、鯖立て支援における秘匿情報の扱いについて言えば、そういう「参加者が明確で限定されている」という性質は有用なんでしょうけど。それは作業のグループについて要求される特性であって、コミュニティや「Mastodon などに関心のある鯖缶」を集めるために使うツールとしては微妙だと思っている

言うて discourse も js でかなりチャットに近くなってません？(実際どのくらいなのか知らんけど)

質問サイトなど見ていると、初心者が的を外した質問をして、それに対して知ったかぶりが頓珍漢な回答をしていてベストアンサーになっていて、まともな回答は埋もれている、というパターンを際限なく目にするし、「人に物を聞く」というのは聞く側にも相応のレベルが必要

このアカウントは、notestockで公開設定になっていません。

まあつらぽよを吐き出しているだけなので

有機物がウンコしかなかったら食うしかないんですよ(不適切なたとえ)

鯖缶工場についてはまだクローズドなものを使う妥当性もあるのでまあという感じだけど、 OSS の開発とかで discord による意思決定とかがあるとｳｹﾞｹﾞという気持ちです

何らかの特殊なプラットフォームに登録して「参加しました！！」しないと意思決定プロセスを見たり参加できないプロジェクト、定義ではそれでもオープンかもしれないけど、普通に嫌じゃないですか(いや大規模ならそれも仕方ないのかもしれないが)

や、意思決定に参加するのはまだ仕方ないとしても、建前では誰もが見られるはずの情報を見るのに何故か登録が必要なの、妥当性がない

このアカウントは、notestockで公開設定になっていません。

メールアドレスを明け渡したうえで「○○さんが参加しました！」と参加者全員にアナウンスされる、しかも参加するまで中に誰がいてどういう雰囲気なのか全くわからない、という障壁があらゆる人間にとって全く抵抗のない行為なのであれば、 Slack も十分にオープンだと思います

簡潔に言えば、「大学のサークルは誰でも入れるからオープンでしょ」は嘘だろみたいな気持ちです

つまり痕跡を残さず閲覧できるか、というのは一番基礎的な部分だと思っていて、匿名でアーカイブを読める ML であればそれは(少なくとも最低限度以上には)オープンだと私は考えています

アクティブメンバーが1000人いることは確証持てないですよ、参加してみないと

このアカウントは、notestockで公開設定になっていません。

脆弱性対応とか秘匿情報あたりのあれこれとかを考えると、この辺りが仕様としては良さげな感じなんですよね

発言権については、発言の責任とか荒らし防止あたりの話があるので、匿名で閲覧できるその次のレベルだと思っていて、それが必要かどうかは状況によるのかなと思います

このアカウントは、notestockで公開設定になっていません。

邪悪さに問題がないのであれば、より適切なツールを使ってほしいなぁという感想です

このアカウントは、notestockで公開設定になっていません。

たとえば「この仕様/実装はオープンに開発が行われています」と称しつつ、意思決定プロセスは見えなくて結果だけ提示されていたりすると、「？？？」ってなりません？ 自然言語的には成果物だけ公開していても「オープンな開発」になるのかもしれませんが。

成果物のみでなく開発がオープンであることを謳うなら、意思決定が(多少の遅延があったとしても)有象無象にも見えるようになっているべきだ、みたいな気持ちがあります

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ちょっと違うかな

「誰にでも全裸見せます！」があったとして、「全裸を見るには名前をここに書いてください！」を受け入れられるか、みたいな話ですね(そして後者スタイルを選択しているコミュニティで本当にそれは必要なのか？)

「全裸を見るには名前をここに書いてください！」があっても確かに「オープン」かもしれないけど、それって本当に「自由に全裸を見られる」と言えるのか？ みたいなお気持ちです

これはちょっと文脈が変わるんだけど、「誰でも投票できます！名前を書いてください！」は自由な投票だろうか、みたいな(文脈が違いすぎる)

べつに匿名であることが重要なのではなくて、「『オープン』を謳うにも関わらず必要のない匿名性喪失を要求するのは、一貫性が感じられない」とでも表現すればいいんですか

秘匿されるべき情報やアイデンティティを結び付けるべき行動ももちろんあるし、そこに認証や広報を要求することを否定しているわけではないです

結局これなんでしょうね

「オープン」という言葉に暗黙に自由ソフトウェアの文脈を見出してしまうのが、いけないといえばいけないのかもしれない

たとえば「ソースコードを公開していれば『オープンソース』になるわけではない」に近いアレかもしれないけど

なんでしょう、オープンであることの意義って、任意の第三者による検証を許すとか情報を人類に共有することによる知的資産の目的とかいろいろあると思うんですが、「名前を書いたら……」ってその目的のために必要だとは到底思えないし、任意の第三者やすべて人類との情報共有を否定しているようにしか見えないんですよ

https://mastodon.cardina1.red/@lo48576/100802971946366731
https://mastodon.cardina1.red/@lo48576/100802977298032187

思想的には、だいたいそんな感じの考えを経て「オープンと『名前を書いたら』が一貫して見えない」と言っています

無論、深い意味も理想もなく「なんとなくオープンソース」なものも沢山あるんだろうし、それらを否定するつもりもないけど、そういったプロジェクトで雑にツール選びをしたりすると、結果として「？？？」と感じてしまうということなのかも

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

極端だけどまあ程度を無視して構図的にはそんな感じです

はいプロ
世界一セキュリティが堅固
インターネット界のtourist
XSS時代の終焉を告げる者
実質同一オリジン
HTTPヘッダを書くために生まれてきた男

簡潔に言うと、 discord はゲーマー用のチャットを謳っている

まあ仕様がクソなのは単に仕様がクソなだけで、設計思想とかとはまた別の話だけど、それはそれとしてそういう問題もあるのか……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

それは承知のうえでの話ですが、まあﾊｲ

今日も一日、型安全に！

？

冗長化とバックアップの区別がつかない人なんて実在するのか……

C が書けても習得が簡単ではない(かもしれない)もの、関数型とかリアクティブとかそっち系のパラダイムごと違うやつなどがありそう(適当)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

まあそれはそうなので、お気持ちとか意図の問題です

このアカウントは、notestockで公開設定になっていません。

そこで「誰でも乗り越えられる障壁」を嫌うかどうでもいいか、というのが主題です

たとえば「実名を叫ぶと我々に参加できます」も定義上は「オープン」でしょうけど、これが障壁でないと考える人は多くないのではと思います

私が言っているのは実利とかそういうレベルの話ではなく、「障壁や(本人にとっての)コストになるかもしれない不要な行為をなぜ要求できるのか」という話です

実利があるなら、嫌いだがそれも仕方ねえか、で終わる話

完全バックアップ、差分バックアップ、増分バックアップ等の概念があり、一般にスナップショットは完全バックアップ相当では。(ただし内部実装としては差分や増分でありうる(たとえば CoW))

相当というのは「展開できるデータ、理屈上保持しているデータは(完全バックアップ相当)」という意味であって、内部実装は別の話なので文脈によるのでは

Git - 基本的なスナップショット
https://git-scm.com/book/ja/v2/Appendix-C%3A-Git%E3%81%AE%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89-%E5%9F%BA%E6%9C%AC%E7%9A%84%E3%81%AA%E3%82%B9%E3%83%8A%E3%83%83%E3%83%97%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88

たとえば git の commit は working tree のスナップショットであると説明されるが、その各オブジェクトの内部表現は完全なコピーだったり差分・増分だったりする

ZFS も CoW だったはず

たしか aufs の overlay の代わりに btrfs の snapshot を使えるとかじゃなかったか(詳しくは知らん)

ZFS の snapshot は read only なので、まあそれはそうという感じなのだが、 btrfs の snapshot は書き込み可能にできるし通常のサブボリュームを CoW で作っただけみたいな感じなので力強い

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

「(適当)」の方がいいよ(適当)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

そうして人々は Python 2.7 を使い続ける(違う)

ｴｸｽﾍﾟﾘｱ好きだよ、 UI がカスタマイズされたクソでないのがまた良い

このアカウントは、notestockで公開設定になっていません。

オッ人脈 (この話はよくない)

このアカウントは、notestockで公開設定になっていません。

日本語訳は大事、それはそうなんだけど、一次文献を読めないものにコストをかけるなら相応の覚悟と支払いをするべきという気持ちがある

たとえば気になるソフトウェアでドキュメントの非公式日本語訳や日本語解説があったとしても、 README その他諸々が公式でアラビア語(ここはあなたの読めない言語)しか用意されていなかったとして、私はそれを使う気になれませんね

べつに一次ソースが読めないものを使うのも好きにすればいいんだけど、それがリスクであることは意識しておくべきなんだよね

いざというとき「困った！」と叫ぶようでは覚悟か準備が足りてないし、「いつかこうなると思ってた」と思えるくらいでないといつか痛い目見る

このアカウントは、notestockで公開設定になっていません。

英語である必然性はないんだけど、翻訳のコストが高い割に「読める人に翻訳はあまり必要ない」という需要と供給のアンバランスも難しい

このアカウントは、notestockで公開設定になっていません。

アーキテクチャやソフトウェアを統一された規格でトップダウンにパッケージング……

もしかして……

いや言うまい

私が生きている時代の話ではないので

このアカウントは、notestockで公開設定になっていません。

そこはまあ習得コストの問題もありそう

そこで Lojban ですよ

Rails (で作ったアプリケーション) がガラクタの寄せ集めだと言う人いそう(知らんが)

leftpad の話は……

このアカウントは、notestockで公開設定になっていません。

iBus は知らないけど fcitx は多分そう

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

べつに英語賛美とかしてないし、英語よりマシなものがあるなら是非普及させてくれというお気持ちですね

Lojban はいいぞ

まあ理由がないなら自由なライセンスにせよというのはそういう状況で人類の資産を増やす手助けになるので、デフォルトの選択肢として推奨する価値はある

理由がないなら CC や PD 、理由がないなら MIT や PD 、そんな気楽さでやっていけばいいと思います

このアカウントは、notestockで公開設定になっていません。

Python 2.7 が残り続ける理由ですね

このアカウントは、notestockで公開設定になっていません。

電子部品はデータシートが一番大事(ほんまか？)なドキュメントなので、まあ……

このアカウントは、notestockで公開設定になっていません。

GFDL とかじゃないんだ

AGPL 、一応文書にも使えるということ？ 単にソフトウェアの一部として提供されているということ？

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

つまり最初そうだったけど変更できていないという惰性か……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Lojban

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

うまい翻訳システム、今に至るまで未解決の難題なので、まあ険しいが仕方がない

依存を複数手動で……というのは、パッケージマネージャによる自動化と機械可読化で解決されようとしている問題なので、まあ筋は通っていると思います

依存については、まあ「ユーザが不要と判断した機能を切り捨てられる」という性質を持たないソフトウェアが駄目なのではという感想がある (gentoo / Rust 並感)

C/C++ はマクロとビルドシステムで機能と依存のオプトイン・オプトアウト・切り替えに対応しているし、 portage はそれをパッケージマネージャのインターフェースから提供できているし、 Rust はもっと綺麗にそれを実装している

そもそも動的型付きスクリプト言語なんて実行時依存追加だって可能なはずなので、それができないように見えるならソフトウェアの設計が悪いの一言で終わりなのでは

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

あとさっきの POSTD の記事、まとめが強調のためか雑過ぎてアカン

教訓を引き出すなら

・標準ライブラリを使え
・標準にある機能を敢えて外部に頼りたいならオプトインにしろ
・必要性を確認せず雑に機能や依存を増やすな

という感じになると思うんだけど……

明示されているものには明確に、曖昧なものには適当に、というのが自然な流れだし、実際そうなってると思うので、「今まで曖昧にしていて今困っている」は Seyana... という感じ

私も OSS に「この依存要らんやろ」と「この機能は optional にすべきやろ」でﾌﾟﾙﾘｺ出したことある (両方 merge された)ので、件の記事の主旨には賛同する (まあ言語ごとの哲学みたいなのは尊重されるべきだろうけど)

「この依存要らんやろ」は、 m×n の配列を管理するのに任意次元の多次元配列演算ライブラリみたいなのを使っていたので、自分で小さな型を作って依存排除した

その経験からすると、「適当な道具を使え」「適当な道具がないなら、(たとえ多少の重複があっても)自分で作ることを検討する」という感じ

結局バランス感覚の問題と言ってしまえばそうなるのかもしれない

このアカウントは、notestockで公開設定になっていません。

強み、「テキスト」

軽いだけなら、 non-copying でバッファからデータ持ってこられるバイナリ表現の方がいいです(割と本気)

たとえば数値を文字列で送るのと、バイナリで送ってエンディアン変換を噛ますのは、後者の方が圧倒的に軽い

このアカウントは、notestockで公開設定になっていません。

json と同様にスキーマレスなデータを表現できるものとして CBOR や messagepack が有名だが

テキストであること、(バイナリに比べ)非効率ではあるが圧倒的にデバッグが楽なので、結局流されてテキストを使ってしまいがち

このアカウントは、notestockで公開設定になっていません。

＞ HTTP/2 ＜

HTTP 、 CR+LF をどうにかすればいいのにと思ってたらいきなりバイナリプロトコルになったので爆笑した

実際のところ、透過的圧縮で deflate とかかけてたりするので、たかが CR+LF が CR になる程度ではクソの役にも立たないんだろうなと思った(実験してないので実際どの程度効果が薄いのかは知らん)

このアカウントは、notestockで公開設定になっていません。

や、 XML はスキーマを知らなくても共通の文法知識である程度処理できるという性質 (つまり json が持っている性質) とか、名前空間による外部データの混乱なき合成とかが重要なのであって、テキストかどうかは二の次なのではみたいな気持ちがある(いや知らんけど)

共通の文法を持ったスキーマ可変(後付け可能)なバイナリフォーマットがあまりなかったというだけでは

RIFF みたいなコンテナフォーマットは存在したけど、それも単に「配列として振る舞う」程度のものでしかない

ZIP の 64-bit 拡張がひどい話……

そもそも ZIP の仕様がひどい (完)

「どこぞで独自拡張に使われていたヘッダなので導入しました」「この機能とこの機能は競合します」

は？？？

いや、あの……

たとえば 64-bit 拡張とストリーミング拡張はヘッダの仕様が競合するので共存できない。
つまり 4GB 以上のファイルを持つ ZIP は作成できるし、ストリーミングしながら ZIP は作成できるが、 4GB 以上のファイルを持つ ZIP をストリーミングで作れない (なんじゃそりゃ)

ZIP そんなに難しくないし、日本語訳とかもあるので、規格眺めてみるといいと思います

互換性ェ……という気持ちになる

他には、たとえば ZIP の内部圧縮形式として deflate 以外にも bzip2 やら XZ やら jpeg やら wavpack やらいろいろ用意されてるんだけど、 pkzip 以外誰が対応してるの……

音は微妙だが意味が近いので評価に値する

あと、 ZIP のファイル・ディレクトリのエントリのメタデータの形式はプラットフォーム依存とされているので、「このエントリがディレクトリであるか」を判定するのは環境依存 (は？？？？)

もちろんファイル名などのエンコーディングも環境依存

ZIP 、読めば読むほどすごい

ところで 64-bit で思い出しましたが、ファイル内アドレスの表現が 32 bit だったのに、マイナーバージョンアップで唐突に 64 bit になった有名ファイルフォーマットがあります。

FBX 7.4 と FBX 7.5 です

このアカウントは、notestockで公開設定になっていません。