【音MAD】カクシカ色デイズ / ダイハツ部 - YouTube
https://www.youtube.com/watch?v=aP-f9cUGYlk
share と reload がハンバーガーメニュー使わずアクセスできるようになったのはかなり QoL 上がりそう
ストレージストラテジーガイド | Red Hat Product Documentation
https://docs.redhat.com/ja/documentation/red_hat_ceph_storage/7/html-single/storage_strategies_guide/index#what-are-storage-strategies_strategy
storage strategies、字面と語呂が若干洒落っぽい
36ベイで Xeon ×2 なマッスィーンをプライマリな NAS として使っているのだが、 CPU 使用率的に完全に持て余しており、もう少し運用方針を真剣に考えるべきか真剣に悩んでいる
問題は電源が冗長化されている x86 マシンがこれしかないので他のやつらにプライマリな NAS を任せられないという点。
UPS でしっかり電源を確保できれば他のマシンでもあるいはという感じなのだが、電気代と UPS の維持費どちらが安いか考える必要がある
メモリがちゃんと 256 GB 載っており計20物理コア40スレッドなので、むしろ仮想化ホストに適任のはずだが。
ヘビーな計算用にどうかというと、ちゃんとノードを跨いで計算を分散できるなら最近の Ryzen とかの方がシングルコア性能は普通に高そう (なんならクロック周波数2倍とかある) で、そっちは正直そんなに魅力的でもないかもしれないが。
どうせ CI なんか複数構成でのビルドを試すことになるので、1ノードだけ速くてもしょうがない。
TrueNAS を1ノードだけにしておいてバックアップを Synology へというのは考えたのだが (というか昔やっていたのだが)、ハードウェア故障があった場合のフェイルオーバーがかなりダルそうなのであまり良い選択に思われない
今のところは TrueNAS の replication を使っているので、プライマリの NAS が故障してもセカンダリな TrueNAS を代わりに使うことができるようになっている
そもそも Xeon とか ECC メモリとか Xeon 用2ソケット M/B とか生産完了したケース用の SATA バックプレーンとか、普通に入手性が悪そうだし (中古市場を漁りまくれば転がっているかもしれないが) ハードウェア故障の可能性とは真剣に向き合うべきだな
SATA HDD の10個やそこらなら、いざとなればどうにか工夫してデスクトップ用でも接続できる範疇なので、あとはケースだけの問題? ほんまか?
RM400
https://www.silverstonetek.com/jp/product/info/server-nas/RM400/?location=GB
たとえば SilverStone の RM400 などは 4U ラックマウントで3.5インチ8ベイなので、まあまあイケている。これにデスクトップ用構成で組んでやれば、容易なホットスワップは捨てることになるがとりあえずハードウェア的にはどうにかできる感じになってきそう
Very Slow Network Performance on Virtual Machines | TrueNAS Community
https://www.truenas.com/community/threads/very-slow-network-performance-on-virtual-machines.94883/
VM 内の OS アップデートが 24kB/s で泣いているのだが、もしかしてこれか……
サーバ用の M/B で PCIe の空きスロットはたっぷりあるので、 10G NIC もうひとつくらい追加しても良いのかもしれん
小さくはあるがそんなに物理的な力の必要な工程はないので、扱いにおいて DDR4 とか DDR5 の RAM をしっかり挿すときほどの恐怖はない
「ちょっと力加減を間違ったり向きがズレたりしたら壊れるぞ……」みたいな恐怖が全然ないので気楽なものである
まずはハードウェア故障に対してフェイルオーバーで対応するのか部品交換で対応するのかを考えるべきなのか?
toka の背面排気の温度を確認したところ35.9℃のようなのだが、これは室温も上がるわけだ (窓を開けているのにデスクが 30.4℃ 64%RH)
続いて賞味期限が 07-08 のヨーグルトを胃にデプロイしている。賞味だからへーきへーき
Rust で変数もとい束縛が書けそうな場所には大体パターンが書けるの合理性はあるけどちょっとびっくり仕様だよなやっぱり
Rust のおもしろ&びっくり valid 文、
(|(true|false)|true)(true);
とかがある
irrefutable ならなんでもいいので極論
||->(){(|()|())(())}();
も valid
これはまあ closure の文法がアレ説はある (とはいえ開閉で別記号にしたところで駄目なものは駄目であることは C++ で証明されており……)
このアカウントは、notestockで公開設定になっていません。
海外MMO開発元、CPUのインテルを名指しで批判。「欠陥CPUを販売している」として - AUTOMATON
https://automaton-media.com/articles/newsjp/intel-20240713-301727/
Pentium の FDIV バグを思い出してきた
ランキングから適当に漁って読んでみたネッツ小説の文体がキツすぎたが、「いや私も若者の生き血を啜って若さを保たねば……」となりながら読み続けた。
無理だった。
コードレビューをするときとかに特に意識していることがあって、それは「必須かどうか」「要請かどうか」を明確にすること。
* 必須であり要請: 「〜のようにする必要があります (あると思いますが、いかがでしょうか)」
* 必須ではないが要請: 「必須ではありませんが特別な理由がなければ今回の場合は〜のようにするのが望ましいかと思います」
* 必須であり要請でない: 「AのようにしたければBする必要があります」 (←Aする必要があるとは言ってない)
* 必須でなく要請でない: 「一般に〜のようにするのが良いとされていますが、必須ではないです」
RFC 2119 の語彙でヨロシク! と言って通じるならそれが楽なんだけど、 “純粋な自然言語” でやりとりをすると迂遠になりがちね
全人類,とまでは言わないが,†報・連・相†を徹底させたいなら「issue立てるときのテンプレートみたいなやつ」を真っ先に紹介すべきだと思うんだけど,どう?
チェックリストの意味のなさをいつも思ってたけど、まさにこれだわ。「こういうのでいいんだよ、こういうので」 - Togetter [トゥギャッター]
https://togetter.com/li/1726711
これ「理想の状態を書くよりも、理想の状態に近付けるための操作をチェックリストの項目とすることが望ましい」みたいな話なかったっけ
それが理想なんだけど,「どうすれば」以前に「どうなっていてほしい」」すら書いてない現状が問題という話です(今は)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
それはそれとして産業用の高性能なグラボってロープロだったりはしないんだ (リプで 4060Ti とか言われてるけど)
精一杯換気しているが 31.7℃ 63% で汗が引かない。外は涼しいようだが湿度が高すぎて無理だ。
このアカウントは、notestockで公開設定になっていません。
私の同期で「VMにLinux入れてるときはピンと来てなかったけど中古のノートPCで直接ブートして遊んでたら分かった」ってひともいましたね
これは極めて個人的な感覚だが、「触って様子を見てみる」みたいな考え方がもうダメというか、 “Lチカしかやらない人未満” というか (暴言)
「便利ならメインにする」くらいの気概がないと見るべき場所がどこなのかさえわからないまま浅瀬でちゃぷちゃぷするだけになるだろ、そんなことならいかがでしたかブログでも読んでる方がマシ
まあでも “手を動かすことへの信仰” みたいなのって結構根強いのだろうなとは思う。残念ながら私はそういう信仰ないので共感はしないが。
このアカウントは、notestockで公開設定になっていません。
メモリ 128 MB のマッスィーンで Knoppix を動かしていたときはつらかったなぁ (?)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
「学習曲線が低い (そして上昇させづらい)」みたいなのはあると思う。そして人々にとって使いやすさとは学習曲線の勾配ばかり目につくものなのだ。