アカウント名:
パスワード:
UA偽装しなくてもISOをダウンロードできるようになった。これは神改善。
正式版のISOはInsider PreviewのBuild 22000.194のISOとビット単位で完全一致した。ようやくMSもリリース候補の何たるかを理解したらしい。リリース候補と同じものを出してくれなくては正式リリース前に動作検証などできないではないか。
そして初めて実機でアップグレードを試みてみたが、案の定ブロックされた(CPU非サポート)。
対応CPUではないものの、Insider Preview参加から継続してまだ使えている
対応ハードではないですよの表示はあるものの、デバイスマネージャー覗くと「トラステッド プラットフォーム モジュール 2.0」なるものが存在しているどうなるか知らないがとりあえず使い続けてみようと思う
#右クリックメニューは結局このままか…
右クリックメニューコマンドの選択でおおむね1クリック余分に必要になったのはどう考えても不便すぎて、使用アプリがWindows 11のコンテキストメニューに対応するまで移行できそうにない(現時点ではハードウェアがそもそもサポート対象外なのでVMでの感想だが)。
>使用アプリがWindows 11のコンテキストメニューに対応するまで移行できそうにない
みんな好き勝手にメニューに追加してしっちゃかめっちゃか状態を解消するための対応なんで、一般アプリがそれを回避して第一階層に登録できたらまた封じ込め措置が取られるんじゃないの?
今の仕様が使い勝手最悪なのは同意だけど
Microsoftが公式に提供している方法なのに回避とか言われましても。なお、同じアプリが複数のメニュー項目を追加したときは強制的にサブメニューにまとめることで以前の繰り返しを防ごうとしている模様(そこで「同じアプリ」の判別のためにパッケージIDが義務付けられた)。Chromeの拡張機能がコンテキストメニューに追加できる項目と似たような仕様だと思った
（Intel Core i3-2105 ＋ 16GB では駄目ですか…？）
> ビット単位で完全一致した。 えっ？ バージョン番号も変わってないの？
> リリース候補と同じものを出してくれなくては それってリリース候補じゃなくてリリースじゃね？
> えっ？ バージョン番号も変わってないの？
そうだよ。完全に同じ。 > それってリリース候補じゃなくてリリースじゃね？
本当にわかっていないと仮定していちおう解説しておくと、最後のリリース候補をそのままリリースするんだよ。もし不具合が見つかったらリリース候補を更新する。不具合が見つからなくなるまでこれを繰り返し、最後のリリース候補がそのままリリースになる。というのが本来のリリース候補。たとえばFirefoxのリリース候補はそのように運用されている。MSはリリース候補を何か違う意味で使っていたようなのだが。
MSはリリース候補を何か違う意味で使っていたようなのだが。
MSが「何か違う意味」でRCを使ってた理由って「アプリケーション開発者向けの公開ベータ版」でアプリケーション開発者が不具合報告をしてくれなくて、本来の意味でのRC版になってからアプリケーションのテストを始めるアホベンダーが多かったせいでブチ切れて「てめーらRC版になるまで本気出さないんなら本気出すようにベータ版の段階からRC版って名前にしてやるよ」っていったからなんだよなぁ。つまり、マイクロソフトじゃなくてソフトベンダーが悪い。
>MSが「何か違う意味」でRCを使ってた理由って「アプリケーション開発者向けの公開ベータ版」でアプリケーション開発者が不具合報告をしてくれなくて、本来の意味でのRC版になってからアプリケーションのテストを始めるアホベンダーが多かったせいで
これ、Windows10のCBとCBBでも同じようなことやったベンダが多かったな。CBBになってから検証しますとか言い出したのが多かったからBranch(分岐)でなくチャネルになった。
結構昔だけど、Windows 2000の時はRC1→RC2(店頭配布)→RC3(雑誌付録)=リリースとなっていて、RC3とリリース版は同じビルド番号だった記憶がある。
補足というかさらに前提として、ソースが同じでもビルドし直したら別個体、という点の理解も必要かと。スクリプト言語しか経験がないとこれも理解出来なさそうだけど…
候補っていうか内定だよな。別段そこで他の候補と競争するわけでも無い。
次の候補(RC)と競争してるんだよ。適格であれば候補がそのまま正式版。不適格であれば、今の候補はお払い箱で、次の候補。
しかし無慈悲なウィンドウズアップデート
まあRCって実際そういうものなのだがインサイダープレビューはRCというよりはユーザの意見を得るためのものだった気もする。
DevチャネルやBetaチャネルはそれでいいと思うけどRelease Previewチャネルもそうなのかな。MSはRelease Previewに降ってくるタイミングで動作検証の開始を推奨してるみたいだし
あとは不具合が見つかったらリリースをキャンセルし修正版をリリースてのも理想の話で現実にはそんなことどこもやってないな。軽微な不具合（開発元の感想です）は開示ないし非開示の上でそのままリリースする場合が多い。不具合のないソフトなんてないのでそんなこと言ってたら永遠にRC止まり。
同意なんだけど今回の最後のInsiderPreviewがリリース版と同じですよという情報が公式リリースされていないのでまだまだ理解が足りていないと思う。同じだとアナウンスがあればそこで初めて互換性チェックしようかなという気になるんだけども。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
Build 22000.194 (スコア:2, 参考になる)
UA偽装しなくてもISOをダウンロードできるようになった。これは神改善。
正式版のISOはInsider PreviewのBuild 22000.194のISOとビット単位で完全一致した。ようやくMSもリリース候補の何たるかを理解したらしい。リリース候補と同じものを出してくれなくては正式リリース前に動作検証などできないではないか。
そして初めて実機でアップグレードを試みてみたが、案の定ブロックされた(CPU非サポート)。
Re: (スコア:0)
対応CPUではないものの、Insider Preview参加から継続してまだ使えている
対応ハードではないですよの表示はあるものの、デバイスマネージャー覗くと「トラステッド プラットフォーム モジュール 2.0」なるものが存在している
どうなるか知らないがとりあえず使い続けてみようと思う
#右クリックメニューは結局このままか…
Re: (スコア:0)
右クリックメニューコマンドの選択でおおむね1クリック余分に必要になったのはどう考えても不便すぎて、使用アプリがWindows 11のコンテキストメニューに対応するまで移行できそうにない(現時点ではハードウェアがそもそもサポート対象外なのでVMでの感想だが)。
Re: (スコア:0)
>使用アプリがWindows 11のコンテキストメニューに対応するまで移行できそうにない
みんな好き勝手にメニューに追加してしっちゃかめっちゃか状態を解消するための対応なんで、一般アプリがそれを回避して第一階層に登録できたらまた封じ込め措置が取られるんじゃないの?
今の仕様が使い勝手最悪なのは同意だけど
Re: (スコア:0)
Microsoftが公式に提供している方法なのに回避とか言われましても。
なお、同じアプリが複数のメニュー項目を追加したときは強制的にサブメニューにまとめることで以前の繰り返しを防ごうとしている模様(そこで「同じアプリ」の判別のためにパッケージIDが義務付けられた)。Chromeの拡張機能がコンテキストメニューに追加できる項目と似たような仕様だと思った
Re: (スコア:0)
（Intel Core i3-2105 ＋ 16GB では駄目ですか…？）
Re: (スコア:0)
> ビット単位で完全一致した。
えっ？ バージョン番号も変わってないの？
> リリース候補と同じものを出してくれなくては
それってリリース候補じゃなくてリリースじゃね？
Re:Build 22000.194 (スコア:1)
> えっ？ バージョン番号も変わってないの？
そうだよ。完全に同じ。
> それってリリース候補じゃなくてリリースじゃね？
本当にわかっていないと仮定していちおう解説しておくと、最後のリリース候補をそのままリリースするんだよ。もし不具合が見つかったらリリース候補を更新する。不具合が見つからなくなるまでこれを繰り返し、最後のリリース候補がそのままリリースになる。というのが本来のリリース候補。たとえばFirefoxのリリース候補はそのように運用されている。MSはリリース候補を何か違う意味で使っていたようなのだが。
Re: (スコア:0)
MSはリリース候補を何か違う意味で使っていたようなのだが。
MSが「何か違う意味」でRCを使ってた理由って「アプリケーション開発者向けの公開ベータ版」でアプリケーション開発者が
不具合報告をしてくれなくて、本来の意味でのRC版になってからアプリケーションのテストを始めるアホベンダーが多かったせいで
ブチ切れて「てめーらRC版になるまで本気出さないんなら本気出すようにベータ版の段階からRC版って名前にしてやるよ」って
いったからなんだよなぁ。
つまり、マイクロソフトじゃなくてソフトベンダーが悪い。
Re: (スコア:0)
>MSが「何か違う意味」でRCを使ってた理由って「アプリケーション開発者向けの公開ベータ版」でアプリケーション開発者が
不具合報告をしてくれなくて、本来の意味でのRC版になってからアプリケーションのテストを始めるアホベンダーが多かったせいで
これ、Windows10のCBとCBBでも同じようなことやったベンダが多かったな。
CBBになってから検証しますとか言い出したのが多かったからBranch(分岐)でなくチャネルになった。
Re: (スコア:0)
結構昔だけど、Windows 2000の時は
RC1→RC2(店頭配布)→RC3(雑誌付録)=リリース
となっていて、RC3とリリース版は同じビルド番号だった記憶がある。
Re: (スコア:0)
補足というかさらに前提として、ソースが同じでもビルドし直したら別個体、という点の理解も必要かと。
スクリプト言語しか経験がないとこれも理解出来なさそうだけど…
Re: (スコア:0)
Re: (スコア:0)
候補っていうか内定だよな。
別段そこで他の候補と競争するわけでも無い。
Re: (スコア:0)
次の候補(RC)と競争してるんだよ。
適格であれば候補がそのまま正式版。
不適格であれば、今の候補はお払い箱で、次の候補。
Re: (スコア:0)
しかし無慈悲なウィンドウズアップデート
Re: (スコア:0)
まあRCって実際そういうものなのだがインサイダープレビューはRCというよりはユーザの意見を得るためのものだった気もする。
Re: (スコア:0)
DevチャネルやBetaチャネルはそれでいいと思うけどRelease Previewチャネルもそうなのかな。MSはRelease Previewに降ってくるタイミングで動作検証の開始を推奨してるみたいだし
Re: (スコア:0)
あとは不具合が見つかったらリリースをキャンセルし修正版をリリースてのも理想の話で現実にはそんなことどこもやってないな。
軽微な不具合（開発元の感想です）は開示ないし非開示の上でそのままリリースする場合が多い。
不具合のないソフトなんてないのでそんなこと言ってたら永遠にRC止まり。
Re: (スコア:0)
正式版のISOはInsider PreviewのBuild 22000.194のISOとビット単位で完全一致した。ようやくMSもリリース候補の何たるかを理解したらしい。リリース候補と同じものを出してくれなくては正式リリース前に動作検証などできないではないか。
同意なんだけど今回の最後のInsiderPreviewがリリース版と同じですよという情報が公式リリースされていないのでまだまだ理解が足りていないと思う。
同じだとアナウンスがあればそこで初めて互換性チェックしようかなという気になるんだけども。