2025年5月アーカイブ

● 結論
- 環境変数は小文字のみを使う
- 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

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

前に組んだのが2017年だからまる8年立つし、Windows10サポート切れが迫っている(2025年10月)し、という事情で久々にデスクトップ自作PCを組んだ。とはいえ面白みがほぼない普通すぎる構成で。パーツの詳細はこっちへ。

オーバクロックよりも省電力を優先して試行錯誤する。最近は電圧を下げるよりも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はもう用意しなくてもいいやとなるのかもしれない。