./lab

結局chromebookでは戦えなかったよ・・・ 表題の通り中古のthinkpadを買いました。i5-1135G7が載っています。うちの中ではかなり新しい。 このご時世にmemory 8GB / SSD 256GBモデルということでWindowsだとおそらくかなりつらみがありますね。 ちょっと急ぎだったこともあり、秋葉原の店頭で買ったものです。まあ納得できる値段でした。本体へペンによる書き込みがあり、表示より安くなりましたし。。 ところで、店頭POPにはWWANに関する記載はありませんでした。しかし・・・？ マドンドウズ〜 pic.twitter.com/0cAz0o0nMg — NTSK (@nt776) April 11, 2026 なんということでしょう（ビフォーアフター） ということで、WWANを搭載しているモデルだったようです。やったぜ。 今まで手元で使ったことがあるWWANモジュールは、3g時代のSierraやEC25Jだったのですが、この端末はPCIe接続のモデムである「EM120R-GL」が搭載されているようです。 Linuxを入れる UniversalBlue を #FediLUG で聞いたことを思い出し、Auroraを入れてみました。しかし、慣れていない こともあり 、急ぎの用事終わるまではUbuntuで戦うこととしました。また後日チャレンジします。 さて、通常通りインストールしたUbuntuであれば大半のデバイスのドライバが勝手に入ります。（指紋リーダまでOSインストールするだけで使えちゃう。便利だねえ） しかし、今回はWWANは別でした。モデム自体は認識されているのに、APNなどの設定をNetoworkManagerで突っ込んでも接続ができない。Chromebookのときも素直にいかなかったよな〜とAPN設定をいじっていたものの、特に変わらず。 調べてみると、どうも電源投入時に「FCCロック」？という状態になっており、そのままでは電波を出せない様子。 https://forums.quectel.com/t/rm520n-gl-module-installation-on-ubuntu/40603 /usr/share/ModemManager/fcc-unlock.available.d内に、モロEM120R-GLのpid/vidであるところの「1eac:1001」が存在することを確認。上記フォーラムのとおりに/etcへシンボリックリンクを張って再起動したところ、無事自動的にドコモ回線を掴むようになりましたとさ。 パソコンについてるWWAN、昔よりは使いやすくなってるけどまだまだ癖がありますね。

ClaudeやCodexに、GBS-ControlをESP-IDFに移植してもらった https://github.com/ntsklab/gbs-control/tree/esp-idf ターゲット 元プロジェクト：ESP8266 今回：ESP32-C3及びC6 開発環境 元プロジェクト：Arduino ESP8266 今回：ESP-IDF 方針 自分でコードを書かない LLMだけでどこまでできるのか、遊ぶ 移植方針など ターゲットデバイスは、XIAO ESP32-C3とC6。ピンヘッダ用の穴に直接JST-XHコネクタなどを実装することで、基板などを起こさなくても比較的楽にGBS8200ボードへ接続可能。（ピッチが違うため、良い子は真似してはいけません） 元がArduinoコードなので、Arduinoコンパチレイヤでラッピングしてなるべく元のソースをそのまま使用できるようにした。 C3/C6はESP8266と違いBLEがついていたりするので、Nordic UART Serviceベースのshell機能が追加になっている。元々は機能拡張版を作る予定がなく、GBS-Cが動作するまでのデバッグ用にBLE経由ログ出力などの機能を追加し始めてからブランチを分けた結果こうなっている。計画性のなさ。 Debugピンの入力や外部クロック処理など、こちらの環境で使用していない機能については動作未チェック。 追加機能あり版 https://github.com/ntsklab/gbs-control/tree/esp-idf-ext 某所で必要な機能を追加したバージョン。これが作りたくて、ESP-IDFへforkした節がある。 ロータリーエンコーダではなく物理ボタンによるジオメトリ、PreCoast、PostCoastレジスタの調整を可能としている。これにより画面のズレや、上部の歪みなどが発生した場合に、ある程度ソフト的に調整が効くようになっている。1 また、ESP8266用は現在のコードでは古いMVSなどが映らない（スタッタリング、同期取れず画面が流れるなど）する。2これは、SyncWatcherが動的にtv5725の同期系レジスタをいじる仕組みが原因の様子。3 こちらのIssueに記載があるが、古いバージョンではMVSも映っていたとのこと これらの情報から、旧GBS-Control互換モードを実装してもらい、無事古いMVSでも同期が取れるようになった。 他にも、複数台運用に耐え得るように各種無線の識別子を任意の文字列に変更する機能などを実装。 一旦こちらを運用に乗せて試験中です。 Coast系パラメータを正しく調整するには、後述するレガシモードで動作させるか、set syncwatcher offコマンドなどでSyncWatcherを明示的に無効化する対応が必要。 ↩︎ 自宅のMV-1Bでは動いていたのに、本番環境で使うMV-1FZでは動かず、大分悩んだ ↩︎ MVSの同期信号が終わってるのが真因ではあるのですが。。。 ↩︎

