Wordle 242 4/6*
⬛🟩⬛🟩⬛
⬛🟩⬛🟩⬛
⬛🟩🟩🟩⬛
🟩🟩🟩🟩🟩
ぐぬぬ
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
https://twitter.com/mootastic/status/1493138546009518082
The Harmful Consequences of the Robustness Principle
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-05.html
ねー
> For a protocol that is actively maintained, the robustness principle can, and should, be avoided.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
> This formulation of the principle expressly recognizes the possibility that the specification could be imperfect. This contextualizes the principle in an important way.
とかもなるほどなぁのアレがある
まあ続けて
> An imperfect specification is natural, largely because it is more important to proceed to implementation and deployment than it is to perfect a specification. A protocol, like any complex system, benefits greatly from experience with its use. A deployed protocol is immeasurably more useful than a perfect protocol. The robustness principle is a tool that is suited to early phases of system design.
とあるんだけど。
> In particular, the application of the robustness principle is particularly deleterious for early implementations of new protocols as quirks in early implementations can affect all subsequent deployments.
ふーむ
> Sometimes what appear to be interoperability problems are symptomatic of issues in protocol design. A community that is willing to make changes to the protocol, by revising or extending it, makes the protocol better in the process. Applying the robustness principle instead conceals problems, making it harder, or even impossible, to fix them later.
本質情報だ
> From this perspective, application of the robustness principle to the implementation of a protocol specification that does not change is logical, even necessary. But that conclusion relies on an assumption that existing specifications and implementations are unable to change. Applying the robustness principle in this way disproportionately values short-term gains over the negative effects on future implementations and the protocol as a whole.
> Protocol designers are strongly encouraged to continue to maintain and evolve protocol specificationss beyond their initial inception and definition. This might require the development of revised specifications, extensions, or other supporting material that documents the current state of the protocol.
> Most interoperability problems do not require revision of protocols or protocol specifications. For instance, the most effective means of dealing with a defective implementation in a peer could be to email the developer responsible. It is far more efficient in the long term to fix one isolated bug than it is to deal with the consequences of workarounds.
せやな。
> Any protocol participant that is affected by changes arising from maintenance might be excluded if they are unwilling or unable to implement or deploy changes that are made to the protocol.
> Deliberate exclusion of problematic implementations is an important tool that can ensure that the interoperability of a protocol remains viable.
言うねぇ
> Developing and deploying changes that risk exclusion of previously interoperating implementations requires some care, but changes to a protocol should not be blocked on the grounds of the risk of exclusion alone.
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-05.html#section-5-2
> Applying the robustness principle in this way disproportionately values short-term gains over the negative effects on future implementations and the protocol as a whole.
結局この部分が人類のインタネッツ史50年をかけての “気付き” の中核な気がするな
This account is not set to public on notestock.
というよりは「良かれと思ってやってたけど、今頃になってやっと長期的な影響が観測できるようになってきて、結構悪影響がデカいことがわかったよ」という、まあ純粋な人間集団の行動の予見不足という感じ
これまで机上の空論でどうにか最善を目指してきたけどひとまずは経験に裏打ちされた行動指針を得ることができたという点で、貴重かつ重大な学びではある
とくに昨今はセキュリティまわりの状況が大きく進歩しつつあり、インターネット最初期の思想を検証なしにそのまま持ち越すのは……という事情もある
(まあ意地の悪い読み方をすると、「プロトコルを直せ。実装を直せ。不正な入力を不正だと突き付けろ。問題を見なかったことにするな」というだけの話を何度も繰り返しているだけなんだけど)
「駄目なところに気付いたのに直さず見なかったことにするから後々大変なことになるねん」って、まあ文脈なしにそれだけ言われれば当然じゃんという話でもあるからなぁ……
あとは「不正な入力に対する適切なハンドリング (大抵の場合は拒絶) を規格に組み込んでおくことで、却ってプロトコル拡張や後方互換性維持が安全にできるようになるぞ」とかは具体的な学び感がある
個人的に JSON-LD がそこをうまくやらず案の定汚く失敗しているところを見ているので、実感が……
RX 6700 XT が 10k 円未満でいけそうなので、たぶん近いうちこれを買うことになるな #MyNextGpuWontBeNvidia
何なのかというとですね、 nvidia-drivers 495.xx より後のバージョンで X.org まわりのトラブルを抱えているせいで 495.44 を使い続けている (現状最新は 510.54 とか) のでストレスを抱えているので、さっさとメインの Linux 機を Radeon に乗り替えてしまって、 GeForce はゲーム専用インドッズ機に回してしまいたい #MyNextGpuWontBeNvidia
いやべつに Linux で nouveau 使うこともできるけど、数万円の機材を意味もなく最低クロックに張り付かせて動かすなんて馬鹿馬鹿しいので #MyNextGpuWontBeNvidia
AMD、2022年の製品ロードマップを発表、「Zen 4」Ryzen™ 7000シリーズは今年後半に | CGinterest
https://cginterest.com/2022/01/06/amd%E3%80%812022%E5%B9%B4%E3%81%AE%E8%A3%BD%E5%93%81%E3%83%AD%E3%83%BC%E3%83%89%E3%83%9E%E3%83%83%E3%83%97%E3%82%92%E7%99%BA%E8%A1%A8%E3%80%81%E3%80%8Czen-4%E3%80%8Dryzen-7000%E3%82%B7/
This account is not set to public on notestock.
たとえば JSON-LD って @hoge みたいな @ で始まるプロパティに特別な解釈を与えているんですが (典型的には @version)、 JSON-LD 1.0 で @ で始まるすべての名前を予約しなかったせいで、 JSON-LD 1.1 では…… みたいな話とか
https://github.com/w3c/json-ld-syntax/issues/296#issuecomment-553517533
@version が JSON-LD 1.0 になくて 1.1 で導入されたせいで、 "@version": "1.1" と書くと 1.0 処理系で妥当な (かつ特殊でない) term として解釈できてしまって困るので "@version": 1.1 のままにします、という……
This account is not set to public on notestock.
This account is not set to public on notestock.
https://github.com/w3c/json-ld-syntax/issues/296#issuecomment-553176191
> 's much more likely we'll have 2.0 before hitting a 1.10 problem.
ほんまええ話や
https://github.com/w3c/json-ld-syntax/issues/296#issuecomment-553176191
> It's much more likely we'll have 2.0 before hitting a 1.10 problem.
ほんまええ話や
まずバージョン番号がまともに同値比較できないというのが意味わからん、ウェッビ系はそれでいいのかよ……という感想しかなかった (["1.1"] でも問題は回避できるんだけど、人間にとって書きづらいので 1.1 の方がいいらしい)
1.1 を IEEE 754 とかの表現に変換するのは処理系の問題であって JSON 自体ではトークン「1.1」としてちゃんと記述するという仕様なんだからそれでええやろ、と。んなことあるか?
This account is not set to public on notestock.
This account is not set to public on notestock.
ウクライナ国防省にサイバー攻撃、ウェブサイトにアクセスできず | Reuters
https://jp.reuters.com/article/ukraine-crisis-military-cyberattack-idJPKBN2KK23T
エレクチオン (えれくちおん)とは【ピクシブ百科事典】
https://dic.pixiv.net/a/%E3%82%A8%E3%83%AC%E3%82%AF%E3%83%81%E3%82%AA%E3%83%B3
なるほど?
電話番号0120922734はウォーターサーバー設置営業Casa
https://www.telnavi.jp/phone/0120922734
自称家賃保証会社がウォーターサーバーの営業かけてくるのか、クソすぎる
This account is not set to public on notestock.
キオクシアの製造トラブルでNAND価格が第2四半期に高騰の可能性、TrendForce | TECH+
https://news.mynavi.jp/techplus/article/20220214-2271996/
ゲェー
最近ホビドンエストがそろそろ出るじゃんということに気付いたので、論理昨日になってやっとゼロドーンを始めた
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.