無効にするスマイリースマイリーを全て表示するトピックのレビュー[quote="pal"]上書きでも問題はありません。脆弱性は使っていなければ問題ないでしょう。(インストールされているだけでは問題はないはずです。)[/quote][quote="pal"]上書きでも問題はありません。脆弱性は使っていなければ問題ないでしょう。(インストールされているだけでは問題はないはずです。自動的にパースしないユーザエージェントを表示する認証コード認証コード:*上の画象に表示されている文字を入力してください。各文字は大文字・小文字の区別があります。さんが書きました:ファイアウォールに引っかかって数分後にアップデータが失敗してから、ようやくパッケージのダウンロード先が提示されます。接続先は検証していないので割愛しますが、毎回失敗しますか?毎回、あるいは高頻度であれば、どこかに不具合が内在している可能性があると思いますが。引用:最初から接続先の一覧を先に提示するのが賢明なのではありませんか?基本的にはここはユーザーしか居ません、ユーザー同士の情報交換の場でしかありませんので、バグでも立てて、製作側に問題提起してください。[quote="ななし2"]ファイアウォールに引っかかって数分後にアップデータが失敗してから、ようやくパッケージのダウンロード先が提示されます。[/quote]接続先は検証していないので割愛しますが、毎回失敗しますか?毎回、あるいは高頻度であれば、どこかに不具合が内在している可能性があると思いますが。[quote]最初から接続先の一覧を先に提示するのが賢明なのではありませんか?[/quote]基本的にはここはユーザーしか居ません、ユーザー同士の情報交換の場でしかありませんので、バグでも立てて、製作側に問題提起してください。FireFoxのアップデートについて横からすみません。新しくトピックを立てるのもはばかられましたので追記したいと考えます。今のFFのアップデートの仕方、或いはインストーラの提示方法は素直ではなく、果たしてユーザーにとって好ましいものなのでしょうか。最新に更新されたパッケージを最初からダウンロード可能にせず、わざわざインストーラを使って間接的にAWSなどを経由させるようにしている点が意味不明です。ファイアウォールに引っかかって数分後にアップデータが失敗してから、ようやくパッケージのダウンロード先が提示されます。ビッグデータ大好きクラウド企業に、何を送信しているのかわからないインストーラの組み合わせで、プライバシーが保護されているといえるのでしょうか。現状で57.0.4へのアップデータは少なくとも以下のアドレスのいずれか複数に接続することを確認していますが、ならば最初から接続先の一覧を先に提示するのが賢明なのではありませんか?ec2-34-216-200-83.us-west-2.compute.amazonaws.comec2-35-164-27-94.us-west-2.compute.amazonaws.comec2-54-68-215-19.us-west-2.compute.amazonaws.comgeneric-http2.external.zlb.scl3.mozilla.com当然、現状のアップデータはこれであっても、次のリビジョンではどこに接続しに行くかわからないのでは気が重いです。新しくトピックを立てるのもはばかられましたので追記したいと考えます。今のFFのアップデートの仕方、或いはインストーラの提示方法は素直ではなく、果たしてユーザーにとって好ましいものなのでしょうか。最新に更新されたパッケージを最初からダウンロード可能にせず、わざわざインストーラを使って間接的にAWSなどを経由させるようにしている点が意味不明です。ファイアウォールに引っかかって数分後にアップデータが失敗してから、ようやくパッケージのダウンロード先が提示されます。ビッグデータ大好きクラウド企業に、何を送信しているのかわからないインストーラの組み合わせで、プライバシーが保護されているといえるのでしょうか。現状で57.0.4へのアップデータは少なくとも以下のアドレスのいずれか複数に接続することを確認していますが、ならば最初から接続先の一覧を先に提示するのが賢明なのではありませんか?ec2-34-216-200-83.us-west-2.compute.amazonaws.comec2-35-164-27-94.us-west-2.compute.amazonaws.comec2-54-68-215-19.us-west-2.compute.amazonaws.comgeneric-http2.external.zlb.scl3.mozilla.com当然、現状のアップデータはこれであっても、次のリビジョンではどこに接続しに行くかわからないのでは気が重いです。バージョンといった使用環境についての最低限の情報を書き添えることをお勧めします。さんが書きました:ソフトウェアを利用せずとも、バックグラウンドでソフトウェア更新する方法をご教示下さい。一括管理している運用条件だと推察いたします。このようなケースなら、次の法人向けサポート記事を参考になさってはいかがでしょうか。(状況によっては、法人サポート〈有償〉の利用を視野に入れた方がいいケースもありえます。現状と一致しないものもありますが、基本的な考え方は通用するはずです。さんが書きました:また、バックグラウンドの際に使用するアップデートサーバは手動更新の際のアップデートサーバと同様でしょうか。自動更新のおおまかな流れとしては、定期的に更新確認をおこない、更新可能な状態だと判断されれば、該当するアップデーターがダウンロード・実行されます。更新確認をしに行くドメイン名などを知ることができます。さんが書きました:新しいバージョンの上書きインストール時は古いソフトウェアのアンインストールは不要でしょうか。アンインストールせず上書きインストールでもまず問題ありませんが、使われなくなった古いコンポーネント類が残ることはあります。情報が残ることもあります。いえ、最新バージョンが正しく上書きインストールされていれば、その最新バージョンの使用に影響することはありません。(補足)自動更新では、基本的に旧バージョンから更新された差分のみを適用する動作になります。自動更新で問題が起こり、やむを得ずフルインストールするような場合は、既存バージョンに何らかの障害が起こっている可能性があるので、旧バージョンをアンインストールしたあと最新バージョンを標準的にインストールするほうが、後々の安定性のためには効果的だと思います。できればプロファイルも作り直しておくと、なお安心できるでしょう。可能性は低いと思いますが、旧バージョンをアンインストールしていない状態で新バージョンの上書きインストールに失敗したようなとき、新旧両方のバージョンを視野に入れてトラブルシューティングをおこなう必要が出てくるなど、対処が面倒になる場合があります。さんが書きました:また、アップデートの目的は脆弱性対処ですが、FFにおける脆弱性はFF使用有無に関わらず影響を受ける可能性はございますでしょうか。さんが仰るとおりだと思います。持つ脆弱性の影響がおよぶことはありません。稼働するケースはありえます。呼び出され、インターネットにアクセスすることはありえます。いうケースを管理しきれない場合、既知のセキュリティ脆弱性が未修正の旧バージョンを使い続けていると、法人全体のリスクを増大させるでしょう。さんが書きました:幣システムでは、FF(64bit)を数十台導入しております。混在していると、個別に対処しなければならない場面が増えると思います。自動更新については、次の点に注意してください。複数の更新チャンネルがあり、現用されているバージョンのチャンネルに対応して更新が進みます。版が使われるケースがありますが、運用経過のどこかで通常版と混在したような場合、更新が2系統に分かれるケースが出てきます。版のバージョンが一致する時期にインストールをおこなったときです。