航空法の定義だと
航空機 ⊂ 飛行機　？

この法律において「航空機」とは、人が乗つて航空の用に供することができる飛行機、回転翼航空機、滑空機、飛行船その他政令で定める機器をいう。

てか、航空法における航空機というのが、私が思ってたより狭い概念だ。
飛行機を含んで船や車を含まない最上位の概念ってなんて言うんだろう？

私見

どちらも譜類管理にかんする抽象化を提供している。
VFSのほうが“根幹的”？

参考①の図1を参考に。

U +-------------+   +---------------------------+
s | Application |   |  FUSE file-system daemon  |
e +------^------+   +---------------------------+
r        |          |       FUSE library        |
         |          +-------^--------------^----+
======== v ================ | ============ | =====
  +|Cache|------+   +-------v--------+ +---v--+
K |     VFS     <-\ |   /dev/fuse    | |Other |+
e +------^------+ | +----------------+ |kernel||+
r        |        | | FUSE   : Queue | |sub-  |||
n +------v------+ \->        :   =   | |system|||
e |Kernel-based |   | driver :   =   | +------+||
l |  file system|   +----------------+  +------+|
  +-------------+                        +------+

参考

①　Bharath Kumar Reddy Vangoor，Vasily Tarasov，Erez Zadok「To FUSE or Not to FUSE: Performance of User-Space File Systems」，『USENIX Conference on File and Storage Technologies』第15回57–72頁。2017

https://www.clear-code.com/blog/2013/4/24.html

「どう変わったか」が大事なコミットメッセージを書くときは比較対象を縦に並べましょう。

typoの修正は縦に並べても見つけることは大変〔...〕違っている箇所の下に「^」で印をつけます。

TestDefaultPathRuels ->
TestDefaultPathRules
                 ^^

https://blog.jxck.io/entries/2023-05-17/abnf-or-algorithm-in-rfc.html (2023-05-18閲覧)。

IETF の RFC 3986 は "インターネット" で広く利用される仕様であり、 ABNF ベースで記されている
[...] https://www.rfc-editor.org/rfc/rfc3986

一方 WHATWG は、 "ブラウザ" が実装することを目的とした仕様であるため、 Parsing Algorithm が細かく書かれている。
[...] https://url.spec.whatwg.org/

WHATWG URL は、 RFC ベースだったことによるブラウザ間の実装差異を無くし、互換性を高めるための基盤として書かれたものである

例えば IPv6 アドレスの ABNF なんかも矛盾があるが、それでも世の中回っているのだから、実装側もわざわざ ABNF から実装を起こしたりしてないことが伺える。 ABNF から愚直に起こした実装なんて速いわけがないので、当たり前ではある。

Algorithm だけになってしまうと、実装しないとフォーマットの全体像が掴めないという点は確かにある。むしろ、 ABNF は実際のところ、その目的の方が大きい。そこから正確なパーサを生成するというよりも、「結果がこのような形になる」というシリアライザのソースとしての側面は、どの ABNF も大抵は担保されている。

問題は、 ABNF にパースの役割を担わせた点、そしてその上位互換として Algorithm が併記されていることで起こっている。

symbolic linkの訳語を考えて輪郭を描くこと。
「柔輪結」？

接触元

CUIは命名優先

GUIは実体優先

あ～、だからGUI上のショートカットって扱いにくいのか

意味を噛み砕いて理解すること。

Containerfile および Dockerfile 内で使用できる利用可能なコマンドは同じです。

Dockerfile is an alternate name for the same object. Containerfile and Dockerfile support the same syntax.

とのこと。
なんとなく，Containerfileのほうが汎用な呼び方に思えるので，こちらを積極的に利用する。

no/zero-codeは同じ意味か？ いや分からんけど。

図画的な操作かどうかは関係ないっぽい

The user interface of a low-code platform is often made up of components that users can drag-and-drop to design the app they want.

[...]

A no-code app builder often uses drag-and-drop functionality and other graphical building tools to streamline development and make it accessible for a wide variety of users.

Low-code is a rapid application development (RAD) approach that enables automated code generation through visual building blocks like drag-and-drop and pull-down menu interfaces.

[...]

In a no-code development platform (NCDP) [...] all code is generated through drag-and-drop or point-and-click interfaces.

即譜(ソクフ): script (file)
論譜(ロンプ): program (file); 一時的にこう訳す

即譜と論譜は，かなり区別が曖昧な用語だと思う，というか，おそらく努力しても明確に区別するのは難しいだろう。
たとえば，ある文脈では完全に対立した概念として両者が用いられる（仕類(シルイ)の即譜，C言語の論譜，など）のに，別の文脈では論譜が即譜を内包する（仕類即譜と，C祖稿を換配した後の微形譜類の両者を指す，など）。

2023-01-08現在，どちらも「──譜」という形で訳している。しかし，とくに “program” は譜類ではなく行為を表わす概念として用いられることも多い。その場合は，論組という訳語が最適であり，論譜というような特定の物質に意味が縛られる訳語はマズいだろう。
ただし，「即譜」と訳せる “script” と，対立する概念としての “program” は，「論譜」と訳してもいいと思う。

要旨

事前の私案

同じ事象を異なる角度から見ているだけで，同じ物質を指すのでは？
「乾燥させる」ことと「湿気を奪う（吸う）」こと。

JISなんかだと水分の吸収率とか適用する対象物とかによって定義が分かれていたりするんだろうか。
「吸湿剤」は空間の湿気を取り除く場合にしかそう呼んではいけない，とか。

t_w氏と描出経路が（たぶん）めちゃくちゃ似てて笑った。

シリカゲルについての事柄を描きたいなぁ。
→とりあえずシリカゲルは作っとくか。
→これだけだと探しにくいから，こいつが属する上位概念も作っとくか。
→「乾燥剤」と「吸湿剤」，どっちに引き入れとくべきなんだ？
→どっちも作って引き入れちゃえ

いやまあ，内情までは知らんが。でも時印を見る限り，時系列は（描出間隔を含めて）合ってそう。

緒論

私の現時点での断案

両者の概念がすこし似通っているうえに，読み方・字面がかなり近しいので取り違えやすい気がする。

ていうか，「標準となるものからのずれを正す」という意味ではほぼ完全に同じ概念では？
片や自然言語，片や定量的測定値，という違いはあるが。