SSTP CommunicateってSocket経由で打ち込めないのなんかびみょうなきがする
SSTP CommunicateってSocket経由で打ち込めないのなんかびみょうなきがする
このアカウントは、notestockで公開設定になっていません。
謎の発光体てつわんこにもほしいなと思ったら、たしかに発光体はあるんだけどぜんぜん謎じゃなかった。
てつわんこはあんまりメカっ娘成分がないから、こういうのもいいよなあと思い直してる
https://mstdn.f72u.net/@uyupica/104517717600137448
このアカウントは、notestockで公開設定になっていません。
いろんな理屈があるけど、ばっさり言うと小型軽量でトルクがあって制御しやすいもの、なんていう都合の良いものを採用すると、だいたい信頼性が犠牲になる #frfr
このアカウントは、notestockで公開設定になっていません。
しかも実体化させようとすると各関節のアクチュエータの類いが割とカジュアルにぶっ壊れるので、ロボ娘によくある各所の謎のアクセントめいた発光体は実は故障表示って流れありそうだと思ってる。 #frfr
ロボ娘の目が光るやつ、なんかこう機械感あっていいんだけど、実際に実体化させようとした場合はむしろやむにやまれず光らせないといけない流れになる。下記実例。
https://sites.google.com/view/masiro-project
#frfr
このアカウントは、notestockで公開設定になっていません。
ふるどんはあけっぴろすけべ、うかどんはむっつりすけべって感じだと理解してる(とてもしつれい)
バルーンの表示速度をいじるのはないなあ。基本的にユーザさんに任せるべきものなので。
仕様作るとしても正確なウエイトじゃなく、標準に対して何%とかになりそう。
https://ukadon.shillest.net/@bbergenia/104516995077842860
FreeBSD使いは「jailで何年も前からDockerと似たようなことができた!」って言い張るんだけど、マイナー技術なのでお察しであった。
そういやSSPは一応セグメントヒープ有効にしたけど、そもそもメモリ確保はほとんどがCRT経由なので、小さいメモリ確保最適化に埋もれてしまい何も違いがなかったというオチ。
ビルドシステムのフラグ切り替えで、chrome:flagsに入るわけではなかった。Manifestの変更が要るからあたりまえだけどざんねん。
Segment Heap適用でメモリ使用量が減るって、つまりChromeはWindowsのヒープ直接使ってるってことなんだろうか。
Chromeもセグメントヒープ適用する話、メモリ使用量は減ったけどCPUに負担かけるので一旦デフォルトでは無効化したらしい。
なんかchrome:flagsで制御できるようなこと書いてあるけど、セグメントヒープのオプトインってマニフェスト依存なんじゃ…?
https://techdows.com/2020/07/google-disables-windows-segment-heap-chrome-85-performance-issues.html