Những yếu tố xã hội hoặc kỹ thuật nào dẫn đến sự gia tăng của tâm lý CIY?
Nguyên nhân sâu xa rõ ràng là lý do kỹ thuật: Tính di động nhị phân khó hơn tính di động nguồn . Ngoài các gói phân phối, hầu hết các phần mềm miễn phí vẫn chỉ có sẵn ở dạng nguồn vì điều đó thuận tiện hơn rất nhiều cho (các) tác giả / người bảo trì.
Cho đến khi các bản phân phối Linux bắt đầu đóng gói hầu hết mọi thứ mà mọi người bình thường muốn sử dụng, lựa chọn duy nhất của bạn là lấy nguồn và biên dịch nó cho hệ thống của riêng bạn. Các nhà cung cấp Unix thương mại thường không bao gồm những thứ mà hầu hết mọi người đều muốn (ví dụ như một trình bao đẹp như GNU bashhoặc tương tự), chỉ là việc triển khai shvà / hoặc của riêng họ csh, vì vậy bạn cần tự xây dựng công cụ nếu bạn (như một quản trị viên hệ thống) muốn để cung cấp một môi trường Unix đẹp cho người dùng của bạn để sử dụng tương tác.
Tình hình hiện nay, với hầu hết mọi người là quản trị viên duy nhất và người dùng duy nhất của máy ngồi trên máy tính để bàn của họ, khác rất nhiều so với mô hình Unix truyền thống. Một sysadmin đã duy trì phần mềm trên hệ thống trung tâm và trên máy tính để bàn của mọi người. (Thường bằng cách có các máy trạm của mọi người chỉ cần NFS-mount /optvà /usr/local/từ máy chủ trung tâm và cài đặt công cụ ở đó.)
Trước những thứ như .NET và Java, tính di động nhị phân thực sự trên các kiến trúc CPU khác nhau là không thể. Văn hóa Unix phát triển với tính di động nguồn là mặc định vì lý do này, với rất ít nỗ lực thậm chí cố gắng kích hoạt tính di động nhị phân cho đến khi những nỗ lực gần đây của Linux như LSB. Ví dụ, POSIX ( các tiêu chuẩn chính Unix) chỉ cố gắng chuẩn hóa nguồn di động, thậm chí trong các phiên bản gần đây.
Yếu tố văn hóa liên quan: Unix AT & T thương mại ban đầu đi kèm với mã nguồn (trên băng). Bạn không phải xây dựng hệ thống từ nguồn, nó chỉ ở đó trong trường hợp bạn muốn xem một cái gì đó thực sự hoạt động như thế nào khi các tài liệu không đủ.
Wikipedia nói :
"Chính sách Unix của tài liệu trực tuyến mở rộng và (trong nhiều năm) sẵn sàng truy cập vào tất cả các mã nguồn hệ thống đã làm tăng kỳ vọng của lập trình viên, và góp phần vào sự ra mắt năm 1983 của phong trào phần mềm miễn phí."
Tôi không chắc điều gì đã thúc đẩy quyết định này, vì việc cho phép khách hàng truy cập vào mã nguồn của phần mềm thương mại là chưa từng thấy trong những ngày này. Rõ ràng có một số thành kiến văn hóa ban đầu theo hướng này, nhưng có lẽ đã phát triển từ nguồn gốc của Unix như là một hệ điều hành di động được viết chủ yếu bằng C (không phải ngôn ngữ lắp ráp) có thể được biên dịch cho các phần cứng khác nhau. Tôi nghĩ rằng nhiều hệ điều hành trước đó có nhiều mã được viết bằng asm cho một CPU cụ thể, vì vậy tính di động ở mức nguồn là một trong những thế mạnh ban đầu của Unix. (Tôi có thể sai về điều này; Tôi không phải là chuyên gia về Unix ban đầu, nhưng Unix và C có liên quan.)
Phân phối phần mềm ở dạng nguồn cho đến nay là cách dễ nhất để cho phép mọi người thích ứng nó với bất kỳ hệ thống nào họ muốn nó chạy trên đó. (Người dùng cuối hoặc người đóng gói nó cho bản phân phối Linux). Nếu phần mềm đã được đóng gói bởi / để phân phối, người dùng cuối chỉ có thể sử dụng phần mềm đó.
Nhưng thật quá nhiều để mong đợi các tác giả của hầu hết các gói tạo ra nhị phân cho mọi hệ thống có thể. Một số dự án lớn cung cấp nhị phân cho một vài trường hợp phổ biến (đặc biệt là x86 / windows trong đó HĐH không đi kèm với môi trường xây dựng và nhà cung cấp HĐH đã chú trọng lớn vào việc phân phối các trình cài đặt chỉ nhị phân).
Để một phần mềm chạy trên một hệ thống khác với hệ thống mà tác giả đã sử dụng thậm chí có thể yêu cầu một số thay đổi nhỏ, dễ dàng với nguồn . Một chương trình nhỏ một lần mà ai đó đã viết để tự gãi ngứa có lẽ chưa bao giờ được thử nghiệm trên hầu hết các hệ thống tối nghĩa. Có nguồn làm cho nó có thể thực hiện những thay đổi như vậy. Tác giả ban đầu có thể đã bỏ qua một cái gì đó, hoặc cố ý viết mã di động ít hơn vì nó tiết kiệm rất nhiều thời gian. Ngay cả các gói lớn như Info-ZIP cũng không có người kiểm tra trên mọi nền tảng ngay lập tức và cần mọi người gửi các bản vá tính di động của họ khi các vấn đề được phát hiện.
(Có các loại vấn đề về tính di động ở mức nguồn khác chỉ xảy ra do sự khác biệt trong bản dựng env và không thực sự liên quan đến vấn đề ở đây. Với tính di động nhị phân theo kiểu Java, công cụ tự động ( autoconf/ auto-make) và những thứ tương tự như cmakesẽ Không cần thiết. Và chúng tôi sẽ không có những thứ như một số hệ thống yêu cầu đưa vào <netinet/in.h>thay vì<arpa/inet.h> chontohl(3) . (Và có lẽ chúng tôi sẽ không có ntohl()hoặc bất kỳ công cụ đặt hàng byte nào khác ở vị trí đầu tiên!)
Tôi phát triển ngôn ngữ .NET thường xuyên, vì vậy tôi không biết chữ.
Biên dịch một lần, chạy mọi nơi là một trong những mục tiêu chính của .NET và Java, vì vậy thật công bằng khi nói rằng toàn bộ ngôn ngữ đã được phát minh trong nỗ lực giải quyết vấn đề này và kinh nghiệm phát triển của bạn là với một trong số chúng. Với .NET, nhị phân của bạn chạy trên môi trường thời gian chạy di động (CLR) . Java gọi môi trường thời gian chạy của nó là Máy ảo Java . Bạn chỉ cần phân phối một nhị phân sẽ hoạt động trên bất kỳ hệ thống nào (ít nhất là bất kỳ hệ thống nào có người đã triển khai JVM hoặc CLR). Dĩ nhiên, bạn vẫn có thể gặp các vấn đề về tính di động như, /so với \dấu phân cách đường dẫn hoặc cách in hoặc chi tiết bố cục GUI.
Rất nhiều phần mềm được viết bằng các ngôn ngữ được biên dịch đầy đủ thành mã gốc . Không có .nethoặc mã byte java, chỉ là mã máy riêng cho CPU mà nó sẽ chạy, được lưu trữ ở định dạng tệp thực thi không di động. C và C ++ là những ví dụ chính về điều này, đặc biệt là trong thế giới Unix. Rõ ràng điều này có nghĩa là một nhị phân phải được biên dịch cho một kiến trúc CPU cụ thể.
Phiên bản thư viện là một vấn đề khác . Các thư viện có thể và thường xuyên giữ API cấp nguồn ổn định trong khi thay đổi ABI cấp nhị phân. (Xem Sự khác biệt giữa API và ABI .) Ví dụ: thêm một thành viên khác vào mờ structvẫn thay đổi kích thước của nó và yêu cầu biên dịch lại với các tiêu đề cho phiên bản thư viện mới cho bất kỳ mã nào phân bổ không gian cho cấu trúc như vậy, cho dù đó là động (malloc ), tĩnh (toàn cầu) hoặc tự động (cục bộ trên ngăn xếp).
Hệ điều hành cũng rất quan trọng . Một hương vị khác nhau của Unix cho kiến trúc CPU cùng có thể có định dạng tập tin nhị phân khác nhau, một ABI khác nhau cho thực hiện cuộc gọi hệ thống, và các giá trị số khác nhau cho các hằng số như fopen(3)'s O_RDONLY, O_APPEND,O_TRUNC .
Lưu ý rằng ngay cả một nhị phân được liên kết động vẫn có một số mã khởi động dành riêng cho hệ điều hành chạy trước đó main(). Trên Windows, đây là crt0. Unix và Linux có cùng một thứ, trong đó một số mã Khởi động C-Runtime được liên kết tĩnh thành mọi nhị phân. Tôi đoán trên lý thuyết bạn có thể thiết kế một hệ thống trong đó mã đó cũng được liên kết động và một phần của libc hoặc chính trình liên kết động, nhưng đây không phải là cách mọi thứ hoạt động trên thực tế trên bất kỳ HĐH nào tôi biết. Điều đó sẽ chỉ giải quyết vấn đề ABI gọi hệ thống, không phải là vấn đề về giá trị số cho các hằng số cho các hàm thư viện chuẩn. (Thông thường các cuộc gọi hệ thống được thực hiện thông qua các hàm bao bọc libc: Một nhị phân Linux x86-64 bình thường cho nguồn sử dụng mmap()sẽ không bao gồm syscallhướng dẫn, chỉ là mộtcall hướng dẫn cho chức năng bao bọc libc cùng tên.
Đây là một phần lý do tại sao bạn không thể chạy các nhị phân i386-FreeBSD trên i386-Linux. .
Nếu bạn muốn phân phối nhị phân, bạn cần tạo một tệp riêng cho mọi kết hợp CPU / OS-Hương vị + phiên bản / cài đặt-thư viện-phiên bản .
Quay trở lại thập niên 80/90, có nhiều loại CPU khác nhau được sử dụng chung cho các hệ thống Unix (MIPS, SPARC, POWER, PA-RISC, m68k, v.v.) và nhiều hương vị khác nhau của Unix (IRIX, SunOS, Solaris, AIX, HP-UX, BSD, v.v.).
Và đó chỉ là hệ thống Unix . Nhiều gói nguồn cũng sẽ biên dịch và hoạt động trên các hệ thống khác , như VAX / VMS, MacOS (m68k và PPC), Amiga, PC / MS-DOS, Atari ST, v.v.
Vẫn còn nhiều kiến trúc CPU và HĐH, mặc dù hiện tại phần lớn máy tính để bàn là x86 chạy một trong ba HĐH chính.
Vì vậy, đã có nhiều kết hợp CPU / HĐH hơn mức bạn có thể bắt đầu, ngay cả trước khi bạn bắt đầu nghĩ về sự phụ thuộc vào các thư viện của bên thứ 3 có thể ở các phiên bản khác nhau trên các hệ thống khác nhau. (Bất cứ thứ gì không được nhà cung cấp hệ điều hành đóng gói sẽ phải được cài đặt bằng tay.)
Bất kỳ đường dẫn nào được biên dịch thành nhị phân cũng là hệ thống cụ thể. (Điều này giúp tiết kiệm RAM và thời gian so với việc đọc chúng từ tệp cấu hình khi khởi động). Các hệ thống Unix trường học cũ thường có rất nhiều thứ được tùy chỉnh bằng tay, vì vậy không có cách nào bạn có thể đưa ra bất kỳ giả định hợp lệ nào về những gì ở đâu.
Phân phối nhị phân là hoàn toàn không khả thi đối với Unix trường học cũ ngoại trừ các dự án thương mại lớn có thể đủ khả năng xây dựng và thử nghiệm trên tất cả các kết hợp chính .
Ngay cả làm nhị phân cho chỉ i386-linux-gnuvà amd64-linux-gnulà khó. Đã dành nhiều thời gian và công sức cho những thứ như Cơ sở Tiêu chuẩn Linux để biến các nhị phân di động thành có thể . Ngay cả các nhị phân liên kết tĩnh cũng không giải quyết mọi thứ. (ví dụ: chương trình xử lý văn bản nên in trên hệ thống RedHat so với hệ thống Debian như thế nào? ví dụ, vì biên dịch lại từ nguồn không giải quyết chúng.
Bên cạnh đó, ký ức trở lại trong ngày còn quý giá hơn bây giờ. Loại bỏ các tính năng tùy chọn tại thời gian biên dịch có thể tạo ra các nhị phân nhỏ hơn (kích thước mã ít hơn) cũng sử dụng ít bộ nhớ hơn cho cấu trúc dữ liệu của chúng. Nếu một tính năng yêu cầu một thành viên bổ sung trong mọi trường hợp của một số thứ nhất định classhoặc structđể theo dõi một thứ gì đó, việc vô hiệu hóa tính năng đó sẽ thu nhỏ đối tượng thêm 4 byte (chẳng hạn), thật tuyệt nếu đó là một đối tượng mà chương trình phân bổ 100k.
Các tính năng thời gian biên dịch tùy chọn ngày nay thường được sử dụng để làm cho các thư viện bổ sung tùy chọn. ví dụ như bạn có thể biên dịch ffmpegcó hoặc không có libx264, libx265, libvorbis, và nhiều thư viện khác cho cụ video / bộ mã hóa âm thanh, xử lý phụ đề, vv vv Thông thường hơn, rất nhiều thứ có thể được biên dịch có hoặc không libreadline: nếu nó có sẵn khi bạn chạy ./configure, các kết quả nhị phân sẽ phụ thuộc vào thư viện và cung cấp chỉnh sửa dòng ưa thích khi đọc từ thiết bị đầu cuối. Nếu không, thì chương trình sẽ sử dụng một số hỗ trợ dự phòng để chỉ đọc các dòng từ stdin với fgets()hoặc một cái gì đó.)
Một số dự án vẫn sử dụng các tính năng tùy chọn để loại bỏ mã không cần thiết vì lý do hiệu suất. ví dụ, nhân Linux có thể được xây dựng mà không cần hỗ trợ SMP (ví dụ: đối với hệ thống nhúng hoặc máy tính để bàn cổ), trong trường hợp đó, việc khóa rất đơn giản. Hoặc với nhiều tính năng tùy chọn khác ảnh hưởng đến một số mã lõi, không chỉ bỏ các trình điều khiển hoặc các tính năng phần cứng khác. (Mặc dù các tùy chọn cấu hình dành riêng cho phần cứng và dành riêng cho phần cứng chiếm rất nhiều tổng số mã nguồn. Xem Tại sao nhân Linux có hơn 15 triệu dòng mã? )