表題の通りですが、Wordpressやめました。 以前からやめたいな〜とは思っていたのですが、色々思うところがあり一気に実施しました。 旧来の記事が壊れているかもしれませんが、そのうち直します。。。

やすかったのでつい・・・ 購入の（いい）わけ 以前、GPD P2 MAXが壊れつつある話を書きました。 GPD P2 MAXが壊れつつある日記 代わりになるパソコンほしいな〜とは思っていたのですが、小さい端末はそもそも高いですし、フル機能パソコンである必要もないな、と思っていたので使い物になるかも含めてお試しに、というところです。 購入したのは今年初め辺り？から中古という名目でほぼ新品のものが投げ売りされている、Lenovo 14e Chromebook Gen 3 です。 物自体は2023年の商品で、Softbankから5G対応品として販売されているのが特徴ですね。 調べていて分かったんですが、同じ名称でWWAN非対応、性能が増強されているモデルもあるようです。 本体についてのレビューは沢山の方がされているのでそちらを見てもらうとして。液晶画面はIPSなど高輝度/広視野角なものに慣れきった今、下手したらブラウン管並みのノスタルジーを感じるぐらいイマイチですね。そんなことない？そう…。 VS Codeとかの日本語入力 ChromebookということでOSはChromeOSなのですが、開発用という名目でLinuxコンテナを動作させる仕組みがあります。内部ではLXCっぽいアレになっているそうです。 VSCodeが動きそうな話は事前に調べていたので、早速入れてみたのですがなるほど日本語入力が効かない。 ググると分かりますが、ChromeOSからLinuxアプリに対する日本語入力は昔から少し難があったようで、古くはLinuxコンテナ側でIMを動作させていた様子。2023年頃からは、cros-im？という仕組みが標準になりChromeOS側のIMを使うことができるようになったそうです。 それ以降に書かれた記事では、VSCodeはそのまま日本語入力できるようになった、みたいな記述が多く困っていたところ、ChromeOSにおいてもLinuxアプリはWaylandとX11でcros-imの挙動が変わる的な話を発見。（URL失念。。。） 確かに、ネイティブなLinux環境でもその辺でみんな（誰？）悩んでいるのはよく見ます。 というか、多分そういうことなんだろうなとは根拠なく思っていました。 試しに以下で起動してみた結果、日本語入力が普通に動作しました。 code --ozone-platform=x11 Waylandにこだわっているわけでもないですし、これでいいか、と。 ChromeOSは、Linuxコンテナ内で作られたdesktopファイルを読んでメニューにアプリアイコンを出している？そうです。ということで、基となるdesktopファイルのExec行を直接編集して、上記引数を追加してターンエンドです。やったぜ。 VSCodeでGithubアカウントへログインしようとしたところ、keyring周りのエラー。 ストレージ暗号化されているし弱い暗号化？で保管されても構わないよ〜とは思いつつ、gnome-keyringインストールしているのにな〜と。 ということで以下ドキュメント参考にargv.jsonへ設定追加で解決。 https://code.visualstudio.com/docs/configure/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code WWAN（5G）でDocomo回線を使う せっかくですのでWWAN機能も使いたいですよね。 ChromeOSはAndroidのテザリングを遠隔で有効化できるので、WiFiだけでもそんなに苦労はしないのですが…。 個人の都合で、SB回線のSIMはメイン機で使ってしまっているため、余っているIIJmio type Dあたりを使いたいところです。 APNなどを適当に**（フラグ）**設定してみたのですが、どうにも「モデムが登録されていません」だの「有効期限が切れている」だの出てきてうまく繋がりません。 調べたところChromeOSは、SIMロック時モバイルデータの設定画面に特定のキャリアしか使えない旨の表示が出るらしいです。つまりとくにSB限定になっているわけでもなさそう。 さて困ったな…と思いpovoのSIMを入れてみたところ接続されるじゃありませんか。えぇー(´・ω・｀)となりましたが、動作にキャリア差があるということはAPN設定周りの可能性が高いなと思案。IIJのサポートサイトをよく見ると、ありましたよ。Windows用の設定ページをよ〜くみると… 画像で。すんげえちっちゃく。 APNの種類 （タイプDの場合）インターネットおよびアタッチ （タイプA）インターネット そしてChromeOSのモバイル設定画面が以下。 すでにチェックが入っていますが、「Attach (IA)」はデフォルト無効です。 Androidにはそんな設定ないじゃんねえ(ヽ´ω`) きれいにフラグを回収しましたとさ。同じ轍を踏むな…！ 俺達のChromebookカスタムはまだまだこれからだ！！ Holloのほうでも書いていたのですが、ChromeOSのこういうチマチマしたカスタマイズ、りなざうで遊んでるときの感覚に近いですね。たのしい。 ChromeOSふっ飛ばして遊ぶというのも中々楽しそうなんですが、しばらくは普通に使ってみようかなあというところです。

