計画的に椅子の上で気絶部？
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
単に、わざわざ逐一紙にダンプせんでも理解・納得できるのが自分の適性ってだけじゃない？
高適性のフィールド以外で勝負したいならそりゃ効果的な勉強法とか気にするべきだろうけど、学校くらいだったら常人も超人も何もないでしょ。向いてりゃできるしそうでないならできない、それだけ
このアカウントは、notestockで公開設定になっていません。
ワイの場合は予復習の習慣が全く身に付かなかったため大学でえらい苦労した (まあ苦労せず微妙な成績に甘んじることの方が多かったような気もするが……)
もうなんか面倒になったので gitea インスタンス爆破して立て直すことにする。どうせ自分用で他人に見せてないやつなのでええやろ
……と思ったが、やっぱり TurnKey Linux 18 の Gitea アプライアンスが出てくるまではそのままにしておきたい。どうせ出たらアップグレードするし。
object storage の /lfs/ を削除して誤魔化しとこ。
FUJITSU PRIMERGY RX1330 M5 セレクト(Xeon E-2314/8GB/SAS 300GB*2 RAID1/W2019std/ラック) PYR1335ZDY - NTT-X Store
https://nttxstore.jp/_II_FJ16385088
ラックマウントの “ちゃんとした” ワークステーションが ¥196k になってるのを眺めている
このアカウントは、notestockで公開設定になっていません。
虚無僧(こむそう)とは？ 意味や使い方 - コトバンク
https://kotobank.jp/word/%E8%99%9A%E7%84%A1%E5%83%A7-66225
コムそうだったのか。知らなんだ
"No junk" 節では
> A common issue with long-living installations is the accumulation of unused files. Junk take up disk space, pollute backups, and may even slow down the system, but is fortunately impossible on this rootfs.
と言っていて、まあわかるのだが、ここで想像するのって大抵は /etc に残るゴミであって /usr 以下とかのシステムパッケージとかではないように思われる
一方で "Selected Per-Directory Persistence" 節では
> All custom system configuration. The persisted `/etc` is overlaid early in the boot process for custom configuration and init scripts to take effect.
としており、いやそれ結局ゴミ残るやつ……という。
でも overlay であって丸ごと保存するわけではないような書き方だし、 user-provided なファイルしか残らないし自分でお掃除できるよねということなのだろうか？
あと /var/lib/docker/ も persist 対象になるようで、まあ毎度 pull なんてしてられないから理解はできるのだが、ゴミが /etc の次に残りやすいやつじゃん……という
マルウェア対策の観点では /bin, /usr, /lib を immutable にすることには合理性があるが、それはゴミが残る心配がないというのとは別の話で、この辺りのディレクトリは実際にはパッケージマネージャに全面的に委託する場合がほとんどだから (/usr/local 除く)、ゴミは心配しない。
/var が永続しないのは良いと思うけど (/var/lib/docker 除く)。
というわけで、発想としては悪くないと思うが、どちらかというと宣言的に記述されたレシピを起動時に食わせて勝手に諸々がセットアップされる方式の方が、ディレクトリツリーまるごと永続させる方式よりもゴミは残りづらいんじゃないかなと思った。
しかしまあ端末上で直接 docker コマンド叩いたりする雰囲気のこと書いてあるし、 declarative であることは目標ではなかったのだろう
UNIX socket ちゃんと使ったことないから勉強しないとなぁという気持ちがなくもない
あと D-Bus はもっと使ったことないのでもう少し知識がないといつか何かのデバッグをしたくなったとき困りそうという気持ちもある
ここでいう「使ったことない」は「自分で書いたコードやコマンドでローレベル API を叩いたことがない」を意味しています
ファイルを使ったやりとり、うっかり多重起動したときとかに排他制御が面倒そうというのがある
シンプルに2状態 (つまり mutex ひとつ) だけであればファイルの存在を使ったロックでいけるが、 mutex が2つ以上欲しいとか3状態以上欲しいとかになるとたぶんファイルの存在だけではうまいこと同期できないし、共通ファイルへの上書きで状態を表現しようとしても競合しそう
大抵はサーバとクライアントが非対称でサーバは指定されたソケットパスとともに起動するから、サーバの多重起動に関しては問題にならないが。
Switch Pro Aggregation スイッチ – Ubiquiti 日本公式ストア
https://jp.store.ui.com/products/unifi-switch-aggregation-pro
税込 ¥170k、 10G SFP+ ×28 と 25G SFP28 ×4、 L3スイッチ
いいじゃん
【緊急地震速報 第3報 2024年1月28日】
8時59分頃、千葉県北西部を震源とする地震がありました。地震の規模はM4.4程度、最大震度3程度と推定されています。この情報は気象庁の予報に基づく推定です。情報は誤差を含む場合があります。
#緊急地震速報
ラックがノイキャンヘッドホン貫通するほどギシギシ鳴ってたけど、揺れの方向の問題か
機能 #129: 部屋の掃除 (床置きの本と、PCケースの段ボール) (2024-02) - 生活 - Nopmine
https://redmine.potato.immo/issues/129
そろそろ向き合う時が来たかもしれん
このアカウントは、notestockで公開設定になっていません。
Home - Snipe-IT Free open source IT asset management
https://snipeitapp.com/
Snipe-IT〜資産管理のOSS〜 | OSSのデージーネット
https://www.designet.co.jp/ossinfo/snipe-it/
これ気になって立ててみてるんだけど、まだ全く使っていない
このアカウントは、notestockで公開設定になっていません。
たとえば消耗品とかの管理をできるとは私も思わないけど、 HDD の購入日時とシリアル番号とデプロイされた場所は把握しておきたいんですよ (故障した際にいつの領収書を探してどこに送ればいいかわかる必要があるため)
現状だと領収書を茶封筒に入れてそこに購入年月日と失効予定日と内容物を書く運用になっているが、うーん
あと私は割とメタデータ入力のオタクかもしれないので、たぶん普通のユーザよりは耐えられる気がしている (やってみないとわからん)
消耗品の管理を真面目にやってたら old gear なんて発生しない (むしろ old gear を発生させる人にこそ管理が必要だが……)
私の場合は無理しなくても最悪 Redmine にモノごとに「備品管理」チケットを立ててやるなどの雑運用が可能なので、どうにでもなる
Redmine、各種のモデリングを自前でやっていろいろ定義できるので、割と何にでも応用できて最後の砦として有能
こう、「自作 PC の部品が複数集まって PC になっており、基本的にまとめて動かすが、いざというときは分離する」みたいなところの管理がうまくできる気がしないのが悩ましい
components と hardware という分類で Snipe-IT がどれだけうまく扱えるのかもわからん (触ってみるしかなさそう)
機能 #112: [Redmine] 設備管理用トラッカーの検討 (2024-01) - 人生管理運用 - Nopmine
https://redmine.potato.immo/issues/112
悩ましいよ
https://redmine.potato.immo/issues/112#note-6
> そもそもこういった管理は実は Wiki 機能等でも良いのだが、敢えて Redmine 側に入れたい理由としては、時系列ログとしてコメント追記方式の方が適しているように思えるためというのと、 ID が自動で割り振られて楽だからというのが主な理由。
> もちろん Wiki ページを自分で追記式かつ各情報チャンクに時間情報の紐付いたログとして運用することも可能ではあるのだが、やはりどうしても整理された情報を残そうという意識がはたらいてしまう。
> 加えて、 Redmine 内でチケットにしておけば階層構造や関係の設定ができるとか、終了したタスクとして非表示ながら履歴を残しておけるというのもある。
> Wiki だと「非表示」というのが難しく、やるとすれば別階層を作ってそちらにページを移動するとかになる。
> システムによっては URI が変化してしまうし、そうでなくとも本質的にステータスであるものを階層の移動で表現するのはあまり好みでない。
このあたりが悩みの本質の一端
Redmine、 Wiki と同じくらいには「最後の砦ぢから」がある。なんなら Wiki 機能内蔵してて Markdown で書けるし。
あと GitHub とかの issue とは違ってトラッカーの種別とワークフローというやつを設定できるが良い
あまりに柔軟すぎて、適合してしまったらなかなか逃げられないが
運用中のモノそのものと作業タスクと運用状況そのものの追跡、どう管理するかはかなり悩んでいる。決め手がない。
この辺りのノウハウやモデリングは、引越とか海外出張とか大掃除とか一通りのイベントで battle-tested になったらどこかにまとめたい (まとめるための静的サイトジェネレータは今書いている最中だが……)
Redmine にアクセスできないと思ったら無惨な死体が
本質情報: どうせメモリ 128 GB 積んでるしオーバープロビジョンもできるからメモリをケチる必要はない
このアカウントは、notestockで公開設定になっていません。
『ロリータ』のロリ、実はそんなに 令和::ロリ じゃないんだよな (?)
その辺りはロリータだのアリスだのハイジだので1M回擦られてるけど……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
コンテンツ鑑賞 #109: [体験版] はじめるセカイの理想論 - 趣味・娯楽 - Nopmine
https://redmine.potato.immo/issues/109
コンテンツ鑑賞 #110: [体験版] アンラベル・トリガー - 趣味・娯楽 - Nopmine
https://redmine.potato.immo/issues/110
やっていくぞ
USB2.0のHDDにARKインストールできるかもと思って試してみたら、USB2.0の遅さがネックになってインストールに9時間かかるっぽい＞＜；
そりゃ USB 2.0 だと High Speed で 480Mbps だから……
しかも半二重通信 (まあ一方的に書き込みだけする場合はあまり関係ないだろうけど)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
買い物・物欲 #132: アンラベル・トリガー 数量限定豪華版 - 趣味・娯楽 - Nopmine
https://redmine.potato.immo/issues/132
よく考えたらはじめるセカイの理想論の方が発売日近かった
status:
> 店舗特典も併せて考えないといけないが、飾るのに難儀するタペストリーがこれ以上増えてもなぁ……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Proxmox Backup Server 用にﾐﾆ PC が欲しくなってきたな (よくない)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Currying - Wikipedia
https://en.wikipedia.org/wiki/Currying
あとスペルはガチで curry です
Haskell 氏、一度は言語になったと思ったら言語擬人化によって再び人間として復活したの面白すぎる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
忘却の峡谷がつらかったのを鍾離のシールドでゴリ押ししていたが、鍾離+ナヴィアでかなり快適になってきた #原神
というかナヴィアちょっと鍛えただけでスキル7万ダメとか出ててこわすぎる、今までのキャラの育成は何だったんだ
会心が 26/114 とかになってるし、もうちょっと率に振りたいな
このアカウントは、notestockで公開設定になっていません。
Installation — Proxmox Backup 3.1.2-1 documentation
https://pbs.proxmox.com/docs/installation.html#recommended-server-system-requirements
> Memory: minimum 4 GiB for the OS, filesystem cache and Proxmox Backup Server daemons. Add at least another GiB per TiB storage space.
Synology の DS1821+ に VM 立てて誤魔化せないかとも思ったが、結構要求が強い。
現状でも NAS (toka) のストレージが 22 TB (増強予定あり) となると、メモリが 26 GB 以上必要ということになり、 NAS (yonagi) 上の VM の片手間でやらせるには厳しい。 yonagi にはメモリが 20 GB しかないのだ。
deduplication しまくる的な説明があったので、たぶんそのためにメモリを食うのだろう。納得いく話ではある
正直 dedup を捨ててストレージを増強して数の力で押し通すという手もないではないが
機能 #133: Proxmox Backup Server を検討 - 鯖缶 - Nopmine
https://redmine.potato.immo/issues/133
