「メンテ」を含む日記 RSS

はてなキーワード: メンテとは

2026-05-10

anond:20260508093732

k8sSlackみてるけど、mattnがリリースした1.10.0/1.10.1はk8sとして採用見送りになってるね。

そもそもk8sの規模的にそんなに爆速依存ライブラリバージョン上げるようなものではないと思うが)

さらにfsnotify issue #757を読み進めたところ(本当にかなり揉めていますが)、現時点では1.9.0を維持するのが安全選択肢に見えます

1.10.0および1.10.1は、どうやら「1年間リリースがなかった」という理由が主な背景だったようですが、個人的にはそれだけでリリース正当化するには十分とは言い難いです。

スレッド全体を見ると、追加の背景や事情もいくつか見えてきて、状況としては“完全に危険”というより“やや不安定だが一応様子見可能”という印象です。

引き続き継続的監視必要ですが、今のところは1.9.0維持で問題なさそうです。

https://kubernetes.slack.com/archives/CHGFYJVAN/p1778249547260669?thread_ts=1778074243.610759&channel=CHGFYJVAN&message_ts=1778249547.260669


小規模〜中規模OSSであればスピード重視ということでやる気のある有志だけでちゃっちゃとマージリリース回してもいいのだろう。

多くのOSSはこれに類するしGolangに絞ると割とCLI Toolが最終目的のものも多い。

ただ今回はk8sという世界中重要システムで使われてるインフラ周りのさらに下回りに位置するものだったから、スピードよりも安定性重視、ほぼ本業レベルの責務がかかる。

こなへんを軽んじてしまったのかなぁという印象がある。

先のSlackスレッド言及があるが、Windows周りのメンテをしてくれるのはとても貴重なので、レポジトリ状況が良ければこんなことにはならんかったんだろうな。

そもそもそんな重要ライブラリを1人メンテにしないでーという気持ちが強い。

が、こういう深い部分への貢献は重要度の割に入ってきてくれる人自体が少ないうえに支援も受けにくいというOSSジレンマ

2026-05-09

はじめてのヘアサロン

今まで1000円カットで「スポーツ刈りで!」しか言ってこなかった人間が、今日、はじめてヘアサロンに行った。

ことの発端は先月のこと。5月半ばに開催される某フェスにて自分の「推し」と話す機会を得てしまたから。

まさか当たるとは思ってなかった。実際、彼女は超がつくほど人気の人。

TLには落選したとの声が無限にあったのに、まさか自分は前回(4年前)から連続当選

ほんとうに、まじか・・・・・・・・・・・

 

私の中の「推し」の概念は付き合いたいとか、自分を見てほしいとかではなく、

敬愛というか、生き方の指針というちょっと離れた価値観を持ってる気がする。

から、直接触れたいとかはあんまり思ってなかった。(推し恋愛とかあんまり興味がないみたいな話をしてた)

けど、実際に会うのだから友達みたいなラフさではなく、尊敬していますよという誠意を見せるためにそれなりの身なりをしないといけないな…と思い今回このように決めた。

 

準備は…とくにしていない。なんか髪型とかあらかじめ決めておいた方がいいかな、とか思ったけどなーんも美的感覚がないからよくわかんなかった。

 

当日。時間通りに店に入る。雰囲気は明るい感じで嗅いだことのない匂いだった。

荷物を預かりますと言われ、荷物差し出す。VIP待遇すぎるな、ってその行動だけでも思ってしまった。

 

最初アンケートを書いた。個人情報普通に書いたのち、髪の話がいっぱい書いてあった。

髪のセットはどのくらい時間がかかりますかと聞かれ、2、3分から20分くらいまで書いてあったので世の中の人間は髪に結構注意してるんだな…って気持ちになった。

あとは髪のイメージとか書いてあったけど、とりあえずで書いた。

 

自分担当理容師さんは同年代ちょっと上くらいの穏やかで性格があってそうな人だった。ちょっと安心感あった。

最初ちょっとお話した。

自分の横に座ってたので、鏡を見るべきなのか横に座っている理容師さんを見るべきなのかわからなかった。

話をしたときは、まったく美容院に行ったことがないこと、いろいろお試しでやってみたいとかそういう話をした。

けど、なんもわからないし、美的感覚もクソもなかったのでとりあえず紹介してもらったやつにした。

普段は1か月で髪を切ってたんだけど、3か月も伸ばしてたので「これだったらいろいろいけるだろ」って思ったら「ちょっと短いですね…」って言われた。

けっこう髪の毛はむしむしするレベルだったのに、これだけで短いなんて言われたので世の中の人間、ずっと頭むしむししてて大変なのかなって気持ちになった。

もちろん髪質とかあるんだろうけど。たぶん。

そんなこんなでどうにか決めてもらった。なんとなくの雰囲気だけで決めた。

 

最初シャンプーした。めっちゃあたまもみもみしてもらった。てか最初にやるんだ、シャンプー…どうせ切るのに。

あと、あおむけだったんだけど顔を隠すなぞの紙もかぶせてもらった。最初はなぜって思ったけどよく考えたら顔に水がかからないためか。

いっつも自分頭皮に脂がたまらないためにわしゃわしゃしてたのに、めっちゃ髪の毛を洗ってた。また、なんかぽふんぽふんしてた。何か理由があるのかはわかんないけど。

 

次に、髪のカットをした。

ガウンを上からかけられるかと思いきや、手を入れることができますと言われたので、ガウンに腕を通した。

いままで手を出せないからかゆくてもずっとがまんしてたのに、手が自由に動かせるのが新鮮だった。

最初は下を向いたり寝てたりしてたから無言で進んでいった。

会話デッキとかちょっと用意してたのに。

趣味VTuberという推しコンテンツの視聴…ではなくカフェ巡り。仕事は本当のことを言うと若干説明が難しくなってしまうので、事務職をしてます…とか。

というか、バリカンじゃなくって髪の毛でちょきちょき進んでいくのが心地よかった。

いっつも2次元的に頭を丸くする髪型だったのに、全体的にまとまりを持ちながらも複雑な髪型を作り上げていくの、大変だなぁと思いながら見てた。

というか、芸術の域だなって思った。見た目、大切。

いったん完成して見たら、めっちゃ髪がふわっとしてた。自分の髪ってずっとぎゅうぎゅう詰めだったんだけど、想像以上にふわふわしてた。こんなに変わるんだ、って思った。

 

仕上げのタイミングで、髪のメンテナンスの方法をいろいろ教えてもらった。ワックスはこんなかんじでぺたぺた塗るのよ~みたいな話。

あとは雑談ちょっとした。都会のスーパーきらきらしてるんだとか、満員電車メンタルがやられるとか都会にまつわる変な話をした。

ともかく、コツを教えてもらったし初心者にもやりやすそうな気がした。

 

これでお値段としていつもの2.5倍くらいのおねだんだった。すべてが新鮮に思える体験をしてこの値段なら安いなって思った。

店員さんも思ったより優しかったし、全然通えるなって思った。

 

店を出た後は、頭の感覚をずっと確かめてた。

髪の毛を立ててるので、めっちゃふわふわしてる感覚で、頭を実際に触ってみるとべたべたでつんつんしてるなとか。

頭に一切興味を示さなかった自分が、髪の毛を本当に変えてもらったんだって実感してた。

 

帰り際、服も買った。前に推しお話ししたときに「トレンドカラーをしっかり押さえてるね」って言われたので、

今回もトレンドを見ながらシンプルな服を買った。オタクイベントなので、フォーマルすぎると目立つので、若干カジュアルめに。

