これは置き場が決まらないうちに電源投入して運用開始してしまった19インチサーバラック

LANケーブル、15 cm だと上下の隣同士 (1U の距離) しか接続できないし 50 cm だと 2U 跨いで 3U 分の距離を渡しても大いに余るので、 30cm が欲しい

Amazon.co.jp: Amazonベーシック パッチインターネットケーブル サーバー用 ギガビットイーサネット ハイスピード RJ45 Cat 7 ホワイト 約0.3m : パソコン・周辺機器
https://www.amazon.co.jp/dp/B07ZTR9K9Z

一番最初に出てくるのが STP な RJ45 の Cat7 (笑) ケーブルでだいぶカス

0.3m 、ラインナップはあるが高い…… 0.5m だと異様に安かったりするのに

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

DS2422+ はやく安くならないかな……

実家にオフサイトバックアップ用に DS1821+ を持って帰りたいので、それに代わるもっとデカい NAS を欲している

このアカウントは、notestockで公開設定になっていません。

信じていいかは知らんけど、壊れたとき別の RAID カードへそのままお引越しできないから云々みたいな話は聞いたことがある (実際どうなのかは知らない)

RAIDコントローラが互換なものを選ばないとアレイの構成情報を読んでくれないみたいな話らしい、まあそれはそうか

単にミラーしたりで済むアレではないからと。そうなるとやっぱダルいのでソフトウェアでやった方が個人では楽な気がするな

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

共有が必要なら NAS を用意するのが最適解では (市販品にするか自前サーバにするかはさておき)

まあ速度は生ディスクに比べるべくもないが……

このアカウントは、notestockで公開設定になっていません。

UHK 60 v2 についてきた C to C ケーブルが死んだっぽくて、泣きながらｱﾏﾝｿﾞｿﾞでコネクタ部の持ち手の短いケーブルを注文した

電源は通っていてデータ線が死んでるっぽい

乱暴な使い方はしていないはずだが、束ねてあった部分をほどいたらお亡くなりになったので、たぶん内部の銅線が見た目より柔らかくなくて疲労で折れたとかそのあたりかなという感じがする。しらんけど。

ケーブルチェッカー持ってないからなぁ

Release v4.1.1 · mastodon/mastodon
https://github.com/mastodon/mastodon/releases/tag/v4.1.1

ｱﾋﾟﾃﾞして寝るか

mastodon versions · mastodon
https://github.com/mastodon/mastodon/pkgs/container/mastodon/versions?filters%5Bversion_type%5D=tagged

ghcr.io の方にまだ v4.1.1 tag が来てなくて引っ掛かった (仕方ないので edge 使った)

期せずして、 NAS 2台 (HDD 計11台) で100W であることが判明してしまった

残りの65Wはルータ1台、10Gスイッチ2台、 Wi-Fi6 無線 AP、 RasPi 4 Model B

100W かぁ……

30日で 72 kWh ですね……

自前サービス用に軽率にドメインやメールアドレスを生やしがちなので、ドメイン数とかユーザ数に制限がある専用メールサーバは怖くて使えない

ghcr.io の mastodon:v4.1.1 まだ来てないねぇ

……と投稿した瞬間に来たわw

ソドムとゴモラみたいなスパイス

C# の null 判定の話 | ++C++; // 未確認飛行 C ブログ
https://ufcpp.net/blog/2020/12/isnull/

うわぁ……

うわぁポイントはいくつかあって、一番根本的で今更どうしようもないのは変数が透過的に参照になっているところで、アドレスと値を明示的に区別できる言語仕様なら「ポインタと null を比較」は「ポインタの参照先の値をユーザ定義の比較演算子で比較」と混同しようがなかった。
透過的な参照は他にも shallow copy と deep copy の問題とか引数渡しと書き換えの問題とかを発生させる悪しき概念だと思う。

で、次に妙なのが、バインドを伴うパターンマッチと boolean の式としての条件式が同じ書き方をできて、しかもそのバインドのスコープが if を抜けた箇所まで残ってる部分。
if (a.X is not { } x) return;
の後ろまで x が残るのは普通にうわぁとなります (ブロックスコープのない Python かよ……)

たとえば C++ でも if(auto x = hoge) {...} における x のスコープは then 節と else 節の中で済んでいるはずで、「if の条件の形で if 外から参照可能な名前を宣言/定義する」というのは妙じゃないですか？

ところが最後のコード例を見ると残るっぽい書き方になってる

