非営利技術コンソーシアムのLinux Foundationが、Googleが開発したAIエージェント同士の相互運用を目指すためのプロトコル「Agent2Agent(A2A)」の開発プロジェクトを管理することを発表しました。Googleはプロジェクト移管の理由について、「ベンダーに依存せずコミュニティ主導で開発を続けていくため」と語っています。
GoogleがAI同士をつなげるプロトコル「A2A」をLinux Foundationに移管、一企業への依存を避けコミュニティ主導の開発を目指す - GIGAZINE
Linux Foundationによれば、A2AプロトコルプロジェクトはGoogleだけではなく、Amazon Web Services(AWS)やMicrosoft、Cisco、SalesForce、SAP、ServiceNowなど100以上の大手テクノロジー企業からも支援を受けているとのこと。
GoogleがAI同士をつなげるプロトコル「A2A」をLinux Foundationに移管、一企業への依存を避けコミュニティ主導の開発を目指す - GIGAZINE
⇧ う~む、「ベンダー」の依存は避けられ無さそうな気がするんだが...
「Cisco」とかって一般的な「Linux ディストリビューション」とはかけ離れた独自の「OS(Operation System)」を提供していたりするものな...
Gitのcruft packsという機能とは
ネットの情報を漁っていたところ、
分散型バージョン管理システムGitの開発チームは、最新バージョンとなる「Git 2.50」を6月16日(現地時間)にリリースした。
分散型バージョン管理システム「Git 2.50」がリリース、複数クラフトパックの改善などを実施|CodeZine(コードジン)
Git 2.50では、新たなオプション--combine-cruft-below-sizeが追加され、出力パックの最大サイズを指定する代わりに、既存のどのクラフトパックを結合するかを決められるようになっている。
分散型バージョン管理システム「Git 2.50」がリリース、複数クラフトパックの改善などを実施|CodeZine(コードジン)
同オプションは、複数のクラフトパックに分散して、多数の到達不能オブジェクトが蓄積されているリポジトリで特に役立ち、既存のクラフトパックの結合によって、リポジトリ内のクラフトパックの数を徐々に減らせるようになる。
分散型バージョン管理システム「Git 2.50」がリリース、複数クラフトパックの改善などを実施|CodeZine(コードジン)
なお、同オプションの導入にともない、--max-cruft-sizeの役割が変更され、--max-pack-sizeのクラフトパック固有のオーバーライドとして動作するようになった。
分散型バージョン管理システム「Git 2.50」がリリース、複数クラフトパックの改善などを実施|CodeZine(コードジン)
⇧ とあるのだが、そもそも「cruft packs」の「機能」自体が何なのかよく分からない...
The cruft packs feature offer an alternative to Git’s traditional mechanism of removing unreachable objects. This document provides an overview of Git’s pruning mechanism, and how a cruft pack can be used instead to accomplish the same.
⇧ うむ、全く分からん。
何故「cruft packs」の「機能」が必要とされるに至ったのかの「背景」は、
⇧ 上記の説明にあるのだが、「サーバー」側の話になるような気がするので、「GitHub」などの「マネージド」な「サービス」を利用しているのであれば、気にする必要は無さそうではある。
おそらく、「オンプレミス環境」などで自前で「Gitリポジトリ」用の「サーバー」を用意して運用しているような場合に関係してくる話にはなりそう。
つまり、
⇧ 上図で言うところの「Remote」を管理する「サーバー」に該当する話なのかなと。
「オンプレミス環境」で「Remote」を管理する「サーバー」を用意するとなった場合、
Git Server
As Git is a distributed version control system, it could be used as a server out of the box. It is shipped with a built-in command git daemon
which starts a simple TCP server running on the Git protocol.
Dedicated Git HTTP servers help (amongst other features) by adding access control, displaying the contents of a Git repository via the web interfaces, and managing multiple repositories. Already existing Git repositories can be cloned and shared to be used by others as a centralized repo. It can also be accessed via remote shell just by having the Git software installed and allowing a user to log in.
Git servers typically listen on TCP port 9418.
⇧ 上記にあるように構築作業を頑張る必要がありますと。
ただ、
Git server as a service
There are many offerings of Git repositories as a service. The most popular are GitHub, SourceForge, Bitbucket and GitLab.
⇧ 上記のように、提供されている「Git」用の「サーバー」を利用するのが多い気はしており、この場合は、「cruft packs」の「機能」とかは、「Git server as a service」を提供している企業の方で良しなに最適化してくれているような気がする。
まぁ、「cruft packs」の「機能」を利用する機会は無いとは思うのだが、「GC(Gabage Collection)」のような機能ということになるのかな?
「Phind」に質問してみたところ、以下のような回答が返ってきた。
■cruft packs 利用しない場合
■cruft packs 利用する場合
差異とかは以下のようになるらしい。
No | 特徴 | cruft packを使用しない場合 | cruft packを使用する場合 |
---|---|---|---|
1 | オブジェクトの保存形式 | 個別のloose objectとして保存 | 単一のpackファイルにまとめて保存 |
2 | .git/objectsディレクトリ | 大量のファイルが散在し、ディレクトリが膨大になる | 効率的な構造で管理 |
3 | mtime管理 | 各オブジェクトの個別管理 | .mtimesファイルで集中管理 |
4 | ディスク使用量 | zlib圧縮のみ | delta compression可能 |
5 | パフォーマンスへの影響 | 大量のオブジェクトでinode不足が発生する可能性 | 効率的な管理が可能 |
6 | クライアント側の影響 | 通常のGit操作のみ | 通常のGit操作のみ |
7 | サーバー側の最適化 | 基本的なgcのみ | 自動的な最適化実行 |
8 | バージョン要件 | 特になし | サーバー側のみ新しいバージョンが必要 |
9 | パフォーマンスへの影響 | クライアント操作に影響なし | クライアント操作に影響なし |
ちなみに、
- 単一のクラフトパック
- 複数のクラフトパック
の違いについても質問してみたところ、以下のような回答が返ってきた。
う~む、まぁ、「cruft packs」の「機能」については使う機会はないのかなぁ...
毎度モヤモヤ感が半端ない…
今回はこのへんで。