「データセンターがデータトラフィックを処理する方法はもっと効率的にすることができる」として、カナダ・ウォータールー大学のマーティン・カーステン教授が提案したコード修正が、Linux 6.13で反映されます。修正により、主要データセンターのエネルギー消費量は最大で30％削減できるとのことです。
Linuxのコードをたった30行修正するだけでデータセンターの電力消費量を最大30％削減可能、実際にLinux 6.13から反映される - GIGAZINE
カーステン教授は変更内容について、Fastlyのエンジニアとして知られるジョー・ダマト氏と組んで、およそ30行のネットワークトラフィック処理改善コードを作成しました。新コードを導入すると、主要なデータセンターのエネルギー消費量は最大30％削減されるとのこと。
Linuxのコードをたった30行修正するだけでデータセンターの電力消費量を最大30％削減可能、実際にLinux 6.13から反映される - GIGAZINE
当該コードは有効性のテストが行われたのち、Linuxに提供され、2025年1月27日(月)リリースの「Linux 6.13」の一部になっています。
Linuxのコードをたった30行修正するだけでデータセンターの電力消費量を最大30％削減可能、実際にLinux 6.13から反映される - GIGAZINE
カーステン教授によれば、AmazonやGoogle、Metaなどがデータセンターで当該コードを使うようにすれば、世界中で「ギガワット時」単位のエネルギーが節約されるとのことです。
Linuxのコードをたった30行修正するだけでデータセンターの電力消費量を最大30％削減可能、実際にLinux 6.13から反映される - GIGAZINE
⇧ 改善を施したおよそ30行のソースコードを適用する箇所が一か所で済んだのかが気になりますな...
HashiCorp VaultのSecrets EnginesでKVにはv1とv2のバージョンあるがAPIのエンドポイントの罠あり
気付くまでに時間がかかったのだが、
⇧ 前に、「HashiCorp Vault」の「Secrets Engines」が様々あるということが分かったのだが、「Secrets Engines」として「KV」を利用している場合に、「API」の「エンドポイント」については、
⇧「data」のあるなしの差分があるらしいのだが、
■v1
■v2
⇧ お分かりいただけただろうか？
そもそも、ドキュメントの「API」の「エンドポイント」の「v2」の例が間違っているっぽいのも問題なのだが、それよりも衝撃的なのが、どちらも「API」の「エンドポイント」で「v1」を指定する必要があるという部分ね...
■「Secrets Engines」が「KV」の場合のAPIエンドポイント
| No | version | API エンドポイント |
|---|---|---|
| 1 | v1 | https://[HashiCorp VaultのURL]/v1/secret/[HashiCorp VaultのSecret Path] |
| 2 | v2 | https://[HashiCorp VaultのURL]/v1/[secret-mount-path]/secret/data/[HashiCorp VaultのSecret Path] |
うむ、発狂しそうなんだが...
何故、混乱するようなことをしてくれるのか...
こういうのを見てしまうと、メソッドをラッパーしておくのが安牌な気がしてくるんよね...
まぁ、プログラミング言語向けのHTTP Clientの方で、バージョンによってメソッド自体を分けている場合は、ラッパーするかどうか迷うところではありますが...
とりあえず、太字部分は固定値ということになりそうなんだが、兎に角「HashiCorp Vault」の「API」の「エンドポイント」の構成が無茶苦茶に分かり辛いのよ...
公式のドキュメントにある「Parameters」が、
の2つの意味があるっぽくて、所謂「ダブルミーニング」になってしまっているのよね...
ちなみに、
⇧ stackoverflowで「API」の「エンドポイント」について言及されておりました。
質問者の人は、「HashiCorp Vault」の公式のドキュメントの通りにしているのにもかかわらず、一向にリクエストが成功しないので「裏切られた」気分だったでしょうね...
一次情報が役に立たない状況は辛過ぎるんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
