溶岩に落ちて全財産を溶かした顔

世の中やばい人がいるらしいな？

私はちゃんと使ってた distro だと Ubuntu (gnome2 時代) → gentoo で今に至るのでシンプルですね

触っただけとかインストールしたきり使わなかったとかだと Debian とか KNOPPIX とかがある

あと最近だとコンテナ関係でいろいろ弄るので、そっちではあまり distro とかこだわってないですね(シェルが sh か bash か、エディタが nano か vi か vim か、そっちの方が重要)

ちょっと昔は Ubuntu と gentoo のデュアルブートとかしてたんですけど、もう大昔の記憶って感じがする

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

昔は原理主義の気が強かったので docker は駄目だ、漢は黙って rkt と systemd-machined だ、って言ってたんですが、実際 docker の方がネットワークまわりとかよろしくやってくれてあまりに便利なので屈してしまった(それ以来鯖では docker を常用している)

https://twitter.com/L16777216/status/737660161435697154
https://twitter.com/L16777216/status/695945365221060608
元気があったあの頃……

人間は元気がなくなるとベンダーロックインを無抵抗に受け入れがちという実感を伴った教訓がある

なんDATっ！

……って言えばいいんですかこれは

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

ほっほう

中国で OSS のサーバアプリケーションの運用の自由がどういう状況になってるのか知らないので何とも言えず

ラボの教授と話してたんだけど、中国共産党が「はい中国用公式改造(バックドア)付き mastodon だよ〜こっち使えば国家がトラブルの NASA を保証するよ〜」つって、政治的な方面の圧力でバックドアを使わせるように誘導とかもできるのではなかろうかと言ってて、なるほど〜ってなった

そうすると監視する側はむしろ企業がやってるプロプライエタリなサービスより監視しやすくなって助かるのではなかろうか、みたいな話

プラグインで機能を挿し込まれて、 API が生えてるの、完全にふたなりでは(錯乱)

もう寝ないと駄目かも

This account is not set to public on notestock.

> あれ以外の何かユーザー側からは非難の声が高まった。

雑な文章っぽさがすごくて笑うwww

たしか Dockerfile 、成果物コンテナイメージを生成するためのビルド時専用イメージみたいなのを(単一の Dockerfile で)作れたはずなので、そういうの使ってやれば assets:precompile とかも docker build 一発でできるのでは、みたいな気持ちがある

Docker multi stage buildで変わるDockerfileの常識 - Qiita
https://qiita.com/minamijoyo/items/711704e85b45ff5d6405

これですかね

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

鯖アプデしよ

This account is not set to public on notestock.

This account is not set to public on notestock.

gentoo ユーザとして言わせてもらうと、ビルドはメモリ上でやるのが良いです (docker がどこまでそれを許してくれるかは知らず)

ソースコードの tarball はディスクに、展開はメモリに、ビルドもメモリで、最後のインストールでディスクに書き戻す……というのが通常のビルドの流れだけど、 docker は中間イメージとか全部ディスクにキャッシュするし、そもそもディスクイメージ丸ごとは結構大きくなるかもしれないし

This account is not set to public on notestock.

私は make.conf では
PORTAGE_TMPDIR="/var/tmp/portage_tmpfs"
しといて、
package.env/notmpfs で
sys-devel/gcc x86_64-pc-linux-gnu/notmpfs.conf
とかやっといて、
env/x86_64-pc-linux-gnu/notmpfs.conf に
PORTAGE_TMPDIR="/var/tmp/portage"
って書いてます

単に tmpfs の場合はそれが明示されてほしかったので

今思い付いたんだけど、もしかしてもしかして、英語erがときどき ™ って入れてくるの、 "to me" を意味してたりするのか！？

ActivityPub がテキストのフォーマットを持てるから、 markdown のコンテントをやりとりして表示側で HTML にするのも可能って話ですか (TL 追ってない顔)

markdown 、まあ普通に書けばプレーンテキストみたいなものだし、 OStatus でそのまま markdown をプレーンテキストとして送っても GNU Social でも問題なく見られそう

ただ、 HTML に直してから GNU Social に送られてしまうと、表示する web UI 側でスタイルの指定しないとちゃんと理解できない感じになるので、変換はしてほしくない気がする (たとえば blockquote とか、デフォだと字下げくらいしかしてくれなくて引用だとわかりづらい)

GitHub のライセンス表示、デュアルライセンスに対応してるんですかね(知らず)

ライセンスを明示するための機会可読フォーマットが求められている……(のか？)

や、私のこれは病気みたいなものなので、事あるごとに機械可読形式を推していきます

実際そういうのあれば、依存先のプロジェクトのライセンスとかも再帰的にチェックしてライセンスの継承とか違反の確認とかがかなり楽になりそうだと思いますが

つまり LICENSE ファイルには README と同じく「デュアルライセンスだよ〜」と記しておき、具体的な文章は今までどおり LICENSE-MIT とかに分けて書くとかが楽ってことかな……？

