curl chạy trên 100 hệ điều hành
(daniel.haxx.se)- curl hạn chế các thay đổi để tiếp tục được build và kiểm thử cả trên những môi trường cũ; ngay cả trong pull request gần đây cũng yêu cầu không được làm hỏng khả năng tương thích với
time_t32-bit và các nền tảng legacy - Cốt lõi không phải là duy trì một danh sách nền tảng thật dài, mà là giữ lời hứa về độ ổn định ABI/API để người dùng vẫn hoạt động bình thường sau khi nâng cấp
- Quan trọng hơn số lượng người dùng của một hệ điều hành cụ thể là có ai thực sự chăm sóc và sửa lỗi cho nó hay không; nếu vẫn còn maintainer thì cả những nền tảng ít người dùng cũng có thể tiếp tục được hỗ trợ
- curl và libcurl đã lan rộng trên nhiều hệ điều hành, kiến trúc CPU và các cấu hình đặc thù nhờ nguyên tắc ưu tiên tính di động, luôn giữ trạng thái “build được và chạy được”
- Lý do chính khiến các lệnh curl cũ thất bại thường không nằm ở thay đổi của curl, mà gần hơn với sự thay đổi của môi trường Internet như host/URL biến mất và việc chuyển từ HTTP sang HTTPS
Tiêu chí thay đổi không làm hỏng nền tảng legacy
- Trong một pull request curl gần đây, thay đổi chỉ có thể được hợp nhất vào kho mã git nếu không làm hỏng việc build hoặc kiểm thử trên các nền tảng legacy
- Thay đổi đó liên quan đến khu vực
time_t, và vì curl đã hỗ trợ kiểutime_t32-bit nên cần phải giữ nguyên hành vi đó time_t32-bit hiện đã bị hạn chế phạm vi sử dụng, và khi năm 2038 đến gần thì các ràng buộc có thể còn lớn hơn, nhưng nhiều nền tảng legacy vẫn đang dừng ở phiên bản 32-bit- Những yêu cầu như vậy khiến công việc của người đóng góp khó hơn, nhưng trong curl đó được xem là một phần của quá trình hoàn thiện thay đổi cho thật chỉn chu
Tương thích là một cam kết lớn hơn số lượng nền tảng
- Dự án curl liên tục nỗ lực để giữ độ ổn định ABI và API cũng như khả năng tương thích
- Ứng dụng dùng libcurl từ giữa những năm 2000 vẫn có thể nâng cấp lên libcurl mới nhất và hoạt động theo cùng cách mà không cần biên dịch lại ứng dụng
- Các script curl viết từ đầu những năm 2000 cũng có thể được kỳ vọng sẽ hoạt động gần như tương tự trên các bản phát hành curl mới nhất
- Tính tương thích này không chỉ là một câu quảng bá mà là nguyên tắc cốt lõi của curl và libcurl
- Người dùng có thể tin cậy vào curl
- Ngay cả khi có bản phát hành chứa lỗi, dự án vẫn cố gắng cung cấp các bản cập nhật giúp chuyển sang phiên bản mới mà không phải chịu nỗi đau nâng cấp phần mềm thường thấy
- Tinh thần không cố tình làm hỏng những gì vốn đang chạy tốt được đưa vào tiêu chí bảo trì
Yếu tố quyết định việc hỗ trợ là maintainer
- Số lượng người dùng của một nền tảng cụ thể không phải là động lực chính để curl tiếp tục hỗ trợ nền tảng đó
- Tiêu chí quan trọng hơn là ai sẽ đảm nhận công việc và liệu việc bảo trì cần thiết có thực sự được thực hiện hay không
- Nếu có người đóng góp xác nhận curl vẫn tiếp tục hoạt động trên một nền tảng nào đó, thì ngay cả các nền tảng được biết là có ít người dùng cũng vẫn có thể chạy curl
- Thời điểm một nền tảng thực sự biến mất khỏi curl là khi phần mã cần cho nền tảng đó không còn được duy trì nữa
- Ngay cả mã không còn được duy trì cũng có thể vẫn hoạt động trong nhiều năm
- Có khi phải rất lâu mới phát hiện ra rằng curl không còn chạy được trên một nền tảng cụ thể
- Ngược lại, ngay cả với nền tảng có nhiều người dùng, việc duy trì cũng khó khăn nếu thiếu maintainer có ý chí và kiến thức để xử lý các vấn đề đặc thù của nền tảng đó
Lý do lan rộng trên nhiều môi trường
- curl và libcurl tập trung rất mạnh vào việc build được và chạy được trên càng nhiều môi trường càng tốt
- Chính thái độ luôn cố gắng giữ cho phần mềm hoạt động cả trong những cấu hình độc đáo hoặc kỳ lạ là một trong những lý do giúp chúng lan sang nhiều hệ điều hành và kiến trúc CPU khác nhau
- Nhiều người dùng và công ty vẫn tiếp tục sử dụng các nền tảng cũ, ngách hoặc legacy
- Với những đối tượng này, việc giữ nguyên khả năng truyền tải của curl thường tốt hơn về mặt bảo mật so với tự xây một triển khai thay thế
- Nếu không cần phải làm hỏng tính năng, thì để người dùng hiện tại tiếp tục dựa vào curl vẫn là lựa chọn tốt hơn
Việc loại bỏ hỗ trợ diễn ra chậm và công khai
- curl đôi khi cũng loại bỏ một số hỗ trợ
- Mục tiêu bị loại bỏ chủ yếu là hỗ trợ cho thư viện bên thứ ba đang dần ít được dùng và biến mất, nhưng việc gỡ bỏ hỗ trợ cũng có thể xảy ra ở các khu vực khác
- Việc ngừng hỗ trợ được tiến hành chậm rãi, thận trọng và có trao đổi công khai
- Người dùng muốn biết phải có thể biết trước về thay đổi
- Người dùng phải có cơ hội chuẩn bị, hoặc phản đối nếu thấy đề xuất là không hợp lý
- Nếu người dùng không thể nhận ra sự thay đổi trong hành vi thì điều đó không được xem là đã thay đổi
- curl được tạo ra cho người dùng, và nếu người dùng vẫn muốn một hành vi nào đó tiếp tục tồn tại thì hành vi đó nên được giữ lại
Lý do thực sự khiến các lệnh cũ thất bại
- Các giao thức Internet và các phiên bản của chúng xuất hiện rồi biến mất theo thời gian
- Phần lớn các lệnh curl viết vào năm 2002 có thể ngày nay không còn chạy nguyên trạng nữa
- Lý do thất bại có thể không phải do bản thân curl, mà vì tên host và URL được dùng khi đó nay không còn hoạt động nữa
- Một trong những lý do lớn khiến lệnh curl năm 2002 không còn hoạt động y nguyên ngày nay là quá trình chuyển từ HTTP sang HTTPS
- Dù năm 2002 đã có các trang dùng TLS hoặc SSL, khi đó điều này chưa phổ biến, và các phiên bản giao thức TLS được dùng lúc ấy ngày nay có thể bị xem là không còn an toàn
- Các thư viện TLS hiện đại và curl có thể từ chối kết nối với các cấu hình TLS cũ chưa được cập nhật
- Ngay cả khi bạn còn giữ một tệp thực thi curl từ năm 2002 và chạy nó hôm nay, nó vẫn có thể không kết nối được với các trang HTTPS hiện đại
- Điều này không phải do curl thay đổi, mà do tầng giao thức truyền tải đã thay đổi
1 bình luận
Ý kiến trên Hacker News
Một thành tựu rất đáng nể. Curl đúng là một công cụ như món quà trời cho.
Thật thú vị khi Daniel nhấn mạnh time_t 32-bit là một điểm quan trọng về tương thích. Nếu mục tiêu là giữ cho nó tiếp tục chạy trên nhiều hệ điều hành, điều đó hoàn toàn hợp lý. Nhưng năm 2038 giờ chỉ còn cách 14 năm, và nó gần hiện tại hơn rất nhiều so với thời điểm curl ra đời. Không biết đến lúc nào thì công sức hỗ trợ thời gian 32-bit sẽ bị coi là không còn đáng nữa. Tôi đoán là khoảng 3 tháng sau ngày Y2K38, hoặc có khi còn lâu hơn
Có một điều các nhà phát triển học được khi trở nên gần gũi hơn với đội vận hành. Càng có nhiều bên phụ thuộc, gánh nặng càng lớn. Hạ tầng và các hệ thống trung tâm, khi có đủ nhiều thứ phụ thuộc vào chúng, sẽ mất đi sự linh hoạt; ngay cả những thay đổi nhỏ cũng trở nên thật sự khó khăn.
Nếu trong dịch vụ của riêng bạn có backend và frontend, và bạn muốn đập đi làm lại API giữa hai bên, ai quan tâm chứ. Cứ làm thôi.
Nhưng nếu bạn muốn loại bỏ một trường hợp biên kỳ quặc trong template mặc định chỉ vì nó “xấu xí”, bạn phải xem xét 20 dịch vụ cũ, 20 dịch vụ đã hiện đại hóa nửa vời mà chẳng ai muốn đụng tới, và thêm 50 dịch vụ đang dùng nó. Chỉ riêng lượng việc cần làm để hiểu thay đổi đó lớn đến mức nào đã như vậy rồi. Ở bước này còn chưa nói đến việc thực sự triển khai thay đổi hay đảo ngược kỹ thuật những bí mật khó hiểu.
Tôi sẽ không gọi đó là việc hào nhoáng, nhưng chống đỡ để nhân vật chính tỏa sáng tiếp tục đứng vững trong khi âm thầm thay hết mọi thứ bên dưới là điều khiến roadie hay quản trị viên có thể tự hào
Trong danh sách có khá nhiều thứ đã hơn 25 năm không có bản phát hành. Họ vẫn đang tạo các bản build hiện tại trên SCO, Xenix, OS/2, NextStep sao?
Tôi từng chạy thử những thứ này và biết rằng curl cũng tồn tại ở đó, nhưng theo kinh nghiệm của tôi, curl đó luôn là phiên bản ít nhất 15 năm tuổi.
Nếu nói không muốn phá vỡ một ma trận hỗ trợ nào đó, mà phần lớn ma trận đó đã quá 10 năm kể từ bản build cuối cùng, thì làm sao biết chắc là nó thực sự chưa bị phá?
Không rõ có thể build cho Xenix được không. GCC mới nhất có thể nhắm tới là 2.7, mà bản đó đã cổ lỗ rồi. Nếu tính cả mã mạng thì còn hơn thế nữa. Có lẽ chỉ là “ở một thời điểm nào đó nó từng chạy trên các hệ thống đó” thôi
Về câu “rất nhiều người dùng và công ty cứ bám lấy các nền tảng cũ, ngách và legacy, và chúng ta chẳng làm được gì”, hầu hết mọi người, kể cả các nhà phát triển mã nguồn đóng độc quyền, đều làm phần mềm có phần đầu giấy phép kiểu “chương trình này được phân phối với hy vọng sẽ hữu ích, nhưng không có bất kỳ bảo đảm nào, kể cả bảo đảm ngụ ý về khả năng thương mại hay sự phù hợp cho một mục đích cụ thể”.
Cách đó chi phí thấp.
Ngược lại, một số người, trong đó có tôi, phát triển phần mềm được bảo đảm phù hợp với mục đích, với bảo hành rõ ràng và tuyệt đối.
Cách đó rất đắt và chậm.
Nếu khi có thứ gì đó hỏng, con người có thể chết, môi trường có thể bị hủy hoại, hoặc thiệt hại có thể lên tới hàng triệu đô la, thì việc tiếp tục dùng một nền tảng cũ và ngách đã được các nhà phát triển rất chậm rãi, cẩn trọng soi xét kỹ trong 30–40 năm là điều có lý.
Ít nhất tôi tự nhủ như vậy mỗi khi nhìn vào Ada trên INTEGRITY chạy trên PowerPC
Nếu một người chết có thể dẫn tới thiệt hại hàng triệu đô la, thì đúng ra không nên dùng phần mềm hay nền tảng có nhóm nhà phát triển nhỏ cỡ “số nghệ sĩ tung hứng người Pháp mắc bệnh Wilson”
Một lý do cho sự phổ biến này có lẽ là giấy phép permissive. Tôi đoán nó là giấy phép MIT, nhưng có vẻ hơi khác [1]. Có ai giải thích dễ hiểu điểm khác biệt chính so với MIT là gì không? Trang bản quyền không giải thích chi tiết.
[1] https://curl.se/docs/copyright.html
“Ngoại trừ những gì có trong thông báo này, không được dùng tên của chủ sở hữu bản quyền để quảng cáo hoặc xúc tiến việc bán, sử dụng hay giao dịch khác liên quan đến phần mềm này khi chưa có sự cho phép trước bằng văn bản của chủ sở hữu bản quyền”
[1] https://spdx.org/licenses/curl.html
Tôi cứ tưởng gần 100 cái sẽ chỉ là các phiên bản Linux, nên thật bất ngờ khi ngay cả tính mọi phiên bản Linux là một hệ điều hành duy nhất thì vẫn có 100 hệ điều hành
Viết mã có cân nhắc nhiều hệ thống legacy theo kinh nghiệm cá nhân của tôi thường khiến mã tốt hơn nói chung.
Bạn sẽ tuân thủ tốt hơn các thực hành lập trình quen thuộc như đặt tên, kiểu dữ liệu, mô-đun hóa; và trừ những phần được đánh dấu rõ ràng, mức độ tuân thủ chuẩn cũng tốt hơn. Các tầng trừu tượng vững hơn, đặc biệt là trên nền tảng hiện đại thì ít lỗi hơn, và hệ thống build cũng chắc chắn hơn. Nó sẽ tự động tương thích với các nền tảng tương lai, hoặc ít nhất là rất dễ làm cho tương thích.
Tuy nhiên nếu chỉ nhắm tới vài hệ thống legacy, bạn có thể sống sót bằng một mớ vá víu và hack kỳ quặc, nên điều này có thể không đúng
Việc liệt kê FreeDOS, DR-DOS, MS-DOS là các hệ điều hành riêng biệt nghe hơi lạ. Chúng rất giống nhau, và không như các nhánh Unix khác nhau, về cơ bản là tương thích ABI
Thế mà vẫn có người muốn viết lại nó bằng Rust. Rust có thực sự nhắm tới được tất cả các kiến trúc và hệ điều hành đó không?
Bài đọc liên quan: một bài viết về curl đã ra đời như thế nào và đã trải qua lịch sử ra sao (1)
(1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...