インターネット老人なのでmacOSでは未だに爆弾マークが表示されると思い込んでいる
kb10uy(@kb10uy@mstdn.maud.io)の投稿
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(八段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
インターネット老人なのでMacBookの例の無理のある同時押しをPROMリセットと言ってしまう
特定のパラメーターで長く使っていると長押しチキンレースがそのパラメーターでだけ上手くなるので乗り換え直後はイライラしがち
このアカウントは、notestockで公開設定になっていません。
なぜヘッドレスブラウザはあるのにディックレスブラウザ、ヴァジャイナレスブラウザは存在しないのか
puppeteer 使えば提出されたコードを改変せずに完全に自動化できそう (Nodeのオタク並の感想)
このアカウントは、notestockで公開設定になっていません。
TatoEbakouiu/key /stroke wo MS-IME desonomamaUTtesimaunode,Zenkaku Eisuuji gaippaiDeTekiteSaiakuNaKibunNinaru
最近使った単語が予測で出てくるのはいいんだけど最近使った(連)文節が出てくるのがなんかやだなあという感じになる
それはそうと SKK for Android 、説明を見る限りでは QWERTY のおたくに厳しい設計な気がする。速度が下がってもいいのでチマチマShiftを打ちたい
僕はスペースを何回も押すというわけではなく、4回ぐらいまでなら連打、先頭に出てきてなかったら候補開いて探すというのをやっている
変換候補、MS-IMEのころから予測はアテにならないというのを知っていたので無意識のうちにスペースを押していて、当たり前すぎてそれをやらないという文化圏に想像が及ばなかった……
ところでみなさん比那名居天子はちゃんと「ひななゐてんし」と打っていますか？「ひなないてんし」は邪道なのでやめましょう
このアカウントは、notestockで公開設定になっていません。
僕のはいかにもGoogle日本語入力って感じの一生誰も使わなさそうなエントリが大量に並んでるのに
「未来のオレは背がぐんっと伸びてカッコよくなってるハズ！なんたって、毎日牛乳飲んでるからな！」
今更言っても遅いかもしれないけど、ログボが入ると1枚目は100ではなくて125になるのでもしジュエルが余ってるなら先に交換してしまったほうがジュエル効率はいいです
SRコッコロちゃん全部回収しようと思うとイベント中にあと500ぐらいは回収しないといけないだろうなあ
ステージ入りする前の藍子の衣装が置いてある。もちろんドロワーズもセットだ。
僕はそのクロッチ…に相当すると思われる場所にめがけて彼女への劣情を吐き出した。これを直接穿くのかはわからないが、一目見た程度では色が同化して分からないので、穿いてから違和感に気付くだろう。どんな顔をするのか楽しみだ。
このアカウントは、notestockで公開設定になっていません。
ぼくはそういう層ではなかったからわからないんだけど、ニチアサ系って本当におもちゃそれなりには売れてるんですか
このアカウントは、notestockで公開設定になっていません。
BONG BONG BONG
BONG BONG BONG BONG
BONG BONG BONG
(575)
このアカウントは、notestockで公開設定になっていません。
O-Ku-Ri-Mo-No Sunday! (M@STER VERSION) - 久川凪 (CV: 立花日菜)、久川颯 (CV: 長江里加) #NowPlaying
UTF-8がそれなりに(正規化などを考えなければ)ASCIIっぽく扱えるという点は注意しなければならないと思う
4バイトになるシーケンスの先頭バイトのあと、残りの3バイトを意味のある部分だけではなくちゃんと上位ビットの正当性も検証しろよな、という話だったはず
あ、あんまり関係ないけどUTF-8のデコードを自分で組むのは悪意のあるUTF-8シーケンスに対して脆弱になりうるのでやめようね！
どちらかというと、テキストのシリアライズのフォーマットとしての符号化形式とは別で「高速処理可能な内部表現/アルゴリズム」が普及してほしいという気持ちがある
基本単位のbit数変えるだけならまだUTF-16→UTF-8よりは簡単そうなんじゃないかなという思考実験
111110yy 11110yyy 1110xxxx ... と続くならUTF-16では 11111111111110zz 1111111111110zzz 111111111110zzzy …とできそうだね、というものです
UTF-8は6byteまでしか対応できないって言ったけど同じことをUTF-16でやれば105bitまで対応できるしUTF-32でやれば415bitまで対応できそうだね
Rustでエラーを合成する - Qiita
https://qiita.com/termoshtt/items/8c015d9289613ec640f1#fn1
> nurseryは「養成所」の意味。Rust本体にあった方が良い機能をrust本体とは別に作っている。
言語から公式とかで出されるライブラリによる対応程度がちょうどよい
むしろサポートすべきでない、たぶんそこそこ頻繁にアップデートされるものなので
私の記憶が正しければRakudo Perl 6処理系のバイトコード仮想機械MoarVMがそうです（先ほどはわかりやすさのため0x110000以上としましたが、実際にはその全体を使わずに符号付き整数型にして負数はgraphene clusterを詰め込んだ領域を参照するような実装だったはず）
How do we output PROPER texts from Unicode strings?
みたいな記事Mediumとかにないかな
逆に内部形式なのを利用してUnicodeでは使われることのない0x00110000以上の値にgraphemeを動的に対応付けていくことでgraphene cluster単位でO(1)インデックスアクセスを可能にする言語処理系もある
utf8mb4 はまあ、 5バイト以上は不正っつってるらしいので固定長のアプローチとしては正しいと思うんだけどね
でもMySQLのutf8(mb4じゃないほうね)については、なんかこう、規格で4バイト以上の可能性も指摘されていたのに3バイト固定長にしてしまっていたのはちょっとアレだと思うんだんばあ
まあ 5, 6 byte のUTF-8表現が必要になってしまう未来は来てほしくないし実際来ないような気がするけどね
まあだから Unicode 1.0 時代の UTF-16/UCS-2 に対して設計の不備を指摘するのはかわいそうなんだけど、なにぶん当事者意識が不足しているので批判しがち
「符号化方式が 1 符号で表わせる領域よりも Unicode の領域が広くなってしまう(せざるをえない)」とその符号化方式はクソの烙印を押されてしまう可能性が非常に高い
このアカウントは、notestockで公開設定になっていません。
まあこれが U+10FFFFFFFF まである、とかだったら UTF-32 が途端に第二の UTF-16 と化すので UTF-64 が必要ということになるんだろうけども
まあ25bitだとしてもUTF-32がある以上UTF-64が存在してもあんまり意味がないという議論は通る
libicuが16bit単位ベースだったのはビックリしたけどまああれも歴史的経緯なんだろうな……
非常に不謹慎な話をすると世界の民族は現象傾向なので僕はU+10FFFFまであれば本当に十分だと思っている
graphene clusterの存在によって可変長になるので内部形式をUTF-8にしてO(1)インデックスアクセスを諦める言語処理系もある
「初期の Unicode が BMP だけで足りると思っていたのがダメだった」というのはわかる
grapheme cluster の存在によってどうせ可変長になるので交換形式は別にマルチバイトでええやろと思わなくもない
.editorconfig は使用で「定義されてないエンコーディングが指定されていても無視しろ」みたいなことになっているらしいのであれに cp932 とか書けないのが惜しい
sed [OPTION]... {script-only-if-no-other-script} [input-file]...
ほんとだ……
pattern がひとつしかないなら -e は要らないし pattern が複数なら sed -E -e 'pattern1' -e 'pattern2' ってしそうな気がする
まあ課題以外で無用な混乱が発生するのでデフォルトのエンコーディングは基本的には変えないほうがいいと思った(適当)
電車でGO!!やってて思うけど、込め直しなしであそこまで正確に止まれるのやっぱ本職ってすげえわ
先程の「脆弱性の責任を報告者に押し付ける存在」もそうだし「既知の脆弱性を認識しつつ適当に吹き上がる存在」もだいたいこれ
一人合作で稀によくあるSpecial thanks: 森羅万象メソッドだ
ダメだな、BITMは生物中心的だしEITM(Existence In The Middle)あたりまで抽象化しないと(???)
壊れるのが怖くて脆弱性対応できないサービス、はっきり言って運用リソースが必要コストに足りてないのに手を抜いてるだけではという気持ちがあるし、自分でパッチ書くわけでもなし、アプデもできないのであれば運用などすべきでないみたいな過激な気持ちもある
公開されて(特に時間がたっている)ならば攻撃された側が「なんか知らんが不正に操作されたムキーッ」っていうのはどうなんだみたいな気持ちです
不正性なあ 客観的に不正かどうかという点で言えば公開されてても脆弱性ならもちろん不正だとは思う
そういうわけなので任意の理由で脆弱性の対応にキャッチアップできていな(い|かった)事案については僕としてはあんまり同情できねえなあという一方で自業自得だなあという自戒でもある
現実に対応できるリソースがないという事実は受け入れるけど(既知の脆弱性については)同情は得られないねというぐらいの話です
高橋邦子の「エロビアンナイト」には「赤嶺麻衣」というキャラクターが登場しており、これの元ネタはAkamaiではないかと言われている
「誰でも(諸説あり)思いつくような対策をしているかどうか」でだいぶ印象かわるなあということを実感する
あのときぐらいにUDPがデフォでオフになったらしく、よかった
https://github.com/memcached/memcached/wiki/ReleaseNotes156
このアカウントは、notestockで公開設定になっていません。
このPDF、GitHubが一貫して「Akamaiのお客様」と表現されているの、当たり前なんだけどなんかじわる
まあその、あれだね、DDoSにおあつらえむきな機能がmemcachedには存在するという残酷な事実っぽい
「研究者は、イン
ターネット上に 9 万台以上の Memcached サーバーが存在し、現在そのうちの 5 万台以上がリフレクターとして悪用される脆弱性があると推測しています。」 
DDoS リフレクション攻撃 - memcached UDP | Akamai JP
https://www.akamai.com/jp/ja/resources/our-thinking/threat-advisories/ddos-reflection-attack-memcached-udp.jsp
「DDoS 攻撃の新たな展開：Memcached リフレクション攻撃」
> This would result in a massive amplification factor where a 203 byte request results in 100MB response of reflected traffic, per request.
もうここだけでヤバさが凝縮されている
Memcached UDP Reflection Attacks - The Akamai Blog
https://blogs.akamai.com/2018/02/memcached-udp-reflection-attacks.html
Akamaiブログで解説されていた
まあGitHubがTbpsクラスのDDoSをうまく受け流したのは流石というかAkamaiようやったなという感じだよね
で、増幅率については (ターゲットへの配送量 / 攻撃者の送信量) みたいな感じらしいけどこれが理想的には 1.5万倍とかになるらしく、DNS騙すより圧倒的に効率がいいのが要因とのこと(もちろんその騙す前提としてUDPなわけですが)
memcachedを外部に晒してる時点で論外な気がするんだけど、デフォルトのlistenアドレスが 0.0.0.0 となってるらしい
たしか「増幅率が非常にいいから」というのと「デフォルト設定のセキュリティがガバ」というのだったはず
ぼくが前に買ったSDか何かにmemcachedによるDDoSアタックがなぜ横行しているのかという解説があったな
全然関係ないけど、この記事 *memchaded *memchached *memchashed と全ての memcached の綴りが間違っててウケる
https://japanese.engadget.com/2018/03/01/github-1-35tbps-ddos/
「訴訟問題に発展したときに話がややこしくなるのでクソ設計アプリを世に放つのはやめましょう」という教訓は得られた
そろそろ寝なければならないので話をまとめると「どこを指して私電磁的不正記録作出・供用とみなすか」なんだろうなあ
