昨夜涼しかったのが嘘のように暑いな、こりゃ今日もエアコンつけるしかないか……

TurnKey GNU/Linux (<https://www.turnkeylinux.org/>) の v18 (Debian bookworm ベース) を待っているのだがなかなか正式リリースされないので、待ちきれず v17 で諸々をデプロイしてしまっており、よくない

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

Markdown Editor · BookStack
https://www.bookstackapp.com/docs/user/markdown-editor/

ふーむ、良さげかもしれん

内部フォーマットが気になるけど、書きぶりからして HTML (あるいはそのサブセット) と互換なものっぽいし、だとすれば悪くない

ポストに油と火のついたマッチを突っ込めば revert できるよ

そうかも

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

mouso

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

青の祓魔師　aliexpress　違い

どっちも知らんのでオタク任せた

エコノミ焼き

コンテナ技術の普及によって web アプリの CPU 並列性が追求されなくなったって、どういうこと？ ほんまかいな

まさか「並列化できてなくともフロントエンドを複数デプロイすればいいからw」みたいなしょーもない話じゃないよな？

かなりぁゃιぃ回答だな

「他の言語の連中は目新しさだけで物を選んでいるが、俺等は違う」みたいなのも割合偏った思考というか “信者” そのものだと思うけど、まあいいです

“アンチテーゼ” というのはしばしばそういう半ば決めつけにも似たイデオロギーを基にしているもので、それはそういうものだと思うしかないな

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

「ｺﾞｮｰﾙﾁﾝはコルーチンだから CPU コア数を必要としない」みたいな話ならわかるけど、それが有り難いのってむしろ thick provisioning してたりサーバ1台で大量のコネクションを捌かないといけなかった時代であって、コンテナ化はむしろ thin provisioning で CPU 並列化をどんどんやっていこう的な方向に向かわせるものだと思うんだよなぁ

べつに並列化できるからといってそうする旨味があるかは別の話だけど

https://plrm.polyohm.net/notice/AZc4NVY9IlUOy83w4u

高知！？ と思ったけど Kochi, India らしい

Kochi - Wikipedia
https://en.wikipedia.org/wiki/Kochi

hmm

また「文字列の長さ」問題に行き当たってしまった

しかも今回は「文字列表現が生の &str や &[char] とは限らない」という文脈付き

信者臭を感じつつも全体的に言ってることはそこまで間違っていない気がするんだけど、例の箇所だけはかなり引っ掛かっているので全体的に「わかっていて書いているのか、わからず唱えている受け売りなのか」というところで怪しさが出てきている

脳がプリエンプティブマルチタスクしてる

とりあえずバイト長でやるか……

いや、 Stream の一番奥のバックエンドが &str でなかったらバイト長取れないし駄目な気がしてきた

バックエンド依存ということにして逃げるか、バックエンドを &str に固定してしまうか

しかしバックエンドを &str に固定するとメタデータ付きのストリームが扱いづらくなりそうなんだよなぁ

あと winnow だと take_while 系のものとかが基本的に token 列を扱うものなので素朴にとりやすい「長さ」が code point 数の方になってしまっている

いや取りやすいというのは嘘かも、後からトークン数を得るのはだいぶダルいし Offset trait で取得できるのはバックエンド表現におけるオフセットだから

うーん……

しかしトークン長の制限をできる lexer でないと怖くて外部由来のデータなんか食わせられないんだよなぁ

一旦べつのことしよ

まずはデータ同期用の一部プライベートサーバを自宅クラスタに引っ越す

日本書紀に載ってそう (?)

本質データ (1.4 GiB) の6倍以上 (8.7 GiB) の容量を食っている /var/lib/docker の図

nc 鯖引越できた

めちゃくちゃダルかった、やっぱりこの辺りの手軽さでは docker なんだよなぁ

まあ性能も上がったしメモリも128倍になったし良しとしましょう (?)

メモリが128倍 (本当は256倍) あると思うと何があっても許せる気がしてくるな

ストレージに至っては400倍以上あるけど

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

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

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

家が傾いている人とかは

OST | Genshin.Global
https://genshin.global/product-tag/ost/

ﾜｲはここで購入した (ちゃんと届いた)

ディスクが傷だらけで正確なリッピングが大変だったのを「ちゃんと」にカウントしても良いなら、だけど……

運送というよりはケース (円盤固定) の問題だと思うので、たぶんどこで買っても似たような状態だろうとは思っている

ところで続きはいつ出るんでしょうか？？？？

海外通販となると業者の選び方が難しいし、相手が中国となると尚更考えることが増え……などのいろいろがあり (気にしすぎな面はあろうけど)

ｱﾘｴｸとかも実は使ったことなし

鈍器にあるんだ……

外出ダルすぎてどこで何を売っているのかの感覚が全くない

まあ近年だったらﾍﾟｲﾊﾟｭ使えれば補償についてはどこも大差ないのかもしれん (しらんけど)

補償以外の面では差は付きそうだけど

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

k8s クラスタ、これで組んでみてます (まあ組んだだけで結局アプリ動かしてないけど)

ホストとかクラスタ自体のｱﾋﾟﾃﾞが簡単にできるのが高得点です

HA クラスタとして構築はできてるんだけど、結局 PV の扱いどうしよう……となってそこで放置している

CI サーバとか用意したら PV なんて要らないコンテナを立てたり消したりなどしまくるだろうから、そのときは存分に活用すると思う

mastodon とかの resource hungry なアプリこそ自宅鯖で動かしたいが、そんなことをすると IPv4 アドレスは割り当てられないしネットワーク帯域が心配だし可用性も間違いなく落ちるしで、どうしようもない

ソ連の初代指導者でしょ

デジタル庁には日本の祝日を ics 形式で配るくらいのことは当然のようにやってほしかったのですが、あと何年かかりますか？

Google やら Apple やらの民間企業 (しかも海外) が配信してくれているけど、そもそも祝日を決めているのは法律なんだから政府としてこのくらいのことはできてほしいというお気持ちがかなり強い

どう足掻いても Synology NAS (DSM) で eth0.201 が global IPv6 address をくれない。 eth1 は大丈夫なんだけど。

tag vlan をやめたら何事もなかったかのように使えるようになった、マジで何なんだ

そういえば SKK 多対多登録スクリプト、ここ数年放置してるな……

シェルスクリプト (主に sed) で粘っていたような記憶があるが、 Rust で書けば相当メンテしやすくなるはずなのでそうするか……

Rustで単一化を書くスマートな方法を考えた
https://zenn.dev/qnighy/articles/9a1d69da24a4ee

ﾎ㍂

たしかに一度解決されてしまった部分は上書きされないなら once cell 相当の機能になるか。うまいなぁ

OnceCell が repr(transparent) してない理由は何だろうと思ったけど、いずれにせよ std 入りしてしまったからには transparent であるとは保証したくないだろうし、自前で用意するしかないか

XML を設定ファイルに使うのは率直に言ってアプリ側が筋が悪いと思う

あれはテキストと構造を混合して記述できるという点と名前空間により拡張を自然に接続できる (かつ汎用処理系がその拡張の内実を知らずとも処理できる) というところに大きな価値があるのであって、普通は設定ファイルにそういう能力いらんやろ

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

readable かもしれないけど絶対に writable ではない

せめて JSON5 くらいのまともな文法になってからでないと検討に値しないし、人間が編集する可能性のある設定ファイルが pure JSON 形式というのはもはやいじめですよ

YAML なら良いとかそういうことは言ってません！！！

なぜ人類こうも極端なのか

JSON5 – JSON for Humans | JSON5
https://json5.org/

オタクどもに知っておいてほしい「俺たちが本当に欲しかった JSON」です

Hjson, a user interface for JSON
https://hjson.github.io/

こういうのもあるけど、うーん……

そこまで悪くはないと思うのだが、 ''' によるブロック文字列みたいなのが導入されてしまうと、じゃあ中でのエスケープ規則とか行頭空白の削除規則とかはどうなんですか、みたいなところに元ネタ言語から正確に類推できない自由度が発生してしまうので、結局完全な新規言語とそんなに習得コストは変わらないのではと思う

まあ TOML より深い階層を書きやすそうという点では割と評価できるけど

「XML は人間が読み書きしづらい」とか「XML を設定ファイルに使うのは」とかの言説を見るとムズムズする。 XML は設定ファイルに適した形式として設計されてないし、向いてない用途に無理矢理使った様子を見て人間の読み書きを評価されても……何もかも間違っとるやん……

HTML と等価なデータ構造を JSON で書いてみてからもう一度同じこと言ってもらえます？ という感想です

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

名前思い出せないわかる

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

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

「横スクRPG」くらいまで絞るとまあまあそれっぽいかも (RPG とは限らない気がするが)

ｹﾞﾑの分類なんもわからん

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

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

アメスク アメ横 横スク 白スク

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

つまり「不服」は脱衣を意味している……ッ！？

こうですか

わからん…… lexer のユーザが期待する「打ち切る長さ」の「長さ」の単位は何なんだ……

制約の強い環境のユーザを想定すると、バイト長で制限することを考えるのが自然だが、一方で lexer への入力はバイト単位とは限らないという問題もある (たとえば UTF-16 だったり UTF-32 だったりで u16 や u32 の列が渡される可能性がある)

かといって Unicode code point の数にしてみたところで、コードポイント数で制約をかける意図とは……？ となる。ASCII 128“文字” と絵文字128“文字” はメモリへの負荷がぜんぜん違うわけで。