Tác giả: Jeremy Andrews
Bài phỏng vấn này được dịch và đăng trên giaiphapso.com dưới sự cho phép của tác giả
Ba mươi năm trước, Linus Torvalds là một sinh viên 21 tuổi tại Đại học Helsinki khi lần đầu tiên phát hành Linux Kernel. Thông báo của anh ấy bắt đầu bằng “Tôi đang làm một hệ điều hành (miễn phí) (chỉ là một sở thích, sẽ không lớn và chuyên nghiệp…)”. Ba thập kỷ sau, 500 siêu máy tính hàng đầu đều chạy Linux, cũng như hơn 70% tổng số điện thoại thông minh. Linux rõ ràng đã phát triển khác những gì anh nói.
Trong ba thập kỷ, Linus Torvalds đã dẫn dắt sự phát triển của Linux kernel , truyền cảm hứng cho vô số các nhà phát triển và các dự án mã nguồn mở khác. Vào năm 2005, Linus cũng đã tạo ra Git để giúp quản lý quá trình phát triển kernel. Và kể từ đó nó đã trở thành hệ thống kiểm soát phiên bản phổ biến nhất, được tin cậy bởi vô số dự án nguồn mở và dự án sở hữu độc quyền (proprietary projects).
Cuộc phỏng vấn sau đây nằm trong loạt bài của Tag1, một công ty tư vấn công nghệ toàn cầu, với các Nhà lãnh đạo Nguồn Mở (Open Source Leaders). Linus Torvalds đã trả lời các câu hỏi qua email, phản ánh những gì anh ấy đã học được trong nhiều năm từ việc dẫn dắt một dự án mã nguồn mở lớn. Trong phần đầu tiên này, phỏng vấn tập trung vào việc phát triển nhân Linux và Git. Linus giải thích: “[Linux] là một dự án cá nhân với ước mơ lớn lao là tạo ra một hệ điều hành mới, nhưng thực sự ban đầu là tôi chỉ cố gắng học những kiến thức cơ bản về phần cứng PC. “
Về việc tạo ra Git và sau đó giao nó cho Junio Hamano để cải thiện và duy trì, Linus cho biết: “Tôi không muốn khẳng định rằng lập trình là một nghệ thuật, bởi vì nó thực sự chỉ là về ‘kỹ thuật tốt’. Tôi là một người tin tưởng vào câu thần chú ‘một phần trăm cảm hứng và chín mươi chín phần trăm mồ hôi’ của Thomas Edison: nó hầu như chỉ về những chi tiết nhỏ và công việc hàng ngày. Nhưng thỉnh thoảng có một phần ‘cảm hứng’, điều đó không chỉ đơn thuần giúp giải quyết một số vấn đề, mà là giải quyết một cách rõ ràng và độc đáo và, thậm chí là tuyệt vời. Và Junio đã có những cảm hứng đó. “
Dưới đây phần đầu tiên trong cuộc phỏng vấn gồm hai phần.
Phát triển nhân Linux
Jeremy Andrews: Linux có ở khắp mọi nơi và là nguồn cảm hứng cho toàn bộ thế giới nguồn mở. Tất nhiên, không phải lúc nào cũng như vậy. Anh đã phát hành Linux kernel nổi tiếng vào năm 1991 với một bài thông báo khiêm tốn trên Usenet, comp.os.minix. Một thập kỷ sau, anh đã viết cuốn sách hấp dẫn có tựa đề “Chỉ để giải trí: Câu chuyện về một cuộc cách mạng tình cờ” (Just for Fun: The Story of an Accidental Revolutionary) giúp khám phá phần lớn lịch sử đó. Năm nay, vào tháng 8, Linux sẽ kỷ niệm 30 năm thành lập! Thật tuyệt vời, xin chúc mừng! Tại thời điểm nào trong cuộc hành trình này, anh nhận ra mình đã làm gì, và rằng Linux không chỉ là “một sở thích”?
Linus Torvalds: Điều này nghe có vẻ hơi nực cười, nhưng thực tế điều đó đã xảy ra từ rất sớm. Vào cuối năm ’91 (và chắc chắn là đầu năm ’92) Linux đã trở nên lớn hơn nhiều so với tôi mong đợi.
Và đúng vậy, xét đến thời điểm đó, có lẽ chỉ có vài trăm người dùng (và thậm chí “người dùng” có thể hơi quá vì mọi người đang mày mò với nó), có lẽ nghe có vẻ kỳ quặc nếu xét về việc Linux sau đó đã trở nên lớn hơn nhiều như thế nào. Nhưng theo nhiều cách đối với cá nhân tôi, điểm mấu chốt lớn là khi tôi nhận ra rằng những người khác thực sự đang sử dụng và quan tâm đến nó, và Linux bắt đầu có một cuộc sống của riêng mình. Mọi người bắt đầu gửi các bản vá và hệ thống thực sự bắt đầu làm được nhiều hơn những gì tôi đã thực sự hình dung ban đầu.
Tôi nhớ rằng X11 (X Window System) đã được chuyển sang Linux vào một thời gian nào đó vào tháng 4 năm 92 (đừng nói chi tiết quá về ngày tháng vì đã quá lâu rồi), và đó là một bước tiến lớn khi có GUI và một bộ tính năng mới.
Để nhìn lại tất cả điều này – tôi thực sự đã không bắt đầu với bất kỳ kế hoạch lớn với kỳ vọng cao nào. Đó là một dự án cá nhân không nằm ngoài ước mơ là tạo ra một hệ điều hành mới, nhưng thực sự đã phát triển từ việc ban đầu chỉ cố gắng tìm hiểu sơ lược về phần cứng PC của mình.
Vì vậy, khi tôi phát hành phiên bản đầu tiên, nó giống như kiểu “này, hãy nhìn những gì tôi đã làm”, và tôi hy vọng rằng những người khác sẽ thấy nó thú vị. Nhưng nó không phải là một hệ điều hành thực sự nghiêm túc và có thể sử dụng được. Nó chỉ là việc hiện thực hóa một ý tưởng, và là một dự án cá nhân mà tôi đã thực hiện trong vài tháng.
Và dự án cá nhân đó trở thành thứ được mọi người sử dụng nó, gửi phản hồi (và báo lỗi), và có các bản vá lỗi không thường xuyên, đó là sự thay đổi lớn đối với tôi.
Có một điều cơ bản: giấy phép bản quyền ban đầu là một cái gì đó kiểu “bạn có thể phân phối sản phẩm này ở dạng mã nguồn, nhưng không phải vì tiền”.
Đó là bởi vì đối với tôi, một trong những vấn đề thực sự là giấy phép sử dụng unix thương mại rất đắt (đối với một sinh viên nghèo đã tiêu hết tiền vào chiếc PC mới thì đó là vấn đề). Vì vậy, điều quan trọng đối với tôi là mã nguồn có sẵn (để mọi người có thể mày mò với nó) và tôi muốn nó được mở cho những người như tôi, những người không đủ tiền mua các lựa chọn thay thế.
Và tôi đã thay đổi giấy phép vào cuối năm ’91 (hoặc đầu năm ’92) thành GPLv2 vì có những người muốn phân phối Linux trên đĩa mềm cho các Nhóm người dùng Unix, nhưng ít nhất muốn bù lại chi phí của đĩa mềm và thời gian sao chép. Và tôi nhận ra rằng điều đó rõ ràng là hoàn toàn hợp lý, và điều quan trọng không phải là “không có tiền”, mà là “mã nguồn cần được công khai”.
Kết quả cuối cùng: mọi người không chỉ phân phối nó tại các cuộc họp của các nhóm người sử dụng Unix, mà còn phân phối cho những người sử dụng SLS và Slackware trong vòng vài tháng.
So với những thay đổi thực sự cơ bản ban đầu, mọi thứ khác đều “gia tăng”. Chắc chắn, sự thay đổi là rất nhiều (IBM xuất hiện, Oracle DB chuyển sang sử dụng Linux, Red Hat IPO, Android trở nên thịnh hành trên điện thoại, v.v.), nhưng chúng vẫn ít mang tính cách mạng hơn so với ban đầu “những người mà tôi thậm chí không biết đang sử dụng Linux”.
Jeremy Andrews: Anh có bao giờ hối hận về sự lựa chọn giấy phép của mình, hoặc về tiền mà những người và công ty khác đã kiếm được từ thứ mà anh đã tạo ra?
Linus Torvalds: Hoàn toàn không.
Trước hết, tôi đang làm khá tốt. Tôi không quá giàu, nhưng tôi là một kỹ sư phần mềm được trả lương cao, làm những gì tôi thích, theo lịch trình của riêng tôi. Tôi không thấy có sự tổn thương nào.
Nhưng quan trọng không kém, tôi tin chắc 100% rằng giấy phép là một phần quan trọng trong sự thành công của Linux (và Git, cho cùng vấn đề đó). Tôi nghĩ rằng tất cả mọi người tham gia sẽ hạnh phúc hơn nhiều khi họ biết rằng mọi người đều có quyền bình đẳng và không ai là đặc biệt liên quan đến việc cấp phép.
Có một số lượng hợp lý các dự án “giấy phép kép” này trong đó chủ sở hữu ban đầu giữ lại giấy phép thương mại (“bạn có thể sử dụng giấy phép này trong sản phẩm độc quyền của mình nếu bạn trả phí giấy phép cho chúng tôi”) và mặt khác, dự án cũng có sẵn theo một số thứ như GPL cho các trường hợp nguồn mở.
Và tôi nghĩ thật sự khó để xây dựng một cộng đồng xung quanh tình huống đó, bởi vì phía nguồn mở luôn biết rằng đó là “lớp thứ hai”. Thêm vào đó, nó dẫn đến rất nhiều thủ tục giấy phép chỉ cấp phép để bên đặc biệt luôn giữ được các quyền đặc biệt của họ. Vì vậy, nó thêm rất nhiều rào cản cho dự án.
Và mặt khác, tôi đã thấy rất nhiều dự án mã nguồn mở được cấp phép BSD (hoặc MIT hoặc tương tự) chỉ phân mảnh khi chúng trở nên đủ lớn để trở nên quan trọng về mặt thương mại và các công ty liên quan chắc chắn quyết định chuyển các bộ phận của riêng họ thành độc quyền.
Vì vậy, tôi nghĩ GPLv2 là sự cân bằng hoàn hảo giữa “mọi người đều làm việc theo cùng một quy tắc”, và vẫn yêu cầu mọi người phải trả lại cho cộng đồng (“ăn miếng trả miếng”). Và mọi người đều biết rằng tất cả những người khác có liên quan đều bị ràng buộc bởi các quy tắc giống nhau, vì vậy tất cả đều rất bình đẳng và công bằng.
Tất nhiên, một phần khác của điều đó là bạn cũng nhận ra những gì bạn đưa vào. Chắc chắn, bạn có thể cố gắng “tham gia” vào dự án và chỉ là một người dùng, và điều đó không sao cả. Nhưng nếu bạn làm điều đó, bạn cũng không kiểm soát được dự án. Điều đó cũng có thể hoàn toàn ổn, nếu bạn thực sự chỉ cần một hệ điều hành cơ bản và Linux đã làm được mọi thứ bạn muốn. Nhưng nếu bạn có yêu cầu đặc biệt, cách duy nhất để thực sự ảnh hưởng đến dự án là tham gia.
Điều này giúp mọi người trung thực. Bao gồm cả tôi. Bất kỳ ai cũng có thể phân nhánh dự án và đi theo con đường riêng của họ, và nói “tạm biệt Linus, tôi đang tiếp tục bảo trì phiên bản Linux của mình”. Tôi “đặc biệt” chỉ vì – và miễn là – mọi người tin tưởng tôi sẽ làm tốt công việc. Và đó chính xác là cách nó phải như vậy.
Việc “ai cũng có thể duy trì phiên bản của riêng mình” khiến một số người lo lắng về GPLv2, nhưng tôi thực sự nghĩ đó là điểm mạnh chứ không phải điểm yếu. Hơi khó hiểu, tôi nghĩ đó thực sự là nguyên nhân khiến Linux tránh được sự phân mảnh: mọi người đều có thể tạo nhánh dự án của riêng mình, và điều đó không sao cả. Trên thực tế, đó là một trong những nguyên tắc thiết kế cốt lõi của “Git” – mỗi bản sao của kho lưu trữ là một nhánh nhỏ của riêng nó và mọi người (và các công ty) tạo ra phiên bản của riêng họ là cách tất cả phát triển thực sự được thực hiện.
Vì vậy, việc chia tách không phải là một vấn đề, miễn là sau đó bạn có thể hợp nhất các phần tốt lại. Và đó là nơi GPLv2 xuất hiện. Quyền được nhân bản và làm việc của riêng bạn là quan trọng, nhưng mặt khác của đồng tiền cũng quan trọng không kém – sau đó luôn có quyền kết hợp trở lại với nhau khi các phần được chứng minh là thành công.
Một vấn đề nữa là bạn thực sự muốn có các công cụ hỗ trợ quy trình làm việc đó, nhưng bạn cũng phải có tư duy để hỗ trợ nó. Một trở ngại lớn không chỉ là việc cấp phép, mà còn là “máu xấu”. Nếu phân bản bắt đầu từ những lý do đối nghịch nhau, có thể rất khó để hợp nhất hai phân bản – không phải vì lý do cấp phép hoặc kỹ thuật, mà bởi vì phân bản khác nhau quá gay gắt. Một lần nữa, tôi nghĩ Linux đã tránh được điều đó chủ yếu bởi vì chúng ta luôn coi việc biến đổi mọi thứ là tự nhiên, và sau đó cũng rất tự nhiên khi cố gắng hợp nhất trở lại khi một số công việc đã cho thấy là thành công.
Vì vậy, câu trả lời kiểu này đã đi ở một khía cạnh nào đó, nhưng tôi nghĩ nó là một câu hỏi quan trọng – tôi thực sự không hối hận về việc lựa chọn giấy phép, bởi vì tôi thực sự nghĩ rằng GPLv2 là một phần rất lớn lý do tại sao Linux thành công.
Tiền thực sự không phải là một động lực tuyệt vời. Nó không kéo mọi người lại với nhau. Có một dự án chung và thực sự cảm thấy rằng bạn thực sự có thể là một đối tác đầy đủ trong dự án đó, điều đó thúc đẩy mọi người, tôi nghĩ vậy.
Jeremy Andrews: Ngày nay khi mọi người phát hành mã nguồn theo GPLv2, họ thường làm điều đó vì Linux. Anh đã tìm thấy giấy phép như thế nào và bạn đã dành bao nhiêu thời gian và nỗ lực để xem xét các giấy phép hiện có khác?
Linus Torvalds: Hồi đó, mọi người vẫn có những cuộc chiến khá gay gắt về BSD và GPL (tôi nghĩ một phần được thúc đẩy bởi cách RMS chọc giận mọi người), vì vậy tôi đã xem một số cuộc thảo luận về giấy phép chỉ qua các nhóm tin usenet khác nhau (như comp.arch, comp.os.minix, v.v.).
Nhưng hai lý do chính có lẽ chỉ đơn giản là bộ trình dịch gcc – công cụ rất quan trọng trong việc đưa Linux hoạt động, vì tôi hoàn toàn yêu cầu một trình biên dịch C – và Lars Wirzenius (“Lasu”), là sinh viên CS nói tiếng Thụy Điển khác tại trường Đại học cùng năm của tôi (Cộng đồng nói tiếng Thụy Điển số khá nhỏ ở Phần Lan).
Lasu nghiên cứu nhiều hơn về các cuộc thảo luận về giấy phép, v.v. so với tôi.
Đối với tôi, việc lựa chọn GPLv2 không phải là một vấn đề lớn, chủ yếu là về thực tế là giấy phép ban đầu của tôi rất đặc biệt và cần cập nhật, và tôi cảm thấy mắc nợ gcc, và GPLv2 phù hợp mong muốn của tôi là “bạn có để cung cấp cho lại mã nguồn”.
Vì vậy, thay vì tạo ra một giấy phép khác (hoặc chỉ chỉnh sửa giấy phép gốc – chỉ cần loại bỏ điều khoản “không có tiền có thể đổi chủ”), tôi muốn chọn một giấy phép mà mọi người đã biết và đã có một số luật sư tham gia.
Jeremy Andrews: Ngày điển hình của anh như thế nào? Bao nhiêu trong số đó được dành để viết mã, so với xem lại mã, so với đọc và viết email? Và làm thế nào để anh cân bằng giữa cuộc sống cá nhân và làm việc trên Linux Kernel?
Linus Torvalds: Dạo này tôi viết code rất ít và lâu rồi không viết. Và khi tôi viết code, tình huống phổ biến nhất là có một số cuộc thảo luận về một số vấn đề cụ thể, và tôi thực hiện các thay đổi và gửi chúng dưới dạng bản vá chủ yếu như một lời giải thích về một giải pháp được đề xuất.
Nói cách khác, hầu hết các đoạn mã tôi viết đều mang tính chất “nhìn xem, chúng ta làm theo cách này thì sao”, trong đó bản vá là một ví dụ rất cụ thể. Thật dễ dàng để sa lầy vào một số cuộc thảo luận lý thuyết cấp cao về cách giải quyết vấn đề nào đó và tôi thấy rằng cách tốt nhất để mô tả một giải pháp thường là chỉ viết đoạn mã – có thể không phải toàn bộ – và chỉ cần thực hiện nó. rất cụ thể theo cách đó.
Bởi vì tất cả công việc thực sự của tôi đều dành cho việc đọc và viết email. Nó chủ yếu là về giao tiếp, không phải lập trình. Trên thực tế, tôi coi loại giao tiếp này với các nhà báo và blogger công nghệ, v.v. theo đúng nghĩa đen là một phần trong ngày làm việc của tôi – nó có thể được ưu tiên thấp hơn so với các cuộc thảo luận kỹ thuật thực tế, nhưng tôi cũng dành một lượng thời gian kha khá cho những việc như thế này.
Và vâng, tôi cũng dành thời gian cho việc xem xét code, nhưng thành thật mà nói, vào thời điểm tôi nhận được các pull request, nói chung mã được đề cập đã được nhiều người xem xét rồi. Vì vậy, trong khi tôi vẫn xem xét các bản vá, tôi thực sự có xu hướng xem xét nhiều hơn các lời giải thích và lịch sử về cách bản vá đến với tôi. Và với những người tôi đã làm việc lâu nhất, tôi thậm chí không làm điều đó: họ là người duy trì hệ thống con của họ, tôi không ở đó để quản lý vi mô công việc của họ.
Vì vậy, khá thường xuyên, công việc chính của tôi là “ở đó”, là đầu mối thu thập, và là người quản lý và thực thi các bản phát hành. Nói cách khác, công việc của tôi thường thiên về quy trình bảo trì hơn là mã cấp thấp.
Jeremy Andrews: Môi trường làm việc của anh như thế nào? Ví dụ, anh thích một căn phòng tối không ai quấy rầy hay một căn phòng có thể nhìn thấy xung quanh? Anh có xu hướng làm việc trong im lặng, hay trong khi nghe nhạc? Anh thường sử dụng loại phần cứng nào? Anh có xem lại code bằng lệnh vi trong terminal hay bằng một IDE ưa thích không? Và anh có bản phân phối Linux (Linux distribution) ưa thích cho công việc này không?
Linus Torvalds: Phòng của tôi không hẳn là “tối”, nhưng tôi đã đóng rèm cửa sổ cạnh bàn làm việc, vì tôi không muốn có ánh sáng mặt trời chói chang (không nhất thiết là vào thời điểm này trong năm ở Oregon;) . Vì vậy, không có quang cảnh, chỉ là một bàn làm việc (lộn xộn), với màn hình 4k kép và một máy tính để bàn mạnh dưới bàn làm việc. Và một vài chiếc máy tính xách tay để xung quanh để thử nghiệm và để sử dụng khi tôi đang trên đường.
Và tôi muốn làm việc trong im lặng. Tôi đã từng ghét sự tích tắc của các ổ đĩa cơ học, vui vì từ lâuchúng đã đã bị bỏ vào thùng rác và tôi đã sử dụng ổ SSD hơn một thập kỷ nay. Và những chiếc quạt CPU ồn ào cũng không thể chấp nhận được.
Và tất cả được thực hiện trong một terminal truyền thống, mặc dù tôi không sử dụng ‘vi‘. Tôi sử dụng trình soạn thảo đáng ghét được gọi là “micro-emacs”, hoàn toàn không liên quan gì đến GNU emacs ngoại trừ một số ràng buộc chính tương tự. Tôi đã làm quen với nó ở Đại học Helsinki khi tôi còn là một cậu bé, và tôi đã không thể cai sữa cho mình, mặc dù tôi nghĩ rằng tôi sẽ phải sớm thôi. Tôi đã chỉnh sửa để hỗ trợ utf-8 (rất hạn chế) cho nó một vài năm trước, nhưng nó thực sự quá cũ và cho thấy tất cả các dấu hiệu của việc đã được viết vào những năm 80 và phiên bản tôi sử dụng là một bản không được cập nhật từ giữa những năm 90.
Đại học Helsinki đã sử dụng nó vì nó hoạt động trên DOS, VAX / VMS và Unix, đó là lý do tại sao tôi được giới thiệu về nó. Và bây giờ các ngón tay của tôi đã gắn chặc vào nó. Tôi thực sự cần phải chuyển sang một cái gì đó thực sự được duy trì và hoạt động đúng cách utf-8. Có lẽ là ‘nano’. Nhưng tôi cũng chưa thực sự bị buộc phải dạy những ngón tay cũ kỹ của mình những thủ thuật mới.
Vì vậy, môi trường desktop của tôi khá đơn giản: một số trình soạn thảo mở, trình duyệt web và email (và một số tab khác, chủ yếu là các trang web tin tức và công nghệ). Tôi muốn có một lượng không gian desktop hợp lý, bởi vì tôi đã quen với việc có các cửa sổ đầu cuối khá lớn (100×40 là loại kích thước bắt đầu mặc định của tôi) và tôi có nhiều terminal mở cạnh nhau. Do đó, các màn hình 4k kép được sử dụng.
Tôi sử dụng Fedora trên tất cả các máy của mình, không phải vì nó nhất thiết phải “được ưu tiên”, mà vì đó là thứ tôi đã quen. Tôi không quan tâm lắm đến bản phân phối – đối với tôi, đó chủ yếu là một cách để cài đặt Linux trên máy và thiết lập tất cả các công cụ của tôi, để sau đó tôi có thể thay thế hkernal và làm việc trên đó.
Jeremy Andrews: Linux Kernel Mailing List là nơi phát triển kernel diễn ra công khai và có lưu lượng truy cập cực kỳ cao. Làm thế nào để anh theo kịp với rất nhiều email? Anh đã khám phá các giải pháp khác để cộng tác và giao tiếp bên ngoài danh sách gửi thư, hoặc có điều gì đó về một danh sách gửi thư đơn giản hoàn hảo cho những gì anh làm chưa?
Linus Torvalds: Ồ, tôi không đọc trực tiếp kernel mailing list, và đã không còn làm chuyện đó trong nhiều năm. Nó quá nhiều.
Điểm cơ bản của kernel mailing list là nó cc’d tất cả các cuộc thảo luận. Và theo cách đó, khi một người mới được đưa vào cuộc thảo luận, họ có thể xem lịch sử bằng cách xem kernel mailing list.
Vì vậy, những gì tôi đã từng làm là được đăng ký vào danh sách, nhưng tất cả các email linux kernel mailing list (lkml) mà tôi không được cc trực tiếp sẽ được tự động lưu trữ, vì vậy tôi không nhìn thấy nó theo mặc định. Nhưng sau đó khi một số vấn đề được chuyển tới tôi, tất cả cuộc thảo luận đó sẽ hiển thị, bởi vì nó ở đó trong email của tôi, chỉ là không có trong hộp thư đến của tôi cho đến khi nó được cần đến.
Ngày nay, tôi sử dụng chức năng lore.kernel.org vì nó hoạt động rất tốt và chúng tôi có một số công cụ khác được xây dựng xung quanh nó. Vì vậy, thay vì để nó tự động lưu trữ trong kho lưu trữ thư của riêng tôi, các cuộc thảo luận sẽ được hiển thị theo cách đó. Nhưng quy trình làm việc cơ bản là giống nhau về mặt khái niệm.
Rõ ràng là tôi vẫn nhận được một lượng email kha khá – nhưng theo nhiều cách, nó đã trở nên tốt hơn trong những năm qua, thay vì tồi tệ hơn. Một phần lớn trong số đó là Git và sự hoạt động tốt của kernel release flow dù chúng ta đã từng gặp nhiều vấn đề với code flow và công cụ. Tình hình email của tôi thực sự tồi tệ hơn nhiều vào khoảng đầu thế kỷ này, khi chúng tôi phải xử lý những bản vá khổng lồ và chúng tôi gặp vấn đề nghiêm trọng về khả năng mở rộng trong quy trình phát triển.
Mô hình mailing list (với công cụ xung quanh nó) thực sự hoạt động rất tốt. Điều đó không có nghĩa là mọi người không sử dụng các phương tiện giao tiếp khác ngoài email (cả giữa người với người và danh sách gửi thư): có những người thích các thiết lập trò chuyện thời gian thực khác nhau (IRC là phương thức truyền thống). Và mặc dù đó chưa bao giờ là điều của tôi, nhưng rõ ràng đó là thứ mà một số người thích sử dụng để động não. Nhưng mô hình “danh sách gửi thư dưới dạng kho lưu trữ” hoạt động rất tốt và hoạt động liền mạch với toàn bộ “gửi bản vá lỗi giữa các nhà phát triển dưới dạng email” và “gửi báo cáo sự cố dưới dạng email”.
Vì vậy, email vẫn là kênh liên lạc chính và giúp bạn dễ dàng thảo luận các vấn đề kỹ thuật, với các bản vá lỗi được nhúng trong cùng một phương tiện. Và nó hoạt động trên các múi giờ, điều này rất quan trọng khi mọi người ở rất xa nhau về mặt địa lý.
Jeremy Andrews: Tôi đã theo dõi chặt chẽ quá trình phát triển kernel trong khoảng một thập kỷ, viết blog về nó trên KernelTrap và viết về các tính năng mới khi chúng phát triển. Tôi đã dừng lại vào khoảng thời gian kernel 3.0 được phát hành, sau 8 năm của phiên bản 2.6.x. Có thể tóm tắt một số điều thú vị hơn đã xảy ra trong kernel kể từ bản phát hành 3.0 không?
Linus Torvalds: Hì. Đã quá lâu rồi tôi thậm chí không thể bắt đầu tóm tắt mọi thứ. Đã một thập kỷ kể từ 3.0 và chúng tôi đã có rất nhiều thay đổi về mặt kỹ thuật trong thập kỷ đó. ARM đã lớn mạnh và ARM64 đã trở thành một trong những kiến trúc chính của chúng tôi. Rất nhiều và rất nhiều trình điều khiển mới cũng như chức năng cốt lõi mới.
Nếu có, điều thú vị trong thập kỷ qua là cách chúng ta thực sự giữ cho mô hình phát triển thực tế thực sự trơn tru và những gì không thay đổi.
Chúng tôi đã trải qua nhiều sơ đồ số phiên bản khác nhau trong nhiều thập kỷ, chúng tôi có các mô hình phát triển khác nhau, nhưng bản phát hành 3.0 trên thực tế là bản hoàn thiện mô hình mà chúng tôi đã sử dụng kể từ đó. Nó giống như được công bố chính thức toàn bộ “các bản phát hành dựa trên thời gian, số phiên bản chỉ là số và không có bất kỳ phụ thuộc tính năng nào”.
Chúng tôi đã bắt đầu toàn bộ bản phát hành dựa trên thời gian với một cửa sổ hợp nhất trong 2,6.x ngày, vì vậy phần đó không phải là mới. Nhưng 3.0 là khi dấu tích cuối cùng của “con số có ý nghĩa” bị lật tẩy.
Chúng tôi đã có sơ đồ đánh số ngẫu nhiên (chủ yếu là trước 1.0), chúng tôi đã có toàn bộ mô hình “số nhỏ lẻ có nghĩa là hạt nhân phát triển, thậm chí có nghĩa là hạt nhân sản xuất ổn định” và sau đó trong phiên bản 2.6.x, chúng tôi bắt đầu phát hành dựa trên thời gian mô hình. Nhưng mọi người vẫn có câu hỏi “cần gì để tăng số lượng chính”. Và 3.0 đã công bố chính thức rằng ngay cả số phiên bản chính cũng không có ý nghĩa gì và chúng tôi sẽ cố gắng giữ cho các con số dễ xử lý và không để chúng phát triển quá lớn.
Vì vậy, trong thập kỷ qua, chúng tôi đã thực hiện những thay đổi hoàn toàn lớn (Git giúp dễ dàng hiển thị một số thống kê về con số: khoảng 3/4 triệu commits của hơn 17 nghìn người). Nhưng bản thân mô hình phát triển đã thực sự khá suôn sẻ và ổn định.
Và điều đó thực sự không phải lúc nào cũng vậy. Hai thập kỷ phát triển kernel đầu tiên đầy rẫy những thay đổi mô hình phát triển khá đau đớn. Thập kỷ sau đã có thể dự đoán việc phát hành các release.
Jeremy Andrews: Hiện tại, bản phát hành mới nhất là 5.12-rc5. Quy trình phát hành được chuẩn hóa như thế nào? Ví dụ: những loại thay đổi nào xảy ra đối với -rc1, so với -rc2, v.v.? Và anh quyết định một bản phát hành nhất định sẵn sàng được phát hành chính thức vào thời điểm nào? Điều gì xảy ra nếu anh sai và tìm thấy một hồi quy lớn sau bản phát hành cuối cùng, và tần suất điều này xảy ra như thế nào? Quá trình này đã phát triển như thế nào trong những năm qua?
Linus Torvalds: Tôi đã ám chỉ điều này trước đó: bản thân quy trình thực sự là khá chuẩn, và đã duy trì như vậy trong thập kỷ qua. Nó đã trải qua một số biến động trước đó, nhưng nó thực sự gần giống như hoạt động của đồng hồ kể từ 3.0 (và trên thực tế là một vài năm trước đó – việc chuyển sang Git theo nhiều cách là sự khởi đầu của quá trình hiện đại và nó đã mất một thời gian trước đó mọi người đã quen với nó).
Chúng tôi đã có chu kỳ “hai tuần cửa sổ hợp nhất (merge window)”, theo sau là khoảng 6-8 bản releases hàng tuần trước khi release cuối cùng trong gần 15 năm cho đến nay.
Và các quy tắc luôn giống nhau, mặc dù chúng không phải lúc nào cũng được thực thi hoàn toàn nghiêm ngặt: merge window dành cho code mới được cho là “đã thử nghiệm và sẵn sàng”, sau đó khoảng hai tháng tiếp theo dành cho các bản sửa lỗi và thực sự chắc chắn rằng tất cả các vấn đề được giải quyết. Điều này không phải lúc nào cũng xảy ra và đôi khi mã được cho là “sẵn sàng” đó bị vô hiệu hóa hoặc hoàn nguyên hoàn toàn trước khi phát hành.
Và sau đó nó lặp lại – vì vậy chúng tôi có một bản phát hành khoảng 10 tuần một lần hoặc lâu hơn.
Và tiêu chí phát hành là tôi cảm thấy đủ tự tin, điều này rõ ràng là dựa trên những loại báo cáo sự cố vẫn đang đến. Nếu một số khu vực vẫn hiển thị sự cố muộn trong trò chơi rc, tôi khá quyết liệt chỉ hoàn nguyên mọi thứ và nói rằng “chúng tôi sẽ giải quyết vấn đề này trong một bản phát hành sau khi chúng tôi đã tìm ra mọi thứ một cách đầy đủ”, nhưng nhìn chung, điều đó là khá hiếm.
Có phải lúc nào quy trình này cũng hoạt động không? Không. Sau khi kernelđược phát hành, bạn có được người dùng mới, bạn có được những người không tham gia kiểm tra trong quá trình phát triển tìm thấy những thứ không hoạt động và chúng tôi đã không thấy được trong loạt rc. Đó là điều không thể tránh khỏi. Đó là một phần lý do tại sao chúng tôi có toàn bộ cây “kerneln ổn định”, tiếp tục bổ sung các bản sửa lỗi sau khi phát hành. Và một số kernel ổn định được duy trì lâu hơn những kernel khác, và được gọi là nhân LTS (Long Term Support tức Hỗ trợ lâu dài).
Tất cả những điều này hầu như không thay đổi trong mười năm qua, mặc dù cuối cùng chúng ta đã có nhiều tự động hóa hơn. Tự động hóa kiểm tra kernel nói chung là khó – một phần vì rất nhiều kernel là trình điều khiển sau đó rõ ràng phụ thuộc vào tính khả dụng của phần cứng – nhưng có một số công cụ thực hiện cả kiểm tra khởi động và hiệu suất, đồng thời thực hiện nhiều thử nghiệm tải ngẫu nhiên khác nhau. Và điều đó đã được cải thiện rất nhiều trong những năm qua.
Jeremy Andrews: Tháng 11 năm ngoái, anh cho biết đã rất ấn tượng với chip ARM64 mới của Apple trong một số máy tính mới của họ. Anh có đang theo dõi nỗ lực phát triển để hỗ trợ họ với Linux không? Tôi thấy công việc đã được hợp nhất vào sẵn sàng cho việc tiếp theo. Có khả năng Linux sẽ khởi động trên phần cứng MacBook của Apple sớm nhất là nhân 5.13 sắp tới? Anh có khả năng chấp nhận sớm việc này không? Ý nghĩa của ARM64 là gì?
Linus Torvalds: Thỉnh thoảng tôi mới kiểm tra, nhưng vẫn còn sớm. Như anh thấy, hỗ trợ sớm có thể sẽ được hợp nhất vào 5.13, nhưng cần nhận ra rằng đó thực sự mới chỉ là bước khởi đầu và chưa làm cho phần cứng của Apple trở nên hữu ích với Linux.
Không phải phần arm64 cuối cùng là vấn đề, mà là tất cả các trình điều khiển cho phần cứng xung quanh nó (đặc biệt là SSD và GPU). Công việc ban đầu cho đến nay giúp một số nội dung cấp thấp thực sự hoạt động, nhưng không dẫn đến bất kỳ điều gì hữu ích ngoài việc kích hoạt phần cứng ban đầu. Sẽ mất một thời gian để nó trở thành một lựa chọn thực sự để mọi người dùng thử.
Nhưng không chỉ phần cứng của Apple đã được cải thiện – cơ sở hạ tầng cho arm64 nói chung đã phát triển rất nhiều và các lõi đã chuyển từ “Meh” sang cạnh tranh hơn nhiều trong không gian máy chủ. Không gian máy chủ arm64 khá chán cách đây không lâu, nhưng bộ xử lý Graviton2 và Ampere’s Altra của Amazon – cả hai đều dựa trên ARM Neoverse IP được cải tiến nhiều – tốt hơn nhiều so với những gì các sản phẩm cung cấp cách đây vài năm.
Tôi đã chờ đợi để có một cỗ máy ARM có thể sử dụng được hơn một thập kỷ cho đến nay, và nó vẫn chưa sẵn sàng, nhưng rõ ràng là nó gần hơn rất nhiều so với trước đây.
Trên thực tế, tôi đoán tôi có thể nói rằng tôi đã muốn một chiếc máy ARM lâu hơn thế – khi tôi còn là một thiếu niên, chiếc máy tôi thực sự muốn là Acorn Archimedes, nhưng tính khả dụng và giá cả đã khiến tôi phải mua một chiếc Sinclair QL (bộ xử lý M68008) và sau đó rõ ràng là một vài năm sau đó là một chiếc PC i386.
Vì vậy, nó đã được sản xuất trong nhiều thập kỷ, nhưng chúng vẫn chưa được phổ biến rộng rãi và giá cả, hiệu suất cạnh tranh như máy tính. Hy vọng rằng trong một tương lai không xa.
Jeremy Andrews: Có điều gì trong kernel không tối ưu, nhưng sẽ yêu cầu viết lại hoàn chỉnh để giải quyết đúng cách không? Nói cách khác, kernel đã 30 năm tuổi và kiến thức, ngôn ngữ và phần cứng đã thay đổi rất nhiều trong 30 năm này: nếu anh viết lại nó từ đầu, anh sẽ thay đổi điều gì?
Linus Torvalds: Chúng tôi thực sự giỏi và có thể viết lại hoàn toàn mọi thứ nếu cần thiết, vì vậy bất cứ điều gì có thể là một thảm họa không thể giải quyết được từ lâu đã được viết lại.
Chắc chắn, chúng ta có một lượng lớn các lớp “tương thích”, nhưng chúng thường không quá khủng khiếp. Và không rõ liệu thậm chí các lớp tương thích đó có thực sự biến mất nếu viết lại từ đầu hay không – chúng là về khả năng tương thích ngược với các tập nhị phân cũ hơn (và thường là tương thích ngược với các kiến trúc cũ hơn, ví dụ: chạy các ứng dụng x86 32 bit trên x86-64). Vì tôi coi khả năng tương thích ngược là rất quan trọng, nên tôi muốn giữ những điều đó ngay cả khi viết lại.
Vì vậy, rõ ràng là có rất nhiều thứ “không phải là tối ưu” theo nghĩa là bất cứ điều gì có thể được cải thiện, nhưng cách bạn diễn đạt câu hỏi, tôi phải nói rằng không, không có gì ở đó mà tôi coi thường. Có những trình điều khiển cũ mà không ai có thể quan tâm đến đủ để dọn dẹp, và vì vậy họ có thể làm những điều xấu xí, nhưng một phần quan trọng của điều đó là “không ai đủ quan tâm”. Nó không phải là một vấn đề, và khi nó trở thành một vấn đề, chúng tôi có xu hướng khá tích cực loại bỏ hỗ trợ kế thừa thực sự mà chúng tôi không thể tìm thấy bất kỳ ai quan tâm đến. Vì vậy, chúng tôi đã loại bỏ rất nhiều trình điều khiển trong nhiều năm và chúng tôi đã loại bỏ toàn bộ hỗ trợ kiến trúc khi nó không còn có ý nghĩa gì để duy trì.
Không, lý do chính duy nhất cho việc “viết lại” sẽ là nếu bạn gặp một số trường hợp sử dụng mà toàn bộ cấu trúc không còn ý nghĩa nữa. Kịch bản có thể xảy ra nhất sẽ là một hệ thống nhúng nhỏ nào đó không muốn mọi thứ mà Linux cung cấp, và có phần cứng nhỏ đến mức nó chỉ muốn một thứ gì đó nhỏ hơn và đơn giản hơn những gì Linux đã trở nên trong những năm qua.
Vì Linux đã phát triển rất nhiều. Ngay cả phần cứng nhỏ (điện thoại di động, v.v.) ngày nay cũng có khả năng hơn nhiều so với máy gốc mà Linux được phát triển.
Jeremy Andrews: Còn lại về việc viết lại ít nhất các phần bằng Rust, một ngôn ngữ được thiết kế đặc biệt cho hiệu suất và sự an toàn? Có chỗ để cải thiện theo cách này không? Anh có cảm thấy rằng có bao giờ một ngôn ngữ khác như Rust có thể thay thế C trong hạt nhân không?
Linus Torvalds: Chúng ta sẽ xem. Tôi không nghĩ rằng Rust sẽ tiếp quản nhân lõi, nhưng việc thực hiện các trình điều khiển riêng lẻ (và có thể là toàn bộ hệ thống phụ của trình điều khiển) trong đó có vẻ không hoàn toàn khó xảy ra. Có thể cả hệ thống tập tin. Vì vậy, nó không phải là “thay thế C”, mà là “tăng cường mã C của chúng tôi khi nó có ý nghĩa”.
Tất nhiên, trình điều khiển nói riêng là khoảng một nửa kernal code thực tế, vì vậy có rất nhiều chỗ cho điều đó, nhưng tôi không nghĩ rằng bất kỳ ai thực sự mong đợi sẽ viết lại các trình điều khiển hiện có bằng Rust, nhiều hơn một “một số người sẽ làm trình điều khiển mới sử dụng Rust, và một vài trình điều khiển có thể được viết lại nếu nó có ý nghĩa “.
Nhưng ngay bây giờ, đó là “mọi người đang dùng thử và trải nghiệm với nó” hơn là bất cứ điều gì hơn thế. Thật dễ dàng để chỉ ra những lợi thế, nhưng chắc chắn cũng có những phức tạp, vì vậy tôi đang thực hiện một cách tiếp cận chờ và xem để xem liệu những lợi thế đã hứa có thực sự thành công hay không.
Jeremy Andrews: Có phần cụ thể nào của kernel mà cá nhân anh tự hào nhất không?
Linus Torvalds: Các phần nổi bật mà tôi có có thể chỉ ra là lớp VFS – virtual filesystem (hệ thống tập tin ảo) (và tra cứu tên đường dẫn (pathname) nói riêng) và mã máy ảo của chúng tôi. Nguyên nhân là vì Linux chỉ thực hiện một số điều cơ bản đó (tra cứu tên tập tin thực sự là một hoạt động cốt lõi trong hệ điều hành) tốt hơn nhiều so với bất kỳ thứ gì khác ngoài kia. Và điều thứ hai chủ yếu là vì chúng tôi hỗ trợ hơn 20 kiến trúc và chúng tôi vẫn làm điều đó với một lớp VM thống nhất, mà tôi nghĩ là khá ấn tượng.
Nhưng đồng thời, đây là một chức năng “bạn quan tâm đến phần nào của hạt nhân”. Kernel đủ lớn để các nhà phát triển khác nhau (và những người dùng khác nhau) sẽ có những ý kiến khác nhau về những gì quan trọng nhất. Một số người nghĩ rằng lập lịch là phần thú vị nhất của kernel. Những người khác lại thích sự phức tạp của trình điều khiển thiết bị (và chúng tôi có rất nhiều thứ đó). Cá nhân tôi có xu hướng tham gia nhiều hơn vào các lĩnh vực VM và VFS, vì vậy tôi chỉ ra những lĩnh vực đó.
Jeremy Andrews: Tôi đã tìm thấy mô tả về tra cứu tên đường dẫn (this description of pathname lookup) và nó phức tạp hơn tôi mong đợi. Điều gì làm cho việc triển khai Linux tốt hơn nhiều so với những gì được thực hiện trong các hệ điều hành khác? Và theo anh “tốt hơn” có nghĩa là gì?
Linus Torvalds: Tra cứu tên đường dẫn thực sự là một việc phổ biến và cơ bản đến nỗi hầu hết mọi người bên ngoài các nhà phát triển kernel thậm chí không nghĩ về nó như một vấn đề: họ chỉ mở tập tin và coi đó là điều hiển nhiên.
Nhưng nó thực sự khá phức tạp để có thể làm tốt. Chính xác là vì mọi thứ đều thực hiện tra cứu tên đường dẫn, nó cực kỳ quan trọng về hiệu suất, và nó là một trong những lĩnh vực mà bạn cũng muốn mở rộng quy mô tốt trong môi trường SMP và nó có rất nhiều phức tạp trong cơ chế khóa (locking). Và bạn rất không muốn thực hiện bất kỳ IO nào, vì vậy bộ nhớ đệm là rất quan trọng. Trên thực tế, tra cứu tên đường dẫn quan trọng đến mức bạn không thể để nó cho hệ thống tập tin cấp thấp, bởi vì chúng tôi có hơn 20 hệ thống tập khác nhau và việc mỗi hệ thống này thực hiện bộ nhớ đệm riêng và việc thực hiện locking riêng của chúng sẽ hoàn toàn là một thảm họa.
Vì vậy, một trong những điều chính mà lớp VFS làm là thực sự xử lý tất cả việc khóa và lưu vào bộ nhớ đệm của các thành phần tên đường dẫn, đồng thời xử lý tất cả quá trình tuần tự hóa và truyền tải điểm gắn kết, đồng thời thực hiện tất cả với các thuật toán không khóa (RCU), nhưng cũng với một số thứ giống như khóa thực sự thông minh (khóa “lockref” của hạt nhân Linux là một “spinlock với số tham chiếu” rất đặc biệt, được thiết kế theo nghĩa đen cho bộ nhớ đệm dcache và về cơ bản nó là một số tham chiếu nhận biết khóa chuyên biệt có thể thực hiện khóa xóa cho một số tình huống phổ biến).
Kết quả cuối cùng: hệ thống tập tin cấp thấp vẫn cần thực hiện tra cứu thực tế cho những thứ không được lưu trong bộ nhớ cache, nhưng chúng không cần phải lo lắng về bộ nhớ đệm và tất cả các quy tắc đồng tiền và quy tắc nguyên tử đi cùng với tra cứu tên đường dẫn. VFS xử lý tất cả những điều đó cho họ.
Và tất cả đều vượt trội so với bất cứ điều gì mà bất kỳ hệ điều hành nào khác đã làm được, trong khi về cơ bản thì khả năng mở rộng hoàn hảo cho cả những máy có hàng nghìn CPU. Và nó làm được điều đó ngay cả khi tất cả các máy đó đều chạm vào cùng một thư mục (bởi vì những thứ như thư mục gốc hoặc thư mục chính của dự án, là những thứ mà ngay cả các ứng dụng có luồng nặng đều chạm vào cùng một lúc và điều đó không được phân phối đối với bất kỳ loại hành vi trên mỗi luồng).
Vì vậy, nó không chỉ là “tốt hơn”, mà là “Tốt hơn” với chữ ‘T’ viết hoa. Không có gì khác ngoài đó đến gần. Dcache Linux chỉ đơn giản là trong một lớp riêng của nó.
Jeremy Andrews: Năm qua thật khó khăn trên toàn thế giới. Đại dịch COVID-19 đã ảnh hưởng đến quá trình phát triển kernal như thế nào?
Linus Torvalds: Nó thực sự chỉ có ảnh hưởng rất nhỏ, bởi vì cái cách mà chúng tôi luôn làm việc lâu nay. Email thực sự trở thành một công cụ tuyệt vời và chúng tôi không dựa vào các cuộc gặp mặt trực tiếp.
Vâng, nó đã ảnh hưởng đến hội nghị thượng đỉnh hạt nhân(yearly kernel summit) hàng năm vào năm ngoái (và năm nay vẫn đang diễn ra), và hầu hết các hội nghị đã bị hủy hoặc biến thành ảo. Và những người làm việc trong văn phòng trước đây chủ yếu bắt đầu làm việc tại nhà (nhưng rất nhiều người bảo trì nhân lõi (core kernel) đã làm như vậy trước giờ). Vì vậy, rất nhiều thứ xung quanh nó đã thay đổi, nhưng bản thân sự phát triển cốt lõi vẫn hoạt động chính xác như trước đây.
Và rõ ràng là nó đã ảnh hưởng đến tất cả cuộc sống của chúng ta theo những cách khác – chỉ là sự phân chia xã hội nói chung. Nhưng nhìn chung, là một nhà phát triển kernel đã tương tác với mọi người gần như hoàn toàn qua email, chúng tôi có lẽ là một số người ít bị ảnh hưởng nhất.
Hệ thống quản lý mã nguồn phân tán Git
Jeremy Andrews: Linux chỉ là một trong những đóng góp phổ biến của anh cho nguồn mở. Vào năm 2005, anh cũng đã tạo ra Git, hệ thống quản lý mã nguồn phân tán cực kỳ phổ biến. Anh đã nhanh chóng chuyển cây nguồn nhân Linux (Linux kernel source tree) ra khỏi Bitkeeper độc quyền sang Git, đồng thời trao quyền bảo trì cho Junio Hamano trong cùng năm đó. Có rất nhiều điều hấp dẫn ở đó, điều gì đã khiến anh đạt được vị trí lãnh đạo trong dự án này một cách nhanh chóng như vậy, và anh đã tìm và chọn Junio như thế nào?
Linus Torvalds: Vậy câu trả lời này có hai phần.
Phần đầu tiên là tôi không muốn tạo một hệ thống kiểm soát nguồn mới. Linux được tạo ra bởi vì tôi thấy giao diện cấp thấp giữa phần cứng và phần mềm rất hấp dẫn – về cơ bản nó là sự lao động của tình yêu và sở thích cá nhân. Ngược lại, Git được tạo ra không cần thiết: không phải vì tôi thấy kiểm soát mã nguồn là điều thú vị, mà bởi vì tôi hoàn toàn coi thường hầu hết các hệ thống kiểm soát mã nguồn ngoài kia, và hệ thống mà tôi thấy ổn nhất và thực sự hoạt động khá tốt trong mô hình phát triển Linux ( BitKeeper) đã trở nên không thể kiểm soát được.
Kết quả cuối cùng: Tôi đã làm Linux hơn 30 năm (còn vài tháng nữa mới đến ngày kỷ niệm phát hành bản đầu tiên, nhưng tôi đã bắt đầu với thứ sẽ trở thành Linux từ 30 năm trước) và tôi đã duy trì nó toàn bộ thời gian. Nhưng Git? Tôi không bao giờ nghĩ rằng tôi thực sự muốn duy trì nó lâu dài. Tôi thích sử dụng nó và rõ ràng tôi nghĩ đó là SCM (source code management) tốt nhất hiện có với số lượng lớn, nhưng đó không phải là niềm đam mê và sở thích cơ bản của tôi, nếu bạn thấy những gì tôi đang cố gắng nói.
Vì vậy, tôi luôn muốn ai đó khác duy trì SCM cho tôi – thực tế là tôi sẽ cảm thấy hạnh phúc nhất nếu ngay từ đầu tôi đã không phải viết.
Đó là nền tảng ban đầu
Đối với Junio - anh ấy thực sự là một trong những người đầu tiên trở thành nhà phát triển Git. Sự thay đổi đầu tiên của anh ấy đến trong vài ngày sau khi tôi công khai phiên bản Git đầu tiên (và rất sơ sài). Vì vậy, Junio thực sự đã xuất hiện kể từ khi bắt đầu có Git.
Nhưng không phải tôi đã giao dự án cho người ngẫu nhiên đầu tiên xuất hiện. Tôi đã duy trì Git trong một vài tháng, và điều khiến tôi hỏi Junio liệu anh ấy có muốn trở thành người duy trì hay không là khái niệm rất khó diễn tả về “đúng gu”. Tôi thực sự không có mô tả tốt hơn cho nó: lập trình là giải quyết các vấn đề kỹ thuật, nhưng cách bạn giải quyết chúng và cách bạn nghĩ về chúng cũng rất quan trọng, và đó là một trong những điều bạn bắt đầu nhận ra theo thời gian: một số người có điều đó “ngon” và chọn giải pháp “đúng”.
Tôi không muốn khẳng định rằng lập trình là một nghệ thuật, bởi vì nó thực sự chỉ là về “kỹ thuật tốt”. Tôi rất tin tưởng vào câu thần chú “một phần trăm cảm hứng và chín mươi chín phần trăm mồ hôi” của Thomas Edison: nó gần như là tất cả về những chi tiết nhỏ và công việc càu nhàu hàng ngày. Nhưng có một phần “cảm hứng” không thường xuyên, điều “ngon” đó không chỉ là giải quyết một số vấn đề – giải quyết nó một cách sạch sẽ và độc đáo và có, thậm chí là đẹp đẽ.
Và Junio đã có được cái “ngon” đó.
Và mỗi khi Git xuất hiện, tôi cố gắng nhớ thực sự làm cho nó rất rõ ràng: Tôi có thể đã bắt đầu và thiết kế những ý tưởng cốt lõi trong Git, nhưng tôi thường nhận được quá nhiều tín dụng cho phần đó. Đã hơn 15 năm trôi qua và tôi chỉ thực sự tham gia với Git trong năm đầu tiên đó. Junio là một người bảo trì gương mẫu và anh ấy là người đã tạo nên Git như ngày hôm nay.
Nhân tiện, toàn bộ điều “ngon” này và tìm những người có nó, và tin tưởng họ – đó rất nhiều không chỉ về Git. Đó cũng là lịch sử của Linux. Không giống như Git, Linux rõ ràng là một dự án mà tôi vẫn tích cực duy trì, nhưng rất giống Git, nó cũng là một dự án có rất nhiều người khác tham gia và tôi nghĩ một trong những thành công lớn của Linux là có hàng trăm người bảo trì xung quanh, tất cả với “hương vị ngon” khó định nghĩa, và tất cả những người duy trì các bộ phận của kernal.
Jeremy Andrews: Anh đã bao giờ chỉ giao quyền kiểm soát cho người bảo trì để sau đó xác định đó là quyết định sai lầm chưa?
Linus Torvalds: Cấu trúc bảo trì của chúng tôi chưa bao giờ đen trắng và không linh hoạt đến mức có thể là một vấn đề. Trên thực tế, nó không giống như chúng tôi thậm chí làm cho việc kiểm soát bảo trì trở thành một thứ gì đó rất được ghi chép lại: chúng tôi có một tập tin MAINTAINERS, nhưng đó là để bạn có thể tìm đúng người, nó không thực sự là dấu hiệu của một số quyền sở hữu độc quyền.
Vì vậy, toàn bộ “ai sở hữu cái gì” là một hướng dẫn linh hoạt hơn và “người này đang hoạt động và đang làm tốt” hơn một số “rất tiếc, bây giờ chúng tôi đã cho người đó quyền sở hữu và sau đó anh ta bị hỏng”.
Và nó cũng linh hoạt theo nghĩa có thể bạn là người duy trì một hệ thống con, nhưng nếu có thứ gì đó bạn cần từ một hệ thống con khác, bạn thường có thể vượt qua biên giới. Tất nhiên, đó là điều mà mọi người nói nhiều trước khi thực hiện, nhưng vấn đề là nó xảy ra và không khó “bạn chỉ được phép chạm vào tập tin đó”.
Trên thực tế, điều này thực sự có liên quan phần nào đến cuộc thảo luận trước đó về việc cấp phép, và một ví dụ khác về cách một trong những nguyên tắc thiết kế của “Git” là toàn bộ “mọi người đều có cây của riêng mình và không có cây nào là đặc biệt về mặt kỹ thuật”.
Bởi vì rất nhiều dự án khác đã sử dụng công cụ – như CVS hoặc SVN – về cơ bản, điều đó làm cho một số người trở nên đặc biệt, và về cơ bản điều đó có “quyền sở hữu” đi cùng với nó. Trong thế giới BSD, họ gọi nó là commit bit (bit cam kết): cung cấp cho người bảo trì “commit bit” có nghĩa là bây giờ anh ta được phép commit với kho lưu trữ trung tâm (hoặc ít nhất là các phần của nó).
Tôi luôn chán ghét mô hình đó, bởi vì nó chắc chắn dẫn đến kết quả chính trị và mô hình phát triển “bè phái”, nơi một số người đặc biệt và được ngầm tin tưởng. Và vấn đề thậm chí không phải là phần “được tin tưởng ngầm” – nó thực sự là mặt khác của đồng tiền là những người khác không được tin tưởng, và theo định nghĩa là những người ngoài cuộc và phải thông qua một trong những người bảo vệ.
Một lần nữa, trong Git tình huống đó không tồn tại. Mọi người đều bình đẳng. Bất kỳ ai cũng có thể nhân bản, tự phát triển và nếu họ làm tốt công việc của mình, họ có thể được hợp nhất trở lại (và nếu họ làm một công việc xuất sắc, họ trở thành người bảo trì, và cuối cùng họ trở thành người hợp nhất vào cây của họ; ).
Vì vậy, không cần phải cho mọi người đặc quyền đặc biệt – không cần “commit bit” đó. Và điều đó cũng có nghĩa là bạn tránh các chính trị xung quanh nó, và bạn không cần phải ngầm tin tưởng mọi người. Nếu cuối cùng họ hoàn thành một công việc tồi tệ – hoặc thông thường hơn, chỉ kết thúc việc và tìm kiếm một mối quan tâm khác – họ sẽ không hòa nhập trở lại và họ cũng không cản đường những người khác có những ý tưởng mới mẻ.
Jeremy Andrews: Các tính năng mới của Git có bao giờ gây ấn tượng với anh và trở thành một phần trong quy trình làm việc của anh không? Có những tính năng nào anh vẫn muốn thấy được thêm vào không?
Linus Torvalds: Các ca sử dụng của tôi rõ ràng là những ca sử dụng đầu tiên được thực hiện, vì vậy đối với tôi, hiếm khi là về các tính năng mới.
Trong những năm qua, Git chắc chắn đã được cải thiện và một số trong số đó cũng đáng chú ý trong quy trình làm việc của tôi. Ví dụ, Git luôn hoạt động khá nhanh – đó là một trong những mục tiêu thiết kế của tôi – nhưng phần lớn nó ban đầu được thực hiện dưới dạng shell-script xung quanh một số chương trình trợ giúp cốt lõi. Trong những năm qua, hầu hết kịch bản shell đó đã biến mất, và điều đó có nghĩa là tôi có thể áp dụng patch-bombs từ Andrew Morton thậm chí còn nhanh hơn tôi có thể làm trước đây. Điều này rất hài lòng, vì đó thực sự là một trong những điểm chuẩn ban đầu mà tôi đã sử dụng để kiểm tra hiệu suất.
Vì vậy, Git luôn tốt cho tôi, nhưng nó đã trở nên tốt hơn.
Những cải tiến lớn về việc nó đã trở nên tốt hơn nhiều như thế nào khi sử dụng như một “người dùng thông thường”. Rất nhiều người trong số đó đã học quy trình làm việc của Git và chỉ làm quen với nó (nó rất khác so với CVS và những thứ khác mà mọi người đã từng làm), nhưng phần lớn trong số đó là bản thân Git đã trở nên dễ chịu hơn rất nhiều. để sử dụng.
Kết luận, Phần một
Trong phần thứ hai của cuộc phỏng vấn, Linus nói về những gì anh ấy học được từ việc quản lý một dự án mã nguồn mở lớn. Anh ấy cung cấp nhiều thông tin chi tiết và lời khuyên cho những người bảo trì về những gì anh ấy thấy phù hợp nhất và cách anh ấy tránh bị kiệt sức. Anh ấy cũng nói về Linux Foundation và những gì anh ấy làm khi không tập trung vào việc phát triển nhân Linux.
Xem phần 2 của cuộc phỏng vấn với Linus Torvalds tại đây
