アカウント名:
パスワード:
単純に設計が雑なだけじゃん・・・
違う、対応しているかどうかのチェック処理が走って対応しているってフラグを返すのに取得すると-1がかえんの。死んでたらそもそも違う動作する。死んでるならまだマシなのに中途半端に生きているからダメ案件
＃まぁ LFSR なので Intel の実装でも真の乱数ではもともとないし、正直 AMD の CPU がちゃんとした値を返さないって昔の TSC のほうが仕様的に変だという意味で酷い気がするけど。
開発者曰く、タイプ4のUUIDを使っており [github.com]、UUIDの衝突が起こる確率が高いと思うのなら、systemdだけでなく、linuxカーネル含めて修正してねとのことです。
# 真の乱数なら、毎秒1億個を800年間生成しても、衝突する確率は50%なんだから気にしなくてもよいんじゃ・・・# それよか、地震とか噴火で端末が壊れる可能性のほうが・・・
＃何ヶ月に一回かインターミッテントに化けるようなバグのデバッグをやるはめになったらたぶん身にしみると思うけど。
月のオーダーと100年のオーダーが同じに見える(しかも毎秒1億回も動かされると思っている)なんておめでたいですね
確率を気にするのであれば、systemdだけでなく、カーネルが使用しているuuidがダブってしまった結果、挙動がおかしくなる可能性も考慮すべきでは？
マーフィーの法則は、意外と高い失敗の確率に気が付いていないか、無視していることが多いことの注意喚起にはなる。でも、元コメのように、とても低い確率の失敗が起きると言っているわけでも、何か超常の力が働いて失敗が起きるわけでもない。
流石ですね、通勤手段が使えない確率の方が高いですからね、会社に泊まってデバッグしているんですね。
> マーフィーの法則を10回ほど口に出して読み上げてみるべきだ、と思うな。
それは、ほとんどすべてのWebシステム開発者に言うべきでしょう。
Webシステムでは、クライアント-サーバー間でセッションを保持するためにセッションIDを使うことがありますが、多くの処理系では、乱数をもとにセッションIDが生成されます。
あなたの考えでは当然、セッションIDがダブる事を考慮する必要がありますが、例えば、phpやtomcat等のメジャーな処理系ではセッションIDの対応が不十分です(一方は、ID生成をリトライしそれでも衝突を回避
そのコメントの返答が「The Linux kernel uses a (mostly) sane construction」。systemdのUUID生成方法は異常との指摘。
その返信でいってるのは、linuxがエントロピープール等を使って乱数を作成している。つまり、乱数の品質のことをいっているのであって、alp氏の主張「乱数を使用していることがおかしい」の前ではsystemdもlinuxも同列に扱うべき
＞# 真の乱数なら、毎秒1億個を800年間生成しても、衝突する確率は50%なんだから気にしなくてもよいんじゃ・・・今回のは特異な例だけども、先ずは「真の乱数なら」ってのが保証されて居ないってのを考慮していないってのが一番の問題だと思うんだ。そこについてはIntelだってどっこいどっこいなんで、その手の理想状態での考察より危険度は絶対に高かったと認識して対処できていた筈だと。
RdRand命令(intelが初めて実装し、AMDが追従した)は、暗号論的擬似乱数(生成される乱数が一様(特定の値が偏って出力されない)で、また、以前生成された値から次に生成される値の予測が極めて困難なこと)としての使用が想定されているので、 [www.isus.jp]
（命令が正しく実装されていれば）理想状態から大きく剥離しないと考えるのはおかしくはないんじゃないかな？
# 本件とずれるけど、本の虫で陰謀論とか言っているのは、# 暗号での使用を想定している命令なのに、固定値とか質の悪い乱数を出力しているから
その確率はゼロではないけど、同じ値が2回連続するだけで2^64回=1.8e19に1回、1800京分の一。何回の衝突で起動しなくなるのか知らないけど、期待して悪い数字じゃないような。暗号化だってパスワードだって、確率が低いことを根拠として成り立ってる物なんだし。
純粋に血塗れに Systemd が悪い。
つまりsystemdがCPUを内包していなかったからいけないんだね！
天文学的確率だとしてもあらゆる可能性について対応してないシステムのほうが悪いよなAMDのCPUは何も悪くない
>AMDのCPUは何も悪くないんなわけあるか。
今回の場合UUIDの生成に使っているようなので、そもそも「UUID1個発行するごとに『真の乱数』を取ってくる」こと自体が適切なのかどうか、という疑問もありますね。LFSRなら1周するまでユニークな値が来ることが保証できるのに対して、『真の乱数』は「ものすごく低い確率だが稀に連続して同じ値が来ることも保証されている」ことを考えると、初期値は『真の乱数』を使うにしても2個目以降はむしろ1次元でループするような擬似乱数を使わないと、潜在的には低確率でバグる実装になってしまいますし。
同値が連続しないことを保証したいなら、それこそ一個乱数源(最悪定数や時刻でも良い)とって自前のLFSRに突っ込めばいいだけだよね。LFSRを一回シフトしてレジスタ値を使うとかだと次の値が非常に規則的になるけど、0以外のあらゆる値を満遍なく出してくれるから値を散らすだけならすごく便利。
# ていうかハードウェアで乱数作るならダイオードの熱雑音とかやって欲しい。
普通は乱数値を生のまま使わず、状態機械を通すから同じ値が続いても不都合はないはずだが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
安定のSystemd (スコア:0)
単純に設計が雑なだけじゃん・・・
Re:安定のSystemd (スコア:0)
違う、対応しているかどうかのチェック処理が走って対応しているってフラグを返すのに取得すると-1がかえんの。
死んでたらそもそも違う動作する。
死んでるならまだマシなのに中途半端に生きているからダメ案件
Re:安定のSystemd (スコア:1)
＃まぁ LFSR なので Intel の実装でも真の乱数ではもともとないし、正直 AMD の CPU がちゃんとした値を返さないって昔の TSC のほうが仕様的に変だという意味で酷い気がするけど。
Re: (スコア:0)
開発者曰く、タイプ4のUUIDを使っており [github.com]、
UUIDの衝突が起こる確率が高いと思うのなら、systemdだけでなく、linuxカーネル含めて修正してねとのことです。
# 真の乱数なら、毎秒1億個を800年間生成しても、衝突する確率は50%なんだから気にしなくてもよいんじゃ・・・
# それよか、地震とか噴火で端末が壊れる可能性のほうが・・・
Re:安定のSystemd (スコア:1)
＃何ヶ月に一回かインターミッテントに化けるようなバグのデバッグをやるはめになったらたぶん身にしみると思うけど。
Re: (スコア:0)
月のオーダーと100年のオーダーが同じに見える(しかも毎秒1億回も動かされると思っている)なんておめでたいですね
Re: (スコア:0)
確率を気にするのであれば、systemdだけでなく、
カーネルが使用しているuuidがダブってしまった結果、
挙動がおかしくなる可能性も考慮すべきでは？
Re: (スコア:0)
マーフィーの法則は、意外と高い失敗の確率に気が付いていないか、無視していることが多いことの注意喚起にはなる。
でも、元コメのように、とても低い確率の失敗が起きると言っているわけでも、何か超常の力が働いて失敗が起きるわけでもない。
Re: (スコア:0)
流石ですね、通勤手段が使えない確率の方が高いですからね、会社に泊まってデバッグしているんですね。
Re: (スコア:0)
> マーフィーの法則を10回ほど口に出して読み上げてみるべきだ、と思うな。
それは、ほとんどすべてのWebシステム開発者に言うべきでしょう。
Webシステムでは、クライアント-サーバー間でセッションを保持するために
セッションIDを使うことがありますが、多くの処理系では、乱数をもとに
セッションIDが生成されます。
あなたの考えでは当然、セッションIDがダブる事を考慮する必要がありますが、
例えば、phpやtomcat等のメジャーな処理系ではセッションIDの対応が不十分です
(一方は、ID生成をリトライしそれでも衝突を回避
Re: (スコア:0)
開発者曰く、タイプ4のUUIDを使っており [github.com]、
UUIDの衝突が起こる確率が高いと思うのなら、systemdだけでなく、linuxカーネル含めて修正してねとのことです。
そのコメントの返答が「The Linux kernel uses a (mostly) sane construction」。
systemdのUUID生成方法は異常との指摘。
Re: (スコア:0)
その返信でいってるのは、linuxがエントロピープール等を使って乱数を作成している。
つまり、乱数の品質のことをいっているのであって、
alp氏の主張「乱数を使用していることがおかしい」の前ではsystemdもlinuxも
同列に扱うべき
Re: (スコア:0)
＞# 真の乱数なら、毎秒1億個を800年間生成しても、衝突する確率は50%なんだから気にしなくてもよいんじゃ・・・
今回のは特異な例だけども、先ずは「真の乱数なら」ってのが保証されて居ないってのを考慮していないってのが一番の問題だと思うんだ。
そこについてはIntelだってどっこいどっこいなんで、その手の理想状態での考察より危険度は絶対に高かったと認識して対処できていた筈だと。
Re: (スコア:0)
RdRand命令(intelが初めて実装し、AMDが追従した)は、
暗号論的擬似乱数(生成される乱数が一様(特定の値が偏って出力されない)で、
また、以前生成された値から次に生成される値の予測が極めて困難なこと)
としての使用が想定されているので、 [www.isus.jp]
（命令が正しく実装されていれば）理想状態から大きく剥離しないと考えるのは
おかしくはないんじゃないかな？
# 本件とずれるけど、本の虫で陰謀論とか言っているのは、
# 暗号での使用を想定している命令なのに、固定値とか質の悪い乱数を出力しているから
Re: (スコア:0)
その確率はゼロではないけど、同じ値が2回連続するだけで2^64回=1.8e19に1回、1800京分の一。
何回の衝突で起動しなくなるのか知らないけど、期待して悪い数字じゃないような。
暗号化だってパスワードだって、確率が低いことを根拠として成り立ってる物なんだし。
Re: (スコア:0)
純粋に血塗れに Systemd が悪い。
つまりsystemdがCPUを内包していなかったからいけないんだね！
Re: (スコア:0)
天文学的確率だとしてもあらゆる可能性について対応してないシステムのほうが悪いよな
AMDのCPUは何も悪くない
Re: (スコア:0)
>AMDのCPUは何も悪くない
んなわけあるか。
Re: (スコア:0)
今回の場合UUIDの生成に使っているようなので、そもそも「UUID1個発行するごとに『真の乱数』を取ってくる」こと自体が適切なのかどうか、という疑問もありますね。
LFSRなら1周するまでユニークな値が来ることが保証できるのに対して、『真の乱数』は「ものすごく低い確率だが稀に連続して同じ値が来ることも保証されている」ことを考えると、初期値は『真の乱数』を使うにしても2個目以降はむしろ1次元でループするような擬似乱数を使わないと、潜在的には低確率でバグる実装になってしまいますし。
Re: (スコア:0)
同値が連続しないことを保証したいなら、
それこそ一個乱数源(最悪定数や時刻でも良い)とって自前のLFSRに突っ込めばいいだけだよね。
LFSRを一回シフトしてレジスタ値を使うとかだと次の値が非常に規則的になるけど、
0以外のあらゆる値を満遍なく出してくれるから値を散らすだけならすごく便利。
# ていうかハードウェアで乱数作るならダイオードの熱雑音とかやって欲しい。
Re: (スコア:0)
普通は乱数値を生のまま使わず、状態機械を通すから
同じ値が続いても不都合はないはずだが。