コロナの極めて強い感染性と、感染者を事実上隔離不可能な日本の住宅事情を鑑みれば、家庭内感染ってほぼ不可避なんよね。それをなんとかできる可能性が示されたのは大きいと思う。
https://www.shionogi.com/jp/ja/news/2024/10/20241029-2.html
ゾコーバがコロナ予防薬として機能する可能性が示されたとのこと。これ何気に重要なニュースじゃない？
マンガ図書館Z、他のとこでも買えるエロマンガを売ってる時点で、もう「絶版」でも「図書館」でもないし、とにかく変だった。
今回、決済を切られた本当の理由は不明だけども、
>「一部の作品だけ削除して凌ぐのは避けたい」
という赤松氏のポストからも、一部の作品、具体的にはR-18作品を削除して存続という選択肢は、決済代行会社から提示されていたものと推測される。
でも、R-18作品を削除して存続というのは、サービスの理念から考えれば全然アリだと思うんだ。マンガ図書館ZにあるR-18作品って、絶版マンガじゃないのが多分ほとんどだろうから。（ちょっとR-18ランキング見た限りだと、他の電子書籍ストアでもあるやつばっかりだった。これが卸事業ということなんだろう）
R-18作品を削除して存続できないのは、表現の自由を守るためというより、そうしてしまうと、実質的に唯一の商品であるR-18作品がなくなり、皆プレミアム会員から脱退し、サービス運営費が稼げないからだと考えられる。
ここまで考えてようやく分かったが、収益構造が歪だったのが主因に見えるのに、カード会社による表現規制問題にすり替えられた感が強いから、モヤモヤするんだな。
マンガ図書館Z閉鎖は、なんか、こう、モヤモヤしてるんだよな。
マンガ図書館Zって、もう正規には売りようがない絶版マンガを、海賊版としてではなく、作者の許諾を得て、電子化して広告を付けることで、無料で提供しつつ作者に還元しようという試みよね。
で、今回、決済が切られたのは、R-18書籍の閲覧可能となるプレミアム会員のサブスク料。サービス運営費はプレミアム会員料で賄われているので、ここが切られるとサービス存続が不可能になる、という話だ。
要は、広告収入だけでは運営できないということなので、非アダルトな絶版マンガには、作者に十分な利益を分配し、サービス運営費を賄えるほどの商品価値は無い、という意味だよねぇ。だったらぶっちゃけ、コンセプトはとうに破綻してると思うんだ。サブスク課金にしてしまったら、それはもう普通の電子書籍サイトと何も変わらんので。
あるいは、
>マンガ図書館Zを運営する株式会社Jコミックテラスでは他社ストアに作品を提供する「卸事業」も手掛けており、今後は卸事業に注力し継続することで、参加いただいている作家の皆様への還元を図っていきたいと考えております。
を読む限り、要は、不採算事業をやめただけ、という受け取り方だって出来る。こっちの方が可能性高いかもね。
>決済代行会社とも早急に協議いたしましたが、カード会社の判断によるものであり、すでに弊社では覆すことのできない状況でした。
というのが嘘じゃないのなら、決済代行会社の方針ではなく、アクワイアラーか国際ブランドの方針だと素直に受け取っていいんじゃない？
むしろマンガ図書館Zの終了は、カード決済サービスの闇を暴くために敢えてやってんじゃないかとすら思ってる。
>「替わりの決済代行会社を見つけたとしても、また同じ現象が起こる可能性がある」
はあるにせよ、この選択肢をとってサービスを延命させるのがどう考えても第一選択でしょう。JCBなら使えてるサービスは、実際にあるんだしさ。
https://x.com/KenAkamatsu/status/1853771600828809490
JCBも含めて使用不可となると、決済代行会社というより、アクワイアラーの方針ぽいな。
アクワイアラーに、ある国際ブランドがNGを出している項目を取り扱う決済代行会社に関しては、すべての国際ブランド（JCB含めて）で決済NGとする、という方針あるいは内規があっても別におかしくない。
国際ブランドが明示的に、アクワイアラーにNG項目の指示を出している、という事実は無いことになっているが、アクワイアラーが国際ブランドに対して忖度している可能性は別に否定されんしね。
そもそもカード決済にNG項目があることが、必ずしも悪なのか、という話も議論があってしかるべき。実際、二次元ポルノが非合法な国もあるわけで、どこかの国で非合法なものを、カード決済で取り扱わない自由はあっていいと思う。
Windowsの名前解決仕様を確認するのがめんどかったので、久しぶりにChatGPTを開いたのだが、相変わらずとんでもない大嘘をつかれたし、知らないことを聞くのはマジでやめよう。（n敗）
そもそもなんでこんな話してるんだっけ。そうだ、NASからのコピーで更新日時が書き換わる問題は、IPアドレス直打ちではなくホスト名で回避できるのではないか、という仮説から始まったのだった。
この仮説を実証するのは簡単で、IPアドレス直打ちで現象が再現するかの確認をすればいい。…のだけど、これやるとIPアドレス直打ちとホスト指定で別の資格情報を使ってアクセスすることになって、smbの制限で接続が切られちゃうんよね。こうなると復旧がめんどい。
余談だが、Windows端末から、対象機器がmDNS対応かどうかを確認する方法って何が正解なんですかね。
まず、nslookupはmDNS非対応だからNG。
pingやResolve-DnsNameは対応してるけど、クエリに"hoge"と入れるとNBTとLLMNRには"hoge"がそのまま渡り、mDNSには"hoge.local"が渡る。
クエリに"hoge.local"と入れるとNBTとmDNSには"hoge.local"がそのまま渡り、LLMNRには"hoge"が渡る。という仕様らしい。
これだとmDNSに対応してるか、してないかを判別する方法が無いように思う。
"hoge.local"というブロードキャストが飛んでることと、対象機器から応答があることを、パケットキャプチャして確かめるしかなくないです？
よく調べたら、LANDISKはSMB v3でもNBTが使われてた。
まあ、LLMNRをWindows以外でわざわざ実装することも無いか。それするくらいならmDNS対応するよな。
話を戻して、一般のご家庭ではsmb共有フォルダへの名前解決はどうしてるか、実態はこんな順かなぁ。
①IPアドレス直打ち
ていうか名前解決を諦めるパターン。クライアントがWindowsだと、更新日時書き換え問題などが起きうる。
②NBT（NetBIOS over TCP/IP）
クライアントWindows側で、今はデフォルト無効化されたSMB v1を有効化する必要があるが、逆にSMB v2以上非対応の古いNAS等だと、NBTは必ず使える筈なので、今でも結構使われているんじゃないか？
③LLMNR
ご家庭用のWindows対応を謳うNASだと最近はこれが主流か？NBTとLLMNRのどっちが有効化されるかは、SMBがv1か、v2/3かで自動的に変わるんじゃないかと思う。理屈的には名前解決をNBT、通信をSMB v3という組み合わせも成立はするけど。手持ちのLANDISKはv3有効化するとLLMNRで名前解決してるようだ。
④mDNS
mDNSだとクライアントはWindowsに限定されないし、こっちが主流かなぁ。ご家庭用のNASが全部mDNS対応してるのかはよくわからない。
⑤DNS
これは逸般の誤家庭か。.localドメインに所属したNASだとAndroid端末からアクセスできないなどの問題あり。
https://x.com/mutaguchi/status/1522523794883063808
そういえば、Androidから.localなドメイン内マシンにアクセスできない問題どうなったかな、と思って調べたら、
https://zenn.dev/seiichihorie/articles/20240917-android-mdns
https://support.google.com/pixelphone/thread/139593141/local-dns-resolution-suddenly-stopped-working
引き続きどうもなってなかった。
これは、mDNSと競合する、.localなドメイン名を付ける方が悪い、で片づけてもいい話ではあるんだが、そうは言っても.localドメインは現実に存在してるんだし、Androidの名前解決の実装の方で融通を効かせてくれてもいいんじゃないか？というのはある。
https://x.com/mutaguchi/status/1308143508977405952
>一般のご家庭でAndroidからNASとかの共有フォルダにsmbでアクセスするとき、名前解決をどうやってるのかはよく分からない。IPアドレス直指定なのですかね？
結局これだ。みんなIPアドレス直指定なんじゃないか、やっぱり。
というかもともとWindowsからNASやファイルサーバーにアクセスするとき、IPアドレスでアクセスすると、認証情報が保持されないとか無かったっけ。とにかく理由は忘れたけど、IPアドレス直打ちはトラブルの元だという記憶だけは昔からあるので、常にホスト名でアクセスしてるなぁ。
ホスト名でのアクセス、あるいはネットワークドライブ割り当てしてれば大丈夫なのかもしれないね。
IPアドレス直打ちでNASにアクセスして、知らないコンピュータからコピーしたファイルで信頼性が不明だから、Zone IDを付与し、ファイルの更新日時が変更される、という仕様は、まあまあ妥当である気もする。
https://x.com/izutorishima/status/1853655871257293035
これうちの環境では起きてないのよね。
24H2を入れたらこの仕様になるんだろうか？（でも当該KBは6月のだしなあ…）
