このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
Amazon.co.jp: 本のまとめ買いキャンペーン: 本
https://www.amazon.co.jp/b?node=10538264051
これ物理今日までだ。大量に買うか
バベッジの階差機関に指を巻き込まれた人がいたため計算機の不具合がフィンガーと呼ばれるようになった世界 (?)
> I think the overall "deal with it now" approach Rust has is what really makes that statement true.
これ確かにそうだなぁと思った
諸々の API や言語仕様が explicit であるというのはどちらかというと "deal with it now" を実現させるための手段のひとつでしかなくて、その良さの本質は「潜在的な問題を後回しにさせない (後回しにしたまま忘れ去らせない)」というところにあるのかもしれない
このアカウントは、notestockで公開設定になっていません。
自宅サーバ・ネットワークインフラの構成で迷いがあるのもそうだし、 NAS のディレクトリ階層の整理もまだうまく固定できていなくて問題がある
このアカウントは、notestockで公開設定になっていません。
Turing Complete をやりたい気持ちと進捗したい気持ちが綯い交ぜになって
原神のマイナーバグキャプチャ動画が少しずつ蓄積されている
だいたいはキャラが宙に浮いたり地面に沈んだりするもの (?)
なんか物理に癖があるんだなというのが見えてきて楽しい (???)
XML Base (Second Edition)
https://www.w3.org/TR/2009/REC-xmlbase-20090128/
> In particular, xml:base="" does not reset the base URI to that of the containing document.
xml:base、一度設定したが最後、もうリセットはできないのがなぁ。いや、わかるにはわかるんだが。
XML DOM での扱いとかどうなってるんだっけと思って。
Node: baseURI property - Web APIs | MDN
https://developer.mozilla.org/en-US/docs/Web/API/Node/baseURI
> its value is determined by an algorithm each time the property is accessed, and may change if the conditions changed.
それは助かる
「Illustrator」の Ill と「ヌフフ」の類似点
このアカウントは、notestockで公開設定になっていません。
markdown のメモを作ろうとして手癖で .rs を作って syntax highlight が変になってるのを見て「？？？」となっていた
おっかしいなぁ、同じ VLAN 内で 10G スイッチと10GbEインターフェースを通して通信しているはずなのに max 950.27 Mb/s しか出てない
CIFS とかストレージ側で律速になっている可能性はもちろんあるんだけど、ちょうど 1Gbps で頭打ちになっているとなると流石にネットワークを疑わざるを得ない
と思ったら 1.4 Gb/s いってた。じゃあどこが遅いんだ……？
ルータの LAN ポートもまともに通信している様子はないので全部手前のスイッチでちゃんと折り返していると思いたいけど、 fast path とかに入ってたらパケットがカウントされていないだけなどの可能性もあり、まあわからん
しばらくルータと繋がるケーブル抜いてみたが、普通にコピー進行してたし、なんなら最高で 2.38 Gb/s 出てる。どうやら通信路ではなく NAS 側を疑うべきっぽい
わかってきた、 7200rpm の玉は 220 MiB/s くらい出てるのに 5400rpm の玉が 110 MiB/s くらいしか出てない。これで mirror(2)+mirror(2) でアレイ組んでるから 5400rpm ミラーが律速になってるのか
220 MiB/s が 1.7Gbps、110MiB/s が880Mbps だから、平均して 1.29Gbps くらい。かなりそれらしい値になってきた
やっぱり 5400rpm とか使うのやめてさっさと 7200rpm のミラーを沢山追加すべきですね……
うん？ ミラーを合わせて stripe を組んでいるから平均ではなく合算の速度が出るはずだが……
というかコピー終わっても HDD カリカリ言ってる、これ 07:00 にスケジュールされてるリモートバックアップのタスクが走ってるな。それで2で割って平均になっってしまったのか
てことは、フルスペックで頑張れば 3.2Gbps 出るってことだな。
20Gbps に全然届かないじゃん……
読み書き同時にやるとしても、全二重の 20Gbps のリンクを用意すると 20Gbps / (220MiB/s) だから 7200rpm の HDD の11.3倍くらいの速度が出るわけだ。
すると、 mirror vdevs 構成にするなら最低でも HDD 22台くらい積んでないとネットワークの速度をフルに出しきれないと。
とはいえ、もちろんこれは HDD に直にアクセスする場合の話で、ちゃんとキャッシュに載ったりなどすればもっと速くはなるわけだけど。
ZFS なら ARC があるから尚更。メモリも 256 GB 積んでるし……
しかし、このくらいの速度になってくると NVMe M.2 SSD でも積んで L2ARC なり ZIL なりをセットアップするのも手かもしれんな
その前に HDD アレイはそこそこにしておいて (たとえばアーカイブ専用にしておいて)、 SATA SSD でのアレイを組むことを検討すべきなのかもしれん。 600MB/s として 20Gbps まで4.2倍なので、4台で mirror vdevs を組めば書き込みは 10Gbps 近くいくだろうし読む方はちゃんと 20Gbps 活用できそう
CIFS や NFS のパフォーマンスがそこまで出るかは知らん。
だいたい速度を重要視する方の NAS に 12 TB の玉とかが載ってるのがそもそもおかしいんだよ。
多少割高でも 6 TB ×2 とかでやるべきだった。
まあ 12 TB も余ったら余ったで実家の NAS に積みたいので、容量あたり単価が安い方を先に買うだけ買っといて正解ではある。
しかし、何メートルも離れたマシン同士の通信が内蔵 HDD の何倍も速くなるの、すごい時代だな……
HDD どころか SATA 3.0 の 6 Gbps より速いからなぁ
何メートルとは言ったが普通に一般のご家庭でも Cat6A で数十メートルいけるし、光ケーブルとトランシーバを用意すれば建物だって跨げる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
2023-06-11 状況メモ:
SSD 1TB (WD Blue SA510): ¥8280
SSD 1TB (WD Red SA500): ¥15301
SSD 2TB (WD Red SA500): ¥30276 (¥15318/TB)
HDD 6TB (Seagate IronWolf Pro): ¥23120 (¥3853.3/TB)
HDD 6TB (WD Red Pro): ¥39420 (¥6570/TB)
HDD 6TB (TOSHIBA MN08ADA600/JP): ¥18980 (¥3163.3/TB)
選び方にもよるが、 SSD だと2〜5倍を覚悟する必要があるな……
HashSet / HashMap が alloc crate にないやつにまた引っ掛かった (mヶ月ぶりn回目)
そして何故か hashbrown が nostd 対応してるやつね (cf. <https://mastodon.cardina1.red/@lo48576/106000764972071041>, <https://mastodon.cardina1.red/@loliconductor/106000526179928268>)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Noctuaファンが光るブレードを狂ったように振りまくる後継を想像したが、そっちのファンじゃなかった (Noctua は光らないでほしい (?))
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
やっべ、 UB 書きそうになってた (事前に気付けた)
Rc::from_raw のコストは十分小さいと考えていいのかな
Rc::into_raw() でリークさせた *const Rc<_> に対して、元の Rc の所有権を消費することなく clone して新たな Rc を作りたいんだけど、一旦 Rc::from_raw() で戻してから clone して改めて into_raw() する必要があるのか？
Rc::as_ptr からでは Rc の復元ができないっぽいんだよな (refcount 情報が残っていないのでそれはそう)
かといって Box<Rc<T>> を作っといて *mut Rc<T> を保持するのも余計なアロケーションが増えて嫌だし
Feature: `Rc::clone_raw` (and for Arc) · Issue #48108 · rust-lang/rust · GitHub
https://github.com/rust-lang/rust/issues/48108
あっ……はい。
Add strong_count mutation methods to Rc by mystor · Pull Request #83476 · rust-lang/rust · GitHub
https://github.com/rust-lang/rust/pull/83476
こっちを使えばええじゃろと。なるほど？
ピンとこないのが、「一度の Rc::into_raw() で作成された *const T に複数回 Rc::from_raw() を呼び出すのは (仕様として) 許されているのか」なのよね。許されていそうな書きぶりではあるが明示はなさそうだし、仮に「Rc::into_raw() は Rc のインスタンスごとに別の値を返す可能性がある」という仕様だとしたら困る (そうではないとは思うが)。
https://doc.rust-lang.org/1.70.0/std/rc/struct.Rc.html#method.into_raw
> Consumes the Rc, returning the wrapped pointer.
"wrapped pointer" は Rc のインスタンスを跨いで共通だろという認識でいいのかな。そういうことっぽくはあるが……
内部実装としてはそうなんだけど、はたして恒久的な保証として提供されているのかというのが (ドキュメントの例もことごとく1対1で対応するように書いてある感じっぽい)
Any guarantee for validity of multiple `Rc::from_raw()` calls for single `Rc::into_raw()`? - libs - Rust Internals
https://internals.rust-lang.org/t/any-guarantee-for-validity-of-multiple-rc-from-raw-calls-for-single-rc-into-raw/18970
投げた
