Linus Torvalds có ý gì khi trích dẫn về tính di động? [đóng cửa]

Trong một cuộc tranh luận với Andrew Tanenbaum về vi nhân so với kiến ​​trúc hệ điều hành nguyên khối, Linus Torvalds nói,

Tính di động dành cho những người không thể viết chương trình mới.

Anh ta có ý gì?

Như Linus viết trong cuộc tranh luận, đó là bằng lưỡi (nghĩa là không quá nghiêm trọng).

Sau đó, anh tiếp tục giải thích rằng trong khi tính di động là điều tốt, thì đó cũng là một sự đánh đổi; mã không thể truy cập có thể đơn giản hơn nhiều. Đó là, thay vì làm cho mã di động hoàn hảo, chỉ cần làm cho nó đơn giản và đủ khả năng di động ("tuân thủ API di động"), và sau đó nếu cần phải chuyển, hãy viết lại khi cần. Làm cho mã di động hoàn hảo cũng có thể được xem là một hình thức tối ưu hóa sớm - thường gây hại nhiều hơn là tốt.

Tất nhiên điều đó là không thể nếu bạn không thể viết chương trình mới và phải gắn bó với chương trình gốc :)

Tôi nghĩ nó có nghĩa là mỗi chương trình nên được viết riêng cho phần cứng và hệ điều hành mà nó chạy.

Tôi nghĩ những gì anh ấy lái là mã mục đích chung có thể chạy trên nhiều nền tảng sẽ kém hiệu quả hơn hoặc dễ bị lỗi hơn so với mã được viết riêng và được điều chỉnh cho một nền tảng. Tuy nhiên, điều đó có nghĩa là khi bạn phát triển như thế này, bạn phải duy trì một vài dòng mã khác nhau.

Quay lại khi Linux được viết lần đầu tiên, nó đã sử dụng các tính năng chỉ có trên CPU i386, khá mới và đắt tiền vào thời điểm đó.

Đó chính xác là những gì linux làm: nó chỉ sử dụng một tập hợp con lớn hơn của các tính năng 386 so với các hạt nhân khác dường như làm. Tất nhiên điều này làm cho kernel không thể truy cập được, nhưng nó cũng làm cho thiết kế / nhiều / đơn giản hơn. Một sự đánh đổi chấp nhận được, và một điều khiến linux có thể xảy ra ngay từ đầu.

Khi chúng ta bước vào thế kỷ 21, các tính năng làm cho i386 trở nên hoàn toàn chính thống, cho phép Linux trở nên rất di động.

Là một người đã thực hiện rất nhiều Java và trải nghiệm hiện tượng "viết một lần, gỡ lỗi ở mọi nơi" hàng tuần trong nhiều năm, tôi hoàn toàn có thể liên quan đến điều này.

Và Java có lẽ là một ví dụ nhẹ. Tôi thậm chí không thể tưởng tượng được những gì mọi người trải qua, những người cố gắng trong khi một cơ sở mã di động trong bộ ngôn ngữ / bộ công cụ thậm chí không được thiết kế để có thể tự di chuyển được.

Ngay bây giờ tại nơi làm việc, chúng tôi đang nghiên cứu ý tưởng viết một phiên bản rút gọn của một trong những sản phẩm của chúng tôi cho thiết bị di động. Tôi đã thực hiện một số nghiên cứu về cách tạo phiên bản di động cho cả J2ME và Android - cố gắng chia sẻ càng nhiều codebase càng tốt (rõ ràng không thể hoàn toàn "di động" được, nhưng đó là một triết lý tương tự ). Nó là một cơn ác mộng.

Vì vậy, vâng, đôi khi thật tốt khi có thể nghĩ (và làm) về việc sử dụng các công cụ nhất định cho công việc nhất định. tức là tự do phát triển dựa trên một, nền tảng / môi trường nguyên khối, đơn lẻ. Và chỉ cần viết các phiên bản riêng biệt, sạch sẽ cho mỗi.

Mặc dù một số người xem / đối xử với tính di động, tuân theo các tiêu chuẩn, v.v., là ưu việt về mặt đạo đức, hoặc một cái gì đó theo thứ tự đó, những gì nó thực sự sôi nổi là kinh tế.

Viết mã di động có chi phí về nỗ lực để làm cho mã di động và (thường) đã đề cập đến một số tính năng không khả dụng trên tất cả các mục tiêu.

Mã không di động có chi phí về nỗ lực chuyển mã khi / nếu bạn quan tâm đến một kiến ​​trúc mới và (thường) đã đề cập đến một số tính năng không có (hoặc không có) trên mục tiêu ban đầu.

Vòng loại lớn có "khi / nếu bạn quan tâm đến một kiến ​​trúc mới". Viết mã di động đòi hỏi nỗ lực từ phía trước với hy vọng có một kết quả cuối cùng là có thể sử dụng mã đó trên các kiến ​​trúc mới / khác nhau với ít hoặc không cần nỗ lực. Mã không di động cho phép bạn trì hoãn đầu tư vào việc chuyển cho đến khi bạn (ít nhất là hợp lý) chắc chắn rằng bạn thực sự cần chuyển đến một số mục tiêu cụ thể.

