※当サイトの記事には、広告・プロモーションが含まれます。

Linuxのパッケージのオフラインでのインストールはファイル転送できないと厳しいよね...

gigazine.net

Googleの広告技術独占を巡る司法省対Google裁判で最終弁論が行われ、Googleの技術を分割し売却するよう求める司法省の要求の判断が判事の手に委ねられることになりました。判決は2026年になる可能性が高いとのことです。

Googleの広告技術独占を解体するための強制売却を命じる判決が下る可能性大 - GIGAZINE

司法省はGoogleに対し、Google Ad Exchange(AdX)とDoubleClick for Publishers(DFP)という広告配信システムの売却を要求しています。

Googleの広告技術独占を解体するための強制売却を命じる判決が下る可能性大 - GIGAZINE

AdXGoogle広告枠の売買を行うための取引市場で、DFPは広告の配信サーバー。2018年からこの2つを統合した「Google Ad Manager」が提供されていますが、両システムは密接に結びついており、この2つを統合することでGoogleは違法な独占状態を築いたとして、司法省に訴えられています。

Googleの広告技術独占を解体するための強制売却を命じる判決が下る可能性大 - GIGAZINE

司法省はAdXの分離、一部のデータ共有などの措置を義務付けるよう求めていますが、Google側はシステムの分離が困難だとして反発しています。

Googleの広告技術独占を解体するための強制売却を命じる判決が下る可能性大 - GIGAZINE

また、同社の中核事業である検索・広告事業は四半期売上高500億ドル(約7兆8000億円)以上を生み出しており、これはGoogleの親会社であるAlphabetの総売上高の半分に相当するものです。

Googleの広告技術独占を解体するための強制売却を命じる判決が下る可能性大 - GIGAZINE

このため、広告配信システムをおいそれと手放すことはGoogleにとって容易ではありません。

Googleの広告技術独占を解体するための強制売却を命じる判決が下る可能性大 - GIGAZINE

⇧「売上」の額がエグいですな...

まぁ、

  • Google Ad Manager
    1. Google Ad Exchange(AdX)
      AdXGoogle広告枠の売買を行うための取引市場
    2. DoubleClick for Publishers(DFP)
      DFPは広告の配信サーバー

システム的には分割が難しいと思うので、セット販売での売却とするしかない気はしますな...

Linuxのパッケージのオフラインでのインストールはファイル転送できないと厳しいよね...

Linux ディストリビューション」毎に「パッケージ管理ツール」が用意されており、「パッケージ」をインストールすることができるのだが、

ts0818.hatenablog.com

⇧ 上記の記事の時に調べた感じだと、「パッケージ」の「サポート終了」によって、提供されなくなることがありますと。

そうなった場合に、「Linux」の「パッケージ」を「オフライン」でインストールする方法がありますと。

tokku-engineer.tech

qiita.com

nandakagoodvibes.hatenablog.com

⇧ 上記サイト様にありますように、既存の環境の「Linux」の「パッケージ」が更新されていないのであれば、「パッケージ管理ツール」で「パッケージ」を導入できそうではありますと。

ちなみに、

access.redhat.com

パッケージをインストールせずにダウンロードする方法は 2 つあります。

1 つは yum の "downloadonly" プラグインを使用する方法で、もう 1 つは "yumdownloader" ユーティリティーを使用する方法です。

https://access.redhat.com/ja/solutions/395763

⇧「Red Hat」のドキュメントによると、2つの方法が紹介されている。

とりあえず、

  1. オンライン環境のマシン(サポート終了になったパッケージを管理している)
  2. オフライン環境のマシン

の間で「ファイル」を連携する方法が必要ですと。

ちなみに、「Phind」で「パッケージ管理サーバー」との関係についての図をお願いしてみたところ、以下のような図が生成された。

 構成図の説明

色分けの意味

  • 青色(サーバー):パッケージ配信のためのサーバーインフラストラクチャ
  • オレンジ色(リポジトリ):実際のパッケージを保存する場所
  • 紫色(キャッシュ):ローカルに一時的に保存されたパッケージ
  • 緑色(処理):パッケージのインストール時に実行される処理

コンポーネントの関係性

  1. サーバーとリポジトリの構造:
    • 公開サーバーには複数のミラーサイトが存在し、それぞれが異なるリポジトリを提供できます
    • 社内サーバーも同様に、複数の内部リポジトリを持つことが可能です
    • リポジトリは独立して管理されながら、同じサーバー上で運用できます
  2. キャッシュシステム:
    • ローカルキャッシュは、既にダウンロードされたパッケージを保存します
    • 新しいインストール要求時は、まずキャッシュを確認し、ヒットしない場合のみリポジトリから取得します
  3. 処理フロー:
    • 依存関係解決:必要な関連パッケージを自動的に特定します
    • トランザクション確認:インストールの整合性をチェックします
    • インストール実行:すべての条件が満たされた場合にのみ実行されます

 

「社内パッケージサーバー」も「公開パッケージサーバー」から「パッケージ」を取得していたりすると思うが、「公開パッケージサーバー」が「サポート終了」として管理しなくなった「パッケージ」についても「社内パッケージサーバー」が管理してくれている可能性もあるような気がする。

つまり、「公開パッケージサーバー」で「サポート終了」によって提供されなくなった「バージョン」の「パッケージ」について、「社内パッケージサーバー」から取得することができる可能性があるのではないかという話。

で、「社内パッケージサーバー」から「パッケージ」をインストールしていた「マシン」には「サポート終了」によって提供されなくなった「バージョン」の「パッケージ」がインストールされているであろうと。

 

なのだが、実際の現場の環境だと、「ネットワーク」の問題で連携できないようになっていたりするのよな...

  1. 物理マシン同士
  2. マシンが物理的に近距離に配置されている
  3. USBメモリーなどの媒体の利用が可能

というような条件であれば、「ネットワーク」関係なく連携できるのだが、まぁ、実際の現場では、そのような条件を許可しているところが無いことがほとんどだと思いますしな...

昨今、「オンプレミス環境」自体が少ない気もしますしな...

開発環境や検証環境の構築に時間をかけたくないのだが、往々にして環境構築系については整備されていなかったりするのよな...

毎度モヤモヤ感が半端ない…

今回はこのへんで。