まくら牧場が立ちました！
インストールバトル、結果は30時間でした。
aqr.af が死んだらここからみんなにフォローが飛ぶはずです。よろしくね 
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)님의 게시물
まくら牧場が立ちました！
インストールバトル、結果は30時間でした。
aqr.af が死んだらここからみんなにフォローが飛ぶはずです。よろしくね
This account is not set to public on notestock.
This account is not set to public on notestock.
オレンジ的には、それらの指摘は微妙に間違ってると思う＞＜
フォロー方式のコミュニティは、基本的に取捨選択がアカウント単位になってしまう＞＜
でも実際には人のコミュニティはロール単位になってる事が多い＞＜
たとえば、こういうお仕事をしてるhogefugaさん、こういう趣味のhogefugaさん、このゲームで遊んでるhogefugaさん、このお店の常連の、このお祭りに参加してる・・・等々＞＜
たとえばDiscordであれば単一のアカウントがテーマ事のサーバーを渡り歩いてそれぞれで異なるロールとして振る舞うということができる＞＜
現状のFediverseは、あくまでアカウント単位なのでそれが出来ないし、Discordの如くテーマインスタンスで解決しようとすると分散に逆行してしまう＞＜
「Fediverseに(グローバルな)検索システムが必要」って発想は、そういうロール視点から見れば(むしろFediverseを使って無い人にとっては)当然のもので、それに対して「フォローすればよい」と返すのは「え！？ 分散は？」ってなるのもある意味当然かも＞＜
あるいは「ロールにあわせてものすごい数のアカウント作れって事！？」ともなる＞＜
たとえばオンラインゲーマーであれば、遊んでるゲーム毎や参加してるゲーム鯖毎に(たとえばマインクラフトhoge鯖とfuga鯖それぞれひとつ)作れって事！？ ともなる＞＜
オレンジはマインクラフトの(もう誰もログインしてない) 
鯖に参加しるけど、その為のDiscord鯖には参加してるけど、 マインクラフト 鯖に参加した全員とFediverse上で相互フォローにあるわけではないし、オレンジとオンラインのゲームで一緒に遊んだ人(遊ぶ人)全員がオレンジのこのアカウントの投稿を読みたいと思うとは全く思えない＞＜
マインクラフトで一緒に遊ぶ人は、マインクラフトに関するやり取りがしたいんであって、オレンジのFediverseの現状の問題点への指摘やら公共交通の諸問題や他国の事例に関する長文を読みたいわけではないから＞＜
なので、「Fediverseにグローバルな検索システムを構築するのは技術的に困難」であれば、まあそうだろうだけど、
「Fediverseにグローバルな検索システムは不要」とか「アカウント単位以外でTLを構築するシステムは不要」って考え方は、人付き合いが完全に人間全体単位で行われているという勘違いからの発想か、
あるいは、それをテーマインスタンスのLTLで解決するのであれば分散に逆行してしまう考え方なので、
むしろ「検索システムが無いと・・・」って言ってる人の方が、コミュニティの構造と分散に注目出来ている視点を持ってるかも＞＜
「フォロー単位でコミュニティが構築されればそれでよい」って発想の人で、『オレンジとごく稀に接触があるけどオレンジをフォローしてない人』、特に過去にオレンジをフォローしてたけどフォロー外した人に対して
「じゃあ、なんでオレンジをフォローしないのか？＞＜； フォローのみでコミュニティを構築するという事は、結果的に『部分的にでも関わりを持つ相手はフォローする』というモデルに至るけど、なぜフォローしていないのか？＞＜；」
って言いたい＞＜
まずコミュニティの定義を特定する必要がありそう。ブロードキャストドメインを指すのか、それ以外の大雑把なクラスタみたいなものを含むのか。
ブロードキャストドメインの話をしているのであれば、必要とされているのは「コミュニティメンバーの投稿を拡散するリレー的存在」よね。もちろん TL を “コミュニティ” ごとにそれぞれリストで生やしたうえで通知だけ一本化するのでも良いけど
個人的にはブロードキャストドメインとしてのコミュニティ概念にはあまり惹かれないんだけど。
Discord や Zulip でもトピックごとに通知無効化しまくったり、いっそ許可リストでしか通知飛ばさないようにしていたりするので。
全員リアルで友人レベルの狭く密なコミュニティならだいたいフォローしてるし。
まあ私が適性あるかはどうでもよくて「全員に通知飛ばしたいし飛ばされたい」みたいな人がいるらしいという話なら、それはそうだけど。
過去の私の見解としては「コミュニティ」機能を提供する仮想的アカウントは、そのコミュニティが完全に平坦であっても特定のひとつのサーバ (DNS ドメイン) に依存せざるをえない点で分散を阻害する要因になってしまう、ということだったし、その考えは今でも変わらない。
せめてモデレータ間での共同所有とかにできると良いのだけれど。
もちろん、コミュニティに「主催者」がいる場合では現行のシステムでも概ねうまく実装できると思うけど。「友人同士」みたいなのには適していないよね
Discord などは「所有者」をﾃﾞｮｽｺ社にしておきながら admin や mod 権限を委譲することで仮想的に共同所有に見せかけられている、というあたりがポイントなのかもしれない
Mastodonの検索は、そのサーバの連合、つまり同じサーバの利用者がフォロー関係を持つつながりの強いところを検索範囲とするので、
たとえばmastodon.socialだと英語圏の投稿を中心にMastodon全域、fedibird.comだと日本語圏のMastodonとMisskeyに強いなど、特徴が出るよ。
そのサーバのローカルならフォロー関係なく入るから、特定の話題で盛り上がっているサーバなら、その話題を検索するときには一番強くなったりするしね。
まぁXと比べたら物足りないかもしれないけどさ。
クロールするのもいいかもしれないけど、余計なモノも増える気がするね。
少なくともサーバの誰かがフォローしてる人っていうのはかなり有効なフィルターで、投げ捨てのスパムとかは入ってこない。
まあ少なくとも全文検索未対応なmstdn.jpやPawooとか、他の検索が不便なActivityPub系サービスで不自由しているなら、mastodon.socialやfedibird.comで検索試してみるといいよ。
検索できるじゃん、って認識が新たになると思う。
FedibirdはFedibirdで、サーバ単位の考え方、フォローによるつながりを超えたところで活用できるよう、いろいろやっているので、Mastodonの考え方そのままではないんですけどね。
独身男性の得意技であるところの販売時パッケージのまま食器によそわず食べるやつをやってる
This account is not set to public on notestock.
自宅鯖勢の達共同で物件借りて、機器持ち寄ってDC作ったら面白そうと思ったことある
冷房を共有したさはある (夏は室温40℃近くに達する自宅鯖勢としてもな)
オタクなので awk 避けがち (sed に固執しがち)
オタクなので脈絡もなく「オタクなので」を枕詞に使いがち
だいたい awk が欲しくなるレベルだとシェルスクリプトを書いてしまうので、それならべつに sed なり cut なりで一時変数作ったりすることが多いし、ストリーム処理がそんなに必要かというと日常的にはそうでもない。
「集計しながらストリームに新規カラムとして追加していく」みたいなのだと一時変数云々とかやってられないので awk の出番なんだろうけど。
jq は流石に必要なときは避けられない (そもそも JSON が従来の unix 思想から離れたものなので既存ツールが使いづらいのはしょうがない)
.trim() のためだけにサブプロセスが起動するのはそうじゃなくない？みたいな気持ちです(もしかして知らないだけで Bash 拡張にそれぐらいならある？)
基本的にはシェルコマンドでの編集は (awk もそうだけど) 配列に対して map したり filter したりするものという感覚があり、プロセスの数はパイプラインの複雑度に過ぎずデータの大きさや数を反映するものではない (つまり idiomatic に書けばちゃんとスケールする) ので、新規プロセスが起動するコストは気にしていない
言い換えると、プロセス起動のコストが問題になる場面というのは、配列でないデータに対してワンオフの処理をする場合か、ストリームを配列扱いできない場合。
前者は基本的に速度が要らない場合が多いが (なぜならスケールさせる必要がないから)、そういうワンオフ処理が沢山あると塵が積もる。旧来の init がそれで遅くて systemd に勝てないとか。あとは別スクリプトとして吐き出したりしてソースを分離するような構造にも弱い。そこまでやるなら C とか別言語で書くべきということなのだろうけど。
後者はバイナリとか中間ファイルが必要な用途にありがち。ファイルリストを stdin から流し込んで単一プロセスが内部的にループ/並列処理してくれる場合はそれでいいけど、そうでない場合は対象要素ごとにプロセスを起動することになってしまう。 xargs を使う場合とか、 gcc のようなケースとか。
スケールさせる必要のないスクリプトでは気にするな、スケールさせる必要がないのにオーバーヘッドが気になるのは何かがおかしい (別言語を検討しろ)、が私の答えですね。
まあべつに parameter substitution を使っても全然いいんですが。後からもっと複雑な条件 (たとえば数字かどうかを気にするとか、スラッシュ1個までなら許すとか) でトリムしたくなったら結局 sed 使うことになるからなぁ。
parameter expansion は可読性が低すぎるんじゃ。
${var#pattern}
${var##pattern }
${var%pattern}
${var%%pattern}
↑これ検索とか実験なしにちゃんと意味言えるか？ワイは無理や
具体的にはファイルの行数の数値だけを得るのに wc -l を使うまでは良いとして tr -d ' ' か awk '{ print $1 }' がセットになるのが 
wc -l はパディングしない気がするけど……末尾の改行文字の話？
あーいや、パイプから流さなかった場合は後ろにファイル名が付くか
もしかして GNU coreutils がいい感じにやっているだけで BSD 系は出力が違うなどの可能性はある (わからん)
BSD coreutils に食われる可能性がある場合を考慮しなきゃいけないのつらすぎるんだよな Web 標準と違って
最近の BSD 事例だと、 install コマンドのオプションとかで苦しんだ。
シェルスクリプト書くとき long options を使うようにしているのだが、 BSD 版にはなんとほとんど存在しない (ほとんど short のみだったはず)
This account is not set to public on notestock.
$ wvgain --help
illegal option: - !
illegal option: h !
illegal option: e !
illegal option: l !
illegal option: p !
Usage: WVGAIN [-options] [@]infile[.wv] [...]
あのさぁ……
