たとえば/var/log/はここに挙がっていないが、/System/Variable/log/にするのか？それとも/System/Variable/Logging/？
こういうことを考えていくとキリがないし、logをlogという字面のまま使うとすると/System/...とかが悪目立ちする。
あまり好きになれないな。

(1){あれ}

{譜類機構階層標準}{譜類機構階層}(2)

{Nitrux FHS K#D657/99E3}

B̅

正式名称はないっぽい。
https://github.com/orgs/Nitrux/discussions/145

一部では「Aesthetic FHS」と呼ばれている。
https://9to5linux.com/nitrux-3-2-released-with-aesthetic-fhs-linux-kernel-6-6-lts-and-updated-installer
https://github.com/Nitrux/nx-desktop-settings/blob/fd8b8ebff8734e7ecc91c41e76fc20da9fa274eb/etc/init.d/mountbinds#L3

参考: https://github.com/Nitrux/nx-desktop-settings/blob/fd8b8ebff8734e7ecc91c41e76fc20da9fa274eb/etc/init.d/mountbinds#L3

/dev    -> /System/Devices
/boot   -> /System/Boot
/etc    -> /System/Configuration
/usr/sbin       -> /System/Binaries/Administrative
/usr/bin        -> /System/Binaries/Standard
/opt    -> /System/Binaries/Optional
/mnt    -> /System/Filesystems/Internal
/media  -> /System/Filesystems/External
/usr/lib        -> /System/Libraries
/usr/share      -> /System/Shareable
/var    -> /System/Variable
/home   -> /Users

(1){あれ}

{梱譜}(1)

{「搬(パン)」を使う？ K#D657/7A10}

B̅

“package”の何が嬉しいか（中心概念か）を考えると、包んであることもそうだけど持ち運べることもかなり大きい気がする。
持ち運べなかったら共用できないし、そういうのって“(software) package”の概念とそぐわない気がする。

搬(パン)であれば音写性の向上に寄与できるし。
あとは「けい」とか「じ」とか…

{

素朴な疑問}{〈デライト〉}{固有名詞}(3)

{あれ K#D657/D35B}

B̅

固有名詞にいちいち山括弧つけるのって，面倒臭くないですか？

たしかに山括弧をつけないのに比べると若干の時間は掛かっているとは思いますが、実際に山括弧を入力するのは始めに知名をつけるときだけなんですよね。その後は輪符をそのまま貼り付けるか略称・通称を入力するかするだけなので、あまり手間には感じていません。

読み手としては，いちいち無駄に意識させられるので微妙に読みにくいです。

私はもう慣れてしまったのでそんなに意識していませんが、そうでない人からすれば、たしかに山括弧が多用された文章は読みにくいはずです。他人に読ませることを考えるなら、事前に山括弧を取り除いたりするべきでしょうね。

翻訳語の知名にたいする振り仮名は対応する英語・カタカナ語にしたほうが良いとのご指摘においてもおっしゃっていましたが、私の普段の文章は他人にとってたいへん読みにくいんだろうと感じております。
ただ、つねに他人に読ませることを意識して「一般に分かりやすい」文章を書く、というのは私にとっては簡単なことではないので、自分本位な文体・語彙になりがちなのはご容赦ねがいたいです。もちろん、「一般に分かりやすい」文章を書くことはきわめて重要ですし、そういう文章を書けないのに独特な文章を書いても独りよがりになるだけです。一方で「電子頭脳」というデライトの性格を考えると、普段の描出でそこまで意識できないうえ、自分の頭の中身を描き出しているときに他者に思いをはせるのは思考を無駄遣いすることになるとも思っております。

いずれにしても、とくに他者との交流においてはなるべく「普通の」文章にするよういっそう心がけます。

(2){

やり取りを見ていてなんとなく感じたこと}{

なるほど}

{〈AppImage〉}(1)

{AppImage覚書 K#D657/1BE8}

B̅

https://github.com/AppImage/AppImageSpec/blob/28a79bb0e626de2d61485982f99e0ee6eed63721/draft.md#type-1-image-format

とりあえずAppImage仕様のType 1 Imageが現行標準のようだ。Type 0/2は予約・草稿状態っぽい。

AppImageは実行輪結可能形式なRock Ridge拡張ISO 9660譜である。
実行時にISO 9660を装着して、その根幹にあるAppRunという名前の譜類を実行する。

{梱譜}{〈Linux〉}{

AppImage}{実行}(4)

{〈AppImage〉 K#D657/D6E9}

B̅

https://appimage.org/

Every AppImage is a regular file, and every AppImage contains exactly one app with all its dependencies.
Once the AppImage is made executable, a user can just run it, either by double clicking it in their desktop environment’s file manager, by running it from the console etc.
── https://docs.appimage.org/introduction/concepts.html#id2