Mastodon のフロントエンドがたまにコケてるんだけど、ログが全てアクセスログで埋め尽されており全く調査の役に立たない。
どうもコンテナやプロセス自体が死んでいるわけではなさそうなので、どういうコケ方なのかすらわからんし

GitHub のとあるプロジェクトを見て懸念を抱くなどした

デザイン的に隠蔽されているべきはずの内部 ID を「FFI で使いたいから」と堂々と露出する PullReq が投げられており、たぶんこれデザインの議論をすることなく merge されてしまうんだろうなぁと (というのも、 API リファクター前に一度既にそのようなことがあったはずなので)

プロジェクトオーナーの思想がちゃんと強めであればそういうところの分離なり慎重な検討なりがしっかり行われることを期待するけど、そうでもないと「需要あるしパッチもあるから」と軽率に merge されてしまい、いや……うーん……

こういうことがあると、車輪の再発明みたいなのをしたくなってしまうわけですね

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

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

よくやる

IPv6 は ::1 で済むから楽 (そういう問題か？)

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

ちょっと前に上げた SwitchBot Plug Mini の故障動画が RT されていて、さては故障者だな？ と思って TL を見に行ったら、大量の同様の症例報告が RT されていて参考になった ()

どうやら On/Off を繰り返すやつ相当メジャーな壊れ方らしい

稲の声域わからんので気になる

hypertext.makeup は割と渾身の作です (まだ使ってないけど)

https://hypothesis.kim/

個人的なｳｪﾋﾞサイトのドメインを考えています、口頭で簡単に伝えられるものが良い

☆4聖遺物、稀に4セット効果欲しさに必要になることがあるけど、基本的にそれ以外の目的で使うことは滅多にない (ないことはない)

熟知メインとかだと誘惑に負けて伸ばしてしまうことが……

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

キリストの生まれ変わりとか？ (これ以上はいけない)

参考:

List of people claimed to be Jesus - Wikipedia
https://en.wikipedia.org/wiki/List_of_people_claimed_to_be_Jesus

(イエスであると自称する人の一覧)

イベント前に閑雲の伝説任務やっとくか〜で依存関係を掘り下げたことなどはある