いつ買ったんだっけ、と調べてみたら2020年4月末。ちょうど、緊急事態宣言によるBCP長期出張の合間ですね。懐かしい。 症状としては致命的なものから順に 一部キー入力ができない マウスクリックが非常に効きにくい バッテリ容量低下 といったところです。 キー入力に関しては、常時右端の全キー（BcSp, Del/`, @, Ins/Ent/_, /→）及びタイミングによっては左下のCtrlが効かない様子です。終わりすぎ。 水ぬれとかはなく、症状発症時もいつも通り文字打っていたら急に効かなくなった、という感じでした。 症状が出ているキーがキーボード外周部に限られているというところから、内部フレキの一部信号が接触不良等でだめになっている説を思いつきました。 しかしこの機種、工事設計認証番号が背面外装パネルに記載されているんですよね。 また、それがGPD社によって取得されているものであるため、分解は良くないのかな、というところでして。。 ※ググった感じ、内部のIntel無線モジュールには別の工事設計認証番号が記載されている様子。となると、こちらの取得にあたって使用したアンテナと異なるものをP2 MAXにて採用したからGPD社が改めて試験をし、工事設計認証を得た、、、とかなんですかね、無線に関する技適（証明）については詳しくないですけど。 軽く叩いてみたり掃除機で吸ってみたりと、外部からできることはやってみましたが、直らず。 その他の不都合についてもだんだん我慢ができなくなってきたので、潮時かなあというところ。5年は使えたし、結果としては買ってよかったかなとは思いました。 変なキー配置も、慣れてしまえば意外となんとかなるもんでした。日本語あんまり打たなかったっていうのはありますが・・・ 新しいものを買うとして、持ち運べるPC環境はほしいのだけど、大して外には出ないんだよな、という悩み。 外でPCを使う用途って、納品したマイコン系物品の実地デバッグや修正、修理とかなんですよね。ノートパソコンである必要があるのかどうか・・。 使うときだけキーボード型ラズパイ持っていく、とかでもいいのかもなあ。。 ところで、調べてて気づいたんですけどR 210-131828を調べるとW52の周波数しか書いてないんですよね。 これどうなんですかね。だめそう。ｗ

概要 「NetMeister」のDDNS機能から「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」へ移行したよ！ 背景 とある施設において、複数拠点でIXルータ（最近終売した2215。。。）を用いてNWを構築しており、それらの遠隔保守のためフレッツ網内折り返し接続（≒v6オプション）によるVPNを使用しております。 ところで、NTTフレッツ光のIPv6アドレスの配布について、10G以外でひかり電話なしだとNTT側からRAで契約回線ごとに/64を配布されます。 そしてこの配布されるプレフィックスは基本的にONU交換や端末交換を行っても不変ですが、NTTやVNE等の都合で稀に変わることがあります。（俗に半固定、とか言われたりしますね。） 上記の問題を解決するため、IXシリーズではNetMeisterというクラウド管理システムへルータを登録することで、DDNS機能が無料で使える仕組みになっていました。（NetMeister無料版では、IPv4/v6共にインターネット経由での接続のみ対応。そのため、v6オプションのみの契約、記事公開時点では2408:210::/30に含まれるPrefixが降ってくる環境での接続は元来よりNetMeister Primeの契約が必要です。参考：NetMeisterサービス仕様 「NetMeister サービス仕様書」） 動機 しかし、去る2025/4/7に以下のリンクの内容がメールにて通知されました。 https://www.necplatforms.co.jp/product/netmeister/info/250407.html NetMeister ダイナミックDNSサービス（IPv6）無償提供終了のお知らせ （中略） IPv6 DDNSサービスの無償提供を終了し、新たにNetMeister Primeの一部として有償での提供を継続させていただくこととしました。 たいへんだ。 乗り換え先の検討 NTT東日本ではネームサービスというものがあり、公式でDDNSのような機能を提供しています。 https://flets.com/v6option しかし、v6ネームはインターネットに存在するDNSサーバ（例えば、Cloudflare 1.1.1.1）では名前解決ができない仕組みになっており、フレッツ網よりDHCPv6で取得できるDNSサーバを使用する必要があるなど、非常に不便です。 そこで、OPENプロジェクトによる以下のサービス「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」を使用することとしました。（β版、と言い張られておりますが。） https://i.open.ad.jp こちらのサービスはフレッツのネームサービスと違い通常のインターネットに存在するDNSサーバでも名前解決が行えるなど、大変に「けしからん」仕組みとなっています。 ちなみに最近知ったのですが、上記のOPEN IPv6 ダイナミック（以下略）をベースにした商用サービス「IPv6ダイナミックDNS」が開始していたようです。いつの間に。（2021/7らしいです。） https://ddns.e-ntt.jp インターネット上に存在する適当な無料DDNSサービスや私の実験用ドメイン（oyasumi.dev）などを使うという手もありそうに思ったのですが、今回の目的がまさにv6オプションによる折り返し接続であるため、そのために作られたサービスのほうが適当であろうという判断のもと、OPENのDDNSを採用しました。 IXルータでの使用 上記サービスの解説ページにもありますが、なんとIXルータにはDDNS更新機能があり、OPENのDDNSはこれに対応しています。そのため、今までのNetMeister DDNSと変わらずIXルータのみ設置している拠点でも自動でレコードの更新ができます。 動作としては、IXルータ側にてアドレス変更（IPv6だとRAによってIXへ新しいPrefixが配布された場合かな・・・？未検証。IPv6に関してアドレス変更もといソースアドレス選択周りは結構闇が深いのである・・・）を検知すると、ddns profileに設定されたアドレスへ指定のqueryをつけて投げる、という簡単な仕組みです。また、IFのアドレス変更がなくても1hに1回は更新を行う、という動作も可能です。大変便利ですね。 また、管理している拠点のうち一部はIPv6でのインターネット接続ができず、前述のNetMeister無料版の縛りにより中途半端にv4インターネット経由での接続が残る構成になっていましたが、今回ようやくその状態も解消しました。 結論 めっちゃ便利なのでさっさと乗り換えておきゃ良かった。これからもけしからん面白いフレッツサービスが生まれることを心より願っています。 おまけ 今回のOPEN DDNSに関してもソフトイーサ社はローンチ時に大変にけしからん参考になる文書を公開されているので、ぜひ読みましょう。楽しいゲームもあるよ。 https://i.open.ad.jp/news-160614

メモ https://hl.oyasumi.dev/@ntek/0192b99e-8468-733e-9592-447423dbc5fa

★2025/1/29 GithubのURLを変更しました Kubernetesでは、Deployment等のPod templateに対しイメージタグにてlatestを指定することは推奨されておりません そのため、sha256によるコンテナイメージのダイジェスト値指定か、バージョンタグを用いた指定を行う必要があります。 Pod templateにバージョンないしはdigest値を書くということは手動でアップデートの管理を行うということです。別に大した手間ではないですしそれでも良いのですが、せっかく（何が？？）ですので自動更新をさせてみたいものです。 但し、X.Y.ZバージョンのうちY部分の更新は何らかの管理者によるマイグレーション操作が発生する可能性を鑑みて、Z版のみ更新できるようにしてみました。（Z版で手動マイグレが必要にならない根拠は、無し。） 本来であれば以前記載した、「Deploymentでのアプリケーション単一性維持が保証できない問題」も含めて解決できる、何らかのOperatorを実装するほうがスマートです。しかし、当たり前ですがそういった実装には手間がかかりますので今回はKubernetesのCronJobでお茶を濁します。 今回の手法を実現するにあたり、JobのPodからKubernetesのDeploymentを書き換える方法を考える必要があります。 kubectl等の汎用クライアントを動かせるようにしてもよいのですが、このコマンドはフットプリントが結構大きく、また、kubeconfigファイルなどを用意する必要がある、応答を基に処理をしようとすると別途jsonの解釈が必要になる、信頼できそうな既製イメージでjqが入っているものが無さそうである、など、少々都合が悪いです。 そこで、今回はcurlコマンドとjqコマンドのみを用いてkubernetes APIを叩き、DeploymentのpodTemplateへ設定されているイメージのバージョン取得、及びその書き換えを行ってみます。 下準備として、PodからkubeAPIを叩くためにServiceAccountやRole等を作成します。以下に例を示します。 apiVersion: v1 kind: ServiceAccount metadata: name: updater namespace: hollo-1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: get-patch-deploy namespace: hollo-1 rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: updater namespace: hollo-1 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: get-patch-deploy subjects: - apiGroup: "" kind: ServiceAccount name: updater namespace: hollo-1 次に、Pod内部で実行するスクリプトを用意します。（力技。。。）curlでKubernetes APIを操作する方法については以下のサイト等を参考にしました。 ...

クリンスイから乗り換えてみました。 説明書を読む限り、TK-CJ14-Wはもともと使用していたクリンスイCB013と比べてもほぼ同様の水道蛇口に取付可能なように見えます。 ところで、我が家の水道は、食洗機の給水に無理やり対応させるために、蛇口から先が変換の嵐となっています。 https://hl.oyasumi.dev/@ntek/01944460-c42e-787a-a5fe-29928b6b0a42 本来TOTOの内ねじ泡沫キャップなのですが、変換を繰り返した結果、最終段がM22外ネジになっています。そのため、付属している灰色のアダプタで対応しました。 クリンスイCB013と比べてカートリッジ寿命が非常に長い（1年、一部除去項目については半年とのこと。）ため、トータルコストは変わらないか安くなるかな？という思いと、もともと使用していたCB013について4年が経過し、少し汚れが気になってきたため交換に踏み切りました。 除去項目が増えているはずなのですが、正直味などについてはあまり差がないように思います。カートリッジの寿命の長さが衛生的にどうなのかという心配がありますが、現状は満足しています。 一点、不満点をあげるとすれば、吐水口の形状の差なのか水勢が変わってしまい、シャワー以外でシンクでめちゃくちゃに水が跳ねるようになってしまったところです。どうにか改善できないか検討中です。 浄水器関連でなにか起きたら、またブログに記載したいと思います。

なんとなく動いている。 https://hl.oyasumi.dev/@ntek Holloとは 以下を参照。 https://docs.hollo.social/ja/intro Kubernetesで動かして何が嬉しいか Holloは基本的に一人用サーバのため、現状ではあまり嬉しいことはないように思える。ただ、弊環境はDocker等のコンテナ基盤が常時動作していないため、Kubernetesに載せた。 使用したKubernetesディストロとオペレータ等 k0s + Cilium CNI + Cloudflare tunnel ingress controller + CloudNativePG + NFS CSI セットアップ Holloは現在、S3互換オブジェクトストレージを必要としている。今回はCloudflare R2を使用。 HolloはHelmの提供を目指している？様子だが、まだ無いのでとりあえずYAMLで書いていく。 Containerが同時に起動してDBにアクセスすると恐らく壊れるので、DeploymentのストラテジをデフォルトからRecreateへ変更する。※k8sドキュメントにあるように、これではContainerの単一性は保証できないので本来はStatefulSetを使用すべきである。 Hollo本体 kind: Deployment apiVersion: apps/v1 metadata: name: hollo-app namespace: hollo-1 spec: strategy: type: Recreate replicas: 1 selector: matchLabels: app: hollo template: metadata: labels: app: hollo spec: initContainers: - name: wait-db image: busybox:latest imagePullPolicy: Always command: ['sh', '-c', 'until nc -z hollo-db-cluster-rw 5432; do echo waiting for hollo-db-cluster-rw; sleep 2; done;'] containers: - name: hollo image: ghcr.io/fedify-dev/hollo:<strong><version></strong> imagePullPolicy: IfNotPresent envFrom: - configMapRef: name: hollo-config ports: - containerPort: 3000 resources: limits: cpu: "2" memory: "2048Mi" volumes: - name: hollo-config configMap: name: hollo-config Service（宅内からの試験用にCiliumのLoadbalancer機能を使用。Calico等の人はMetalLBとか、よしなに。今回のようにCloudflare tunnel Ingressコントローラ使う場合はClusterIPで十分） ...