らるるの自宅と職場を往復する人生＠それをすてるなんてとんでもない！

Amazonアフィリンク

ダイソーやセリアで売ってる電子機器を分解し、中の構造や回路やチップをリバースエンジニアリングする、という内容の本。回路図を起こしたり、チップの仕様書や素性を調査したり、かなり詳細まで調べている。

「100円ショップ」と言いつつ必ずしも100円のものばかりとは限らない、とはいえ数百円でもやっぱり十分に安い、というあたりはこの手の店へよく行く人ならばもはや常識か。ここ10年ほどは電子機器も増えてきていて、なんでこの値段でこの商品を作れるんだ、と疑問に持つ人も多いと思う。電気電子の知識が必要になるが、そういう疑問に答えてくれるような内容になっている。

著者はどちらかというと、分解して部品取りするのを目的にしているっぽいところがある。人によっては商品を作るときの原価がどうなってるのかまで知りたいんだろうけど、さすがにそこまでは語ってくれていない。原価は、原材料費、シンセンの現地価格、為替、関税、などにも大きく左右される水ものなので、ビジネス目的でそういうのを欲しい人はちゃんと自分で調査しましょう。

さすがに2026年にもなって「中国製は安かろう悪かろう」な認識の人はいないだろうと信じたい。ちょっとしたチップ程度なら中国本土で生産してる昨今、この手のオールインワンチップで機能実現する商品はもはや中国に価格・品質のバランスで勝てるとこはないだろう。国の産業のあり方を改めて考えさせられる。

ちなみに著者は、100円ショップのガジェットを分解してみるのサイトを運営していて、サイトの記事や雑誌に寄稿したものを書籍にまとめたものとなっている。ので、だいたいはこのサイトに行けばタダで読める。私はお布施の意味も兼ねて書籍を購入することにした。著者はこの2020年ごろから比較的注目されてるようで、続編2つや同系統の書籍を出したり、インタビュー特集があったりしている。

というわけで、情報欲しいだけなら買わずにサイトへ行くといい。お布施目的や大きめ紙媒体の写真がほしいなら買おう。ただ、第3版まで刷ったのに誤字脱字がそのままっていうのはちょっと、、

Amazonアフィリンク

特に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くらいの規模でこういうのが必要なんだろうか。

● 前置き
あくまで私の個人の意見であり、こうでなければいけないという強い主張をしたいわけではない。
広告否定派ではない。むしろいわゆるAdBlock類はよくないものだと考えていて、実際使っていない。

● 小さな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あれば足りるサイトがほとんどだし、そういうサイトの時だけウィンドウ広げるし、最悪横スクロールできるし。
文字を大に変更するとレイアウト崩れて閲覧できない --- ブラウザの拡大機能が優秀になったおかげで困らなくなった

● .ssh/config
いちいち/etc/hosts書き換えたり、ssh -p /scp -P したりしなくてよい
　　User rarul
　　HostName 192.168.123.234
　　Port 1022
NAPTごしなど勝手に切断されちゃうなどのとき
　　ServerAliveInterval 60
　　TCPKeepAlive yes
セッションを圧縮して帯域の使用を効率化。ssh -C /scp -C でもいい。
　　Compression yes
同じサーバに複数ターミナル立ち上げるとき
　　ControlMaster auto
　　ControlPath ~/.ssh/mux-%r@%h:%p
　　ControlPersist 15
多段sshしたいとき
　　ProxyJump yourhostname # 踏み台にしたいHostの箇所の名前を指定する
ToS/DSCPでおかしくなるとき
　　IPQoS none
※ Opensshは「lowdelay throughput」がデフォルトだったのが、7.8 から「af21 cs1」になった。
...までは比較的ネット上に書かれているが、10.1から lowdelay reliability throughput のキーワード自体が廃止されたので注意。

● 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から意味をなさなくなるので、もう少し時間が立つとそのことに触れるメモ書きも増えるのではと思う。

(2025/9/20追記: ipc namespaceがらみの話が弱かったため多めに加筆)
(2025/9/26追記: 書き漏れがあったのでさらに加筆)

● お題
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 で別ファイルを作るのがよい

● ccache
ccacheの--evict-older-thanオプションは、atimeではなくてmtimeを見るため、「キャッシュ作ったのは昔だけど最近も使った」ようなものまで消してしまう。
Clarify --evict-older-than ・ Issue #1292 ・ ccache/ccache
https://github.com/ccache/ccache/issues/1292
mtimeではなくatimeを見るようにccacheそのものを変更してしまう以外のいい方法がわからない。
サイズあふれしてないことを確認しながら ccache -M 10G などしてサイズ上限で自動的にクリーンナップさせるくらいがよい？

● 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

● 結論
- 環境変数は小文字のみを使う
- wgetは使わない
- IPアドレス範囲はCIDRで記載する
- ドメイン部分マッチは「.example.com」形式にする

● 設定の具体例
私は /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

● その他
今でも外部と通信するのにプロキシ必須としているような組織ってどのくらい残ってんだろ