伝説任務は無闇にアンロックしない方がいい、さもないとここぞというところですごいことになる (<https://mastodon.cardina1.red/@lo48576/110999979931386445>)

宵宮との旅行を夢オチにされたの、トラウマになっている

でも何の任務だったか忘れたけど、ゲーム起動するたびにパイモンが何か言うのであまりに鬱陶しくて仕方なく進めた任務があったはず。何だったっけ……

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

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

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

ロボット掃除機の動線確保にも苦労しているのに、棚が動くとなるといよいよ空間が必要

棚というよりは引き出しみたいな感覚で使えると嬉しいのかもしれない (作業に応じて適切な資料や道具の入ったラックがデスクの横に来るとか)

労役中と趣味1と趣味2とで必要な棚は違うし、まあそういう使い方だと楽できそうというのは納得できる

ﾊﾟｿｶﾀのｵﾀｸなので基本ぜんぶﾊﾟﾖﾖﾝに入ってますが……

道具とか模型とか紙資料とかがあるならかなり便利だろうね

飯チャー半
飯チャー全

#知らぬ間に椅子の上で気絶部

Open Use ccTLD - ICANNWIki
https://icannwiki.org/Open_Use_ccTLD

9⁠3⁄4

なるほどね？ (U+2060 WORD JOINER, U+2044 FRACTION SLASH)

WJ なし:

355⁄113
8958937768937⁄2851718461558

PC でも Android 13 でもいける

type systems
https://type.systems/

いいね

ﾈｯﾂ小説を読んでいて、南方が寒くて北方が暖かい地理の設定を見たことがないので、そういうところの多様性のなさを感じるとﾈｯﾂ小説だなぁと思う

東の方に日本っぽい国がある設定とか、そういうのとはレイヤーが違う

もちろん日の昇る方角が違ったり自転方向が違ったり磁力の呼び方が違ったり地面が平面だったりするのかもしれないけど……

「南国 (なんごく)」と「北国 (きたぐに)」の読みの非対称性

空間ごとトーラスになってないと、地表がトーラスな程度では北極が点ではなく線として存在するだけになってしまうので問題は解決しない (?)

でも空間ごとトーラスだと太陽が無限に見えるなどの不具合がありそうだけど…… (3次元の循環がどういう構造になるかちゃんと考えてないのでこれは適当発言)

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

ロシア ナワリヌイ氏が死亡 プーチン政権批判の反体制派指導者 | NHK | ロシア
https://www3.nhk.or.jp/news/html/20240216/k10014361581000.html

#はじ論 来週発売じゃん、物理今日あたり体験版やるか……

UTF-8、まあまあ落とし穴は少ない方なんだけど、 redundant encoding だけはセキュリティホールになりかねない罠なので、できるだけ自前実装は避けたいところではある

読まずに書いたけどまさにその話だった。
まあ UTF-8 の罠って Unicode 一般の話 (grapheme cluster と “文字数” とか invalid code point とか) か冗長なエンコードくらいしかなさそうだし、それもそうか

UTF-16 の surrogate pair が実はどの順番でも良いみたいな話を聞いたときは白目を剥いたものですが

[EDIT: 規格を確認してみたところ、どうも嘘くさい]

文字とは……という話をさておくと、通信に使うのでもないのであれば redundant encoding の扱いをしっかりしたうえで自前実装というのはナシではないと思う。避けたいけど。

これ、どこで聞いた話かわからないので検索を試みたが、それっぽい情報が出てこない……

続くといいな日記 – Unicode とサロゲートコードポイント
https://mizunashi-mana.github.io/blog/posts/2020/11/unicode-surrogate-codepoint/

> コードユニット 2 つになる場合は，high / low surrogate は区別できるため，連結さえしていれば順不同で保存できるが，デフォルトではビッグエンディアン，つまり high の次に low という順で保存することが決められている [4]．

> [4] 正確には UTF-16 には2つのバリエーションがあり，コードユニットが2つになった時，ビッグエンディアンで並べるか (UTF-16BE)，リトルエンディアンで並べるか (UTF-16LE) が分かれている．通常の UTF-16 は BOM によりこの2つの方式のいずれかを指定することができ，指定されていない場合はビッグエンディアンになる．

これか。ほんまか？

UTF-16BE/LE がコードユニット (バイト) の順のみならず surrogate pair のコードポイントの順まで制御しているのかという話。ちゃんと規格調べないとわからんな……

The Unicode Standard, Version 15.0 - ch03.pdf
https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf

> D75
> _Surrogate pair_: A representation for a single abstract character that consists of a sequence of two 16-bit code units, where the first value of the pair is a high-surrogate code unit and the second value is a low-surrogate code unit.

The Unicode Standard, Version 15.0 - ch05.pdf
https://www.unicode.org/versions/Unicode15.0.0/ch05.pdf#M9.12264.Heading.55.Handling.Surrogate.Characters

> • A leading surrogate, representing the first part of a surrogate pair
> • A trailing surrogate, representing the second part of a surrogate pair

やっぱり BOM などは関係ないはず。

結論としては、 high surrogate は常に leading で、 low surrogate は常に trailing で、このコードユニット間の順番に UTF-16 の byte order は影響しないはず

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

3.8 Surrogates (D75):

> Isolated surrogate code units have no interpretation on their own. Certain other isolated code units in other encoding forms also have no interpretation on their own. For example, the isolated byte 8016 has no interpretation in UTF-8; it can be used only as part of a multibyte sequence. (See Table 3-7.)

とあるので、解釈不能なゴミが入ってる扱いにする (たとえば U+FFFD「�」にするとか) のでよさそう？

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

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

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

そもそも U+FEFF ZERO WIDTH NO-BREAK SPACE もとい BOM 自体が概念としてアレなところがあり……

ちなみに U+FEFF の no-break space としての利用は非推奨で U+2060 WORD JOINER を使ってねということになっている (余談)

さておき、 BOM がバイナリ層の仕様を表明するものだというところまでは良いとして、しかし BOM はバイナリ層から code units 層に持ってくる段階でトリムされるわけではなくコードユニットとして残ってしまうわけだから、そうなるともっと上のレイヤーに何らかの情報を与えてしまう可能性は否定できないと思うんですよね

“綺麗に” 分離して重ねられたレイヤーであれば、下の層から情報を引き出すときに下の層特有のメタデータは消えて上に伝わらないはずなので。

カタハネで思い出した、おわりのクオリアとかいう (まだ) 存在しないゲームのサントラを何故か持っていることを……

もう存在していないブランドや会社のゲームのサントラとかは結構あるけど、まだ存在していないゲームのサントラはさすがにこれしか持ってない

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

それで合ってると思う。 code unit 内の byte order の制御であって、それ以外の解釈はおそらく誤りであるはず (と信じたい)。

あっw

SJIS にはあるっけ……？ 何も覚えていない

U+FFFD 相当の意味を Unicode 外でどう表現するか、以外と厄介な問題かもしれんな

湯婆婆、若い頃は湯姉姉 (ゆねぇね) だったのかな

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

@koba789 「長老」みたいなものか…… (?)

山奥の人間の寒村で静かに暮らすエルフのおねえさんを長老呼ばわりしてえ〜〜〜！！！！！

？

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

偽中国語異世界小説 - 偽中国語異世界小説（みなもとあるた） - カクヨム
https://kakuyomu.jp/works/16817330653680110893/episodes/16817330653680126229

これおすすめです

そもそも NULL はレイヤーの違うデータなので……

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

そうかも…… (?)

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

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

Feature #28011: Setting for My page blocks to change the maximum number of issues - Redmine
https://www.redmine.org/issues/28011

ほしい

機能 #148: [Redmine] 「確認予定日」フィールドの試験運用 (2024-02) - 人生管理運用 - Nopmine
https://redmine.potato.immo/issues/148

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

インクリメタルラック

メタルラック、規格を統一したつもりでも結局2種類になったりなどするので、部屋のレイアウトは本当にちゃんと考えた方がいいです

これは 90cm×45cm のメタルラックを4つと 85cm×60cm の19インチサーバラックを設置したうえでもうひとつ19インチラックが欲しくなっているｵﾀｸからの、切実なアドバイスです

耐荷重は逆にそうそうオーバーしなくない？
たぶんラックより先に床が死ぬ

私もサーバラックを置く前はそうでした……

ましフォニなぁ……もう1周したい。そしてアンジェ√の「ひざまくら」がR18版でどうなっていたのかこの目で確認したい (?)

https://redmine.potato.immo/issues/37

また Mastodon コケてんのかぁ？ とか言って Grafana を確認したら VPS インスタンスごと死んでて、コントロールパネルにアクセスしたら connectivity issue があるで〜と警告が出ており、数分後「ハードウェアノードに問題が見付かったから勝手に再起動したよ」とのメールが

コントロールパネルから自動でレポートが飛んで再起動する仕組みなのかな。全ノードの定期的なポーリングみたいなのをしていても良さそうなものだが (規模とコストの感覚がわからんので適当言ってる)

相手サーバのバージョンを確認して既知の古すぎるバージョンなら fetch を拒絶する実装 (レイテンシクソデカ)

キャッシュすればよし

C は独自処理系が乱立しているので、そういうのでテストとしてコンパイルできなくなるとかわいそうという気持ちは多少ある

そうでなくとも言語処理系を制限したり個別対応が必要になるような方向性をエコシステム全体がとってしまうとそれはどうなんだという気持ちになるので、そこは雑な意地みたいなので拡張抜きにしがち

実害があるかというと局所的にはほとんどなく、 gcc と clang と icc あたりさえ使えればとは99.9割くらいの人は影響を受けないと思うけど。
長期的・大局的にはまた話が変わってくる

/dev/neru
#今すぐ寝ることで救える命があります

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

モデレーションノートに「2025年にブロック解除」みたいなことを書いておけばよろしい

ぽきた (絶起・ざ・ろっく)

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

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

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

宣言的な管理は好みなので k8s 是非とも使いたいのだが、とにかくストレージとネットワークまわりの諸々が面倒で困る

Talos Linux
https://www.talos.dev/

ノード立てる部分ならこれは悪くなさそう (本格運用でどうなるかは知らんが、今のところアプデあたりはうまく楽できている)

オンプレ k8s 側をうまくやれたとて NAS 側とかの連携がないと……みたいなところはあり、結局境界線の引きかた次第なのはそうかもしれないが。なんとかならんものか……

トラックボールにチルトホイールあるけど、 prev/next ボタン普通にあるし、 Fn3+ボールぐるぐるで縦横スクロールできる設定も入れてあるので、チルトホイールは完全に持て余している

nginx
freenginx
openignx
nginx-ng
yanginx

ng-inx かもしれん (?)

nginy の世界もあったのかもしれない (?)

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

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

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

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

私の場合、オートスケールとかそういうのが欲しいというより、「きれいに宣言的に管理したい」のところが一番

ansible とかだとその辺りどうにもうまくいかないというか、可能ではあるがダルいみたいな感じになるので…… (触ってみた程度しか触ってないけど terraform も痒いところに手が届かなそうじゃない？ という感想がある)

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

暗殺ならヨドバシ

Debian ノードに ansible で諸々整えているけど、実はこれ nixOS とかを使うのが正解だったりしないかなぁという気持ちに

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

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

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

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

ﾎﾖﾊﾞの楽曲、日本からだと mp3 とか lossy なコーデックでの購入しかできなそうな感じで大変険しい (おかげで原神のサントラも円盤を買えた璃月までしか持ってない)

Genshin Impact - Forest of Jnana and Vidya (Original Game Soundtrack), HOYO-MiX - Qobuz
https://www.qobuz.com/us-en/album/genshin-impact-forest-of-jnana-and-vidya-hoyo-mix/yctaclgp2ucsa

ここはハイレゾﾀﾞｳﾝﾖｯﾖ購入できるっぽいんだけど、どうも日本からでは駄目らしい

Qobuzはお客様の国ではご利用できません - 高音質音楽
https://www.qobuz.com/jp-ja/close/jp-ja

https://mastodon.cardina1.red/@lo48576/111343755855898645

まだ2023秋をやっている (まあどうせ日本でサービス開始してもﾀﾞｳﾝﾖｯﾖできない可能性が高いけど……)

Proxmox Virtual Environment - NixOS Wiki
https://nixos.wiki/wiki/Proxmox_Virtual_Environment

ふむ

重い話、まあまあ好き

小説だと読み進める手が重くなるけど、ｹﾞﾑだと半ば受動的なので結構いい

べつに重い話が特別好きなわけではなく、背景のしっかりした物語が摂取できれば何でもいい説はある

コンテンツ鑑賞 #147: [体験版] サルテ - 趣味・娯楽 - Nopmine
https://redmine.potato.immo/issues/147

重い話でいうと、これとか昨日見付けて気になってきています

そんなことあるんだ……

#原神 の特殊ムービーで突然フレームレートが落ちる (30FPSとか？) の、ソープオペラ効果を防ぐためか？

ソープオペラ効果とは？ － テレビが台無しにしたシネマルック | CineD
https://www.cined.com/jp/the-soap-opera-effect-how-your-tv-is-destroying-cinematic-efforts/

ATRAC というか xアプリ (or SonicStage) は酷かったなぁ……

今のｵｮｰｸﾏﾝは FLAC 普通に使えます (WavPack とか Opus が無理なのがちょっと残念だけど)

FLAC にできない音質のロスレス音源は ALAC にするといける場合があり、 Opus とかはどうせ lossy なので AAC (m4a) なり何なりにしてしまえば良い

そういうのを ALAC にするか WavPack にするか悩んで結局 WavPack にしたのだった。何故かはもう忘れた (ALAC の自由ソフトウェア化からそんなに経ってなかったから？)

昔は FLAC + embedded CUE にしていたけど、ｵｮｰｸﾏﾝへの転送でダルくなってトラックごとにファイルを用意するようになった。
それこそ富豪的にストレージ使えるので、ジャケット画像の重複とか分割による圧縮率低下は気にしなくていいし

ｵｮｰｸﾏﾝ以外にも、 PC での音楽再生に MPD 使ってたりしたのでそれもある

ｨﾇｯｸｽのオタクなのでリッピングには cdparanoia を使っている

音楽のメタデータ、他所のやつ全く信用してないので自前で入力しているし、メタデータ編集だけは wine + fb2k でやってる

USB ってやつはバージョンと速度のみならずコントローラまでややこしい

USB 3.x はそもそも USB 1.0/2.0 の信号を 3.0 とは別の信号線で流しているから両立してるんだっけ (あまり詳しく知らないけど)

もともとあった4本が Vcc, GND, D± で、 3.0 で追加された5本のうち2対4本が差動信号で残りの1本が GND だったように記憶している (うろおぼえ)

なるほどwww

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

閑雲引きたかったけど次の八重神子を優先することにしたので泣く泣く保留

最近ナヴィアと鍾離とフリーナで使っているので、全体回復の閑雲も欲しかったんだけど…… (あと移動能力)

スメールの砂漠を無限に彷徨ってる

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