まーーーた読んでたネッツ小説でカスの無能が無思慮に暴れることでストーリーが展開するようになってきてガッカリです
まーーーた読んでたネッツ小説でカスの無能が無思慮に暴れることでストーリーが展開するようになってきてガッカリです
Nihongo gaUTenaitokiha /TL
noMinaSannni /SKK
EnjinqninatteitadakukotodeMondai woKaiketu siteimasu
このアカウントは、notestockで公開設定になっていません。
Rust-Based, Memory-Safe PNG Decoders "Vastly Outperform" C-Based PNG Libraries - Phoronix
https://www.phoronix.com/news/Rust-PNG-Outperforms-C-PNG
へえ
libpng については setjmp/longjmp が使われている衝撃以外は何一つとして記憶が残っていないのが正直なところ
このアカウントは、notestockで公開設定になっていません。
序盤は楽しかったネッツ小説が連載を続けるにつれカスの無能を無思慮に暴れさせることでしかストーリーを紡げなくなっていくさまを何度も何度も何度も見せつけられ、人間に限らず何事にも身の程ってやつがあって、過ぎた努力は裏目に出るのかなぁなどと悲観的な気持ちになった
最近ちょっとした偶然で『ひぐらしのなく頃に』の存在を思い出すことがあったんだけど、あれはバカを暴れさせるのではなく敵味方各々事情があって最善を尽くしている清々しい物語だったなぁと改めて評価している
NTR モノはだいたい財力、コミュニケーション、デカいチンコの3つがあれば防げるみたいなことを言っている人を見たことがあるが、似たようなもので結局バカを暴れさせない展開を書こうとすると、リソースの制約とディスコミュニケーションと諸々の不満は基礎的かつ最終的なギミックになってしまうのかなと思ったり思わなかったり
まあそれはそれとして「そこ最低限の合理的なコミュニケーションできてれば問題起きなくない?」みたいなのを乱発されても結局それ無能の一言で終わるやつでは? みたいな話もあり、何事にも限度というものはあるが
このアカウントは、notestockで公開設定になっていません。
「深淵を覗くとき〜」で言及できてしまう言説マジでそこら中にあるし、なんかハッシュタグつけて一発応答したさがある (?)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
マジで今更だけど、5年くらい運用したMastodonサーバーをクローズしたのちょっと勿体なかったかもしれない
なにやら近いうち Mastodon は DB に暗号化を施しそうな雰囲気があるので、警戒している (可読なエクスポートがダルくなると困る)
rails か tootctl か何かしらのコマンドで復号してダンプとかできると良いのだが (既にあるかもしれないが調べていない)
https://www.w3.org/TR/2008/REC-xml-20081126/#wfc-PEinInternalSubset
WFC: PEs in Internal Subset を、 internal subset 内で定義され展開される PE の replacement text が含む parameter entity reference についてどう解釈べきかを考えている。
```
<!DOCTYPE root [
<!-- ここで name.para と content.para を定義 -->
<!ENTITY % foo "<!ELEMENT %name.para; %content.para; >">
%foo;
]>
```
のような文書があった場合に %foo; の replacement text 内の %name.para; と %content.para; は recognize されて展開されるべきかということ。
Railsのプロセスが起動できれば復号処理自体は難しくないが、書かないと無いだろうなあ
MastodonのきたるDB暗号化については、どうせ1日くらいソース読んだら復号するスクリプト書けるだろとたかをくくっています
エクスポート用のスクリプトが用意されていたはずの GNU Social で実際にエクスポートするのにうまくいかずトラブルシューティングが発生した嫌な思い出があるので、本当に頼むぞ……という気持ちになっています
まあ最悪のケースでもモデル全列挙して全部find_eachしてJSONLでファイルに書き出すみたいなスクリプト書いてrails runnerコマンドに食わせたら終了、みたいなのはありますね
私は Rails で物を書いたことない勢なので、去り際に退去費用としてリーディング・コーディングコストを支払わないといけないのが下手なロックインをされているみたいで気持ち悪いんですよね
被害妄想といえばまあそうかもしれないが、実際完全に掌握していて手元にあるデータを取り出すのになんで自前であれこれ工夫をしないといけないのかという不満はあるので、是非とも公式に復号ダンプ機能は提供してほしい (まあそれができると逆に暗号化する意味あるんかみたいな話になるのかもわからないが)
基本的に DB サーバ単体への脅威に対処するものであってアプリサーバが汚染されている場合は大して意味ないものと認識しているので、復号ダンプできたところで暗号化の意義がなくなるわけではなかろうという認識でいる (が、 Rails 使ってないのでどういう気持ちで使う機能なのか実際のところは知らない)
私はあれやこれやしてよくわからんデータフォーマットを解読するのが好きなのでアレだがまあ普通はそうか
解読するのは嫌いではないが (FBX とか)、それはあくまで趣味として、必要に迫られずやりたい
参入のための工夫は楽しいこともあるが、撤退のための工夫は概してつまらん (個人の感想)
ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY
ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY
ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT
の3つを定義するようになるので、このキーを失わないようにしておくこと。
パフォーマンスの面からも、全部のフィールドを暗号化するつもりは全然ないので、その点ではあまり心配は要らないと思う。
アカウントの秘密鍵とか機密性の高いものが対象で、適用対象は限られるじゃないかな。
想定ケースが「自前 AP 実装に Mastodon の投稿や秘密鍵を全部食わせて代理させる」というリプレース用法なので、秘密鍵とか機密性の高いもの含め全部 (文字通り全部) 吐き出させたいんですよね……
別実装に乗り替えたのに旧サーバをメンテし続けないといけないの嫌じゃないですか?
リソースを圧倒的に食わなくなる read only モードみたいなのがあるならまだしも、たぶんそういうのもないのだろうし……
別サーバへの引越機能を使いたいとかでもなく、そのままのドメインとそのままの ID で、少なくとも ActivityPub の S2S API 範囲ではそのままの情報を出してくれるよう “成り代わり” をさせたい (できるかは知らんが、試してみる価値はある)
@noellabo やっぱそうなるんですね……ひとまず Ruby (on Rails) でよかったと思っておきます
暗号フィールドを含むモデルを、同一構造の暗号フィールドじゃない版のモデルにコピーするコード書いて、railsで一回走らせればええんやないかな。そしたら、あとはPostgreSQLレベルで対応できるようになる。
あと、いま検討してる設計でも、暗号フィールドを含むフィールドを別モデルに切り出して小さくしようとしてる。
accountsから秘密鍵などだけ別テーブルに抜き出すとかね。
使わないときにデコードのコストを掛けたくないわけ。
このアカウントは、notestockで公開設定になっていません。
SDF Public Access UNIX System - Free Shell Account and Shell Access
https://sdf.org/?faq?BASICS?01
なんか自衛隊っぽいドメインのサーバあるなと思ったが、当然ながら関係なさそうだった (それはそう)
class Account < ApplicationRecord
encrypts :private_key
end
Railsのコード的にはこれだけだしね。あとは透過的に処理されるので。
いやわかってるよ本当は繁殖じゃないって。この作品はフィクションだから真似してはいけませんという意味なんだよね。
このアカウントは、notestockで公開設定になっていません。
寒くて忙しくて医療機関が混雑or休みの年末に大掃除する悪習はマジ早いとこやめた方がいいと思うんだ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。