新しいジャンル？前からあったのか分からないけれど、言語を題材としたお話が新鮮で面白い。通常多くの物語は、主人公の周りは言葉が通じることが前提、だってそうしないと話がなかなか進められない。
しかしこれらのお話は「言語による会話が困難」というところからがスタートポイント。なにも理解らないのほうは、コミカル寄りだけれども本当に全く言葉が通じないところからスタート。1巻の段階では、まだジェスチャーと一部の単語の意味が通じるようになったくらい。
ヘテロゲニア リンギスティコは、カタコトでギリ意思疎通はできるけれども、そもそも言語体系や文化の考え方が全く違う、該当する概念が相手側に存在しないとか、ただ言葉が通じればいいってもんじゃないっていうレベルのおはなし。
文化の違いを主題にしたお話は良くあるけれども、そもそも「言語とは？」みたいなところから探索がスタートしているのが面白い。
どちらも絵がかわいくて、読みやすいのでお勧め。
最近、地上波アニメとか少年誌で普通に百合やるようになったんだなぁ…と。前からあったんかもしれんけど。
ふと、自分の感覚では薔薇に対して嫌悪感あるけど、百合について女性からの嫌悪感はないのか？と言うのが気になって調べてみると、統計的には薔薇に対する男性の嫌悪感はやはり高いが、百合に対する女性の嫌悪感は低いらしい。因みに百合に対しては男性からの嫌悪感も低い。なにそれ百合めっちゃお得やん・・・。
左巻きの人がいうジェンダーフリーについて、性差によって社会的機会が失われることは改善したほうがいいと思うけれど、性差は対称ではないんだから、結果が同じであるべきとか何もかも同じであるべきってのはどうかしてると思った今日この頃…。
「令和の！」って言ってみたかったけど、検索キー汚すだけなんでやめました。確認したのはFreeBSD 14.3&Samba 4.22.6とmacOS 26.2
わっかんないよ！
Web記事で言ってることはひとつもわかんないよ！
Web記事でいいって言ってるもの、何がいいのかわかんないよ！
わかんない！ 私にはわかんないの！
いやまじで。
FreeBSDとLinuxじゃ事情が違うんだよ。みんな安易にFinderから読み書きできて「これでOK」なんて言うけど、特定アプリからアクセスしたら不具合いっぱいとかあるんだよ。macOSをガチで使ってるユーザー少ないから、Sambaのアップデートでfruit周りにエンバグ出ても誰も気づいてくれないんだよ。
マジでもうわっかんないんだよ（ぉ。
まぁそんな感じなんですが、Appleが公式にafp捨てるって言い出したんで、そろそろまじめにSambaでmacOS向けのファイル共有に取り組もうかと。
そんな感じで現状の設定がこちら。なんとなく動いてる気がするけど、あってるかどうかもうよくわかんない。「FreeBSD&ZFS&netatalkのmetadata/resouceを引き継ぐ」って組み合わせのサンプルが少なすぎて…。
[global]
dos filetimes = Yes
dos filemode = Yes
inherit permissions = Yes
inherit acls = Yes
map acl inherit = Yes
acl group control = Yes
ea support = yes #4.9以降はdefault yes
vfs object = zfsacl catia fruit streams_xattr
fruit:encoding = native #default: private
fruit:metadata = netatalk #default
fruit:resource = file #default
fruit:veto_appledouble = no #default: yes
streams_xattr:prefix = user.
streams_xattr:store_stream_type = no
nfs4:mode = simple
nfs4:acedup = merge
nfs4:chown = yes
ZFSACLまわりの設定は、このあたりをよくみてください。基本的にACLはldapとかでユーザー同期してないと意味ないんで「とりあず不都合ないように」程度の設定です。
vfs object = zfsacl catia fruit streams_xattr
fruit:encoding = native #default: private
これのためにvfs_catiaが必要。macOSの特有の文字コードのエスケープ方法の指定で、netatalk互換が不要なら初期値のprivateのままでいい。副作用として、nativeではfruit:metadata=streamやruit:resource=streamと組み合わせた場合に完全に動作しないらしい。
fruit:metadata = netatalk #default
fruit:resource = file #default
“fruit:metadata = netatalk”の場合、vfs_fruitが直接拡張属性へアクセスに行きます。なので、streams_xattr関連の設定は、このfruitの設定なら要らないような気がします。過去の試行錯誤の名残なんですが、検証するのが面倒だったのでそのまま残っています。
“fruit:metadata = stream”にしてvfs_streams_xattr経由で拡張属性に保存することもできますが、netatalkと微妙に保存方法が違い、互換性がありません。
fruit:resourceについては、近頃はfruit:resource=streamの設定例が出回っていますが、個人的には非推奨です。あれは「自分の運用ではリソースフォークを使わない」という確信がある場合の設定です。
macOS向けファイルサーバーの面倒なところは、メインのファイルストリームの他に、属性情報のためのMetadataとmacOS独特のリソースフォークという情報があることです。Sambaのデフォルトでは、metadataはUNIXの拡張属性に、リソースフォークは”._”で始まる隠しファイルに保存されます。
一部のファイルシステムでは拡張属性のサイズに上限がありません（確かNTFSも）。なんで”._”で始まる隠しファイル（通称ゴミファイル）を作るよりも、同じく拡張属性に保存した方がスマートなのはその通り。
一方でFreeBSDをはじめとした多くのOSでは拡張属性にはサイズ制限があって、ぶっちゃけサイズの大きいリソースフォークを保存すると破綻します。というのも、まずUFSだと拡張属性が64kB以上扱えません。Metadataくらいなら問題ありませんが、リソースフォークに64kBを超えるカスタムアイコンかいたりするとぶっ壊れます。
一方でZFSの場合は容量制限は無いのですが、サイズが増える(数十kB以上から)と加速度的にアクセス速度が落ちる（数秒〜数十秒単位で）という特性があります。そういう仕様らしいです。1ファイルあたり秒単位でアクセス時間かかってたらいろんなところでタイムアウト起こして、様々な不具合を引き起こします。SSDとかNVMeにすればいいってもんでもなく、そう言う仕様。
なので、FreeBSDではディレクトリに”._”で始まるリソースフォークファイルがばら撒かれる設定が必須です。一度、streamに設定してみたことあるんですが、ファイルコピーが成功したり失敗したり、よくわからない不安定な振る舞いになりました。
これは、”._”で始まるリソースフォークファイルを、クライアントから直にファイルシステムとして見えるのを隠すかどうかのフラグで、デフォルトはYes。
以前はそれでなんの問題もなかったのですが、冒頭のバージョンの組み合わせだと、”no”に設定しないとクライアントからリソースフォークが見えませんでした。つまりはカスタムアイコンがまったく見えない。
Samba側かmacOS側か、どっちが悪いのかわからないけれどバグっぽいです。いつからそうなったとか検証するの、もう疲れたよ⚪︎トラッシュ・・・。
vfsオブジェクトを追加するとき、globalセクションで追加してオプション設定してても、各共有セクションでvfsのロード指定したら、globalセクションで指定したvfsのためのオプションはクリアされるらしい…という記述を見つける。
つまり、globalセクションであらかたオプション設定して、各共有セクションで追加でオプション変更するような記述するとき、各共有セクションでvfs objectを指定したらあかんらしい…。
時々不可解な振る舞いになってたのは、このせいか…。
macOSからsamba/netatalkファイル共有へのアクセスにおいて、一見動いているように見えて細かな設定で対応しないと、以下のようなトラブルが起きる…という例を最後に示しておきます。
基本的に共有上のファイルを、アプリから直接開きに行く場合ですね。
1と2の原因は、リソースフォークだったりEAまわりだったり、ACL周りだったりします。どちらも保存前のファイルに対して、EAやらACLを書き換えて保存無しでファイルを閉じるときには元通りに戻すと言う事を、ユーザーの見えないところで勝手にやろうとして自爆します。
ちなみにMicrosoft officeでのACL周りのトラブルは、Windowsとsambaでもきちんと設定しないと起きます。
3はあらかた不具合がこなれた感じです。
4はまだまだ油断ならない感じ…。
そろそろ10GbEにしてみようか？と思って諸々調べてみた。
10GBASE-Tについて調べ出すと、RJ45かSFP+か？という課題に直面します。RJ45というのは、所謂いままでのLANケーブル用のコネクタ。ツイストペアのCAT6a以上のケーブル使いましょうねってのはちょっと調べたらどこにでも載ってる。
一方で、インターフェースが普通のRJ45じゃなくて「SFP+」というタイプが存在します。じゃあSFP+とはなんぞや？というと、
こんな感じでコネクタが細長くて深いタイプ。ふつうのツイストペアのLANケーブルは刺さりません。何が刺さるのかというと、
こんな感じの「メディアコンバーター」というモジュールが刺さります。これは普通のツイストペアLANケーブルを繋ぐためのモジュールだけど、他にも光ファイバーを繋ぐことのできるタイプもあります。
で、このメディアコンバーターというのは何をしているかというと、10GBASE-Tの元になる信号に対して「ツイストペアLANケーブルで通信できるような信号の補強」をしたり「光ファイバーとの電気/光変換」をしたりします。
まぁ今までのGbEまでは、メディアコンバーターの機能がすでにチップに内蔵されていて、どうしても光ファイバー使いたいときぐらいにしかメディアコンバーターが使われることはありませんでした。
しかし、10GBASE-Tってわりと技術的にかなり無理していて、要はメディアコンバーターの機能だけで、むっちゃ高価で電力を食う。
例えば、10GBASE-TのHUB、SFP+のポートタイプなら安価に売られてるけど、RJ45のHUBとなると、少し前までは1万円/portなんて言われていました。今でも5千円/portくらいか？
実は、SFP+にはツイストペアでも光でもない、もう一つの接続方法があります。それがDAC（Direct Attach Cable）というもの。
こんな感じでケーブルの両端にSFP+のプラグが直付けされています。ケーブルは、SFP+のプラグ部分から外すことはできません。ケーブルを交換不能にしメディアコンバーターの機能も大幅に削減して「このケーブルでこの長さ」にのみ対応させることによって、大幅にコストダウンされています。
ただし、長さの制限が厳しく5〜7mくらいまで。それ以上のものもありますが、そうなるとメディアコンバーター部分により高い性能が必要になり、通常のメディアコンバーターに対するコストメリットがあまりありません。
とはいえ、5~7mまでの長さでDACケーブルで完結できるならば、RJ45よりSFP+のほうがHUBも含めると、かなり安価に10GbEの環境が構築できるわけです。
今までも、SFP+のようなメディアコンバーターのコネクタは存在していて、速度面では常にツイストペアLANケーブルよりも先行していました。しかし、ツイストペアケーブルの速度が10Mbit>100Mbit>1Gbitと速度があがり、消費電力・価格がこなれていくに従ってコスト面でRJ45/ツイストペアに置き換わっていったのがこれまでの流れ。ただ10GBASE-Tについては、その登場から置き換わるまでかなりの時間がかかっています。
10GBASE-Tの規格制定が2006年に対し、いまだにRJ45のコストと消費電力は下がらず、あまりの普及の遅さに見かねて、より遅い2.5GBASE/5GBASE-Tの規格が2021年になって後から制定されるくらい。もう20年も経つのにいまだに技術的にこなれたとは言えない。
去年になってようやく、ホスト側のPCIeカードとしては低消費電力のRealtek RTL8127が出回り始め、普及が始まりつつある感じです。
ただ、HUB側の方は10GBASE-TのRJ45対応品はまだまだ高価。もうすこし時間がかかりそうです。なので現時点では、RJ45/ツイストペアケーブルで構築するのと、SFP+/DACケーブルで構築するのと、どちらがいいのか判断が難しいところ。
そんな感じで、調べるだけ調べていまんとこはまだ見送りかな。
