cURLとlibcurlの多様なオペレーティングシステム対応
- 最近のcURLのpull requestでは、コントリビューターに対して、提案した変更がレガシープラットフォームでのテストを妨げないようにすべきだと明記している。
- cURLは現在32ビットの
time_t型をサポートしており、この機能を維持しなければならないことを強調している。
- レガシーシステムへの関心は、約束を守り不要な破壊を避けるためのものである。
安定性と約束の一部
- cURLプロジェクトは、ABIとAPIの安定性および互換性を維持するために絶えず努力している。
- 2000年代半ばに書かれたアプリケーションを最新のlibcurlにアップグレードしても、再コンパイルなしで同じように動作する。
- これはcURLとlibcurlの中核原則であり、ユーザーが信頼し頼ることのできる安定したインターネット転送ソリューションである。
ユーザー数は重要ではない
- 特定のプラットフォームのユーザー数は、そのプラットフォームをサポートする動機にはならない。
- 重要なのは、作業を行う人がいて、その作業が完了することである。
- コントリビューターがcURLが特定のプラットフォームで動作し続けることを継続的に保証するなら、ユーザー数が少なくてもそのプラットフォームでcURLは動き続ける。
cURLがどこにでもある理由
- cURLが多様なオペレーティングシステムやCPUアーキテクチャで動作し、多くのデバイスにインストールされている理由は、どこでもビルドして動作させることへの強いフォーカスがあるためである。
- 多くのユーザーや企業が古代的、ニッチ、レガシープラットフォームにこだわっており、cURLに依存することは他の代替案よりもセキュリティ面ではるかに優れていると主張している。
私たちは今でも仕様を廃止する
- cURLは時折、特定のサードパーティライブラリのサポートを終了し、他の領域でも変更を加える。
- 仕様はゆっくり慎重に廃止し、オープンなコミュニケーションを通じて、誰もが準備したり異議を唱えたりできるようにしている。
- ユーザーが変更された動作を検知できないなら、実際には変更されていないと見なされる。
世界の変化
- インターネットプロトコルとそのバージョンは、時間とともに変化する。
- 2002年に書かれたcURLコマンドの大半は、ホスト名とURLがもはや機能しないため失敗する。
- 2002年に書かれたcURLコマンドが今日まったく同じようには動作しない主な理由は、HTTPからHTTPSへの移行のためである。
GN⁺の意見
- この文章で最も重要なのは、cURLが多様なオペレーティングシステムとアーキテクチャをサポートし、それによって安定性と互換性を維持しようとする開発者たちの努力である。
- cURLがユーザーと技術の変化にもかかわらず、継続して信頼できるツールであり続けていることは、多くのソフトウェアエンジニアやユーザーにとって興味深く魅力的な事実である。
- この継続的なサポートと安定性は、cURLをインターネットの基本ツールの一つにし、技術の変化の中でも重要な役割を果たさせている。
1件のコメント
Hacker Newsのコメント
Curlの実績への称賛
time_tの互換性が強調されていたが、2038年問題が迫っており、32ビット時間処理の価値について疑問が呈された。依存関係がもたらす負担に対する開発者の認識
古い、ニッチ、レガシープラットフォームが継続して使われていること
古いオペレーティングシステムでのCurlサポート可否への疑問
Curlの人気要因の一つである寛容なライセンス
Linuxバージョンの多様さへの驚き
類似したオペレーティングシステムの区別への疑問
CurlをRustで書き直そうとする要求と、Rustのターゲット対応可能性への疑問
Curlの誕生と歴史に関する関連読書の提案
Curlの広範なサポートと更新に関するユーモラスな言及