● この記事のお題
たまたま使うことになった BUFFALOのWSR-1500AX2L は、さらにもう一歩踏み込んでいて、セッションIDやセッションクッキーはもちろん必要として、パスワードをPOSTするときにクライアントで暗号化して送る必要がある、という中身になっていた。スクリプトなどから利用しようと思った場合に、もう一段階しきいが高くなった。
● 実装の中身
作ったスクリプトがあまりにも汚いので、文章でのみメモっておくことにする
- 1) Cookieをtmpで保持するHTTP clientを作る
- 2) /login_time.html へ GET でアクセスして session_num を記録する
- 3) /login.html へ、下記を添えてPOSTする
----- nosave_Username - ユーザID
----- nosave_encryptedPassword - 後述する
----- MobileDevice - 0 固定でいい
----- nosave_session_num - 2)で記録したもの
- 4) /index.html へ GET でアクセスして sessionID を記録し、以後アクセスするときの Cookie に追加する
- 5) 例えば /info.html へアクセスすれば、WAN側のIPアドレスなどの機器情報を取得できる
● nosave_encryptedPasswordの補足
ルータはクライアントに jsencrypt.min.js を配信することで、クライアントがログインするときにクライアントにパスワードを RSA暗号(PKCS#1 v1.5 パディング) で暗号化させてからPOSTさせる。公開鍵は login.html に固定値でベタ書きされている。パディングありの方式なので、同じ文字列を同じ鍵で暗号化しても毎回異なる結果を得るが、秘密鍵を持つ側は復号化すればそれらが同じものであると判断できる。つまり、1回ChromeブラウザなどでログインしてそのときのPOSTのペイロードをダンプして記録しておけば、スクリプトからは毎回この同じダンプしたものを使うだけで良くなる。なので、先の 3) について、正しくダンプして記録しさえすれば nosave_encryptedPassword は固定値で問題ない。
● A) 同期的に取得する手段も欲しい
まぁわかる
● B) イベント通知受けを開始したら必ず今の状態を初回通知してほしい
Aとは反対方向の要望だけど、多人数開発だとよくある
● C) a->b->cと連続して変化したときbの通知も飛ばさないでほしい
「状態」のはずなのにこういう要望が出てくると雲域が怪しくなる
● D) イベントはキューに溜まるのか/最大何個溜まるのか/あふれたらどのイベントが消えるのか
Cを許すとこのようなことを言われてしまい実装の厳密性が問題になってくる
● E) イベントが溢れたことを検知できるようにしてほしい
Dが出てくると当然こうなってくる
● F) イベントが溢れたときに何をすればよいのかを教えてほしい
知らんがな、イベントを受けて何やりたいか次第だから、イベントを送る側が考えることじゃないはず
● G) a->cと変化しないでほしい、必ずbを経由してほしい
なぜ外部の都合でこちらの内部状態の設計を変えなければいけないのか、これを許すと「bイベントを補間して送る」ような例外の実装をせざるを得なくなる
● H) イベント通知するとき1つ前の状態も添えてほしい
自身の状態遷移の管理すらこちら側に押し付けてくるのは勘弁してほしい
● I) イベントハンドラ内からAの同期を呼ぶと届いたイベントとは異なる状態が取れる
イベントが届いたタイミングとイベンドハンドラが実行されたタイミングが離れれば、そりゃそうなるよね
シンプルなお題ですらこうなるのだから、大人数が関わる開発ではわかりやすくて勘違いしにくい設計が好まれることになる。
]]>ダイソーやセリアで売ってる電子機器を分解し、中の構造や回路やチップをリバースエンジニアリングする、という内容の本。回路図を起こしたり、チップの仕様書や素性を調査したり、かなり詳細まで調べている。
「100円ショップ」と言いつつ必ずしも100円のものばかりとは限らない、とはいえ数百円でもやっぱり十分に安い、というあたりはこの手の店へよく行く人ならばもはや常識か。ここ10年ほどは電子機器も増えてきていて、なんでこの値段でこの商品を作れるんだ、と疑問に持つ人も多いと思う。電気電子の知識が必要になるが、そういう疑問に答えてくれるような内容になっている。
著者はどちらかというと、分解して部品取りするのを目的にしているっぽいところがある。人によっては商品を作るときの原価がどうなってるのかまで知りたいんだろうけど、さすがにそこまでは語ってくれていない。原価は、原材料費、シンセンの現地価格、為替、関税、などにも大きく左右される水ものなので、ビジネス目的でそういうのを欲しい人はちゃんと自分で調査しましょう。
さすがに2026年にもなって「中国製は安かろう悪かろう」な認識の人はいないだろうと信じたい。ちょっとしたチップ程度なら中国本土で生産してる昨今、この手のオールインワンチップで機能実現する商品はもはや中国に価格・品質のバランスで勝てるとこはないだろう。国の産業のあり方を改めて考えさせられる。
ちなみに著者は、100円ショップのガジェットを分解してみるのサイトを運営していて、サイトの記事や雑誌に寄稿したものを書籍にまとめたものとなっている。ので、だいたいはこのサイトに行けばタダで読める。私はお布施の意味も兼ねて書籍を購入することにした。著者はこの2020年ごろから比較的注目されてるようで、続編2つや同系統の書籍を出したり、インタビュー特集があったりしている。
というわけで、情報欲しいだけなら買わずにサイトへ行くといい。お布施目的や大きめ紙媒体の写真がほしいなら買おう。ただ、第3版まで刷ったのに誤字脱字がそのままっていうのはちょっと、、
]]>特にOSレスの規模の組み込みシステム向けのソフトウェア開発の大まかな技術要素を解説した本。経験の浅いソフトウェア開発者や、ソフトウェアに明るくないハードウェア開発者をターゲットに、実開発の経験から、開発の定石やノウハウを語っている。
まえがきにも書かれているんだけど、体系的な技術の獲得というよりも、実開発の経験を詰め込んでいる章立てや内容になっている。また、OSレス程度の規模が対象とはいえ、(2026年から見て)ここ10年ほどの最近のトレンドがいまいち反映しきれていないようにも思える。一方で、日本語の訳者がLinuxに明るいこともあり、注釈が大規模組み込みLinux向けに誘導している風もあって、読んでて想定読者の像がブレてる印象が拭えない。
内容も、パソコンしか知らない(組み込みを知らない)ような初級開発者が組み込み中級を目指す、といったレベルの内容に感じた。細かく読めば、実体験から来る開発の難しさも書いてはあるんだけど、具体的な手法といった深い内容に入るのではなくて、あくまで初級者に向けて一般論を語りとくというか。著者は、DSPなどの信号処理が本当の専門のようで、いっそのことそっちの内容を増やしたほうがよかったのでは、と思わなくもない。「組み込み」と一口に言っても幅が広くてひとまとめにしづらい、という特有の課題なのかもしれない。
というわけで、私としては、組み込みを知らない初級者ソフト開発者が組み込みを本業にするときに読む本、と感じた。残念ながら今の日本ではそれに該当する人って非常に少ないんだよなぁ。
以下は個人的に気になった箇所のピックアップ集。
2.2.2 ブロック図(P11)
＞SPI(スパイと発音)
今までずっと「えすぴーあい」と呼んでた。というか「すぱい」と呼んでる人見たことない...
3.7.1 デジタルマルチメータ(P51)
＞デジタルマルチメータ(DMM)だけは用意してください。
昔ながらのアナログテスターと今どきの簡易ロジアナしか持ってない。1つくらいDMM持っとくべきかなと思った。YouTuberの熊五郎お兄さんが使ってるAstroAI デジタルテスターくらいがニワカにはちょうどいいのかな。
6章付近
割り込み禁止と排他処理(mutex)との違いの説明が怪しかった。OSレスなのでSMP(マルチコア)ではないからこの程度で十分、なのかもしれないけど、逆にマルチコア当たり前なArm Cortex-A(Linux含む)なんかだと困るんだよなぁ。「割り込み禁止だけでクリティカルセクション対応できる」という思い込みをしてしまうと苦労する(経験談)
8.4.3 littlefs
https://github.com/littlefs-project/littlefs/というOSレス環境で使えるFilesystemがあることを知れてよかった。
10 ネットワークとセキュリティ
は、ネットワークに繋がるのが当たり前になりつつある昨今のIoT事情を反映していてよかった。
11.2 RAM不足の対策
コンパイラ最適化の話がなにか古い気がする。GNU gccベースのそこそこ最近のバージョンならば、Cortex-M向けで「ローカル変数の数を減らす」ようなことは意味がない(コンパイラが賢く処理してくれる)ような。Arduinoくらいの規模でこういうのが必要なんだろうか。
● 小さなPopupウィンドウにたくさん詰め込む
どんなにウィンドウ(表示可領域)を広げても、小さなPopupウィンドウの中でしかスクロールできない。
一度に表示できるコンテンツの量を増やすことができない。
特にデータを入力させる目的で使われることが多く、「そんなサイトは利用しない」選択をしづらいことが多い。
● ヘッダ・フッタがスクロールに追随する
たいていはウィンドウが大きいことを前提にしている。大きくはない環境だと、コンテンツを表示できる領域が小さくなったり、そもそもヘッダ・フッタだけで覆い尽くされてしまう。
今どきは、ウィンドウの横幅より縦幅が積まることが多く、またページを上下にスクロールするのが当たり前なので、ページの左右は問題になりにくく、ヘッダ・フッタが表示領域をせばめることになる。
Googleはさすがというか、ウィンドウが小さいとき用のレイアウトを別途ちゃんと用意している模様。
幸い、最近はJavaScriptではなくてCSSのpositionで位置を決めてることが多いため、ブラウザの機能を使いCSSを上書きして対処できる。
● 遅延ロードを多用する
1つページ表示するだけで多量のデータを流したくない気持ちはわかるが、要素ごとに遅延ロードするなど多用されるとつらい。
特に、サーバとの距離が遠いと、ロードごとに数百msec待たされてしまうため、ストレスが溜まりやすい。
ロード完了させないとページ内検索ができない。なのにどこがまだロードされてないか確認しづらい。
外資系の開発者向けサイトでサイトを探索するときにこれのせいで相当いらつくことが多い。
● 無限スクロール
遅延ロードとも被るが、さらにたちが悪く、「次のページを表示」するごとに延々と続く。
「10ページ先」のように一気に飛ばすことができず、サイトの探索が非常にやりづらい。
「10ページ先」を表すようなURLを取得できない。
無限にページが長くなるため、作りが悪いサイトでRAMやCPUが圧迫されることもある。
ページのリロードなどをするとまた最初からロードを繰り返さないといけない。
● キーボードのスクロールを乗っ取る
UP/DOWN/PageUP/PageDown/Home/Endなどを使ったスクロールができないようなページがときどきある。常にマウスがある前提にしてほしくない。
キーを乗っ取った上でスクロール方法やスクロール量を独自方法にしてるサイトもあるが、ブラウザのデフォルトのスクロール量と違っていたりしていて、何をしたいのか本当にわからない。
● 「次を表示」操作にページ切り替えを伴わない
無限スクロールとも被るが、「10ページ先」のような操作ができない、「10ページ先」を表すURLを取得できない、ことが多い。
「次を表示」すると勝手にコンテンツの先頭へスクロールする、なんてのもあるが閲覧中のページへ勝手に操作を割り込まないでほしい。
● 文字ではなくて画像で埋め込む
見た目を気にして画像にしたのだろうが、これだとページ内検索ができない。
ただ、最近はかなり減ったか。あったとしてもピンポイントでのみの使用で実害は小さいようにしているサイトが多い気がする。
今どき全部が画像なのは、謝罪文などのむしろ検索されたくない類かと思う。
● JavaScriptオフだと全く閲覧できない
JavaScript多用してるから機能制限される、というのであればまだわかるが、何も表示されないサイトもある。
ログインさせたり決済したり、はむしろJavaScriptオンじゃないと何もできないように意図的にしているように見える。
JavaScriptオフを許容するかどうか、今だったら人により考えも違うかもしれない。
● ずっとJavaScript処理しててCPUを使ってる
Coinhiveか？と思わせるような、サイトを表示してるだけでずっと何かにCPUを使ってることがちらほらある。
何かのファイル読み込みが詰まってonLoad完了しないせいなのか、本当に仮想コインを掘ってるのかは知らない。
動画などの広告が動き続けてるせいなこともあるが、さすがに最近はそういうのは減ってきた気がする。
一方で最近は、あえてJavaScriptでCPU無駄遣いさせて「ボットでない」ことを証明させる例もある
一部のウェブサイトで一瞬だけ表示される「ケモ耳少女のイラスト」は一体何者なのか？ - GIGAZINE
https://gigazine.net/news/20250823-anubis-web-ai-firewall/
● 嫌いな広告
何が許されて何が許されないか、人により考えは違うけど、あくまで私の考えはということで。
リンククリックや「戻る」操作時にナビゲーションを乗っ取り広告を出す。
他のウィンドウからフォーカスが戻ってきたときに広告を出す。
ページ全体を覆い尽くすようなのを出す。
広告動画を見ないとコンテンツを閲覧できない。
「閉じる」が押しにくいを主張する意見もわからなくはないが、あれはもはや、音を出したりウィンドウ閉じさせない類の詐欺と同じだと思ってる。
● 番外編
ブラウザやパソコン環境が良くなったおかげで気にならなくなったものとして。
onLoadのJavaScriptが走らないとコンテンツを利用できない --- ネット詰まりで起こってもリロードで解決しやすい
埋め込み画像にwidth/height/alt指定がないせいであとからロード時にレイアウトが変わる --- ネット速度が上がったから困ることが減った
過度なウィンドウ横サイズを要求する --- 横1000あれば足りるサイトがほとんどだし、そういうサイトの時だけウィンドウ広げるし、最悪横スクロールできるし。
文字を大に変更するとレイアウト崩れて閲覧できない --- ブラウザの拡大機能が優秀になったおかげで困らなくなった
● ToS / DSCP
IPv4/IPv6パケットにはToS/DSCPのフィールドが存在し、パケットの優先度を指定することができる。QoSの目的で使われる。
Opensshはこれを指定して通信を行うが、その動作がフレッツ光で問題になることがある。このへんに詳しい。
フレッツ光ネクスト + IPoE における IPQoS設定と scp転送速度 - tsutsuiの作業記録置き場
https://tsutsui.hatenablog.com/entry/2024/10/17/013432
結局のところ、コンシューマなレベルのユーザがQoS目的でパケットのフィールドを設定するなんてのは状況を悪化させるに等しいと思うので、フレッツでの問題を回避する場合でも、OpensshのIPQoSはnoneが無難かと思う。
先の通り「lowdelay throughput」は10.1から意味をなさなくなるので、もう少し時間が立つとそのことに触れるメモ書きも増えるのではと思う。
● お題
mq_open()がerrno==EMFILEで失敗した
● マニュアル
man 3 mq_openによれば、
https://man7.org/linux/man-pages/man3/mq_open.3.html
- プロセスあたりのfile descriptor数上限に引っかかった -> RLIMIT_NOFILE(ulimit -n) を確認する
だが、該当しているように見えない。
ENFILEの可能性も考え、/proc/sys/fs/file-max と /proc/sys/fs/file-nr を確認するも、こちらも問題なし。
● mqueueのsysctlパラメータ(1)
/proc/sys/fs/mqueue/ にこんなのがある
- msg_max --- 1つのキューに入れられるメッセージの最大個を変更するときの上限、kernel内での変数名は(mq_msg_max)または(mq_maxmsg)、以下カッコ内のものは同じ意味
- msg_default --- mq_open()の引数で特に指定しなかったときの新規作成された1つのキューに入れられるメッセージの最大個 (mq_msg_default)
- msgsize_max ----- 1メッセージの最大サイズを変更するときの上限 (mq_msgsize_max)
- msgsize_default ---- mq_open()の引数で特に指定しなかったときの新規作成されるキューへ入れる1メッセージの最大サイズ (mq_msgsize_default)
- queues_max ----- システム全体で作れるqueueの個数 (mq_queues_max)
いずれも特権(CAP_SYS_RESOURCE)があれば制限を受けない。
mq_open()のエラーとなると、queues_maxが怪しいが、/dev/mqueue を見る限りキューの個数の上限に達したようには見えない。
● mqueueのsysctlパラメータ(2)
/proc/sys/kernel/ にこんなのがある
- msgmax 1つのメッセージの最大バイト数を制限する (msg_ctlmax)
- msgmnb システム全体で、msg_qbytesの初期化のパラメータ (msg_ctlmnb)
- msgmni システム全体で、mqの名前の個数を制限する (msg_ctlmni)
- auto_msgmni 今は意味をなさない。過去はメモリサイズが msgmni に影響していたため、これに1を書くことでmsgmniの再計算が走るようになっていた
- msg_next_id 次に作成するmqのIDを指示する、がデバッグ用なので通常は使わない？
こちらも同様、引っかかっているようには見えない。
● limitパラメータ
man 7 mq_overview をきっちり読むまでこれに気づかなかった。
https://man7.org/linux/man-pages/man7/mq_overview.7.html
RLIMIT_MSGQUEUE (ulimit -q) というのがある。1ユーザ(uid)あたりで使えるmqueueのメッセージの合計サイズの条件になる。
管理情報も含むため、メッセージの中身のバイト数の合計よりもちょっと厳しく働く。
サイズを予約するときにチェックする？という方向のため、mq_open()のタイミングで失敗する。
たとえ CAP_SYS_RESOURCE を持っていても制限を回避できない
CAP_SYS_RESOURCE を持ってるとlimitを変更する(ulimit -q unlimited)ことができ、制限を回避できる。
結局原因はこれだった。limitを変更すると動作するようになった。
● mqueueについてのその他の補足
- /dev/mqueueは、存在するqueueの名前を確認できる程度で、ここを直接catしたりduしたりはできない
- /dev/mqueue で rm すると、誰も開いていないqueueを名前指定で削除できる
- mqueueのnamespaceは ipc_namespaces になる。mqueueとsysvipcとが対象にある
- /proc/sys/ や /proc/sys/kernel/ のパラメータはnamespaceごとの制限となる。「システム全体」という古い記載がドキュメントに残ったままなことがあるので注意必要
- プロセスがどのnamespaceに属しているかは file /proc/self/ns/ipc で確認できる
- queueのリストやメッセージの状況は ipcs -q もしくは /proc/sysvipc/msg で確認できる
- /dev/mqueueには見えないのにqueueが作られたという状況になることがある模様？その場合 ipcrm -q でID指定すれば削除できる
● mq_open()のソースコードの確認
linux/ipc/mqueue.c の mqueue_get_inode()あたりでmq_open()を呼んだときのパラメータチェックがなされる。
- バックトレースはこうなる mq_open() -> do_mq_open() -> prepare_open() -> mqueue_create_attr() -> mqueue_get_inode()
- CAP_SYS_RESOURCEがあれば、HARD_MSGMAX HARD_MSGSIZEMAX でチェックし、ダメなら -EINVAL を返す
- CAP_SYS_RESOURCEがなければ、mq_msg_max と mq_msgsize_max でチェックし、ダメなら -EINVAL を返す
- mq_maxmsg * mq_msgsize を計算し、unsigned intをオーバフローしたら、-EOVERFLOWを返す
- mq_maxmsg * mq_msgsizeとオーバヘッド(sizeof(struct posix_msg_tree_node)かける個数)を ulimit -q に計上し、rlimitに引っかかったら -EMFILEを返す (★ CAP_SYS_RESOURCEを見ない)
● limitについての補足
下記のrlimitはuid namespaceごとで制限チェックされる(==同じUIDのプロセスの合計値もしくは共通で効く)、ただしややこしいことに制限値はプロセスごとに設定できる。
- RLIMIT_NPROC (UCOUNT_RLIMIT_NPROC)
- RLIMIT_MSGQUEUE (UCOUNT_RLIMIT_MSGQUEUE)
- RLIMIT_SIGPENDING (UCOUNT_RLIMIT_SIGPENDING)
- RLIMIT_MEMLOCK (UCOUNT_RLIMIT_MEMLOCK)
逆に下記はそうではない(==自プロセスのみに閉じた制限チェックになる))
- RLIMIT_CPU
- RLIMIT_FSIZE
- RLIMIT_DATA
- RLIMIT_STACK
- RLIMIT_CORE
- RLIMIT_RSS
- RLIMIT_NOFILE
- RLIMIT_AS
- RLIMIT_LOCKS
- RLIMIT_NICE
- RLIMIT_RTPRIO
- RLIMIT_RTTIME
● capabilitiesについての補足
- ランチャープログラムの場合は Ambient Capabilities で付与するのがよい(子に引き継げるため)、ただしUID/GIDの動的変更をしないfile capabilitiesによる付与を行わないという前提で。
- そうでない場合はマジメに capabilities のexec時の継承ルールを理解して利用するのがよい。
- man capabilities(7) にcapabilitiesを継承するルールが記載されているがこの記号式は何度見ても理解できない。下記に抜粋しておく。
P'(ambient) = (file is privileged) ? 0 : P(ambient)
P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient)
P'(effective) = F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable) [i.e., unchanged]
P'(bounding) = P(bounding) [i.e., unchanged]
● 個人の感想
- rlimit(rlim)の値は、kernelのtask_structのメンバsignalの中にある。なんか直感に対して違和感があった
- msgctlというsysctlがあることを初めて知った
- getpcapsなにもわからない。capabilitiesを読みやすいテキストに表示してくれるという触れ込みなのに、表示されるテキストが記号的で逆に分かりづらい
- ゼロが多い巨大ファイルを強制的に Filesystem sparse (hole) に変換したい場合は cp --sparse=always で別ファイルを作るのがよい
● git lfs
git.lfs.storage (LfsStorageDir)を使っている場合、古いLFSオブジェクトをクリーンナップするよい方法が見つからなかった。
● repo
reop list -p すればrepoで管理するgitのリストを表示してくれるので、これをもとに git -C DIR gc すればよい。
ただ、1つずつgit gcしてると、対象がたくさんあるときに時間がかかる。
そういう場合、一般的には GNU parallel を使うのが良いとされるが、GNU parallel はオプションやら前置後置やらの使いこなしがクソめんどい。
ので、GNU parallelっぽく使える mypara.pl を作って公開してるので、興味ある人は使ってみて。
https://github.com/rarul/tools/blob/master/script/mypara.pl
下記のように、mypara に pipe で行単位で送ると、1行1コマンドとして -j 4 の最大4並列で実行する。
- $ for ff in `repo list -p`; do echo ${ff}; done | xargs mypara -j 4 -c "git -C" -C "gc"
(-p なのか -n なのか、--mirrorの場合はディレクトリ名に".git"が追加でつくとか、そのへんは適当に調整してください)
● bitbake DL_DIR
単純にアクセス時間の古いものを消せばよい。
- $ cd /mnt/share/downloads
- $ find . -type f -atime +60 -delete
- $ find . -type d -empty -delete
まれに「atime記録書き込みするのがイヤだから-noatimeにしている」人がいるが、ことLinuxに関しては、過去に私が記事に書いた通り、relatimeがあるので、あえてnoatimeにする価値は低い。
● bitbake SSTATE_DIR
DL_DIR同様、単純にアクセス時間の古いものを消せばよい。
- $ cd /mnt/local/sstate-cache
- $ find . -type f -atime +60 | xargs rm -f
- $ find . -type d -empty | xargs rmdir
bitbake環境では、sstate-cache-management.py というスクリプトも提供されるが、これは、1つのbitbakeツリーから1つのSSTATE_DIRを利用している場合にのみ利用できる。
複数のbitbakeツリーから1つのSSTATE_DIRを共有している場合には sstate-cache-management.py は役に立たない。
下記も参考に。
26 Conserving Disk Space
https://docs.yoctoproject.org/dev-manual/disk-space.html
● 設定の具体例
私は /etc/profile.d/proxy.sh に記載することにしている
- export http_proxy="http://proxy.example.com:8080/"
- export https_proxy="http://proxy.example.com:8080/"
- export no_proxy="localhost,.example.com,192.168.0.0/16,10.0.0.0/8"
● 結論の説明
- wget はもはや環境変数解釈の変更が受け入れられるほどはメンテされていないのであきらめて curl を使う
- cURLは、Curl-v7.86 (2022/10/26)から明文化された https://github.com/curl/curl/issues/9773
- Dockerは、Go次第だが、明文化されている https://pkg.go.dev/golang.org/x/net/http/httpproxy
- gitは、curlをライブラリとして使っているため、curl次第となる
- Goだけが環境変数の大文字から探しに行くため、混乱避けるためにも、大文字環境変数は一切使わない、小文字環境変数のみにするべき
- アスタリスク(asterisk"*")は、「アスタリスクのみ」の場合だけ明文化されている('export no_proxy="*"')ため、これ以外は使わない
- 「no_proxy環境変数の解釈はツール次第だから注意必要」なのはその通りだが、現実的にno_proxyを使うのは上記くらいなので、あまり困らないと思う
● そもそもの前提
- HTTPプロキシが必要な環境の場合、毎回プロキシ指定するのはめんどいので、環境変数 http_proxy や https_proxy で設定することが多い
- LAN内サーバはプロキシなしアクセスする必要あるので、シームレスに使うために、no_proxy 環境変数に除外するものを設定することが多い
- これら環境変数はしょせんは各ツールが各ツールごとに解釈するという動きをする
- no_proxyの解釈がツールによりバラバラなので統一的な no_proxy の設定方法が定まらずみんな困っていた
● 記事
no_proxyを標準化する方法：お客様事例で徹底解説
https://about.gitlab.com/ja-jp/blog/2021/01/27/we-need-to-talk-no-proxy/
↑の記事の翻訳元の記事がこれ
We need to talk: Can we standardize NO_PROXY?
https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/
no_proxy の設定方法が定まらない話を12年前に取りまとめた記事
no_proxy にネットワークアドレスとかワイルドカードを指定しても期待通りに動かない、でどうするかというお話 - 双六工場日誌
https://sechiro.hatenablog.com/entry/2013/08/06/no_proxy_%E3%81%AB%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%A8%E3%81%8B%E3%83%AF%E3%82%A4%E3%83%AB%E3%83%89%E3%82%AB%E3%83%BC%E3%83%89%E3%82%92
● その他
今でも外部と通信するのにプロキシ必須としているような組織ってどのくらい残ってんだろ
オーバクロックよりも省電力を優先して試行錯誤する。最近は電圧を下げるよりもLLC(CPU Load Line Calibration)を調整するのが流行りの模様。ということで試してみるも、Non-KシリーズのCPUだと相対的に上下幅が小さくなるので、そこまでの差はでない模様。一方で、電圧下げ(offsetでマイナスする)の方向も、最近のCPUはいよいよ上も下もピーキーにコントロールするので、特に低負荷からの立ち上がりで引っかかってしまうことが多い模様。というわけで、申し訳程度に電圧を下げてはみたものの、実際のとこ効果はかなり小さい。
ロード時の負荷管理という意味では、PL1/PL2の電力上限と期間を管理するほうがわかりやすい。PL1/PL2の考えのおかげで、オーバクロックの目的だけではなく、省電力志向もやりやすくなった。i5-14400でテストしてみた感じだと、ワットあたりのCinebenchスコアで計算すると、35W制限が一番効率よく、高効率を選ぶと35W-55Wくらい、定格TDPの65Wを包含しようとすると30W-65Wくらい、となった。ので、PL2を55W、PL1を45Wにしておいた。とはいえ、リテールのCPUクーラでも14400のOCのほぼ上限の85Wくらいで回し続けても十分に冷やせるんだけどね。
ASPMを有効にするのは引き続きアイドル時電力を下げる効果がそこそこあるのを確認した。
ただ、とはいえ自作PCを組む作業は世間一般的には本当に廃れた。特定の目的(ゲーム・動画編集・VTuberなど)があって高性能構成を用意するくらいで、一般的な用途だとちまたにあふれてる小型PCのほうが取り回し含めて十分だなぁとは思う。私も、今回はパーツ流用を考えたから組んだものの、電源やケースも買い替えとなったならば小型PCに走ったかなぁと思う。
あと、Windowsを使う優先度が下がった。旧来の設定を廃することの多いWindows11で、安定性にも疑問を抱くようなトラブルもちらほらとあり、Linuxを使う頻度も上がっている私の事情からすると、そう遠くない時期にWindowsはもう用意しなくてもいいやとなるのかもしれない。
]]>● confパラメータ
- PARALLEL_MAKE ?= "-j 4 -l 12"
- BB_NUMBER_THREADS ?= "4"
--- 上記の掛け算になるので最大16並列になる
--- 1ジョブあたり1GiBくらいメモリを平気で使う
--- 過大な値が初期値に記載されてることが多いので要注意
--- よくばってもスワップで遅くなったりOOMで失敗したりする
--- 深さ優先ビルドのほうが効率良いのでPARALLEL_MAKEを大きくするのがよいと思う
--- "-l 12"でload average制限もつけておくと安全かもしれない
--- - ninjaの場合に -l も引き継ぐ場合と引き継がない場合とがある？(詳細未確認)
--- 「?=」で記載しとくとexportで環境変数で上書きできるので便利
--- - 実は引き継いでほしい変数を宣言しておかないといけない？
--- - 「export BB_ENV_PASSTHROUGH_ADDITIONS="SSTATE_DIR "」など？
- BB_NUMBER_PARSE_THREADS ?= "4" --- parse時はあまり負荷意識する必要ないので特に設定しなくてよいと思う
- PACKAGE_CLASSES ?= "package_ipk" --- rpmからipkにするとビルドは早くなるらしい
--- いまいち効果を確認できず。要追加検証。
- DL_DIR ?= "${TOPDIR}/downloads" --- 複数ツリーでダウンロードフォルダを共通化する
- SSTATE_DIR ?= "${TOPDIR}/sstate-cache" --- 複数ツリーでsstate cacheフォルダを共通化する
- SSTATE_MIRRORS ?= "file://.* http://someserver.tld/share/sstate/" --- リモートや複数PCでsstate cacheを共有する
- INHERIT += "own-mirrors"
- SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
--- DL_DIRになかったときはここも確認する、PREMIRRORSとほぼ同じだがPREMIRRORSよりも便利らしい
- BB_SERVER_TIMEOUT ?= "20" --- 仕事なくなったbitbake serverが終了するまでの待ち時間、bitbakeコマンドを頻繁に実行するなら大きめの方が良い？
- BB_PRESSURE_MAX_CPU = "200000" --- PSI(Pressure Stall Information)のCPUで追加job実行の制限をする
--- CPUの(論理)個数をNとして、N >> 2 だと仮定して、「2 * 1000000 / N"」 くらいか、と思う
--- 詳細はこのへんを見て
- BB_PRESSURE_MAX_MEMORY --- Pressure Stall(PSI)のmemoryはピーキーなので「スワップ発生中」判定くらいしか使いにくいと思う
- BB_PRESSURE_MAX_IO --- Pressure Stall(PSI)のioは負荷の程度を判断する目的では使い物にならないと思う
- INHERIT += "rm_work" --- 中間ファイルを消してくれるのでディスク容量節約になる
● bitbake基本
- bitbake -c taskname recipe-name
--- "taskname"で普段使うのはこのへんか？
--- fetch patch configure compile install deploy image
--- rm_work --- 中間ファイルを消す
--- clean --- outputを削除する
--- cleansstate --- build時に作ったsstate cacheも削除する
--- cleanall --- ダウンロードしたファイルも削除する
- -f --- 強制実行
- -s --- レシピ一覧
- bitbake -c cleansstate world --- すべてのレシピを指定
- bitbake -c populate_sdk recipe-name --- SDKを作る
- bitbake --runall=fetch recipe-name --- すべてのレシピのfetchのみ実行する
- bitbake -c menuconfig virtual/kernel --- menuconfig実行する
● bitbake応用
- bitbake -e recipe-name --- すると変数名が出る？
- bitbake-layers show-layers --- レイヤー一覧を表示
- bitbake-layers show-recipes --- レシピ一覧を表示
- bitbake-layers show-appends --- bbappend一覧を表示
- oe-pkgdata-util find-path /lib/libc.so.6 --- ファイルを提供するレシピを探す
- bitbake-getvar -r recipe-name VARIABLE --- 変数を参照する箇所をデバッグ表示する
- bitbake -g -u recipie-name target-name --- 依存を調査するためのグラフィカルツール
- bitbake -c devshell recipie-name --- ビルドエラーなどのデバッグ用のdevshellを立ち上げる
--- buildhistory-diff
- bitbake-layers create-layer -p PRIORITY LAYER
--- レイヤーは理解できてないのでこれあまり以上書けない、、
● レシピ基本
- PACKAGES --- レシピが提供するパッケージ名、test.bbがあると「"test-dbg test-staticdev test-dev test-doc test-locale test"」が提供される
- PROVIDERS --- レシピが提供するプロバイダ名、要はbbが提供する成果物のこと、test.bbがあると「test 」が提供される
- DEPENDS --- このレシピのビルドのために先にビルドする必要がある依存パッケージを書く
- RDEPENDS --- このレシピの実行のために必要となる依存パッケージを書く
- SRC_URI --- 「file://」「https://」 あたりを使う、sshの場合は「protocol=ssh;」を追加する形になる？
- SRCREV --- git sha1とかを入れる、「SRCREV = "${AUTOREV}"」でブランチ名オンリーにできるが毎回fetchして最新の変更を追随してしまうので推奨されていない
● レシピ変数
ほぼ下記ここからパクった、、
https://qiita.com/rg125_suzuki/items/702e90084e12e0fdf6de#%E3%81%9D%E3%81%AE%E4%BB%96
- ${S} --- ソースコードの展開先
--- gitの場合明示的に「S = "${WORKDIR}/git"」とする必要がある
- ${BPN} --- 基本レシピ名、zlib-native-1.2.11-r0の場合、zlib
- ${PN} --- fixつきレシピ名、zlib-native-1.2.11-r0の場合、zlib-native
- ${PV} --- バージョン、zlib-native-1.2.11-r0の場合、1.2.11
- ${PR} --- リビジョン、zlib-native-1.2.11-r0の場合、r0
- ${BP} --- ${BPN}-${PV}、zlib-native-1.2.11-r0の場合、zlib-1.2.11
- ${PF} --- ${PN}-${PV}-${PV}、zlib-native-1.2.11-r0の場合、zlib-native-1.2.11-r0
- ${TOPDIR} --- ビルドトップディレクトリ、pock/buil dなど
- ${TMPDIR} --- ${TOPDIR}/tmp
- ${WORKDIR} --- レシピの作業ディレクトリ、poky/build/tmp/work/x86_64-linux/zlib-native/1.2.11-r0 など
- ${D} --- ${WORKDIR}/image
- ${B} --- このレシピを処理するときの一時インストール先？デフォルトは ${S} と同じ？
--- ${S}がsrc、${B}がconfigureしたときのobj、${D}がインストール先、という関係？
● レシピ拡張
- レシピを書き換えるのではなくてレイヤーで重ねるべき、とドキュメントに書かれてる
- bbappendはバージョン固有であるべき、とドキュメントに書かれてる
- example_1.0.bb を example_1.0.bbappend で拡張する
- example_1.%.bbappendは、example_1.0.bb にも example_1.1.bb にも効く
- パッチファイルなどを足すときは.bbappendにこんなのを書く
--- FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
--- SRC_URI += " file://custom-modification-0.patch "
- タスクを拡張するときは.bbappendにこんなのを書く
--- do_install:append() {
--- install -d ${D}${sysconfdir}
--- }
● 仮想パッケージ
- PROVIDES = "virtual/libgl" --- 複数レシピが同じ仮想名を提供できる
- PREFERRED_PROVIDER_virtual/libgl = "mesa" --- 仮想パッケージを選ぶ？
- PREFERRED_VERSION_linux-yocto = "5.14%" --- 特定バージョンを選択する、%はワイルドカード
● レシピ応用
- .bbclass --- レシピのルールのテンプレートみたいなやつ、わざわざ自分でカスタム.bbclassを作るケースはほぼないかと
- base.bbclass kernel.bbclass autotools.bbclass cmake.bbclass meson.bbclass useradd.bbclass などがある
- inherit
● 変数代入
- "=" --- 変数を使用するときに展開(makeと同じ？)
- ":=" -- - 即座に展開(makeと同じ？)
- "+=" --- 後置スペースあり追加
- "=+" --- 前置スペースあり追加
- ".=" --- 後置スペースなし追加
- "=." --- 前置スペースなし追加
- "?=" --- 未割り当てのときに割り当てる
- "??=" --- 未割り当てのままのときにのみ反映されるデフォルト値、ややこしいので使わないほうがいいと思う
- VARIABLE:override = "some_value"
--- 変数展開時に先頭に追加する
--- 「VARIABLE_override」という書き方があったが古い構文なので今後は使わない
- IMAGE_INSTALL:append = " dropbear" --- 末尾にスペースなし追加
- FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" --- 先頭にスペースなし追加
- IMAGE_INSTALL:remove = "i2c-tools" --- 変数内のすべての出現を削除
- KERNEL_DEVICETREE:beaglebone = "am335x-bone.dtb"
--- OVERRIDES内に「beaglebone」があるときのみ代入される
--- 優先代入されるので「beaglebone」がある場合は「KERNEL_DEVICETREE = ""」は無視される
● 変数フラグ
- 主にタスクに条件を足すことができる
- do_compile[dirs] = "${B}" --- タスクを実行する前に生成されるべきディレクトリ
- do_settime[noexec] = "1" --- タスクの実行を無効にする
- do_menuconfig[nostamp] = "1" --- タスク実行時にstampファイルを作らない、のでタスクが常に実行される
- do_patch[depends] = "quilt-native:do_populate_sysroot" --- タスク間の依存を追加
● イメージ作成
- IMAGE_INSTALL --- イメージに入れる
- IMAGE_BASENAME --- イメージファイル名
- IMAGE_FSTYPES --- イメージタイプ、ext4 squashfs などに処理できる？
● FAQ
- Q: DEPENDS と RDEPENDS の違いがわからん
--- A: DEPENDSはビルド時依存、RDEPENDSは実行時依存(だからIMAGE_INSTALLにも効く？)
- Q: ビルドエラーログってどこ？
--- A: モジュール毎の temp/ 以下の "log.do_compile"、"run.do_compile"はそのまま実行可能、どちらもsymlink
- Q: include と require の違いは？
--- A: includeはファイルがなくてもエラーじゃない、requireはパースエラー
- Q: ちょっと変更しただけなのにモジュールやファイルがないというビルドエラーが出る
--- A: 既存のレシピで依存やinstallの記載漏れがあるせいと思われる、bitbakeレシピはチェックが厳格なのでこういうのが起こりやすい
● 参考サイト
Yocto build 時間を10時間から10分に高速化した話 - Qiita
https://qiita.com/naohikowatanabe/items/868eefed28cefec20ff8
【yocto】レシピ内変数の早見表 - Qiita
https://qiita.com/rg125_suzuki/items/702e90084e12e0fdf6de
lockfileでdo_compileをシリアライズするという裏技
https://stackoverflow.com/questions/71885775/mutually-exclusive-bitbake-recipes-tasks
● ドキュメント
12 Variables Glossary / The Yocto Projec
https://docs.yoctoproject.org/ref-manual/variables.html
Yocto Project and OpenEmbedded system development training (PDF注意)
https://bootlin.com/doc/training/yocto/yocto-slides.pdf
このへんにサンプルレシピの具体的な例のURLもぜひほしい
● 所感
Yoctoなにもわからない
Yoctoはプログラマ向けではなくてディストリビュータ向けなので開発には向かないと思う
追加のハマりどころがあれば追記する予定
2025/1/31(Fri): 便利そうなコマンド類を追記、誤字脱字訂正
約17年前に発売された「Binary Hacks」の名前を冠する続編本。一般的に「低レイヤー」と呼ばれることの多い、コンピュータソフトウェアの中でも特にOSやCPUに近い部分の技術を、章ごとに1つずつ紹介するという内容になっている。
「Binary Hacks」はそれなりに反響のあった本だったため、その名前を冠するだけで、それ相応に注目を集めることになる。本を読んだ限りでは、名前に恥じることのない程度には濃い内容に仕上がっている。まぁ逆に、こんな内容の濃い本を好き好んで読もうと思うような人がいったいどれだけいるのかというあたりにも疑問を持つ。20年ほど前と比べると、今やこの日本でこういった内容のソフトウェア技術を必要とする仕事やらは本当に減ってしまったなというのが個人的な印象だ。
低レイヤーは技術の進化が早いわけではないとはいえ、20年近くも時代が進むとそれ相応に変わっていくわけで、その内容を雑多的に情報として知れるというのは実際のとこ個人的には非常にありがたい。書籍として出版されることが減ってきているという時代に、しかも需要がどんどん減ってる日本語での技術情報提供でというあたり、儲かりもしないのにこれだけのレベルでまとめ上げてくれた各位には本当に感謝したい。
著者らは「＊年後にさらにこの本の続編が出ることを期待して」のような記載を残している。これこそ、こういう領域に熱意を持って力を注ぎこむような人が今後も続くのかどうか、もっと言えば、こんな領域のソフトウェア技術開発を未来の時代に行っているほど日本(なのか日本語なのか)がグローバルに競争力を維持できているのかどうか、という話なのかなと思う。
前作と比べるとページ数が約1.5倍になっている。改めて前作を斜め読みするに、あまり細かく丁寧に説明するような文章にはなっていなくて、それに対し本作は文章をかなり丁寧に書いている事が多いので、その分がページ数の差なのかなと感じた。600ページ超えとなるともはや大型本よね。「サクッと読む」には少々重いというのが若干残念なところか。
というわけで、低レイヤー技術を対象に日本語で書かれた非常にレアな本で、その領域に片足を突っ込んでる人は迷わず買っておけというところ。逆に、低レイヤーに興味がない人には全くささらないと思う。
下記は本の内容で気になったところをメモがてらに。
HACK#6 共有ライブラリの検索の実例
P39「AT_SECUREタグを持つエントリが含まれていた場合」
今まではsuなどのときにLD_LIBRARY_PATHが無効になる条件がわからなかったけど、補助ベクトルが効いていることを知れてよかった。
過去の記事のどこかに「わからない」と自分で書いた記憶があるんだけど、探しても見つからなかったので、訂正ができない。。
HACK#10 TLSのしくみを理解する
P58「TLSアクセスモデル」
gdbでattachしている最中にThread Local Storageな変数へアクセスする方法がいつもわからずに苦労していた。このあたりの記載を頼りに調査すれば、今どきのgdbからのアクセス方法を確立できそう。
HACK#17 LIEFを使ってELFバイナリを書き換える
P92あたり
まさに最近はシンボルの書き換えがクソめんどいから、こういう専用のツールがあることを知れてよかった。ただPython製というのはどうなんだろ。特にクロス環境にて、いずれにしてもlibelfに依存することを考えれば、Pythonに追加対応させるためのツール整備も最近なら大した事ない？
HACK#38 cgroupでプロセスのリソースを管理する
P248 「IOCOST」
I/O Schedulerで制御することしか知らなかった私からすると、こんな他の手段もあるんだなぁと知れてよかった。けど、本書での紹介っぷりからすると、必ずしも思い通りにI/O量を制御できるわけではなさげ？I/O Schedulerでも制御が難しいし、やっぱりI/O制御は難しいという話なのか？
HACK#43 /proc/PID/rootからコンテナ内のファイルに直接アクセスする
docker内のファイルへ外から簡単にアクセスする方法、ずっとこれのやり方が知りたかった。わからなかったので、わざわざdocker cp使って毎回中から外へ大量のコピーをしてしまっていた。
HACK#49 ftraceを使ってカーネル内で起こっていることをトレースする
P341あたり、
KernelShark trace-cmd、あたりは過去に使ってみたことはあるんだけど、これ、目的を定めて使わないと逆に迷走するなと感じた。GUIで可視化すると一部のエライ幹部に受けが良くて、かえって性能改善活動のジャマになって(以下略
セキュリティの大章は全般的にツールを使った力技的な話が多くて「HACKしている」感があまりしないと感じた。数値表現の大章はいわゆる数値計算の分野だというイメージが強くて「まぁ知らなくてもいいかな」と読み飛ばし気味になってしまった。
]]>● 参考サイト
非自明なデフォルトのデストラクタは暗黙にnoexcept
https://faithandbrave.hateblo.jp/entry/20120322/1332399681
C++ の noexcept specifier のちょっとややこしい仕様
https://zenn.dev/mafafa/articles/a8ae1e546f7634
● 仕様の要点だけを抽出
- 派生クラスのdtorが例外を出すなら、dtorは暗黙にnoexcept(false)である
- 基底クラスのdtorがvirtualかつ例外を出すなら、dtorは暗黙にnoexcept(false)である
- = deleteと定義したら、dtorのnoexceptは翻訳対象から外れ考慮外になる
- 上記に当てはまらなかったら暗黙にnoexcept(true)である
上記のルールにより、declareとdefineとでnoexcept(true|false)が入れ替わるということが起こり得る
● ハマった点
Effective Modern C++ 項目22: Pimpl イディオムを用いる際は特殊メンバ関数を定義する
のルールに則ると、
- a.hpp に class A で virtual ~A(); とdeclare する
- a.cpp に class A で A::~A() = default; と define する
という具合になると思う。
が、このように書くと、バカマジメに仕様を解釈しようとするやつ(某静的解析ツール)は、
- declare と define とで noexcept のprototypeが異なるかもしれない
みたいなことを言い出す。
回避するためには、基本的に noexcept(true) であると明示した方が良いとなる。
- a.hpp に class A で virtual ~A() noexcept; とdeclare する
- a.cpp に class A で A::~A() noexcept = default; と define する
● 所感
C++ﾏｼﾞ闇。。ﾏﾘｶしょ。。
● パソコン
TRIGKEY G4 N95にした(Amazonアフィ)
ライセンスの怪しいWindowsは使わない、技適が怪しいBluetooth/WiFiは使わない。
以前にも書いたけど、BIOSで「Advacnced→Power→GT→RC6」を「Enable」にするとGPU消費電力を抑えやすい。あとは、PL1/PL2制限をキツめにし、Ethernetを100Base-TXに制限し、不要なUSBは接続しない(キーボード・マウス)、不必要なHDMIを接続しない、systemctlでbluetoothdを止める、/sys/devices/system/cpu/cpufreq/policy0以下で「energy_performance_preference = balance_power」「scaling_governor = powersave」「scaling_max_freq = 1500000」とかしておけば、idle時で5W前後にはなるはず。WiFiドライバやBluetoothドライバをrmmodしても特に変化は見られなかった。
● チューナ
PLEX PX-W3U4(Amazonアフィ)
px4_drv.git(@nns779)という非公式ドライバがあるが、メンテが止まっちゃっているので、forkしたこっち(@tsukumijima)のほうがいいかもしれない。Ubuntu-24.04LTSで試すと、UBSANのオーバラン誤検出でdmesgが汚れて困ったので、パッチ(0001-change-usage-for-variable-array.txt)作った。が、同じようなパッチを作った人がすでにいた(px4_drv_chrdev20240521.patch)。
● ICカードリーダ
SCR3310/v2.0(Amazonアフィ)
可能なら、ICカードリーダはPX-W3U4に内蔵のを使ってみたかったが、Windowsで実際に動かしてUSBバスのダンプを取って...みたいなリバースエンジニアリングする気力までは出なかった。
● Mirakurun(チューナサーバ)
docker拾い食いに抵抗がないなら、docker-mirakurun-epgstation.gitが楽だと思う。recpt1を自分でコンパイルして準備し、tuners.ymlとchannels.ymlを整える必要はあるが、逆にそれだけ行えばもう動いてしまう。後述するが、私はEPGStationは自前で立てることにしたので、docker-compose.ymlでそのへんをごまかした。
● EPGStation(録画視聴サーバ)
Ubuntu-24.04LTSのaptで取れるffmpegでも、vaapiとIntelプロプラドライバを整えれば、QSVによるハードウェアエンコードができるということがわかったので、Ubuntuホストのffmpegを使うためにも、EPGStationはdocker板ではなくて自分で立てることにした。とはいえ公式のレポジトリから持ってきて手順通り動かすだけだけど。ffmpegをvaapiのh264で動かすために、config.ymlとenc.jsを変更した。QSVを使うとN95の1.5GHzでもh264エンコードは余裕だった。まぁソフトエンコでも-threads対応だから200-300%くらいでリアルタイムでも回るんだけど。改めてN95/N100シリーズってすげぇ。
● サスペンド
いくら省電力とはいえ、何もやっていないときにも動かしっぱなしにするのはなにかもったいない。ということで、スケジュールをチェックしてサスペンドするsuspendd.plのPerlスクリプトを書いた。次の録画予約、3日に1回EPGデータ巡回、重要なプログラム(sshログイン・Sambaアクセス中・recpt1使用中)、をチェックして空いていたらサスペンドする(rtcwake -m mem -s 3600)ようにしてみた。注意点として、EPGStationは公式にはサスペンドをサポートしていないので、起き上がってきたらresettimer(curl -X POST "http://127.0.0.1:8888/api/recording/resettimer")をしてタイマーのイベントドリブンを再スケジュールする必要がある。しなかったらタイマーイベントがずれて録画予約に失敗する。
● その他
マジメに使い倒すならばデータ置き場をHDDにしたりもいいんだけど、まぁ遊びだから、たぶんこのくらいまでにとどめておくことになるんじゃないかなと思う。暇があれば、生のMPEG2-TSからパケットパースしてschedule EITやpf EITをひろってきて番組表を自力で作る、なんてのもいいのかもしれない。
鉄道業界が社会や地域へ貢献できなくなっている具体例を示して問題点を指摘する本。地方赤字路線の廃止を主題にしつつも、鉄道存続そのもののみを議論しても意味がなく、交通を介し地域や自治体が自身を今後どのように運営するべきかを考えないといけない、と説いている点が特徴となる。
趣味のジャンルで活動する人が多い鉄道系YouTuberの分野で、社会問題の観点で語るYouTubeチャネルを運営する鐵坊主氏の著作。元旅行代理の経歴から鉄道を切り口に地域や自治体のあり方を考える動画をカナダから投稿する、というなかなか類のない活動を行っている。自治体や会議体の公表する資料を読み解きながらていねいに根拠を積み上げて議論する、という点も著者の強みとなっている。
鉄道事業は固定費が重く、また関東ですら今後人口減を迎えるため、それを踏まえ各社は長期計画を立てて運営していたが、それが新型コロナの登場で短期計画がすべて吹っ飛ぶほどの赤字になり経営が揺れ動いた。このため、各社により温度差はあるものの、どこも人口減を見据えた長期計画を前倒しで始めざるを得なくなった。これが、特にJRで、地方の赤字鉄道路線を維持するのはこれ以上はムリだとして廃線に向けて議論を加速したい動きになっている。方や地元自治体は、従来通りの廃線反対な声を上げるだけの例が未だに多い。議論を単に先延ばしにするだけではダメで、人口減の速度と社会情勢を踏まえた地域交通のあり方を真剣に考えなければいけない、と著者は説いている。
私も素人ながら地域や都市機能と交通とのあり方をおぼろげながら考えることがあったけど、著者のYouTubeチャネルを見始めてから、かなりマジメに考えるようになった。特に、ここ25年ほどは一貫して、(新幹線を除き)鉄道路線の整備よりも高速道路網の整備が優先され続けてきていて、それにより、高速バスがJRの特急に勝つ方面が増えた、という点をきちんと理解できていなかったと反省している。是非はともかく、JR分割民営化により、大都市部と新幹線以外はもう諦めて手を抜くんだという国交省の方針の成れの果てが今なんだと思い知らされた。これでは、未だに「国鉄」の認識と変わらない主張をするような自治体とは議論がかみ合わないわけで。
新聞や銀行と並び、もはや斜陽だと言われることもある鉄道業界の現状を知るうえでの良本。特に、鉄道を主人公に語るのではなくて、自治体や社会のあり方に踏み込んで考えている点がよい。逆に、現在の議論が停滞している状況を一変させるアイディアを語っているわけではない点には、現実的になかなかいい案があるわけではないとはいえ、仕方がないのかもしれない。
]]>