これは置き場が決まらないうちに電源投入して運用開始してしまった19インチサーバラック
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
これは置き場が決まらないうちに電源投入して運用開始してしまった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 だと異様に安かったりするのに
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
ストーリアダッシュ、『魔法少女にあこがれて』アニメ化もいいニュースだけど『灼熱の卓球娘』の連載がまたはじまっててめっちゃいい。うれしいね >>
灼熱の卓球娘 REBURN!!│ストーリアダッシュ
https://storia.takeshobo.co.jp/manga/shakunetsuno/
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
とりあえずサブモニター浮かせてみる。メインモニターのほうが圧倒的にスタンドが邪魔なのでこっちを何とかしたほうがいい気もするが、まあ気に入ったら考えます…
DS2422+ はやく安くならないかな……
実家にオフサイトバックアップ用に DS1821+ を持って帰りたいので、それに代わるもっとデカい NAS を欲している
This account is not set to public on notestock.
信じていいかは知らんけど、壊れたとき別の RAID カードへそのままお引越しできないから云々みたいな話は聞いたことがある (実際どうなのかは知らない)
RAIDコントローラが互換なものを選ばないとアレイの構成情報を読んでくれないみたいな話らしい、まあそれはそうか
単にミラーしたりで済むアレではないからと。そうなるとやっぱダルいのでソフトウェアでやった方が個人では楽な気がするな
This account is not set to public on notestock.
This account is not set to public on notestock.
共有が必要なら NAS を用意するのが最適解では (市販品にするか自前サーバにするかはさておき)
まあ速度は生ディスクに比べるべくもないが……
This account is not set to public on 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
30日で 72 kWh ですね……
フリービット、「固定IPアドレス付きIPv6（IPoE）接続サービス」提供開始 - INTERNET Watch
https://internet.watch.impress.co.jp/docs/news/1486496.html
Mastodon v3.5.7 と 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 使った)
ghcr.io の mastodon:v4.1.1 まだ来てないねぇ
これ何度も言ってるんですが、古いバージョンを使い続けることってめちゃくちゃ技術力を要することなので、不安なら全部最新を維持した方がいいです。
実際には起きないけど、もし今日突然GitHubがなくなったら北極圏にコード掘り出しに行かないと社会めちゃくちゃになりそうだなとふと思った
北極に射精管理システムが埋まってるんだよな…
どの部分が「うわぁ」なのかよくわからない＞＜；
(==でいいじゃんって思うし重いかもしれないって重い判定が必要な場合には重くなるの当たり前じゃん感だし、==演算子のオーバーロードをしてある何らかのクラスの当該処理がnull比較でも重いのであれば、そのクラスの問題(そのクラスを書いた人の責任)でしょ？＞＜
それをやめれって制限かけてったらJavaみたいな、ちょっとオリジナルの数値型を作ろうとするだけで演算子が使えなくなる柔軟性の無い言語に行き着いちゃう＞＜)
よく知らんけどRubyみたいに既存のクラスの振る舞いさえ変わっちゃう言語(？ よくわからん)ならあれだけど、新たな数値型を実装したりする場面とかで演算子のオーバーロードを使って、そのなかでの演算子を使う処理が重いかもしれないって、文句あるならそういうの使わずに組み込み型使うとかすりゃいいじゃん＞＜
型安全の考えに対して逆行してると思うけど＞＜
うわぁポイントはいくつかあって、一番根本的で今更どうしようもないのは変数が透過的に参照になっているところで、アドレスと値を明示的に区別できる言語仕様なら「ポインタと 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 外から参照可能な名前を宣言/定義する」というのは妙じゃないですか？
ところが最後のコード例を見ると残るっぽい書き方になってる
あー、もしかして early return する if の場合は後続コード全てが暗黙に else 節に入っているというセマンティクスになってる？
なら理解はできるけど、名前の導入くらい重要なことはちゃんと専用の文法を用意しなよと思うわ
まああとオマケで、 ! 演算子が前置と後置の両方で使えるのも x !is not null (本当は x! is not null 相当の解釈をされている) の勘違いが通ってしまう原因なので、そこは記号を変えるなりすべきで前置/後置演算子両方あり (しかも意味は全然違う) みたいな割当は避けるべきだった
まあ言語仕様なんてだいたいは「今更後知恵で言われても」ばかりなのでそういうものだろうけど、それは妥協する理由ではあっても減点しない理由ではないので……
その変な書き方自体その記事ではじめて知ったし、オレンジは古いバージョンのC# で書いてるので使えない書き方かもしれない＞＜
でもどっちにしてもオレンジは
if (hoge!=null) { なんか処理 }
みたいな書き方しかしないから、別にいい＞＜(？)
そりゃまあ != を重めにユーザ定義しない人には関係ない話だろうけど
一応擁護？しておくと
if (!int.TryParse("hoge", out var x)) return;
Console.WriteLine(x);
という構文はあります
「俺はそんなしょーもない書き方はしない」はそれはそうなんだが、問題は私が他人の書いた C/C++ コードが踏んでいる未定義動作をケアしないといけない立場にあるところでして……言語仕様の堅実さと綺麗さがそこで効いてくるんだよな
これはおもしろいけど、ラーメン でリンクした先が ダイエット に変更される場合にはリダイレクトによっても解決できていない気がする https://scrapbox.io/shokai/wikiでページのURLをIDにすると絶対にうまくいかない
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
そもそも id は identifier なわけだが、記事の内容も本質もメイントピックも可変であるような状況で同一性 identity とはそもそも何なのだろうかと思う
個人的に運用するなら、
* 名前と無関係な id を割り振る
* メイントピックや内容の本質が変わらない変更は (必要に応じて変更前の状態が推察できるようにして) そのまま突っ込む
* 内容やメイントピックが大幅に変化する場合、新しく別々の id で記事を作り、リンクやリダイレクトで繋げた上で旧記事に obsolete マークをつける
みたいな感じにするかな。 RFC とかを想像すると近いかも
URI as a locator (あるいはルーティング) として見るのなら「自動で検索をかけて、最もマッチしたもの{を返す/に飛ぶ}」で良いだろうけど、それは URI as an identifier ではないので後者の在り方を論じるときに通用する方法論ではないなと思う
https://www.aozora.gr.jp/cards/001029/files/43291_21543.html
我々は、例えば、この蜜蝋をとろう。それは今しがた蜜蜂の巣から取り出されたばかりで、未だ自己の有する蜜のあらゆる味を失わず、それが集められた花の香りのいくらかを保っている。その色、形体、大きさは明白である。すなわち、それは堅くて冷く、容易に掴まれ、そして指で打てば音を発する。要するに或る物体をできるだけ判明に認識し得るために要求せられ得ると思われる一切が、この蜜蝋に具わっている。しかしながら、見よ、私がこう言っている間に、それを火に近づけると、残っていた味は除き去られ、香りは散り失せ、色は移り変わり、形体は毀され、大きさは増し、流動的となり、熱くなり、ほとんど掴まれることができず、またいまは、打っても音を発しない。それでもなお同じ蜜蝋は存続しているのか。存続していると告白しなければならぬ。
蜜蝋が融けて変化したからってそのモノの本体は変わらんやろ(同一性が維持される)というのがデカルトの見解だけど、これは物体の同一性が外在的にあるっていうより、認識論だよね。
web の場合はむしろ「誰かがそのように認識した、その瞬間のもの」を参照できるようにしたいので (たとえば本題が同じであろうと、誤解しやすい書き方であったのならその書き方そのものを参照したい)、むしろフォーマットよりも認識の方に楔を打ちたいよな。
ある記事が markdown だったのが HTML に変換されていても参照には大した影響がないが、ミスや古い内容が訂正されていると場合によってはかなり困る
記事について (経時的に) 何を「同じ」だと思うのか、というのはかなり重要な問だと思う
経時的同一性の確保、スナップショットとバージョニングで太古の昔よりうまく行っており、ｲﾝﾀﾈｯﾂ時代になっても相変わらずそうなので (差分を扱う技術は著しく発達したが)、まあ本質的にそれが良い策なのかもしれないなと思う
有用なドキュメントを作るために心掛けたいこと - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2018/12/24/creating-useful-document/#stable-permalinks-per-sections
「セクション名をそのまま ID に使うな、リンクぶっ壊れるだろうが」という話は昔書いた
これがセクション ID であっても記事全体の URI であっても本質的には同じことで、タイトルは情報の要約ではあっても、使いやすいハッシュではない。「コメ」を「米」に書き換えて破綻するような素朴な slug 生成はそもそも ID の類に使うべきでない
デカルトの蜜蝋は、蜜蝋の同一性が脳内に確立されているからこそ、「蜜蝋は融けた」と変化について言及することができる。デカルトが考えているのは、「蜜蝋の同一性」とはあきらかに脳内にある概念のことで、イミュータブルな性質をもっている。
This account is not set to public on notestock.
しかも被参照を考慮すると、潜在的にオブジェクトにアクセスを持つすべての人が自分のうちに情報の同一性観念を持っており、おそらくそれらはあまりアラインされていない……
となると、やっぱり原則としてはすべて別物にしておいて、クエリのレイヤーで「俺 (閲覧者) の考える同一視」を反映するような仕組みが良いのだろうな
あるいは「どのような強さの変更が入ったか」を管理できる semantic versioning (<https://semver.org/lang/ja/>) のような何かで名寄せすることをオブジェクト作成者に要求する必要があるかもしれないけど。
ミスの訂正を自動で反映してほしい人もいれば、「この typo は興味深い」と考えていて typo 修正が適用される前の版を参照し続けたい人もいるかもしれない。これは編集する側で判断できることではないので、閲覧者側にクエリ機能を寄せるしかない
This account is not set to public on notestock.
This account is not set to public on notestock.
書籍の同一性と版といえば、 ISBN をいつ変えるかとか再利用されてるとか、そっちはそっちで話題があったな……
This account is not set to public on notestock.
