非エログリフで思い出したけど、クルアーンはフォント変えるだけで何もかも違う表示になり笑えました。 #unicode
非エログリフ案件はこちらをご覧いただくか、 #unicode でハッシュタグ検索してください
https://oransns.com/tags/unicode
ヒエログリフを検閲して非エログリフだ！というどうでもいいコメントを思いついた。
インフラ足りないで思い出したけど大和川線全通いつですかね…
年度内開通とは言ってるみたいだけどまだ何日とかが出ておらぬ…
J-PARCが問題なんじゃなくて、なんかいろいろかたまってるのにインフラ整備が追いついてない典型例というかなんというか
SPring-8はド田舎にアレだけがぽつんとある感じなので足りております
J-PARC、明らかに交通インフラ足りてないのでは感（空撮写真を見ながら）
このアカウントは、notestockで公開設定になっていません。
SBring-8 (Super Buddha ring - 8GeV) を一刻も早く建設してマニ車の謎とともに解明を急ぐべき
このアカウントは、notestockで公開設定になっていません。
物理層の実装がないキャラを愛でるのに性別というくびきは必要なのだろうか（反語）
みしまやみな 
の投稿
MishimayaMina@ukadon.shillest.net
このアカウントは、notestockで公開設定になっていません。
みしまやみな の投稿
MishimayaMina@ukadon.shillest.netこのアカウントは、notestockで公開設定になっていません。
みしまやみな の投稿
MishimayaMina@ukadon.shillest.netこのアカウントは、notestockで公開設定になっていません。
Homo sapiens performance tuning howtoがほしい。
ラ0.Fの投稿
frfr@mstdn.f72u.net
このアカウントは、notestockで公開設定になっていません。
結局どっかでボトルネックが出てくるのでバランス良く強化しましょうということで
ラ0.Fの投稿
frfr@mstdn.f72u.netこのアカウントは、notestockで公開設定になっていません。
VPSサービスを担ってるサーバ機とかどうしてるんだろうなあ。主記憶も補助記憶も帯域足りずCPUが暇してるオチありそう。
ラ0.Fの投稿
frfr@mstdn.f72u.netこのアカウントは、notestockで公開設定になっていません。
超ウルトラたっぷりコアもだいたい補助記憶装置のI/Oに引っ張られるので、デスクトップ機的な使い方で全域で全力出すなんてまあ無理説
sidekiqもnodeもポスグレも山ほど立ち上げ放題だね！（なおメモリ）
ラ0.Fの投稿
frfr@mstdn.f72u.netこのアカウントは、notestockで公開設定になっていません。
コアあたりの性能が頭打ちの時代に、開き直って脳筋超マルチコア設計でまだまだ開発者フリーランチの時代じゃーっていうのがイケてる
ラ0.Fの投稿
frfr@mstdn.f72u.netこのアカウントは、notestockで公開設定になっていません。
ラ0.Fの投稿
frfr@mstdn.f72u.netこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
まあガチサーバだとXeon何発も積んでるとかなのでそれは別として
Ryzen、実はサーバにぶちこむほうが良いのでは説（なにもかもふつーにマルチスレッド対応なので）
Instance Ticker 0/1を10/11に切り替えよう
書く書類がないってことは、その紙の分の責任を自分で負わねばならぬということなので、割と切実だけど面白いよ。
いつ首切られるかわからんでかい企業と、いつ潰れるかわからん中小企業に、現実的な運用の差異がない説
さくらさんたいへん太っ腹で、旧サービス継続してる人も含めて老朽化対策メンテナンスの名目で容量据え置き全部SSD！とかいうクレイジーなメンテナンスするらしい
石狩リージョンも「論理移設前作業」がはじまったので、そのうちハードウェア交換きそうね
ストレージ的意味ではうち（うかどん）は年単位で耐えられるのでお気になさらず
syuiloさん金欠問題も含めて札束でシバき倒せばどうにかなる論なんだけど、たいへんマネタイズしづらいというかその対極として生み出された感あるのでつらい
Fediverseサーバ維持概論、だいたい札束でシバき倒せばどうにかなる説
もっとも、起こりうるトラブルが多種多様すぎて何から文書化していいかさっぱりわからんよね！
Fediverseに参加するためのサーバ、立てるだけなら各種定番手順の文書が整ってるけど、維持するノウハウが足りてない感じ
Fediverse全体の規模が大きくなってデータ量が肥大化してきたら、リモートの情報を自鯖に抱え込む設計にはできなくなる。
抱え込めないデータをどうするのか。解決が必要な課題である。
ここまでで、データ量増大を加速する大きな存在としては、リレーがあった。雪餅リレーにbest-friends.chatが参加していたことも。
mstdn.jpとpawoo.netが参加するリレーがあったら壮観だよね。リレーはオマケで、参加が任意だったので、実現はしなかったけど。
実はもう一つ大物が控えている。その名はグループ。
コイツは個々にはリレーと同じ働きをするので、うっかり1万人参加するグループにサーバの誰かが参加すると、1万人のサーバとリレーしているような状態になる。
LTLと比べて流量は少ないかもしれないし、すごく多いかもしれない。それが複数存在する状態。
さて、Fediverseの各サーバは、ユーザーがグループへ参加する自由を保証できるのか。
グループに参加できるサーバと、禁止のサーバに分かれることになる？
お一人様なら誰にも遠慮は要らないのに、負荷が大きくて参加できなくなる？
JPとpawooが入ったリレーサービスとか、先にリレーサービス側が音を上げて脱落しそう…
気管支炎までいったら確実に二次感染（今回の場合三次感染？）までいってウイルスか菌かわからないぐじゃぐじゃになってるので、そこまでいったら抗生物質でシバき倒しにいかないと長期化する
