そもそも stub resolver 無効のときの resolved が何をしているのかよくわかってない

なんか固有の API で DBus 経由か何かのリクエストは引き続き受け付けているのかな

unix socket の可能性もあるか

あーはいはい nsswitch 経由で getaddrinfo(3) とかに効いてくるのね

systemd-resolved.socket があるのかと思ったけど、なさそうか

これ結局 libX11-1.8.8 の問題でした、 libX11-1.8.7 に下げたら問題なく動くようになった

なんという罠

Cannot enter any characters using Xim when setting XMODIFIERS (#205) · イシュー · xorg / lib / libX11 · GitLab
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/205

Fcitx5 not working with XIM after libx11 1.8.8 update · Issue #1000 · fcitx/fcitx5
https://github.com/fcitx/fcitx5/issues/1000

これかぁ

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

難読化されたコードがビルドスクリプトに！ という話を見て「autotools の m4 マクロやらシェルスクリプトなんてもともと難読だろ」という感想が素で出てきてしまったので、そりゃ確かに攻撃対象にはもってこいだよなw と深く納得した

ビルドシステムがクリーンであること (複雑なことをしようとしない限り複雑な記述が必要とされないこと) は大事なんだなぁ

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

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

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

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

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

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

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

これが「目の数が多い」ってことなのか……としみじみしましたわね

ありがたい話ですよ本当に

https://mastodon.cardina1.red/@lo48576/112176248011227280

結局脆弱性どころではなかったな……

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

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

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

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

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

zstd は圧縮・展開のバランスは良いものの圧縮率と展開速度だけで比較するなら xz とタメはれるものではないという認識

脱 xz されるとしても zstd ではなく bzip2 になるのでは (知らんけど)

圧縮が得意なバックドア……

zstd はあくまで gzip 代替としてのポジションがメインで、 ssh とかにパイプで垂れ流したりファイルシステム上で透過的に使ったりみたいな I/O に噛ませる用途には適しているが、多数に配布したり圧縮が一度で展開が沢山行われるような用途では bzip2 とか xz の方が適しているはず

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

これ見たことある気がしてきたな…… (たぶんそのときも驚いていたと思う)

Arch Linux - News: Now using Zstandard instead of xz for package compression
https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/

> Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined,

これだけで済むのすげえな (まあ xz は --best なんかやるととんでもない時間かかるので、圧縮時間で妥協しているということなのだろう)

ワイの手元バックアップは xz --best していたりするが、結構縮む

https://mastodon.cardina1.red/@lo48576/111092396444178523
https://mastodon.cardina1.red/@lo48576/111733834879757425
https://mastodon.cardina1.red/@lo48576/111207153226606101

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

--best はしないか……さすがに……w

zstd で -T0 しているから、圧縮率度外視で速度優先してるっぽいな (基本的に単一ストリームを圧縮するならシングルスレッドの方が圧縮強くなりそうなので)

ctx:
[arch-dev-public] RFC: (devtools) Changing default compression method to zstd
https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029520.html

いや、でも zstd の level は 18〜21 でやってて、うん？ (default は 3)

> The current method is `xz -c -z -` which is single-threaded and rather slow, so we are looking to replace it with something faster.

「圧縮速度最重視、かつ公式実装を使う」という条件での比較かな。 xz の並列化実装であるところの pigz とかも使ってないようだし。

……にしては xz -T してないのでやっぱり謎。メモリ食いすぎて無理だった？

てかアレか、そもそも Arch は過去バージョンのアーカイブをそうそう使わなくなるタイプの distro だから長期間保存を前提にしなくてよくて圧縮率は二の次なのか

mastodon のバックアップデータで xz と比較してみよう

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

元の .tar が 8.6 GiB、 xz --best で圧縮した .tar.xz が 1.3 GiB。

zstd --ultra -21 中。
Read: 1024 MiB / 8.57 GiB ==> 27%

なかなか縮むな。期待できそう

暇なので zstd -T0 --ultra -21 もしてみよう。
CPU% が 1601.3 とかなのでたぶん16並列になってる。メモリは今のところ 34% くらい (10.4 GB くらい) でゆっくり増加中

めちゃくちゃコア偏ってて笑う、キャッシュまわりの何かのためのスケジューリングかな

前提として、 Ryzen 9 7950X なので CCD が2つある

zstd -T0 --ultra -21 の結果出ました、 1.5 GiB。ちゃんと計測してないけど結構高速だった気がする割には xz --best の 15.12% に迫る 17.46% の成果。

これは長期間維持するアーカイブでもなければ普通に即決で乗り替えできるレベルだな……

zstd --ultra -21 の結果、 1.5 GiB。 SHA-512 ハッシュが parallel 版と完全に一致した。そうなんだ……

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

結果発表。
zstd は --ultra -21 (level 21)、 xz は --best (level 9) での圧縮。
parallel-n は -Tn による並列圧縮。
元の tarball は mastodon (この投稿を発射するサーバ) の先月のバックアップで、 mastodon の git リポジトリや postgresql の生 DB (not dump) などを含む。

生 tar: 9199626240 bytes (8.6 GiB)
zstd 直列/16並列 (完全一致): 1606277479 bytes (1.5 GiB)
xz 直列: 1391707412 (1.3 GiB)
xz 8並列: 1395747252 (1.3 GiB)

……というわけで、以下の両方の条件を満たす用途ならまだ zstd よりも xz の方が強そう。

* 2%くらいの差が気になる。
* 圧縮時間はあまり気にしない。

xz を8並列でやっているのは、10並列以上にすると OOM Killer に殺されるからです (当方メモリ 32 GB、ただしアーカイブを tmpfs に置いていたのでたぶん自由に使えたのは 12 GB 〜 16 GB)

補足: zstd の並列圧縮は直列の場合と結果が一致するらしい (本当か確認していないが手元だとそうなった)

実測: https://mastodon.cardina1.red/@lo48576/112182504886411013

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

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

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

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

またしても唇がブチギレして「lipが……rip！w」ちゅってる

ぽきた

予約語が英単語であるか記号であるかはオーバーライド/オーバーロード可能性や型付けの強さとは一切関係ないよ

syntax と semantics を混同しないでもろて

個人的には予約語を積極的に英単語にしたり構文を英文風にするのは嫌いです。意味論の良し悪しとは全く独立した話として、減点ポイント

# define BEGIN {
# define END }

の話はよせ！！！

ただまあメソッドチェーンで英文風の語順を使うことで名前付き引数の代わりにしようとする作法などもあって、 positional argument よりマシという点では同意せざるを得ない。嫌いだけど。

たとえば rspec みたいなやつ？

英語圏特有の感性なのか何なのか知らんけど、たとえば雑に例をでっちあげると
let foo = bar();
を
let foo be bar();
と書くことが可読性に貢献すると信じているような連中がいて、さすがに非ネイティブとしては強く反発せざるをえない

べつに = でも be でも書けるものは書けるが、敢えて記号より be を使う理由あるか？ という話なのよ。
で、 && や || の代わりに and や or を使うのも私には同じレベルのしょーもない余計なお世話に見えている

「!」については、この前置の細い記号1つで否定というクソデカいロールをこなすのが異常だから not と書きたいというのはわかる。 and と or よりは。

この問題について言えば前置であることの問題もあるような気がするし、 not(some_boolean) なり some_boolean.negate() なりのような既存の構文に乗せられそうな書き方でも良いのではないか？ という気持ちもなくはない。その辺りはいろいろ意見がありそうだけど

*nix 伝統の負論理なぁ……

＞ _Bool ＜

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

C23 から bool でいけるのか (stdbool.h みたいなの必要だったりする？)

<stdbool.h>
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdbool.h.html

んなこったろうと思ったよ。実に C らしい。

C++ で std::hash_map じゃなくて std::unordered_map にしたやつとかもそうだけど、なんかあの辺りの「既存コードでユーザが使っている識別子と競合すると困るのでキーワードや標準の名前を追加できない」みたいなのを見ると C/C++ だなぁとなる

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

Predefined Boolean constants (since C23) - cppreference.com
https://en.cppreference.com/w/c/language/bool_constant

> Until C23, true and false were implemented as macros provided in <stdbool.h>. An implementation may also define bool, true, and false as predefined macros in C23 for compatibility.

あー、 C23 からは stdbool.h なしで使えるようになるとかそういう話か

おもいきったことしたなぁ

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

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

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

なにやらシュールな絵面になった (仕様バグでは……)

#原神

状態管理の甘さ

#原神

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

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

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

何かしら区別したいときは executable binary と呼ぶことはある

executable text とも binary data とも区別できる

結局 text でないものは non-text と呼ぶしかない気はする

まあ「本質的には text であるものを圧縮などした結果 non-text 表現になっている」ような “バイナリ” を non-text と呼んで良いのかは若干怪しいところがあり、つまり text という言葉自体が既にどのレイヤーの話なのか曖昧さを持っている。この状態で binary という言葉だけどうにかしようとしてもしょうがない。

もうおしまいだよ

そういえば "code" も「符号」であってべつに実行を想定した特定のデータという意味ではないから、 (実行可能な非テキストという意図での) "binary" と似たようなアレなんだよな

あまりにも最初からゼロのセクションすぎる

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

crypto (cryptoconcurrency)

#デファクト

実際シェルスクリプトを「シェル」と呼んでいる人のことは一切信用できないとは思ってしまう

むしろ実行可能イコール「バイナリ」という図式はｲﾝﾄﾞｯｽﾞ界隈の方が強いのでは

Windows 長らくロクなスクリプティング環境がなかったし (近年こそﾊﾟｩﾜｰｼｪﾙがあるが)

そして実行可能ファイルが「実行可能ファイル」と表示されていようが人々がそれに従うとは限らず、実際 Windows ユーザが USB フラッシュメモリを「リムーバブルドライブ」ではなく「USB」と呼んでいることからもこれは明らか

「取り外し可能メディア」だったっけ？ バージョンによるかもしれないけどまあ何でもいいよ

https://mastodon.cardina1.red/@lo48576/107492649468866677

VTuber を見るときの雑念

COM……

PE の拡張子も exe だっけ

https://ja.wikipedia.org/wiki/Portable_Executable

なんかいろいろあってﾜﾛﾀけど exe ではなさそう

うぉおおお！！！
イクゾー！

#崩壊スターレイル

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

これなので「ｳｪﾋﾞｻｲﾄ」と言うようにしている

ストーリー進めるのでしばらく離脱