やはり機会可読フォーマットが必要

パーミッションといえば、 docker の公式の owncloud のリポジトリが、毎回の起動での owncloud システムファイル群初期化時には root 権限を使うのに、 php プロセス自体は www-data ユーザで動くから、アプリとかのファイルが古くてもアップデートできない場合がありまして

https://twitter.com/rockridge07/status/921350234243981317
https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new-hope/
Holyjit は草生えるがwwwww

ほんっっっとこういうセンス好き

妹エクスプロイト
https://ncode.syosetu.com/n9428dl/
えっちなポインタの話です

「オリパラ」という呼称、プリパラっぽいと思ったけど結局何を指しているのか思い至るまで n 秒かかった

とあるアプリケーションの構造をある程度考えてあるのだが、英語に堪能でないせいでデータ型の命名ができずにおり、コードに落とせずにいる

note のような article のような、 memo のような post のような variable のような、更新可能なある程度のまとまりの、小さな断片的な、更新可能な情報リソース

This account is not set to public on notestock.

ブログ、 nanoc 使うんじゃなくてもっとちゃんと書きたい (つまりアプデで動かなくなる心配を少なくしたいのと ruby 依存をなくしたい)

Ruby の if での代入による nil 検査と多重代入、両方使う方法があった気がするけどどんなのだったっけって言ってる

構文が思い出せない

めんどくせえ、もういいや

if (a, b) = (map[:foo], map[:var]) 的なことしたかったんですが、よく考えたらこれだと nil 検査は同時にはできなそうな感じがありますね

Rust で CMS 書きてえ……

CMS というか静的サイトジェネレータです

私 frontmatter というのが嫌いなんですよね

アレ、 markdown とかだから許されてるけど、たとえばバイナリにオレオレメタデータ付けようとすれば外部ファイル使うことになるだろうし、他にも XML はテキストだけど frontmatter 付けたら当然 syntax error ですよ

ファイルの構文を侵食するようなデータの改変を強要するフレームワーク、美しくないし行儀が良くないと思います

特殊な形式のコメントとかをパーサ側でうまく解釈してやるとか、或いはコメント中で特定の文字で括ってやって正規表現的なのでマッチさせるとか、そういう方法でやるのが妥当だと思うわけです (たとえば vim の modeline とかみたいな)

と、まあそういうわけで、今 Ruby のコードをあれこれ書いてブログを改造するのはあまり気持ちが良くないというわけです (この前弄ってたのは XSLT なので汎用)

erb が Ruby 依存強すぎて、パワフルに使いたくないというのがある(が、現状既にいろいろ書いてる)

https://twitter.com/arclisp/status/921374353484234752

うっそやろ

こういうの、未だに専用フレームワーク使わずに文字列操作でデータ作る界隈があるのね……

SQL に外部入力文字列埋め込んでインジェクション脆弱性出してる時代の人々ですか？？？

妹エクスプロイト
https://ncode.syosetu.com/n9428dl/
妹にインジェクションして脆弱性を突く小説です

フーバーダム、 foobar かと思ったら全然関係なかったことで有名 (個人の感想です)

https://twitter.com/johnregehr/status/920691341738123264
これすき

カスタム絵文字の仕様の共通見解がなかなか出てこないのを見るにつけ、やはり絵文字は文字ではないのだから文字と同列のものとして扱ってはいけないという思いが強くなり

Unicode……元気でな……

Rust 、文字列のエンコーディングに UTF-8 を採用しているのはまあ妥当だと思うんだけど、肝心の Unicode が絵文字関連であの様なので、言語と文字コードを強く結合させるのは失敗だったのか……？って言ってる

&str 型の内部実装が選べる方式になってて、デフォが unicode::str みたいな感じになってる、とかであればおそらくこの懸念は発生しなかった(後から latin1::str とかに切り替えられるかもだし)

や、現状の Rust でもそれなりに手間をかければそういう改造は可能なのだろうけど、当然 UTF-8 を期待する既存コードは動かなくなるかもしれないよねという (特に from_utf8() 系のアレが trait でなく &str に直に生えている辺りとか)

Unicode の emoji のみを revert というか無視して、それ以外の更新を全て取り入れた fork みたいなの爆誕したりしませんかね(結構期待してる)

Unicode lite とか Unicode for characters みたいな感じで

@omasanori や、それは実装サイドの話で、あくまで規格としての emoji は Unicode にありつづけるので……

あと文字カテゴリ的なアレとかも

@omasanori まあトライグラフは C/C++ でほとんど誰も使ってなかったのでよかったですが、 Unicode emoji はユーザがそれなりにいるし、規格準拠しない実装が複数出てくるとブラウザ界隈みたいな闇が生まれそうで……

通常の API とか機能であれば「実装されているか確認する」という手段が使えるけど、あらゆるテキストデータ(既存のもの含む)について Unicode の特定のモジュールとか単位についての実装があることを要求するフラグを立てるって、すごく難しそうです