https://ufcpp.net/blog/2020/12/isnull/

あー、もしかして early return する if の場合は後続コード全てが暗黙に else 節に入っているというセマンティクスになってる？
なら理解はできるけど、名前の導入くらい重要なことはちゃんと専用の文法を用意しなよと思うわ

まああとオマケで、 ! 演算子が前置と後置の両方で使えるのも x !is not null (本当は x! is not null 相当の解釈をされている) の勘違いが通ってしまう原因なので、そこは記号を変えるなりすべきで前置/後置演算子両方あり (しかも意味は全然違う) みたいな割当は避けるべきだった

まあ言語仕様なんてだいたいは「今更後知恵で言われても」ばかりなのでそういうものだろうけど、それは妥協する理由ではあっても減点しない理由ではないので……

そりゃまあ != を重めにユーザ定義しない人には関係ない話だろうけど

ふーむ……？

「俺はそんなしょーもない書き方はしない」はそれはそうなんだが、問題は私が他人の書いた C/C++ コードが踏んでいる未定義動作をケアしないといけない立場にあるところでして……言語仕様の堅実さと綺麗さがそこで効いてくるんだよな

人類 C++ やめてほしい

㍂

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

そもそも id は identifier なわけだが、記事の内容も本質もメイントピックも可変であるような状況で同一性 identity とはそもそも何なのだろうかと思う

個人的に運用するなら、

* 名前と無関係な id を割り振る
* メイントピックや内容の本質が変わらない変更は (必要に応じて変更前の状態が推察できるようにして) そのまま突っ込む
* 内容やメイントピックが大幅に変化する場合、新しく別々の id で記事を作り、リンクやリダイレクトで繋げた上で旧記事に obsolete マークをつける

みたいな感じにするかな。 RFC とかを想像すると近いかも

URI as a locator (あるいはルーティング) として見るのなら「自動で検索をかけて、最もマッチしたもの{を返す/に飛ぶ}」で良いだろうけど、それは URI as an identifier ではないので後者の在り方を論じるときに通用する方法論ではないなと思う

web の場合はむしろ「誰かがそのように認識した、その瞬間のもの」を参照できるようにしたいので (たとえば本題が同じであろうと、誤解しやすい書き方であったのならその書き方そのものを参照したい)、むしろフォーマットよりも認識の方に楔を打ちたいよな。
ある記事が markdown だったのが HTML に変換されていても参照には大した影響がないが、ミスや古い内容が訂正されていると場合によってはかなり困る

記事について (経時的に) 何を「同じ」だと思うのか、というのはかなり重要な問だと思う

経時的同一性の確保、スナップショットとバージョニングで太古の昔よりうまく行っており、ｲﾝﾀﾈｯﾂ時代になっても相変わらずそうなので (差分を扱う技術は著しく発達したが)、まあ本質的にそれが良い策なのかもしれないなと思う

有用なドキュメントを作るために心掛けたいこと - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2018/12/24/creating-useful-document/#stable-permalinks-per-sections

「セクション名をそのまま ID に使うな、リンクぶっ壊れるだろうが」という話は昔書いた

これがセクション ID であっても記事全体の URI であっても本質的には同じことで、タイトルは情報の要約ではあっても、使いやすいハッシュではない。「コメ」を「米」に書き換えて破綻するような素朴な slug 生成はそもそも ID の類に使うべきでない

このアカウントは、notestockで公開設定になっていません。

しかも被参照を考慮すると、潜在的にオブジェクトにアクセスを持つすべての人が自分のうちに情報の同一性観念を持っており、おそらくそれらはあまりアラインされていない……

となると、やっぱり原則としてはすべて別物にしておいて、クエリのレイヤーで「俺 (閲覧者) の考える同一視」を反映するような仕組みが良いのだろうな

あるいは「どのような強さの変更が入ったか」を管理できる semantic versioning (<https://semver.org/lang/ja/>) のような何かで名寄せすることをオブジェクト作成者に要求する必要があるかもしれないけど。

ミスの訂正を自動で反映してほしい人もいれば、「この typo は興味深い」と考えていて typo 修正が適用される前の版を参照し続けたい人もいるかもしれない。これは編集する側で判断できることではないので、閲覧者側にクエリ機能を寄せるしかない

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

書籍の同一性と版といえば、 ISBN をいつ変えるかとか再利用されてるとか、そっちはそっちで話題があったな……

このアカウントは、notestockで公開設定になっていません。