ぐるみんの曲は聴くとやりたくなっちゃうのでダメ
ぐるみんの曲は聴くとやりたくなっちゃうのでダメ
やるしかないわね! | #NowPlaying 悲しき蒼穹を翔ける / ぐるみんオリジナルサウンドトラック / ファルコム・サウンド・チーム・JDK
from #AppleMusic #ゲーム音楽
流星のサウンドBOXだけないんだよな
#NowPlaying VS ネビュラグレイ / ロックマンエグゼ サウンドBOX / Capcom
from #AppleMusic #ゲーム音楽
どの国もそうだが、立憲政体だと警察力への抵抗手段がいかに速くいい弁護士を呼ぶかゲームで、警察側はいかに弁護士を呼ばせないかゲームになりがちなのがあれだよな
さすがに返還されるんだw
> 家宅捜索のあと、当然のようにありとあらゆるデバイスが押収されます。
> 意識の高いエンジニアなのですべてのデバイスに個別のパスワードを設定していましたが、意外なことにこれを警察に教える義務はないそうです。
> そうすると当然押収は意味をなさず、何を調べられることもなく右から左へ返還されるのだとか。
おっ | エンジニアのための刑事事件対策まとめ https://qiita.com/moroi/items/e9db57db2bcdbc089ca1 #Qiita @moro_isより
ドレスコードないと人は全裸で街を歩くようになるらしいので、青空見るのに招待コードが必要なのもあながち間違いではないかもしれない（？）
青空見るのに招待コード必要なの、待ち歩くのにドレスコードが必要な感じ（？）
の投稿
jj1guj@misskey.io
このアカウントは、notestockで公開設定になっていません。
Hostodon だと 500 円/月ではじめられるしな
運用費抑えられればもうこれでいいやって感じだ
おすすめユーザもおひとり様サーバになってから (多分ローカルの余計なノイズが乗らなくなって) 機能するようになったので、大体ことが足りてる
ActivityPub、もう大体これで良くない？と思ってる
図で描かれると分かった気持ちになるが、実際にどういうことだって聞かれると全然分かってなかった現象なんなんだろな
concurrent のお気持ちはまだ分からんけど
やっぱ実装してみんことには課題って分かんないよな
GC のお気持ちがわかるようになってきた
このアカウントは、notestockで公開設定になっていません。
辛そう | チャットGPTが示した実在しない判例、NY弁護士が引用 懲戒検討 | 毎日新聞 https://mainichi.jp/articles/20230530/k00/00m/030/048000c
迷惑千万にもほどがあるだろ
メタバースが来るとか勝手なこといってたやつらが勝手に失敗しただけの状況で、まるでメタバース事業が不穏みたいな空気を醸し出さないでほしい
度々 load avg のアラートが飛んでくるので、どういうジョブが入ってるか見るかって言って放置してるな
気づいたら今日 (昨日) が終わってた。寝るか
strict provenance はまだ結構課題が多いって感じなんか
https://github.com/rust-lang/rust/issues/95228
@noellabo なるほど、WebFinger の JSON の方には verified_at は含まれてないんですね。ローカルはローカルで verified_at 持ってるんですね、なるほど
ならば、リモートの方を見ないようにすれば確かに安全そうですね。ありがとうございます！
@noellabo https://github.com/mastodon/mastodon/blob/55785b160320783392ffe3f24c5ca48e6ee7a5f2/app/services/activitypub/process_account_service.rb#L60
ちゃんとローカル側でも verify link 走らせてるんですね。リモートサーバまで見に行かないでローカルサーバで Verified がついてるかを確認するようにすれば安全そうですね
@noellabo verified_at じゃなくて field entity でした
https://docs.joinmastodon.org/entities/Account/#Field
@noellabo ちょっと気になるので今調べてるんですが、Account の verified_at がリモート側の言い分を信じてたら、ユーザにはその URL の持ち主が verified したアカウントのように見えてしまうので、信ぴょう性が上がると思ったという感じです
つまり、https://ruby-ill.social にインスタンス立ててそこに verified_at: https://github.com/ruby を送ってくるアカウントを作ってリレーとかにばら撒くと、Ruby 公式垢に見えてしまったりしないかなと
Mastodon、実は結構詐称に弱いのか？UI が幾つかリモートに行く前提だから、リモート側の Web UI 工夫するだけでいくらでもフィッシングできそうだな
Mastodon fork して、なんでもかんでもリンクに verified つけるようにすれば、本人詐称できることに気づいた。ちゃんとリンク先から見れるようにするのがいいのか (さっきのは普通に公式垢っぽい)
それ使えば Rust の allocation の邪魔しないで malloc 独自実装できる？
virtual address space reserve の方法よく分からんので後で Go の malloc ちゃんと読むか
普段はこういうの書かないので新鮮味があるな
最終的には下位3bit Pointer Tagging ぐらいしたいよな
Rust よく分からずに使って低レイヤいじるのめちゃくちゃ無謀感があって良い（？）
とりあえずこういうの書き始めた
https://github.com/mizunashi-mana/mini-stk-lang-with-ms-gc
soundness や decidability といった性質と計算オーダーが重要な分野から、ベンチマークで速ければ勝ち・なおベンチマーク結果はプラットフォーム毎に変わるぞみたいな分野への移行、結構ギャップがあっておもろい
なんかいっぱい図は溢れてるし、こうやったら速くなりそうみたいなアイデアも溢れてるんだが、実際の実装テクニックは溢れてない
メモリ管理、GC よりまず先に考えることが色々あるのだが、その知見があまり巷に転がってない (探し方が悪いのかもしれない)
メモリ管理初心者なので、初めての GC 実装でめっちゃ知見を得ている
Twitter がヘイトの溜まり場になって問題と言われるが、じゃあ Mastodon / Bluesky がそれを解決してるかって言われると微妙なとこだよな。つまりヘイトの溜まり場になることを一般ユーザが望んでおり、単に敷居が高くてそういうユーザが流れ込んできてないのが今の Mastodon / Bluesky だったとしたら、そもそも色々根底がアレだし
技術屋としては、技術でどのように解決するかを考えがちだけど、技術で解決できることなのかを本来考えるべきなのよなとは思う。思うが、まあ技術で解決できると思った方が色々楽しいのはそう
Bluesky は招待コードが届かないのでまだ見ぬエデンって感じ
なんとなくで Mastodon 管理をやってるので、キャッシュとメディアの違いもわからない
tootctl 分からなすぎ
アイコンが死んでる人のアイコンを復活させる方法 [検索]
#マストドン管理部
このテクニックは malloc 併用にも一役買ってるらしい。つまり、fixed size の細切れ object 置く arena はこの予約した領域で管理し、後は必要になったら mmap で領域足せば良いわけか
> A note about virtual memory
> This guide has largely focused on the physical memory use of the GC, but a question that comes up regularly is what exactly that means and how it compares to virtual memory (typically presented in programs like top as "VSS").
https://tip.golang.org/doc/gc-guide#A_note_about_virtual_memory
#miteru #Golang
cgoとunsafeについてのメモ
https://hnakamur.github.io/blog/2019/12/29/cgo-and-unsafe/
#miteru #Golang
まあ、まさかメモリ容量が短期間でここまで膨れ上がるとは誰も思わんよ
system allocator だけで事が足りてた時代 (というか分割できるほどのメモリがなかった) にできた API だからな
> Interaction with the system malloc
> It is usually best not to mix garbage-collected allocation with the system malloc-free. If you do, you need to be careful not to store pointers to the garbage-collected heap in memory allocated with the system malloc.
https://www.hboehm.info/gc/simple_example.html
感覚的にはそんな感じがしていたが、世の中の allocator はやっぱ基本的には併用は考えられておらず、持ってても non-management heap 発行する機能ぐらいみたいな状況なのかな？
Cloudflare が死んだら、諸々の情報発信が死ぬ感じになった
Rust、めちゃくちゃなんとなくコンパイラに言われた通り書いてるが、自分で何書いてるのかよく分からない (圧倒的知見不足)
まあ、最近の malloc だとあんまりそういうことないのかな？
allocator 独自実装ってそもそもするものなんかな？まあでもしたいよな、malloc で適当に配置されてせっかく fragmentation 対策したのに malloc 側で fragmentation 起きても微妙だし
どうにもよく分からんので、質問してみた
https://prog-lang-sys-ja.zulipchat.com/#narrow/stream/343525-.E8.B3.AA.E5.95.8F/topic/allocator.20.E7.8B.AC.E8.87.AA.E5.AE.9F.E8.A3.85.E3.81.A8.20malloc/near/361682620
> 最近メモリ管理と GC について勉強し始めて、かなり初心者の状態で右も左も分からないという感じなのですが、GC でヒープ管理をする場合 libc malloc に頼らず allocator 独自実装したい場合も多いと思うのですが、その場合 libc malloc との併用は考えない場合が多いのでしょうか？またその場合、malloc がもしよばれてしまった場合のケアなどをするデファクトの方法などはあるのでしょうか？
そもそも malloc & free span が短い arena において、GC marking bit だけ局所化したところで局所化とは？って感じやしな
巷には、bitmap marking で変更を局所化できて嬉しいとかいう記事が出回ってるわけだけど、それいうための前提条件めっちゃ多いよね？という感じだ
当たり前のことだが、Allocator がないと Vec / Box とかも気軽には使えないわけだ
Rust で no std 縛り、めんどくさくなったので malloc 実装は諦め
Glibc malloc internal
https://www.slideshare.net/kosaki55tea/glibc-malloc
#miteru