Nếu bạn chắc chắn rằng bạn sẽ chuyển đến nhiều mục tiêu, thì việc đầu tư trực tiếp vào việc giảm thiểu chi phí chuyển tiếp dài hạn là điều đáng làm. Nếu bạn không chắc chắn về mức độ (hoặc thậm chí nếu) bạn sẽ cần chuyển mã, viết mã không di động cho phép giảm thiểu chi phí trả trước, trì hoãn hoặc thậm chí có thể tránh hoàn toàn chi phí làm cho mã di động.

Tôi nghĩ cũng đáng lưu ý rằng tôi đã nói về "di động" và "không di động" như thể có sự phân chia rõ ràng giữa hai bên. Trong thực tế, điều đó không đúng - tính di động là một sự liên tục, chạy từ hoàn toàn không di động (ví dụ: mã lắp ráp) đến cực kỳ di động (ví dụ: Info-zip) và ở mọi nơi ở giữa.

Tanenbaum đưa ra quan điểm rằng phần lớn Linux được viết theo cách không mô-đun để tận dụng CPU 386, hiện đại, thay vì làm cho tương tác CPU trở thành một thành phần, và do đó rất dễ tráo đổi. Tanenbaum về cơ bản tin rằng việc Kernel quá nguyên khối và gắn liền với CPU 386 khiến nó rất khó,

• Chuyển Linux sang nền tảng CPU khác (Rõ ràng là không chính xác, AMD64, PowerPC, v.v.)
• Các chương trình cổng được viết cho linux x86 sang kiến ​​trúc CPU khác (cũng không chính xác)

Trại linux tạo ra một số điểm, trong đó:

• Linux cung cấp hệ thống tập tin đa luồng như một phần của thiết kế
• Microkernel, trong khi thú vị và trực quan thì không hiệu quả lắm
• Việc tuân thủ API di động làm cho vấn đề về tính di động trở nên phức tạp hơn hoặc khó khăn hơn so với trình chặn.

Nếu bạn muốn viết mã di động, bạn phải viết mã di động.

Ý tôi là gì?

Thiết kế phải phản ánh mục đích. Ví dụ, nếu ngôn ngữ là C, hãy thiết kế nó để số dòng mã tối thiểu cần thay đổi để nó hoạt động. Điều này thường có nghĩa là tách biệt màn hình khỏi tính toán, dù sao đó cũng là một triết lý thiết kế tốt (MVC). Hầu hết mã C có thể được biên dịch ở bất cứ đâu, miễn là bạn có quyền truy cập vào một trình biên dịch tốt. Tận dụng điều đó và viết càng nhiều càng tốt để chung chung.

BTW, câu trả lời này sẽ chỉ áp dụng cho các ứng dụng. Hệ điều hành và nhúng là một động vật hoàn toàn khác.

Giải thích câu nói này "theo nghĩa đen" theo cách của nó.

Trong một trích dẫn khác của Linus, ông nói: "C ++ đang cố gắng giải quyết tất cả các vấn đề sai. Những điều C ++ giải quyết là những điều tầm thường, gần như hoàn toàn là cú pháp mở rộng cho C thay vì khắc phục một số vấn đề sâu sắc thực sự".

Cũng trong tiểu sử của mình, linus "Just For Fun" trong khi trích dẫn về microkernels nói rằng đối với một vấn đề phức tạp 'n' nếu bạn chia vấn đề thành các phần duy nhất '1 / n' .. thì tổng độ phức tạp của việc phát triển một hệ thống như vậy sẽ được 'n!' bản thân nó là một yếu tố đủ để không cố gắng làm điều đó và việc khai thác hiệu quả từ một hệ thống phức tạp như vậy sẽ rất khó khăn.

Bạn phải tính đến thực tế là trong những cuộc tranh luận đó, Linux rất mới và phần lớn chỉ là HĐH. Tôi nghĩ nếu bạn hỏi Linus hôm nay, anh ấy sẽ có ý kiến ​​khác. Có thể không hoàn toàn cực đoan như Tannenbaums, nhưng anh ta có thể sẽ gật đầu và nói rằng anh ta đã đúng về một số điều.

Linus và các nhà phát triển nhân khác đã trải qua rất nhiều khó khăn để tạo ra Linux di động, nhưng một lần nữa, Linux có thể không bao giờ tồn tại nếu Linus phải bắt đầu di động.

Điều đó có nghĩa là những người có thể viết chương trình tốt không cần những thứ có thể mang theo được, bởi vì họ có thể làm việc từ đầu.

Đó là các lập trình viên ít năng khiếu muốn "nhập khẩu" các chương trình khác (tính di động) vào chương trình hiện tại.