メリット
・Rubyとnode.jsとか開発者人口が多いので廃れる心配が少ない
デメリット
・インフラ維持担当から見れば悪夢でいますぐ投げ捨てたい
メリット
・Rubyとnode.jsとか開発者人口が多いので廃れる心配が少ない
デメリット
・インフラ維持担当から見れば悪夢でいますぐ投げ捨てたい
このアカウントは、notestockで公開設定になっていません。
TCHAR (1/2バイト文字内部切替用変態マクロ群) 使った文字列
Local
Pointer
Const
Tchar
STRing
だっけ
「LPCTSTR」という名前をカンニングなしで正しく詠唱
OEM コードページと "Unicode" の変換ならまだマシで、 Seaurchin で UTF-8/UTF-16/SJIS の変換をやってた時は頭がおかしくなりそうだった
なんとかかんとかほげほげExW とか今すぐボツにしろと思うけど、もう第一選択がWinRTになって滅びつつある
（インフラエンジニア）レベルを上げて物理（層のマシンパワー）で殴れば良い
Wineの互換性だいぶマシになってきたのでみんなワインがぶ飲みしよう🍷 🍷 🍷
FreeBSD上でのMastodon安定運用で頭痛くなってる現場からお伝えしました。もうやだ。
だって今更OSなんでもええやん？
なんでもええんやったら運用ノウハウ多いLinux系がええやん？
とりあえず、Mastodon頑張ればLinux系以外でも動くことは動くだろうけど、運用ノウハウが少なすぎてLinuxぶっこんだほうが手っ取り早いってだけだと思う
このアカウントは、notestockで公開設定になっていません。
Windows上で絶対に走らせたくないというかたぶん使ってるのNative拡張まみれなのでWSL上とかでない限りムリ
Linux依存じゃないです。
当サーバはFreeBSDで運用しております。
※そういう話ではない
FMSプログラミングと降下時のFMS操作の理解が、特にボーイングのハイテク旅客機操縦でプロに一番語られてる部分なので、つまりシーケンサーをうまく扱う事が大半になるので、シーケンサーいじりなれてる人に向いてる感＞＜
段取りでおおむね決まるのが正しいあり方で、属人的な職人芸を要するのはいまどきキビシイと思う。KQさんとか職人芸極振りスタイルだけどいずれは諦めないといけなくなるのでは。
ていうか、操作の7割くらいが離陸までに準備で、残り2割が降下(降下の操作がシステム理解が必要で一番難しい)、残りが離着陸みたいな・・・＞＜
無線式移動閉塞とかとセットでなんかこううまく自動化すべきである
このへん鉄道はまだビミョーだもんなあ。TASCとか地上設備盛り盛りで脳筋な実現の仕方だし。
理想的な条件で飛ばすだけなら、オートパイロットその他の充実で旅客機のほうが今はラクかもしれない。いや目がまわるぐらいめんどくさい操作をどうにかマスターできればだけれど。
フライトシム、たぶんやろうと思えば短期間で扱えると思うけど、やっぱり鉄道派
フライトシムで旅客機(のちゃんとした機体データ)で飛ぶと、チャートを実用(？)出来て楽しいよ！＞＜
連動図表とか見たがる病なのでチャート見たがる病に発展するのは当たり前！
どこかに空路で行こうとするたびにチャート見たがる重病にかかったどうしてくれよう
TOKYOコントロールのせいで航空交通管制沼にひきずりこまれたので謝罪と賠償を請求しない
@kanade_lab 指のタッチっていう不安定性の高い仕組みを使ってる以上どうしようもない部分はあるよね…タッチパネルとかと一緒で。
本来はそのへんを考慮して余裕のある配置のUIにしないといけないんだけど…
@kanade_lab PalmCheck（手のひら誤接触判定）のしきい値の見直しとタッチする力の見直しで。マウスコントロールパネルのSynapticsタブからいけるはず
強固な結界で煩わしい魔物を寄せつけません！平和で清廉な森林ライフをあなたの手に！
エルフの森ニュータウン、堂々分譲開始！
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
JP鯖分割するとして名前をどうするか…
yokosuka.mstdn.jp
sasebo.mstdn.jp
kure.mstdn.jp
maizuru.mstdn.jp
oominato.mstdn.jp
とかか（それは違う）
件の、タイムラインスクロール中は先頭が『n件の新着』表示になる奴、ひとまず公式にrevert（適用取り消し）となりました。
便利だと思った人は、Slow mode（手動更新モード）があるからそちらを試してみて！
#fedibird も前と同じリアルタイム追加になってるよ（いま見てるひとはリロードすべし）。
ぶっちゃけユーザーランド側（アプリ側）はどうせ何も考えてないガバガバ野郎ばかりだとOS開発者側は疑心暗鬼になってそう
エラー処理が甘くて、くそでかい画像ファイル食わされてOS巻き込んで陥落したガバガバエラー処理デスクトップマスコットアプリがありましてな…（遠い目
Windows 2000まで？みたいにWindowsで言うところのタスクマネージャだけは死守するみたいな事して欲しいかも＞＜
OSがまず死んじゃ駄目だしその次にマンマシンインタフェースが死んじゃ駄目だし みたいな重み付けやって当たり前じゃんって思うんだけど＞＜
OS側はもちろんだけどアプリ側も＞＜
マストドンも、すごく下の方のレイヤに対する攻撃とかで落ちるのであれば仕方ないけど、自分が処理作り出して過負荷にしてOSごと陥落とか、何も考えてなさ具合ひどすぎる＞＜
GUIもOS内に組み込まれてる設計のOSでないと、スケジューラ内部でGUIプロセスの優先度を上げるとか「そもそも当該プロセスがGUI持ちかどうか」すら分からない以上ムリだろうな…
そのあたり今なにか対策されてるんだろうか。
OOM Killerさん、概ねメモリもりもりのプロセスから生け贄にするから、だいたい一番大事な子が死んじゃう印象があるよ
むしろそのせいでsidekiqが全部ダメになって、OSは落ちてないけどただのカカシになったとかありそう
でも今のLinux Kernel、そんな地獄のような状況になる前に酷いプロセスを容赦なくkillする緊急回避機能ついてなかったっけ
Apacheの時代から「立ち上がるプロセス数のチューニングが甘くてメモリ食いつぶしてOSごとチーン」という重大インシデントは定番なのでお察し
ていうかmsidekiq自体はネットワーク処理エンジンじゃなく単なるジョブプール？かも？＞＜
ちゃんとネットワークの処理自体見てるのかも？＞＜
あと、ネットワーク関係無くそもそもすぎるびっくりな点として、キューたまりすぎて高負荷で「鯖ごと落ちた」とか昨晩もなんか色々出てたっぽいけど、自分の実行環境の負荷の具合見て自制する機能くらいついてないの？＞＜；
Mastodonの配送処理はsidekiq依存で、sidekiqはリトライ間隔をだんだん広げていくように元々設計されてるし、リトライ回数も設定できるから、延々同じ間隔でリトライするような頭の悪いことにはならない。
後は「信用できなさげなサーバ」判定だろうなあ。
スレッドプール自作する勢から見たら、RoR＋nodeって聞いた時点で暴動を起こすレベルな気がする