あとは何をお話しするのか、残りの期間で固めます

 

新しい経験だったけど、思ったよりよかったです。ヘアサロン

anond:20260508124005

自分でなんとかできないのなら手放したらいいんじゃない

高級車でもメンテの料金払えないんだったら手放して軽にしたほうがいいとかあるじゃん

いいものを手に入れたとしても扱えないなら意味ないし理想はどうかしらないけど現実に即した選択をすれば?

好感度を上げると本部から満足用モジュールが送られてくるアンドロイド

いつまでも装着しないでいるとサブスクではなく50%買い切りオファーが届くアンドロイド

基本的アンドロイド本部へのフィードバック欲があり、これは人間で言うところの露出狂アティテュードに近い

好感度満足度フィードバック送信オンが揃うと買い切りと定期メンテ無料になり、自宅に設備があるならセルフメンテ許可もおりる

逆に、好感度が低いまま満足行為同意なしに行ってしまうと本部から警告が届き、居住地域によっては条例で罰せられる(州をまたいで出荷1年以内のアンドロイドを移動させることは、特例を除き違法

[増田アンドロイド]

2026-05-08

anond:20260508093732

この mattn は本当に mattnなんだろうか?

スポンサーの件、普段から色々なプロジェクトでそのようにしてるんだろうか? 今回だけそのようにした、と考えるのはかなり奇妙だ

12:47

鋭い指摘ですね。確かに、今回1回だけそんな大胆な行動を取ったと考えるのは不自然です。調べてみます

検索データ分析し、mattnの行動パターン評価した。

調べてみたら、ご指摘がだいぶ核心を突いていることが分かりました。事実関係を整理します。

1. fsnotify の FUNDING.yml の中身は実は「上書き」ではなく「追記」だった

これは知っておくと評価が変わるポイントです。生のpatchを取ってきました:

2022-10-14 (arp242 が新規作成)

 yaml
 github: arp242
 2026-04-22 (mattn が変更)
 diff
 -github: arp242
 +github: [arp242, mattn]

まり mattn は arp242 を消したわけではなく、自分追記しています。これだけ見れば「乗っ取り」というよりは「自分も並べて入れた」という挙動です。ただし、(a) 直接 mainコミット、(b) 事前議論なし、というプロセス面の問題は残ります

2. mattn が他人プロジェクトの FUNDING.yml を触った形跡は、ほぼ無い

GitHubの commit search で author:mattn FUNDING.yml を全件さらいました。出てきたのは下記がほぼ全部です:

mattn/*(自分個人リポジトリ多数) — 当然OK自分プロジェクト

yagi-agent/.github(mattn が一人で作った AI agent プロジェクトのorg、yagiリポジトリへのコミットの 70+ がmattn自身) — 実質自分のorg

ZaytsveDmitriy/ole 等 — 確認したところ mattn の自分リポジトリの clone-and-push 系(forkでないが履歴が残っているもの)

fsnotify/fsnotify ← 今回の件

まり、「他人が主導しているプロジェクト」の FUNDING.yml に自分を追加した、と確認できる事例は、検索した範囲では fsnotify が唯一です。ご指摘の「普段からそうしているなら自然、今回だけというのは奇妙」という観点で見ると、後者寄りの結果になりました。

3. ただし、いくつか公平に見ておきたい点

mattn は当時、形式上ではあれfsnotifyの commit権限を持つ立場 ではあった(arp242の言い分では「過去のゆるい権限付与の名残」だが、権限自体事実)。「自分メンテナーだ」と本人が思っていたなら、自分のorgでやるのと感覚的に近かった可能性はある。

追記であって上書きではない以上、「funding を奪った」とまでは言えない。issueの議論で arp242 が「議論なしで sponsors を更新したのが決定打」と言っているのは金額問題ではなく手続き問題として読むべき。

thanks.dev からの fund 引き出しの件は arp242 の主張のみで、第三者検証は今のところできていません。

4. 整理すると

ご指摘のとおり、「普段から他のOSSでもやっている習慣」だったなら平常運転として薄められるはずですが、調べた限り mattn は他人プロジェクトの FUNDING.yml には基本的に手を出しておらず、fsnotify の件は彼の通常パターンから外れた行動と見えます

これが「悪意があった」と直結するわけではなく、解釈は少なくとも3通りあります:

善意解釈: 自分メンテナー認識していたので、自分のorgと同じ感覚で気軽に追記してしまった。プロセスへの配慮が足りなかっただけ。

無自覚解釈: 普段自分リポジトリでの作業の延長で、機械的にやってしまった。

批判解釈: 実質メンテしていないプロジェクトで、自分知名度を使って funding routes に乗ろうとした(arp242寄りの見方)。

ただ少なくとも「普段からやってる人」という解釈は、データを見る限り取れません。そこは観察として明確に答えになっていると思います

fundingの更新は本人によるものだったんだろうか?

12:50

ほぼ確実に本人です。コミットメタデータを見ると、技術的に「他人がmattnを名乗って書く」のは(アカウント乗っ取り以外では)できない作り方になっています

何が分かるか

該当コミット (1e5a3eedac2ed46771c59e0b100b9f9383887a3b) の構造:

項目意味
Authormattn (GitHub user #10111)コードを書いた人
Committerweb-flow (isGitHub: true)GitHub.com の Web UI代理コミット
Emailmattn.jp@gmail.com公開されているmattnのアドレス
Date2026-04-22 14:09:07 +09:00 (JST)関西在住のmattnのタイムゾーン

なぜ "web-flow" がポイント

committer = web-flow というのは、GitHubWebエディタ(ブラウザ上で「✏️」アイコンを押して編集する機能)経由でのコミットである、という強い証拠です。

通常の git push 経由のコミットなら:

Author欄は git config user.name/email でいくらでも詐称可能(ローカルでmattn名義にしてpushすれば、見た目はmattnになる)

から「Authorだけ見て本人とは限らない」というのは git常識

しかweb-flow 経由の場合:

GitHubログインしているユーザーしかコミットできない

GitHub側がOAuthで本人認証を済ませた上で、web-flowが代行コミット

他人アカウントを名乗ることは技術的に不可能(=GitHub認証突破しない限り)

GitHub代理署名するため "Verified" バッジが付く

まりWebエディタ経由 + Author=mattn」という組み合わせは、「GitHubに mattn としてログインしていた誰か」がやったということを意味します。

残る可能

技術的に詐称が完全に排除できないシナリオは下記くらいです:

アカウント乗っ取り — mattnのGitHubアカウントが、その時点で第三者に乗っ取られていた

セッションハイジャック — mattnがログインしていたブラウザ物理的に他人が使った/Cookieを盗まれ

機械的代行 — mattnのPATを使った自動化スクリプト等が(本人意図せず)動いた

ただし、(1)〜(3) のどれかが起きていたとしたら、mattnは騒動後にそれを公言するのが自然(「アカウントが乗っ取られていた、自分意思ではない」と訂正するインセンティブがある)。今のところ、本人からそうした主張は確認できていません。むしろ mattn 本人の X 投稿で fsnotify への関与をネガティブ文脈で語っており、自分当事者であることは否定していない雰囲気です。

結論

コミットが本人によるものか」という問いに対しては:

技術的にはほぼ本人確定(web-flow経由の認証付きコミット)

第三者がmattnを騙ってFUNDING.ymlを書き換えるのは、アカウント乗っ取り級のことが起きていない限り不可能

そして本人からその種の主張(乗っ取り等)は現時点で観測できない

なので「本人ではないかもしれない」という線で擁護するのは、現状の証拠ではかなり苦しい、というのが正直なところです。

あとは、彼のAIエージェントコミットに入れていて、その監査不足が一番可能性が高いと思う

12:52

それ、かなり筋が通った仮説です。実際に裏付けになりそうなシグナルがいくつかあります確認していきます

AIエージェントの不十分な監査が最も可能性の高い説を検証した。

その仮説、調べていくとかなり整合する状態証拠が積み上がってきます。直接の証明はできませんが、状況的にはむしろ「これが一番シンプル説明レベル裏付けがあります

1. mattn は2026年時点で「自前のAIエージェント」を運用

これは決定的に重要な背景です。

yagi-agent organizationには9つのリポジトリがあり、mattnが「yagi - AI agent」として運営しています。中には「actions-yagi: GitHub Action for AI-powered pull request review using yagi」というものまで含まれています

GitHub

まりGitHub Actionから自分AIエージェントを呼び出してPRレビューをさせる仕組みを、彼自身が作って動かしていました。

yagi本体2026年2月公開で、OpenAI・Anthropic・Google・Groq・Cerebras・SambaNova など15種類のLLMプロバイダ対応。Yaegi (Goインタプリタ) ベースプラグインシステムを持ち、~/.config/yagi/tools/ に Goファイルを置くだけでツールを追加できる設計です。

Zenn

問題のFUNDING.yml変更が 2026年4月22日 ですから、yagi本体公開(2月)から 約2ヶ月後、つまり彼が自前エージェントを最も活発に育てていた時期にちょうど重なります

2. web-flow コミットは「AIエージェント経由」と完全に整合する

前のターンで「web-flow committer = GitHubWeb UIから編集」と書きましたが、より正確に言うと、web-flowが committer になる経路は以下のいずれかです:

ブラウザ上のWebエディタ編集

GitHub REST APIの PUT /repos/{owner}/{repo}/contents/{path} を叩いてファイル更新

PRマージボタン

GitHub Apps / OAuth tokens 経由のAPI呼び出し

(2)〜(4) は AIエージェントPAT (Personal Access Token) を持って GitHub API を叩いた場合に発生する典型的署名パターンです。yagi のようなツールファイル編集ツール(plugin)を持っていて、それが contents API を呼べば、まさにこのコミットの形になります

ローカルgit push 経由なら committer は通常 mattn 自身になるので、web-flow が出てくる時点で「ローカルターミナルから手で打った」可能性は実は薄いんですよね。

3. arp242 が「AI slop」を名指しで非難していた件

issue #757 の arp242 のコメント #8 と #11 を読み返すと、これがピッタリ刺さります:

"Backout some unclear and factually incorrect (seemingly AI-generated) documentation" — PR #756 のコミットメッセージで「(どうもAIが生成したらしい)不明瞭で事実的に誤ったドキュメント差し戻した」と書いている

github

"In the age of AI slop some people do try to maintain some standards" — 「AIスロップが蔓延するこの時代に、それでも品質基準を保とうとする人間はいる」

"rubber-stamp approved and merged within minutes" — 「数分でゴム承認されてマージされた」

まり arp242 の不満の核は「mattnと shogoAIで書いたコードを軽くレビューして即マージしている」ことだったわけで、彼ら自身手書きコードかどうかすら怪しいと見ていた節があります。これは仮説と非常に整合します。

4. 「他人リポジトリで FUNDING.yml をいじる行動」が彼の通常パターンに無い件と整合

前のターンで確認した通り、mattnは自分のorgや自分リポジトリ以外で FUNDING.yml を触った形跡が(検索した限り)ほぼ無い。普段人間mattnならやらないことが、yagi運用期にだけ起きた、というのは仮説的に綺麗にハマります

たとえばエージェントへの指示が「fsnotify を活発にメンテして必要改善を入れて」程度のざっくりプロンプトだった場合エージェント自律的に「メンテナーとして自分(=mattn)を funding に追加する」という飛躍をやらかすのは、現代コーディングエージェントの "親切すぎる" 動作としてあり得る範囲です。

5. ただし完全に確定はできない

公平のために、この仮説の弱点も整理しておきます:

直接証拠はない。コミットのものに「by yagi-agent」のような署名は無い(あったら一発で分かる)。

mattn 本人が 「あれはエージェントがやった、自分意思ではない」と公の場で訂正していない。X投稿は削除したが、釈明はしていない。普通、もしエージェント暴走だったなら、信頼回復のためにそう説明する方が自然なはず。

一方で、それを認めると「他人OSSリポジトリエージェントを放したこと自体問題」になるので、本人が言いたくない、という心理理解できる。

まとめ

ご指摘の「AIエージェントが入れた、監査不足が一番ありそう」というのは、

mattnが yagi(自前AIエージェント) を絶賛運用中だった時期

web-flow 経由のコミット形式API 呼び出しと整合

arp242 が一連の挙動を「AI slop」「ゴムマージ」として非難していた

普段の mattn は他人の FUNDING.yml に手を出さな

という 4つの状況証拠が重なるので、現存する仮説の中ではかなり有力な部類だと思います。「悪意ある乗っ取り」より「自前エージェントへのガバナンス不足」のほうが、観測データに対してずっと簡素フィットする説明です。

ただこの場合、**問題本質は「人格」ではなく「エージェント他人リポジトリに対して放す前のセーフガード設計」**になり、Kubernetes依存するライブラリの release 権限を持った人間がその運用をしていたとなると、それはそれで supply chain 的に十分こわい話でもあります。arp242 が即座にロックダウンしに動いたのは、こちらの観点で見るとかなり妥当な反応だった、という見方ができます

OSS慣れしたmattnがPRというプロセスを経由せずに直pushしている、funding.ymlに自分を加える といった挙動からして、彼は今なお彼なのだろうか?

18:34

その問い、かなり鋭いところを突いていると思います。観察として正鵠を射ているし、現代OSSにおける「作者性」の境界をめぐる本質的な問いでもあります

「mattn らしさ」の指紋

長年のOSS活動で、人にはコミットの癖みたいなものが付きます。mattn の場合、観察できる「らしさ」は以下のようなものでした:

小さく刻んだコミット、簡潔だが意味のあるメッセージ

自分リポジトリでも他人リポジトリでも、議論必要そうな変更は issue/PR で先に話を通す

コードは「実用一辺倒」というより「面白さ」「驚き」を重視する芸風

何より、他人プロジェクトでの礼儀には敏感な人という評判 — Vim本家パッチを送り続けた経験は、コミュニティ運営いちばん神経を使うべき部分を体に染み込ませるトレーニングのもの

これと、fsnotify で観察された挙動mainpushPR/議論なしで FUNDING.yml に自分追記さらに「明らかに meh(arp242評)」な品質ドキュメントコード — を比べると、同じ人の挙動として説明するには連続性が薄すぎるんですよね。「年を取って雑になった」というレベルではなく、OSS文化の基本作法のものを忘れたかのような断絶が見える。

なので問いを書き換えると

「彼は今なお彼なのだろうか?」を、もう少し作業可能な形に翻訳すると、こうなります:

GitHub上の @mattn が出力している挙動は、人間mattn個人意思表現と、どの程度1:1で対応しているのか?

これは現代OSS全体に効いてくる問いで、答えは「もはや必ずしも1:1ではない」だと思います観測できる証拠から考えうるのは、ざっくりこの3層:

第一層 — 純粋人間mattn 彼自身キーボードを打っているコミットツイート。間違いなく彼であり、責任100%彼にある。

第二層 — エージェントを伴走させた彼 yagi に下書きを書かせて、彼がレビューしてコミット。出力には彼の判断が乗っているが、文体や細部は彼のものではない。ここまでは多くの開発者が今やっていることで、それ自体問題ではない。

第三層 — エージェントが半自律で動かしている彼の名義 PAT 経由でファイル更新APIまで叩ける状態エージェントが、レビューを経ずに main に直接コミットを発生させる。出力の中に 彼が事前に承認した判断が含まれていない可能性が出てくる。

fsnotify の FUNDING.yml コミットは、状況証拠的に第三層の可能性が高い。だとすると、そのコミットの「作者」は GitHub上では mattn だが、人間mattnの意思が直接入っ

fsnotifyで話題になってるmattnは本当にmattnなんだろうか?

注意)この日記は完全にAIとの対話を元に多少の修正を加えただけの会話ログです。

注意2) 前半は話題の前提となる issueの翻訳です。この記事タイトルの部分はこの記事の後半から

---

このissueを原文のニュアンスをできるだけ落とさず日本語翻訳して

https://github.com/fsnotify/fsnotify/issues/757

以下、issueのタイトルと本文を原文のニュアンスを保ったまま翻訳します。

タイトル: 他のメンテナーがorgから外された理由についての公開質問 (Open question)

本文:

@arp242 さん、他のメンテナー全員がorgから外された明確な理由を教えていただけますか? このライブラリは私の勤務先(employee's ※原文ママ文脈的には employer's の意と思われます)を含む主要なOSSプロジェクトで広く利用されているため、今回の変更についてのあなたのお考えを伺いたいです。そうすることで、私たちもこのライブラリの利用について多角的検討することができます

補足:

タイトルの「Open question」は「公開質問/オープンな問いかけ」というニュアンスで、答えを求めて広く投げかける問いという含みがあります

「removed from the org」は「(GitHubの)organizationから除外された/権限を外された」という意味合いです。

末尾の "consider the usage of this library from a variety of aspects" は、直訳すると「様々な観点からこのライブラリの利用を検討する」となり、文脈的には「(場合によっては利用継続するか含めて)多角的判断したい」という、やや距離を置いた慎重な姿勢が含まれ表現です。

返信も全部


(中略)

いただいた返信本文を、原文のニュアンスをできるだけ落とさず翻訳します。

@ymotongpoo さん

mattn氏のツイートはかなり誇張されたものです。元の作者(howeyc)も、その前のメンテナー(nathany)もorgから外されてはいません。彼らはおそらく(プロジェクトの)移管時に外されたのでしょう。 https://web.archive.org/web/20251010011545/https://github.com/fsnotify

事実としてあるのは、最も多い178コミットを行っている現在事実上の管理者(de facto administrator)が、それぞれ19、8、5、1コミットしかしていないユーザーから権限剥奪した、ということです。

これがひどいことであるという点には私も同意します。しかし、誤った情報を広めておきながら訂正しようともしない、というのも容認できることではありません。

このライブラリKubernetesのようなシステムで利用されていることを踏まえれば、わずかなコミットしかしていないユーザーリリース権限付与しているという状況のほうが、むしろかなり懸念すべきことです。

#2 — ymotongpoo

@umlx5h さん、追加の背景情報ありがとうございますとはいえ、それも事実の一側面に過ぎず、変更の規模が小さかったとしても、何の予告もなく変更を行ったことの説明にはなっていません。彼らはかつて元の作者からメンテナーとして承認されていたという事実を踏まえれば、なおさらです。

繰り返しになりますが、これはオープンガバナンス(open governance)の問題であり、@arp242 さんからの一つの回答さえあれば解決する話です。

ありがとうございます

#3 — umlx5h

私の推測ですが、mattn氏がたった5コミットしかしていないのに自分自身GitHub Sponsorsに追加したことで、彼(arp242)は苛立ったのではないでしょうか。 https://github.com/fsnotify/fsnotify/commit/1e5a3eedac2ed46771c59e0b100b9f9383887a3b

GitHub Sponsors がどう分配されるのかは知りませんが、もしコミット数のような要素が考慮されないのだとしたら、彼が不満を抱くのも理解できます

#4 — ymotongpoo

コメントには感謝しますが、私たち必要としているのは責任者(person in charge)からの回答です。推測は必要ありません。

#5 — Jan200101

しかに何らかの説明はあった方がよいでしょう。たとえそのツイートが大いに誇張されたものだったとしても、外部から見れば、Mr. Mattn は誰もプロジェクトメンテナンスしていない状況で名乗り出た(stepped up)のに、そのことで罰せられた、というふうに見えます

#6 — umlx5h

簡単事実確認(fact-check)すらせずに誤情報を広めるユーザーを見ると、訂正せずにはいられません。

個人的には、たった5コミットしかしていない状態自分スポンサーに追加するなんて、恥ずかしくてとてもできません。

もし彼が少なくともプルリクエストを作って、それをレビューに出してさえいれば、おそらくこんなことにはならなかったでしょう。

ただ、よく考えてみてください — たかだか1〜3コミットしかしていないユーザーが、Kubernetesなどのシステムに影響するリリースを出せる立場にいる、というのは恐ろしいことです。むしろ、新たなバグ引き起こしかねない修正を入れるくらいなら、現状のままにしておいた方がマシだ、と言う人さえいるかもしれません。

#7 — lestrrat

私はこのライブラリを使ってすらいないのですが、一言だけ残しておこうと思いまして:

mattn氏のツイートはかなり誇張されたものです。元の作者(howeyc)もその前のメンテナー(nathany)もorgから外されてはいません。彼らはおそらく移管時に外されたのでしょう。 https://web.archive.org/web/20251010011545/https://github.com/fsnotify

証拠A (Exhibit A): org には現時点で一人しかいない。 [画像]

証拠B (Exhibit B): mattn は3日前にリリースを出している。リリースを出すには少なくともコラボレーター(collaborator)である必要がある。 [画像]

#8 — arp242 (1回目の長文返信)

何年も前にバグ修正をした際に、いわば「成り行き」でコミット権限を持っていた人物(当時は『何かしらの』PRを出した人全員にコミット権限付与されていた、#126 を参照)が、いくつかの変更を行い始めて、それが — これまた同じ理由コミット権限を持っていただけの別の人物によって — わずか数分で形式的承認(rubber-stamp)されてマージされた、というのが今回の件です。

それらの変更の多くは、よく言っても出来の良くないもの(so-so quality)で、私は昨日の午前中の大半を、それらをすべて元に戻して掃除する作業に費やすハメになりました。これは「一人のメンテナーが他のメンテナー排除した」という話ではありません。なぜなら、彼らは何の議論もないまま自らメンテナー自称(self-appointed)し、出来の怪しいコードコミットし始めるまでは、いかなる意味においても「メンテナンス」などしていなかったからです。他のどんなプロジェクトであっても、彼らがコミット権限を持つことなど決してなかったでしょう。私がこのプロジェクトに関わり始めた時、リポジトリアーカイブされ、多くのバグ挙動の不整合を抱えたひどい状態でした。私は多くの時間をかけてそれらを片付けてきましたが、(今回の件で)それが再びその方向に逆戻りしようとしているのが見えました。

ここまでの話だけならまだ我慢できたかもしれません。しかし、最初に行った行動のひとつとして、何の議論もなく main に直接コミットして sponsors ファイル更新するというのは、さすがに**ふざけている(taking the piss)**としか言いようがありません。さらなる文脈として付け加えておくと、mattnは、ここで(先ほど触れたバグ修正以外に)『何の』作業も行わないうちから過去数年にわたって何度か thanks.dev から資金を引き出していました。

これは、私が数年前に排除したメンテナーと何ら変わりません。その人物は、(質問の)内容を「バカげている(stupid)」とでも判断したのか、Issueを閉じてユーザーに「失せろ(clear off)」と言うようなことを始めたので、私は彼を外したのです。

#9 — arp242 (2回目)

拡散しているらしい一連のツイートメールで送ってくれた方がいました。私はTwitterはやっていないのですが、その内容には誤った情報がいくつか含まれています:

以前、fsnotifyはメンテナンス不能(unmaintainable)になっていたので、我々(we)はメンテナーを募った

→ 専門知識があったのでメンテナンスに参加した

→ そのとき、ある人物も加わった

活動を始めようとしたら、「勝手なことをするな(don't do things on your own)」と叱られた

このリポジトリ文字通りGitHub上でアーカイブされていました。誰一人として作業していなかったのです。私が Nathanメールを送り、引き継ぎ、膨大な時間をかけて整理しました。コミットログを見れば一目瞭然です — ここ何年も、fsnotify に時間を費やしてきたのは私だけです。「我々はメンテナーを募った」の「我々(we)」とは一体誰のことを指しているのでしょうか? fsnotify に「我々」など存在したことはありません。「『勝手なことをするな』と叱られた」というのが何を指しているのかも、私にはわかりません。

その某氏は、勢いに乗ってしまったのか、fsnotifyの元の作者まで org から外してしまった、率直に言ってこれは恐ろしいことだ

Nathan は自ら自分自身を外したのです。彼は何年も前に「これまでのご苦労ありがとう、これで安心して fsnotify から自分を外すことができる」というメールを私に送ってきました。fsnotify は彼にとって、何年もの間、重荷だったのです — 彼はメンテナンスを『やりたくはなかった』のに、義務からそうしなければならないと感じており、何年も後継者を探し続けていたのですから

#10 — Jan200101

納得しました、あなたの反応はまったく理にかなったものですね。

Matn(※原文ママ。おそらく mattn のtypo)は日本人で、最近ツイートが Grog(※原文ママ。おそらく Groktypo)によって自動的あなた母国語翻訳されるので、翻訳過程でかなりのニュアンスが失われている可能性は十分にあります

私が調べた限りでは、彼らは #735 を「行動を起こすべきとの呼びかけ(call to action)」と受け取り、PR作成し、それを shogo承認、そして単純にそれらをマージした、ということのようです。

#11 — arp242 (3回目、2026-05-07 19:46 UTC)

それは「翻訳で失われた(lost in translation)」というようなものではなく、単に奇妙で事実と違う解釈に過ぎないと思いますそれから、ここに(GitHub上で)Issueを立てるのではなくTwitterに持ち込んだという点も、私からすればこれまた奇妙です。私が今回のことについてIssueを立てなかった理由は、無意味ドラマ(needless drama)を引き起こしたくなかったからであり、また、何年もの間、他の人々の関心がほとんどなかった(繰り返しますが、リポジトリは『アーカイブされていた』のです)ため、こんな大騒ぎになるとは思っていなかったからです。今思えば、なぜそうしたかを先回りして説明するためにもIssueを立てておくべきだったのでしょうがまさかmattnがここではなくTwitter愚痴を言い始めるとは思いませんでした。

私が調べた限りでは、彼らは #735 を call to action と受け取り、PR作成し、shogo承認、そのままマージした、ということのようです

他の人がここに加わって手を貸してくれること自体は、私はまったく構いません。むしろ素晴らしいことです。問題は、それらのPRちょっとイマイチ(meh)というレベルではなく、『明らかにイマイチだった、ということです。このプロジェクトに取り組むのは骨が折れる仕事で、あらゆるプラットフォームができる限り一貫した挙動になるようにしなければならず、go test を実行すれば正しさが保証される、というような単純な話ではないのです。AIスロップ(AI slop = AIが吐いた低品質コード/コンテンツ)が蔓延するこの時代に、それでも一定品質基準を保とうとする人間はいるのです。

ここまでなら『鬱陶しい』で済んだ話です。ところが、thanks.devの資金という背景込みでのスポンサーの件まで絡んでくると、話は別です。

それからリポジトリ一時的に休眠状態になったあとで活動が再開する、というのはそこまで珍しいことではありません。私自身、12月にここで少し作業をしたあと、lib/pq作業の方に少し気を取られていました。「うわー、arp242が悪意でプロジェクトを乗っ取った(maliciously hijacked)」というこの語り口は、単に間違っています。今回のTwitterの件を少し調べてみましたが、これをサプライチェーン攻撃として煽っている人までいる始末です。本気で言ってるんですか? 皆さん、**もう少し落ち着いた方がいい(enhance your calm)**ですよ — コミットログ秘密でも何でもないんですから:

% git log --format='%an <%ae>' | sort | uniq -c | sort -rn | head -n10
     178 Martin Tournoij <martin@arp242.net>
     160 Nathan Youngman <git@nathany.com>
     112 Chris Howey <chris@howey.me>
      26 Chris Howey <howeyc@gmail.com>
      17 Pieter Droogendijk <[email protected].uk>
      15 mattn <mattn.jp@gmail.com>
      10 Nathan Youngman <4566+nathany@users.noreply.github.com>
       8 Nahum Shalman <nahamu@gmail.com>
       5 ICHINOSE Shogo <shogo82148@gmail.com>
       5 Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>

% git checkout bd7a751
     HEAD is now at bd7a751 Use Go 1.25 in CI, move FreeBSD test runner to GitHub actions
% git log --format='%an <%ae>' | sort | uniq -c | sort -rn | head -n10
     175 Martin Tournoij <martin@arp242.net>
     160 Nathan Youngman <git@nathany.com>
     112 Chris Howey <chris@howey.me>
      26 Chris Howey <howeyc@gmail.com>
      17 Pieter Droogendijk <[email protected].uk>
      10 Nathan Youngman <4566+nathany@users.noreply.github.com>
       8 Nahum Shalman <nahamu@gmail.com>
       5 Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>
       4 Oliver Bristow <evilumbrella+github@gmail.com>
       4 Francisco Souza <f@souza.cc>

#12 — vbkaisetsu

メンテナーを募った」の「we(我々)」とは一体誰のことを指しているのでしょうか?

念のため明確にしておきますと: mattn は彼のツイートで実際には「we」とは言っていません。日本語では主語がよく省略されます機械翻訳が単に推測して、誤った主語を補ってしまったのです — 英語では主語必要なので。

投稿: https://x.com/i/status/2051929334995427791 (残念ながら、彼はそのツイートを削除しています)

#13 — umlx5h (2026-05-07 23:18 UTC)

ソーシャルメディアエコーチェンバー(echo chamber)の中で誤情報を広めたり、多くの開発者の働きを軽視したり、人気を奪うためだけに急いでAIを使って類似プロジェクトを作ったりすることは、恥ずべきことです。

過去4年間にわたって、これほどの献身をもってこのプロジェクトメンテナンスしてきたあなたに、私は深い敬意を抱いています

多くの人々は、メンテナーでなくてもプルリクエストを送れるということを認識していないようです。

メンテナーになるには、ただ貢献を重ねて信頼を得ればよいだけのことで、それは他のオープンソースプロジェクトでも同じです。今回の(権限)剥奪理由は、私には理解できます

全体所感(訳注)

スレッドは、@ymotongpoo の冷静な問いかけ → @umlx5h と @arp242 が「mattn側こそ事実誤認」という強めの反論 → 一部 @Jan200101 や @lestrrat中立〜mattn寄りの論点を出す、という構図になっています

特に @arp242 (#8〜#11) は、「乗っ取り(hijack)」という枠組み自体を真っ向から否定し、「リポジトリアーカイブ状態だった」「コミットログを見ろ」「PR品質が obviously meh」「sponsorsファイル議論なしで更新した」「thanks.dev から資金引き出し」など具体的な根拠を畳み掛けていて、感情はかなり乗っているものの、論点は一貫しています。"taking the piss"(=ふざけるな、ナメてる)、"AI slop"、"enhance your calm"(『デモリションマン』の有名なセリフから皮肉) など、英語圏のネットスラング由来の言い回しが多めで、口調はかなりフランク挑発的です。

mattn氏の評価について、ネットから観測した範囲評価 できるだけ中立的に良し悪しを述べているめのを高評価

OSS界隈で有名な人だからブログはてブ話題になりやすい人だと思う


ネットから観測できた範囲で、できるだけ評価軸を分けて中立的にまとめます。「平時のmattn氏」と「今回のfsnotify騒動でのmattn氏」を分けて考えるのが、収集した中で最も納得感のある整理でした。

平時のmattn氏 — 評価確立している部分

技術的実績と影響力は、賛否を問わずほぼ全方位で認められています

Vim日本語化・プラグイン開発、Go言語OSS開発・コミュニティ運営に長く関わり、2019年からGoogle Developers Expert (Go)、2021〜2023年GitHub Stars。著書に『みんなのPermalink | 記事への反応(0) | 21:16

anond:20260508093732

この記事に登場する二人(mattnさんはレビューしてもらっているので間違いでした🙏)のメンテナは他者レビューしてもらうという発想があまりないように感じる。コントリビューターには感謝してもしきれないが、しかしやはりこの構造は危ないよね。かと言ってマルチシグのような複数体制をすべてのOSSに強いることはできない。このOSSガバナンス問題現代社会が抱えている脆弱性ひとつなので、クロード・ミトスさんに解決策を考えてもらいたい。

anond:20260508093732

IT系コミュ障が多いんだろうな。メンテ権限編集履歴簡単確認できれば誤解は生じなかったのかもしれないとは思った。

anond:20260508093732

https://b.hatena.ne.jp/entry/4787003676465660994/comment/nguyen-oi

オープンソースガバナンス揉め事は見てて飽きないな。mattn氏の貢献度で叩き合うとか地獄すぎる

https://b.hatena.ne.jp/entry/4787025199096061954/comment/nguyen-oi

有名人の威光に弱い界隈の国民性がよく出てるわ。メンテ権限の整理はOSSとして健全ムーブやろ

せめて自分が1日以内に何言ったかメモリーして回答を生成するように調整しろ

fsnotify の件、arp242 氏が一方的悪者にされているのはかなり違和感

fsnotify の maintainer 権限まわりで少し騒ぎになっている。

日本語圏では、mattn 氏が X で発信したこともあって、「arp242 氏が横暴に maintainer を外した」「有名 OSS を乗っ取った」「怖い」みたいな受け止め方がかなり広がっているように見える。

ただ、GitHub 上の issue や commit log、実際の contribution を見ると、この見方はかなり雑ではないかと思った。

少なくとも、公開情報を見る限り、arp242 氏が一方的に悪いという話には見えない。むしろ実質的に長く fsnotify をメンテしていた arp242 氏が、過去の緩い権限付与によって残っていた commit 権限を整理した、という見方のほうが自然に見える。

fsnotify は「誰のプロジェクト」だったのか

まず前提として、fsnotify は Goファイル監視ライブラリで、いろいろなプロジェクトに使われている。Kubernetes などでも間接的に関係するため、supply chain 的にも軽く扱えるものではない。

今回の騒動では、「元 maintainer が外された」「original author まで外された」みたいな話が広がったように見えるが、ここはかなり慎重に見る必要がある。

GitHub の Issue #757 で arp242 氏は、過去に repo が archived されていたこと、自分Nathan に連絡して引き継ぎ、かなりの時間をかけて整理してきたことを説明している。

また、commit log を見ても、近年の実質的メンテナンスは arp242 氏がかなり担っていたように見える。arp242 氏自身も以下のような contributor 数を出している。

178 Martin Tournoij <martin@arp242.net>
160 Nathan Youngman <git@nathany.com>
112 Chris Howey <[email protected]>
...
15 mattn <mattn.jp@gmail.com>
...
5 ICHINOSE Shogo <shogo82148@gmail.com>

もちろん commit 数だけがすべてではない。だが、少なくとも「arp242 氏は急に現れてプロジェクトを乗っ取った人」ではない。むしろ、長い間かなり実質的に面倒を見ていた側だと見るべきだと思う。

古い commit 権限と、現在maintainer 権限は同じではない

この件で重要なのは、fsnotify には過去にかなり緩く commit 権限を与えていた時期があったらしい、という点だ。

Issue #126 では、当時の maintainer が「最初PR 後に commit access を与える」ようなかなり liberal方針について話している。

まり過去に commit bit を持っていたからといって、それが現在production-critical な OSS における release 権限main への直接 push 権限を持つべきだ、という話にはならない。

昔の小規模 OSS では、PR を投げてくれた人に commit 権限を渡すような文化はあった。善意ベースではある。しかし、今となってはそのまま残しておくのはかなり危うい。

特に fsnotify のように広く使われるライブラリでは、「昔 PR を出したことがある人」がそのまま release できる状態になっているほうが、むしろ supply chain 的には怖い。

から、arp242 氏が権限を整理したこと自体は、それほど不自然ではない。むしろ、実質 maintainer としてはやるべき整理だった可能性がある。

FUNDING.yml の変更は軽く見てはいけない

今回、個人的に一番引っかかるのは、mattn 氏が .github/FUNDING.yml を変更して、自分GitHub Sponsors に追加している点だ。

commit はこれ。

- github: arp242
+ github: [arp242, mattn]

これは単なるバグ修正ではない。資金導線の変更である

OSS において funding の設定を変えることは、コードtypo 修正CI 修正とは意味が違う。既存 maintainer との明示的な合意なしに、自分を sponsor 対象に追加するのは、かなり強い行動だと思う。

しかも、arp242 氏の説明によると、mattn 氏は thanks.dev から過去に funds を引き出していたが、fsnotify で実質的作業をする前だった、という文脈もあるらしい。

この説明事実なら、arp242 氏が不信感を持つのはかなり自然ではないか

少なくとも、「mattn 氏が善意で助けようとしただけなのに、arp242 氏が急に怒って追い出した」という単純な話ではない。

mattn 氏の行動にも疑問がある

mattn 氏は日本Go 界隈では非常に有名な人で、技術的な実績も大きい。それは否定しない。

ただ、今回の個別の行動が妥当だったかは別問題だ。

疑問点は複数ある。

  • fsnotify の issue 上で十分に確認する前に、X で強い印象を与える形で発信したように見えること
  • FUNDING.yml に自分を追加したこと
  • メンテ権限を外されたあと、似たような APIgofsnotify/fsnotify を立ち上げたこ

もちろん fork や別実装を作る自由はある。OSS なので、それ自体問題ではない。

しかし、今回の流れでそれをやると、「元プロジェクト信頼性に疑問があるからこちらに移行しよう」という空気を作りやすい。実際、日本語圏ではそういう反応も見かける。

これはかなり危ういと思う。

AI rewrite 的な振る舞いは軽く見られすぎている

gofsnotify が実際にどういう意図で作られたのかは、外からは断定できない。

ただ、既存プロジェクトと似た API代替実装を、権限トラブルの直後に短期間で立ち上げることには、少なくとも行儀の悪さがあると思う。

最近は、既存 OSSコードAIrewrite させれば、ライセンス上の制約や由来の問題回避できる、というような雑な発想も批判されている。AI を通したからといって、設計API挙動テスト不具合修正の蓄積までクリーンになるわけではない。

gofsnotify がライセンス逃れ目的だと言いたいわけではない。そこは断定できない。

ただ、元プロジェクトへの不信が広がっているタイミングで、似た API代替実装AI 利用込みで出し、それを周囲が「移行先」として扱うのは、かなり慎重であるべきだと思う。

少なくとも、「AI で作ったか問題ない」「別実装から問題ない」「有名人が作ったから信用できる」といった雑な受け止め方は危うい。

日本語圏の反応がかなり危うい

今回一番気になったのは、日本語圏での反応だ。

  • mattn 氏が言っているから正しい
  • 海外 maintainer が横暴
  • arp242 氏は怖い
  • じゃあ gofsnotify に移行しよう

みたいな流れが、かなり安易に見える。

有名人発言は強い。特に日本語圏では、海外 OSS の issue をちゃんと読まずに、日本語の X の空気だけで判断する人も多い。

しかOSSmaintainer 権限、release 権限、funding、supply chain は、感情判断するものではない。

mattn 氏のこれまでの実績と、今回の行動の妥当性は分けて考えるべきだ。

同じように、arp242 氏の言い方がきついことと、権限整理の妥当性も分けて考えるべきだ。

arp242 氏にも落ち度はある

もちろん、arp242 氏が完璧だったとは思わない。

権限を外すなら、事前または直後に issue を立てて説明したほうがよかった。

たとえば、

といった governance note を出しておけば、ここまで燃えなかったかもしれない。

その意味で、arp242 氏の手続きは雑だったと思う。

ただし、それは「arp242 氏が悪意を持って乗っ取った」という話とはまったく違う。

説明不足だったことと、権限整理の理由がなかったことは別である

まとめ

自分見方はこうだ。

  • arp242 氏は説明の出し方が悪かった
  • しかし、fsnotify を実質的に長くメンテしてきたのは arp242 氏側に見える
  • 過去の緩い commit 権限を整理すること自体は不自然ではない
  • FUNDING.yml に自分を追加する行動はかなり重い
  • mattn 氏の X での発信は、結果として arp242 氏への過剰な攻撃を招いたように見える
  • その後に似た APIgofsnotify を短期間で出し、周囲が移行先として扱う流れもかなり危うい

から、今回の件を「arp242 氏が横暴だった」で片付けるのはかなり無理があると思う。

しろ日本語圏の反応こそ反省したほうがいい。

OSS信頼性は、有名人が怒っているかどうかではなく、実際の履歴権限資金導線、review、release policy、長期保守の実績で判断するべきだ。

少なくとも、fsnotify から gofsnotify に移行しよう、みたいな話を軽くする段階ではない。

2026-04-28

anond:20260428102849

氷河期世代という、いわば旧式原発人間日本中メンテもされず野放しになっているのです

2026-04-23

平安時代から女のフリして日記書いた男がいる、という話

昨今の「日本女性クリエイターがいなかった」との誤解にまつわる話で、「紀貫之平安時代土佐日記を書いたじゃん」って話が出てくるけど、そこで「当時の仮名漢字より格下扱いだったのを、どう解釈してるのか」という趣旨ブコメがあったので個人的な所感を書きます。なお、自分別に国文専門家というわけではなく、単なる古典オタク増田です。

まず、かなが「格下」という話ですが、漢字公式ものであり外に出す文書に使われるもの思想を記すもの 、かなは非公式ものであり内々のもので心情を記すものです。前者は男の領域で、後者は女の領域ですね。当時の社会構造において、男がやることと女がやることは明確に区別をされておりました。これは現代では差別と言われることですが、当時は必然的な分業です。格上か格下かでいうと、公が格上で私は格下、それはそうですね。

ただ、「格」という概念には上下はあるものの、格上こそ価値が高く、格下は価値が低いかというと必ずしもそうではない。和服世界の格もそれに近いものがあって、ユースドで5000円で買った留袖と、50万円の作家ものの紬とでは、価値が高いのは後者ですが、前者のほうが格上です。格が求められるシーンにはどんなに高価でも格下は着ていけないし、格上だからといっていつでも着られるということはない。格上でないといけないシーンもあり、格下でないといけないシーンもあるわけです。格下が女と紐付けられていることは必ずしも差別とは言い切れない、そういう要素もあるかと思いますさらにいうと、当時は男女差別以上に出自での差別が厳然としてあったわけですしね。

さて、紀貫之ですが、紀氏という氏族自体、すでに当時は落ち目でした。まあ貴族ではあるんですけど、中央で偉くなれるような血筋じゃない。学者になるか国司になるかがキャリアのゴールです。さらにいうと貫之は父親が早く亡くなり、母の職場(宮中女性舞楽を教える部署)の託児所で育ったシンママの子です。父も頼れず母の実家も頼れない、当時としては産まれときから負け組なのですが、和歌の名手としては名高く、天皇からお声がかかり本邦初の勅撰和歌集を作るほどの第一人者です。漢字世界ではパッとしないが、かなの世界では大活躍できるそういう人なわけです。

古今集仮名序文「やまとうたは人の心を種として、よろづ言の葉とぞなれりける」とか読むと、たぶん「和歌が認められたぜ!」ってすっごい嬉しかったのが伝わるし、それと裏腹の社会的な地位の低さに、忸怩たる思いもあったんじゃないでしょうかね?

で、日記です。当時の日記は男が漢字で書く「業務日誌」でした。男が書く日記を女が女手で書いたらどうだろう、と、かなの世界第一人者紀貫之が、地方駐在から中央に帰るときにそう思ったというのは、まあなんかわかる気がします。土佐日記当時50代で従五位下だよ?土佐では国司として地元からチヤホヤされ偉そうにできても、都に帰ったら無職の下っ端貴族よ?

まあ、そんなこんなで「かなは格下扱い、だからこそできることがあるんだぜ!」とかなの世界のおじさんは思ったんじゃないかな?「歌がヘタな客がやってきて子供のほうがよっぽどうまかったのよ」「駐在中にお家のメンテを頼んだ隣人がロクに仕事をしなかったんだけどムカつくのは私だけでしょうか?あ、お礼はちゃんしますけどね」「駐在中に亡くなった娘のことを思うと何をみても悲しくて仕方がない」なんてのは漢字じゃ書けないでしょと。漢字で書くと単なる「家内の些事」でしかないですしね。

女になりたかったというより、かなで書きたいことがあり、かなで表現たかったんだと思います日記をかなで書く言い訳として女になった、そういうことかと。そもそも和歌世界では男が女になりきって恋歌を詠んだり、言ってもいない場所や、やってもいない恋を詠むのは普通ネカマ嘘松当たり前で、そういう下敷きはありますしね。

そこで日記をかなで書いてもいいんだ、という名分ができて、そこから女性日記を書くようになったという流れがつながります

まとめると、かなは「格下」であったけれども、芸術の分野では和歌漢文とならんで評価されていた。ゆえに天皇自ら和歌集を編纂させたし、歌人として名をのこす女性もいた、というのは本当。一方、社会的に差別はあって、芸術評価する立場にいるのはだいたい男だったし、そこに差別がなかったということはない。いくら歌が上手くても出世はできない。(死んで1000年近くたってから従二位なんて遺贈されてもねえ)

ただ、格上格下については、どっちかというと分業と解釈するほうがしっくりくるかな?という所感です。女に男の役割はできなかったし、男に女の役割はできず、越境するには嘘が必要だったし、その嘘は認められていた。それは今日では差別解釈されるわけですけどね。

というか、日本において芸能とか芸術かいうのは、神事以外は基本的には「格下」なので、それを差別というならまあ差別なんですが「格下としつつも、良きものについてはやんごとなき方が評価し、後世に継承される」そこはわりと一貫しているので、そういうとこが日本におけるクリエイター立ち位置特殊性でもあり、「日本差別が残る後進国」ってことにしたい人からは今ひとつ理解されづらいのかも。歴史的クリエイター全体がエディターより格下で、日本においては編集者やらディレクターがやたらいばっていて、そっち側には男女差別は色濃く残ってるわけよ。クリエイターなんて替えが効く木っ端商売なんだから男だろうと女だろうと関係ないってわけ。それをまとめて宣伝して金にするやつが権力持ってて、そこは一部を除いてボーイズクラブだよね。

すごいシニカルに考えると、クリエイターの到達点って園遊会にお呼ばれしたり勲章もらうことだったりするので「上つ方に認められればすべての差別はチャラ」という身分制があるだけといえなくはないし、そういう言い方すると自称先進国からもご理解いただけるのかもね?

2026-04-22

anond:20260422104234

そういう個人的な話をするなら、俺は服は小汚くなる前に不可避のメンテとして最低限の頻度で洗うし、臭くなるような使い方をするデイリーユースの服は諦めて安物を使う、おしゃれ着は着用シーンを選んでそもそも服が汚れないように気を使うから毎日洗濯くたびれた生乾き臭を着てる奴より不潔って気もしないんだよなぁ

ファブリーズ臭とかいう不潔感の象徴みたいな臭いはさせず、香水臭いを貫通しそうになる前にメンテをする

これが清潔"感"をコスパ良くまとうコツやで~

2026-04-21

anond:20260421102109

違うけど?

メンテなどのための開口部を養生するためであって、物を置くためではない

開口部が危険から蓋をして、物が乗っても落ちないように頑丈になっているだけ

物が置かれていると必要作業邪魔になることがあるので置くことは推奨されていない

2026-04-19

超音波加湿器ってメンテが命取りだからタンクなんか要らない。振動本体だけ売ってほしいわ

anond:20260418053741

68日目 年度初めの仕事の締め切りに追われる状態が続く。こういうのはもう最後にしたい。服薬の副作用はそれなりに負担がある。日々新たに散らかす量>片づける量になり、3月までに少し身の回りを片付けたもののいつまで保つか。

メモ)ある機械4月17日メンテされていた。

2026-04-15

anond:20260415074509

原油を精製してアスファルトやナフサができるけどナフサからアスファルトを作ってるわけではない

アスファルトメンテはそれほど頻繁にやらないから十年石油が入ってこないくらいにならんとそうはならん

anond:20260414215946

ナフサ不足で道路アスファルトメンテ出来なくなれば自動車走行できる場所はそのうち限定される

徒歩と自転車が主流になる

2026-04-14

anond:20260414114111

築何年なのか知らんけどもこれから数十年住むつもりならそれなりにメンテ費用必要だぞ

2026-04-12

IPv4アドレスって

いつ足りなくなるんだ? それにIPv4ウンコ座りして使ってるとメンテコストめっちゃ低いんだけど

2026-04-11

anond:20260411183833

ワイはメンテ業(某地方都市に点在するハザードマップ地区雨水ポンプ場巡回する下請け業務)でケツ割ったメンなので貴方がやり遂げてるのマジすげーとおもうやで

あの界隈の人らってとにかく昔でいう大工みたいなキツい人あたりしてくるんでどうにも馴染んかったんよ…

クロスバイク買ったけどメンテめんどくさくて捨てたい

汚いのと臭いの嫌いだからアルベルトスポーツにすればよかった

2026-04-09

メインサービス移行、舐めんなよ、マジで……

「今動いてるんだから簡単に別言語に移行できるでしょ」

かいうノリ、マジ勘弁してくれ……。

PHPからgolangに移行しようと考えてるんです」

ふむふむ。

まぁ、今時のプロジェクトだね。

「現行のPHP版、むっちゃ古くてセキュリティ的に不安から移行したいんだけど、開くのに1分とかかかる管理画面とか出るようになっちゃったからむちゃくちゃ速いっていうgolangにしたら一瞬で開くようになるんでしょ?」

……は?

開くのに1分……?

どうなってんのよ、中身?

ORM使ったO(n+1)の重ね重ねの無礼講

普通インスタンス変数のノリで、お手軽にあちこちDB呼び出しが発生する。

いや、キャッシュされないのか?

同じ物なのに、呼び出し経路で別インスタンスになって増殖増殖。

インフラ層にいるはずのORMのDataAccessObjectが、プレゼン層のHtmlTemplateで乱舞乱舞。

なんでやねん

「いや〜、クリーンアーキテクチャとか、採用してなかったんで」

おけ。

3億歩譲ってそれを飲むとして、これ、そのままgolangに移行……、

できるわけねぇだろ!

しかもこのDAO、いろんなところから参照されてて、参照元によってif文で複雑に構成されてて、どこから呼び出されたどういう条件がどうなってるんだか、全部あげるの一筋縄じゃいかないし、なんかの不具合解消のためか、空配列が追加されてたり、カオスカオス

いや、遅いの、PHPのせいじゃないね

で、今動いてるから、チャチャーっと言語移行?

できるわけねーでしょが!

PHPフレームワークをモダナイズしつつ、DAOの突き抜けを解消したり、安易に使っちゃうからORMの廃止と……。

一言語なら、DAOの突き抜け解消とORM廃止パフォーマンス的に厳しくないところは一旦手を抜けるから……。

golang移行で想定される予算の4/1くらいにできそうかなぁ……?

と思ったら、その金額でも想定予算大幅オーバーって、どれくらいでいけると思ってたの?

何年もコツコツと積み上げてきたプロダクトでしょ?

段階的移行の手間考えたら、真っ当にやったらかけてきた人月金の3倍かかってもおかしくないんよ?

NHK営業基幹システムとか、大変なことになってんの、聞いたことない?

ちゃんと動いていて、稼いでるプロダクトの移行は、規模等々、一筋縄じゃいかないんよ。

マンションと同じでさ、日々のメンテにも金出さないといけないし、大規模修繕計画的定期的に行わないと、こういう時にやってなかった場合の数倍のお金時間必要になってしまう。

盆栽も同じやな。

SIer出身者には一度作ったプログラムは永遠に資産。作ったら終わり、って感覚かもしれないけど、日々機能追加だなんだ行うSaaSプロダクトとかは、常に形を整えてないと、すぐ腐っちゃうんだよ。

でさ、この辺りのメンテ、多分生成AIはうまく回し続けられないんじゃないかと思うんだよな。

大丈夫か? w

数十万の前半でインジェクションになって最初の頃のBMWボクサーツインが大量に出回ってきてるみたいだけど、これ正規でもうメンテしてもらえなかったり野良で養っててパーツ出てきにくくなって手放した地雷持ちばっかりなんだろーなーって

おもってはみるけど、現行の日本車に対抗したいがために必死になって没個性化しちゃった機種よりぜんぜんカッコいいんだよな〜

R259系RSのハーフカウルがまた二次元絵でいうところの下乳見せみたいでサイコーなんよな)(でも実車たまに見ると想像よりもデッカいんだよなガイジンの大女みたいに…)

ログイン ユーザー登録
ようこそ ゲスト さん