Dave Cutler giải thích về Windows [Video]
(youtube.com)- Dave Cutler hồi tưởng về bối cảnh thiết kế của Windows NT và văn hóa phát triển tại Microsoft, dựa trên kinh nghiệm kéo dài từ RSX-11, VMS, Windows NT đến Azure và Xbox
- Ngay từ đầu, Windows NT đã hướng tới mục tiêu trở thành hệ điều hành có thể port được và hỗ trợ nhiều môi trường thực thi; khi Windows 3.1 bán được 16 triệu bản trong 6 tháng, Windows đã trở thành môi trường trung tâm thay cho OS/2
- NT thời kỳ đầu xử lý nhiều kiến trúc như i860, MIPS, x86, Alpha, PowerPC cùng HAL, object manager, cấu trúc kernel/driver, và phần lớn cấu trúc cốt lõi vẫn còn tồn tại trong Windows 11
- VMS khi phát hành đặt mục tiêu 0 lỗi đã biết, còn đội ngũ phát triển NT duy trì sự gắn kết bằng Friday WHIM, nhưng ở các giai đoạn NT·Cairo·Longhorn·ứng phó bảo mật cho XP thì lịch trình, chất lượng và việc phân nhánh codebase trở thành gánh nặng lớn
- Cutler xem việc sửa lỗi, kiểm thử, đảm bảo chất lượng và sự tiết chế không thêm tính năng không cần thiết là những thái độ cốt lõi của một đội phần mềm giỏi
Sự nghiệp hệ điều hành trước Windows NT
- Dave Cutler sau khi tiếp xúc với các hệ thống thời gian thực và mô phỏng máy tính tại DuPont đã dần hứng thú nhiều hơn với bản thân máy tính hơn là với công cụ giải quyết vấn đề
- Trong dự án mô phỏng quy trình sản xuất giấy dạng form của Scott Paper bằng GPSS 3, ông gặp lỗi thẻ đục và phải debug
- Để giảm lỗi, ông viết chương trình Fortran, rồi sau đó còn học cả assembly của IBM 7044 và mở rộng sự quan tâm tới cách máy tính vận hành bên trong
- Tại nhóm hệ thống thời gian thực của DuPont, ông viết chương trình tự động phân tích dữ liệu thử kéo Instron
- Chương trình thu thập dữ liệu chạy theo thời gian thực và đọc dữ liệu theo đơn vị 1 mili giây hoặc 100 mili giây
- Sau đó ông phụ trách công việc trên hệ điều hành Exec II của Univac 1107 và chính thức bước vào phát triển hệ điều hành
- Mỗi ngày sau 5 giờ chiều, ông cho operator về và chạy mã thử nghiệm cùng kiểm thử trong 2 giờ
- Trong môi trường hầu như không có debugger, ông debug bằng switch và
halt instruction
Thời DEC: RSX, VMS, compiler, PRISM
- Tại Digital Equipment Corporation, ban đầu ông được tuyển để làm OS/45 nhưng nhanh chóng chuyển sang RSX-11C
- Theo Cutler, không gian địa chỉ 16 bit của PDP-11 là một hạn chế lớn
- RSX-11C là một hệ thống nhỏ và ông đánh giá là khá hạn chế về tính năng ngay cả theo tiêu chuẩn thời đó
- Việc phát triển VMS được bootstrap nhờ phần cứng VAX và một lớp thực thi tương thích PDP-11
- VAX có chế độ PDP-11, và với lớp Application Migration Executive có thể chạy các tiện ích RSX-11M
- Hệ thống tệp Files-11 cũng được hiện thực lại trên VMS để giữ khả năng tương thích
- Giai đoạn đầu phát triển, các công việc cốt lõi như scheduling và quản lý bộ nhớ được thực hiện trên bộ giả lập phần cứng
- VMS dùng tự host như một phương tiện đảm bảo chất lượng
- Khi Proto 3 đã chạy đủ ổn định, chính đội phát triển làm việc trực tiếp trên hệ thống đó
- Khi hệ thống phát
bug check, vài người sẽ chạy tới máy, tìm nguyên nhân bằng debugger, sửa xong rồi khởi động lại
- Cutler hồi tưởng rằng khi phát hành, VMS có “0 lỗi đã biết”
- Điều đó không có nghĩa là “không có lỗi”, mà là họ cố sửa hết mọi lỗi mình biết tại thời điểm phát hành
- Ngay cả vào phút cuối, họ vẫn sửa một
race conditiontrong disk driver
- Sau VMS, ông còn tham gia PL/I compiler, backend của C compiler, code generator, tối ưu hóa và phân bổ thanh ghi
- Frontend của PL/I được mua từ một công ty ở Boston, còn backend được phát triển trên VAX
- Một phần công việc frontend được thực hiện trên Multics của MIT rồi chuyển dữ liệu bằng băng từ
- Tại DEC West, ông tham gia hệ thống thời gian thực Velon và dự án MicroVAX
- Velon là một hệ thống thử nghiệm các ý tưởng như driver ở user mode, kiến trúc hướng thông điệp, multithreading và multiprocessor
- Ở MicroVAX 1, Cutler viết toàn bộ microcode
- Dự án PRISM là nỗ lực kiến trúc RISC của DEC, và ngay ngày hôm sau khi nó bị hủy, Cutler quyết định rời công ty
- PRISM có cả phiên bản kiến trúc 32 bit và 64 bit, đồng thời còn có hệ thống phần mềm đầy tham vọng tên là Micah
- Sau khi PRISM bị hủy, ông định lập công ty server, nhưng hướng đi đã thay đổi sau khi tiếp xúc với Microsoft
Gia nhập Microsoft và thiết kế Windows NT
- Việc gia nhập Microsoft không hoàn toàn chắc chắn ngay cả sau cuộc trò chuyện với Bill Gates, nhưng được quyết định rất nhanh sau bữa sáng ở Denny’s với Steve Ballmer
- Cutler xem Ballmer là người then chốt đã thuyết phục ông gia nhập Microsoft
- Mục tiêu ban đầu của NT là một hệ điều hành portable và hỗ trợ nhiều môi trường thực thi
- Môi trường mục tiêu khi đó là OS/2, và POSIX cũng là một ứng viên quan trọng
- Ý tưởng ban đầu là phần lõi của hệ thống cung cấp các dịch vụ cơ bản, còn phía trên có thể đặt nhiều môi trường khác nhau
- Lý do Windows trở thành môi trường trung tâm của NT là thành công của Windows 3.1
- Windows 3.1 bán được 16 triệu bản trong 6 tháng, và Bill Gates nhận định Windows sẽ là môi trường chính của hệ thống mới
- Việc phát triển NT cũng từng được thực hiện trên OS/2, nhưng nhóm rất muốn nhanh chóng tự host trên chính NT
- Tên NT mang nghĩa “New Technology”
- Có thể từng tồn tại một liên hệ mơ hồ giữa codename N10 của i860 và NT, nhưng Cutler xem NT là New Technology
- Phía marketing phản đối vì cho rằng cái tên “công nghệ mới” có thể khiến người mua e ngại, nhưng Cutler đã kiên quyết giữ tên NT
- Phiên bản NT đầu tiên hỗ trợ nhiều kiến trúc CPU
- Bài nói có nhắc tới x86, MIPS R3000/R4000 và Alpha
- PowerPC được thêm vào ở giai đoạn NT 3.5 hoặc Daytona, và Cutler đánh giá cả bản build lẫn năng lực phần cứng PowerPC đều không tốt
- HAL của NT ban đầu gần với lớp trừu tượng hóa nhà cung cấp hơn là chỉ lớp trừu tượng hóa phần cứng
- Ban đầu nó được cấu thành như các DLL riêng để nhà cung cấp có thể cung cấp HAL
- Về sau Cutler cho rằng sẽ tốt hơn nếu build HAL như một phần của hệ điều hành
- Trong kernel và HAL của NT không có quá nhiều assembly
- Một số phép toán chạy thường xuyên vì lý do hiệu năng vẫn cần assembly hoặc intrinsic
- Trên x64, hướng đi được chọn là dùng intrinsic thay vì inline assembly
Văn hóa phát triển NT, Cairo, Longhorn, bảo mật XP
- Đội NT tổ chức WHIM vào mỗi thứ Sáu để gắn kết một tổ chức đang tăng trưởng rất nhanh
- WHIM là viết tắt của Weekly Integration Meeting
- Ban đầu các quản lý mua bia và snack ở Safeway rồi tổ chức trong phòng thí nghiệm phần cứng, về sau mở rộng sang không gian lớn hơn với catering
- Cutler cho rằng cách mô tả NT như một nơi chỉ liên tục vắt kiệt con người là không đúng sự thật, và họ cố tạo ra cơ hội để mọi người xả căng thẳng mỗi tuần
- Sau NT 3.5, luồng đưa giao diện Windows 95 sang NT diễn ra song song với dự án Cairo
- Tuckwila được duy trì như một dạng NT 4.0 dự phòng; trong các bản build hằng ngày Tuckwila chạy ổn định còn Cairo thì thường xuyên hỏng
- Dần dần các tính năng của Cairo bị loại bỏ, và theo ký ức của Cutler thì kết quả port chính còn lại chủ yếu là phần mềm file server và Kerberos
- NT 4.0 vẫn là một phiên bản cực kỳ được ưa chuộng, và Cutler nói ông từng gặp người vẫn còn dùng NT 4.0
- Lịch trình của NT 3.1 còn kéo dài hơn cả VMS
- Theo ông, VMS được xây trong 2 năm bởi một đội khoảng 20 người cực kỳ xuất sắc
- NT phải làm nhiều việc hơn, và phạm vi còn mở rộng do bỏ i860 rồi thêm MIPS, x86, Alpha cùng nhiều kiến trúc khác
- Trong giai đoạn dẫn tới Longhorn và Vista, việc tách codebase trở thành một vấn đề lớn
- Sau Windows 2000, codebase server và workstation bị tách ra; trong khi phía server sửa rất nhiều vấn đề bảo mật thì phía tiêu dùng lại ngày càng bất ổn trong build và chạy
- XP rất thành công nhưng có nhiều lỗi, và khi các vấn đề bảo mật bùng lên thì rất nhiều công sức đã phải đổ vào sửa lỗi cho XP
- Nhóm của Cutler đã sửa khoảng 5.000 lỗi bảo mật liên quan tới XP
- Phần mở rộng x64 của AMD là một bước ngoặt quan trọng bên trong Microsoft
- AMD đề xuất ý tưởng mở rộng 64 bit ít xâm lấn hơn nhưng vẫn chạy nhanh các ứng dụng 32 bit
- Cutler quyết định xây workstation và server 64 bit dựa trên codebase server, và đây ban đầu không phải là dự án được công ty chính thức phê duyệt
- Khi hệ thống AMD tới nơi, họ boot lần đầu từ CD và hệ thống 64 bit lập tức khởi động, chạy được ngay
microsoft.comsau khoảng một tuần thử nghiệm đã chuyển sang server 64 bit, và được đánh giá là ổn định hơn rất nhiều so với hệ thống 32 bit
- Cuối cùng Longhorn được chuyển sang codebase x64, và chính codebase đó tiếp tục được dùng cho tới hiện nay
Cấu trúc nội bộ của Windows và phần mã còn tồn tại tới nay
- Trong Windows 11 vẫn còn rất nhiều chức năng và cấu trúc cốt lõi từ thời NT 3.5
- Các phần như mã kernel, cấu trúc quản lý bộ nhớ, cấu trúc tiến trình và object manager vẫn được duy trì
- Tỷ lệ mã gốc trong toàn bộ codebase có thể ngày càng giảm, nhưng các cấu trúc cốt lõi thực hiện cùng chức năng thì phần lớn vẫn còn
- Cutler xem object manager của NT là một lý do quan trọng khiến codebase này tốt
- Khác với cách tiếp cận “mọi thứ đều là tệp” của Unix, trong NT có thể tạo bộ mô tả kiểu đối tượng mới, tích hợp vào object manager và thêm các đối tượng hệ điều hành mới
- Đối tượng có thể cung cấp các chức năng như đồng bộ hóa và kiểm soát truy cập
handle tablelà phần quan trọng về hiệu năng nên đã nhiều lần được viết lạihandle translationthực sự là một vấn đề hiệu năng- Cutler lấy ví dụ hệ thống làm việc của ông có khoảng 60 tiến trình, hàng trăm luồng và 150.000
handleđang mở
- Sự phình to của Task Manager được nhắc tới như một ví dụ của code bloat
- Ban đầu Task Manager được biên dịch thành 85KB, còn hiện nay là 4MB
- Dù bây giờ nó hiển thị nhiều thông tin hơn như CPU, mạng và đĩa, Cutler không cho rằng mức tăng tính năng tương xứng với mức tăng kích thước
- Quyết định chuyển graphics driver từ user mode sang kernel mode là cần thiết về hiệu năng nhưng đi kèm nhiều đau đớn trong giai đoạn đầu
- Ban đầu Cutler phản đối việc chuyển sang kernel mode
- User mode và kernel mode có mô hình đồng bộ khác nhau nên đây không phải chuyện chỉ đơn giản dời mã; thêm vào đó còn có gánh nặng từ các cấu trúc dữ liệu và primitive 16 bit
- Về sau độ tin cậy được cải thiện rất nhiều, nhưng đã từng có thời kỳ đầy rẫy vấn đề với graphics driver của các vendor
Azure, Xbox, xCloud
- Sau khi xuất xưởng hệ thống x64, Cutler chán nản vì vấn đề fcib và từng nói sẽ rời Microsoft; sau một kỳ nghỉ theo lời khuyên của Steve Ballmer, ông quay lại vào tháng 11 năm 2005
fciblà viết tắt của checked-in binary; việc một số nhóm check in binary thay vì source khiến việc port trở nên khó khăn
- Sau đó ông tham gia dự án Azure giai đoạn đầu
- Ray Ozzie khởi động dự án khi nhận ra các dịch vụ dựa trên cloud khác nhau không có hạ tầng dùng chung
- Azure thời kỳ đầu nhắm tới hạ tầng nền tảng như triển khai ứng dụng, kiểm soát cấu hình, quản lý phiên bản, khởi động lại, tính phí và hệ thống tệp cloud
- Ông giải thích rằng AWS khi đó chủ yếu cung cấp hạ tầng, còn Microsoft ban đầu muốn bán dịch vụ nền tảng
- Hypervisor đầu tiên của Azure được xây trên công nghệ đến từ thương vụ mua lại Connectix
- Connectix có các sản phẩm Virtual PC và Virtual Server, đồng thời công việc phát triển hypervisor cũng đang ở giai đoạn đầu
- Về sau hypervisor của Xbox bắt nguồn từ hypervisor Red Dog của Azure
- Xbox hoạt động với cấu trúc ba VM
host systemsở hữu toàn bộ thiết bị và đóng vai trò traffic cop cho giao tiếp giữa các VMpresentation VMphụ trách window manager và hệ thống hiển thị, luôn chạy liên tụcgame VMđược khởi động và dừng theo từng trò chơi, và game được đóng gói cùng với OS
- Cấu trúc game được đóng gói cùng OS có lợi cho khả năng tương thích ngược
- Nhà phát triển game đóng gói game cùng OS của GDK, và khi chạy thì VM tương ứng cũng được khởi động cùng
- Cách này tránh việc thay đổi hệ điều hành làm hỏng các game cũ
- Tuy nhiên khi cần đưa tính năng mới vào các game cũ, phải dùng những cách vòng như universal game OS
- Tính năng pause/resume của Xbox hoạt động theo cách lưu và khôi phục VM
- Việc tải game liên quan tới dữ liệu ở mức hàng gigabyte nên mất nhiều thời gian
- pause/resume là chức năng lưu trạng thái VM rồi khôi phục lại sau đó
- Công việc hiện tại được nhắc tới là Linux VM và graphics stack tận dụng thời gian rảnh của console xCloud
- xCloud có cấu trúc đưa các Xbox console vào rack trong datacenter và cung cấp truy cập từ xa
- Console là
single tenantnên mỗi lần chỉ một người dùng và sẽ có thời gian nhàn rỗi - Để chạy các workload machine learning nội bộ của Microsoft trong thời gian không sử dụng, họ đang làm việc trên Linux VM, hypervisor của Xbox và graphics stack
Chất lượng, vận hành đội ngũ, triết lý phát triển
- Cutler áp dụng câu “người thành công làm những việc mà người thất bại từ chối làm” cho cả các đội phần mềm
- Ông xem các thái độ như đã viết code thì không test, còn thời gian nhưng đúng 5 giờ chiều là về, hay không muốn sửa lỗi của chính mình đều là vấn đề
- Ông coi trọng thái độ tự mình làm những việc cần làm để dẫn tới thành công
- Ông đánh giá cao kiểu người “thinker-doer”
- Trích lời Brooks, ông nói có nhiều người chỉ biết nghĩ, ít người thực sự làm, và càng hiếm hơn những người làm được cả hai
- Theo ông, kiến trúc sư cũng phải tạo ra kết quả thực tế sao cho đáp ứng mục tiêu và ràng buộc
- Ông từng muốn treo câu “Nếu không đưa vào thì cũng không cần phải lấy ra” lên tường phòng thí nghiệm ở University of Washington
- Câu này được dùng để nhấn mạnh sự tiết chế trong việc không thêm các tính năng không cần thiết
- Trong môi trường phát triển thời kỳ đầu, công cụ debug rất nghèo nàn nên thái độ giảm sai sót ngay từ đầu là rất quan trọng
- Trước đây đôi khi còn phải dùng tới logic analyzer hay oscilloscope
- Theo ông, ngày nay công cụ đã có nhiều tính năng giúp giảm sai sót nhỏ, nhưng áp lực về chất lượng không còn giống như trước
- Ông cho rằng multitasking là có thể, nhưng năng suất cao nhất đến từ việc tập trung vào một việc duy nhất
- Vì
context switchtốn thời gian - Tuy vậy, ông cũng nói vẫn sẽ chuyển việc để giúp người khác tháo gỡ vấn đề bị kẹt hoặc sửa lỗi
- Vì
1 bình luận
Các ý kiến trên Hacker News
Người phỏng vấn, Dave Plummer, bản thân cũng là một nhân vật cực kỳ thú vị. Tôi đặc biệt thích các video lập trình hoài cổ như https://www.youtube.com/watch?v=JlZe2JwrJqM và https://www.youtube.com/watch?v=b0zxIfJJLAY
Video vừa vui, nhạc nền và đèn RGB còn tạo cảm giác Giáng sinh. Nó cũng khiến Microsoft hiện lên hoàn toàn khác với hình ảnh mà tôi vốn quen thuộc; anh ấy thừa nhận những điểm kỳ quặc ở Redmond nhưng vẫn nói về công việc, đồng nghiệp và Microsoft một cách ấm áp
Tuy nhiên, xem kênh này dường như kích hoạt thuật toán YouTube theo cách nào đó, khiến feed đề xuất của tôi tràn ngập video về ADHD. Có lẽ là do các video liên quan đến tự kỷ và ADHD, nhưng tôi nghĩ YouTube phải đủ thông minh để nhận ra rằng tôi chỉ xem các video về lập trình và lịch sử Microsoft chứ
Dù không muốn nói điều này, nhưng nên rất dè dặt với những gì anh ấy nói về các chủ đề ngoài Microsoft/Windows. Đặc biệt là sau bình luận bên dưới [1]
Việc gần đây họ ép tắt trình chặn quảng cáo cũng khiến tôi mở mắt. Quảng cáo trên YouTube thật sự tệ hại, đến mức nghĩ rằng có người thật sự phản hồi với chúng thôi cũng thấy ngượng. Có vẻ YouTube đã từ bỏ cả việc giả vờ rằng họ muốn mang lại trải nghiệm người dùng tốt
Dù vậy, để xem được những thứ xuất sắc như cuộc phỏng vấn Dave Cutler này thì cũng đáng bới qua một ít bùn lầy
Không đùa đâu, và cách nói “một nửa” cũng khá chính xác. Hoặc là có gì đó bị hỏng, hoặc YouTube đã gắn một mô hình ngôn ngữ lớn vào công cụ đề xuất của họ
Tôi thích xem anh ấy nói ứng biến hơn là xem các video được biên tập kỹ
Chỉ sau đúng một video đó, đề xuất của tôi đã đầy những chuyện về ung thư, những người sắp qua đời và đủ loại bệnh tật. Video đó hoàn toàn không liên quan gì đến nội dung thường ngày của người ấy, và tôi cũng chẳng xem video đề xuất nào kiểu đó, vậy mà chúng cứ liên tục được đẩy tới
Tôi chưa xem video này, nhưng vài năm trước đã đọc Showstopper[1] nên đang rất mong chờ
Điều đặc biệt còn đọng lại với tôi, nhất là vào thời đầu tuổi 20 khi tôi luôn nghĩ mình phải làm việc, là đoạn Dave luôn nghỉ phép đúng lúc, lần nào cũng vậy, không tranh cãi
Có thể bạn không thích Microsoft, nhưng đó có lẽ là lần đầu tôi thật sự thấy một người cực kỳ giỏi và đủ tư cách mà không bị vắt kiệt 24/24
Ngay cả viết ra thế này tôi vẫn thấy hơi lạ, nhưng đó là lối nghĩ kế thừa từ văn hóa nông thôn và bán lẻ kiểu “càng khổ càng có đức”
Đến giờ nghỉ ngơi cho đúng vẫn khó, và rất dễ trì hoãn vì X hay Y quan trọng hơn. Nhưng nhớ lại góc nhìn của Dave là một lời nhắc tốt rằng nghỉ ngơi và làm tốt X không phải là lựa chọn loại trừ nhau
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
“Hãy nhớ ngày Sa-bát, để giữ làm ngày thánh… Ngươi hãy lao động và làm mọi công việc mình trong sáu ngày; nhưng ngày thứ bảy là ngày Sa-bát của Giê-hô-va Đức Chúa Trời ngươi…”
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
Nhân viên càng “chúi mũi vào đá mài” và “còng lưng” làm việc thì lợi nhuận công ty càng tăng, nhưng không cần phải trả lương cao hơn. Khi sức khỏe họ hỏng đủ mức để không làm việc được nữa thì chỉ việc thay người
Xin lỗi vì câu trả lời viết khuya nên hơi thô, nhưng tôi nghĩ mọi người ở đây dù sao cũng hiểu bằng trực giác
Rồi tôi bị burnout, và giờ tôi xem việc nghỉ ngơi cũng như giữ ngày làm việc 8 tiếng, trừ tình huống khẩn cấp thật sự, không chỉ là trách nhiệm cá nhân mà còn là trách nhiệm nghề nghiệp. Vì nó giảm nguy cơ burnout, mà burnout thì đúng nghĩa là có hại cho tất cả mọi người
Tôi từng đọc một bài nói rằng vào giai đoạn cuối phát triển WinNT 3.1, có ai đó đã làm một trình bảo vệ màn hình hiển thị màn hình xanh. Có lẽ là trên Usenet
Trước đó tôi chưa từng làm trình bảo vệ màn hình, nhưng do lỗi driver mạng nội bộ của Microsoft, tôi có thể khiến máy phát triển WinNT của mình blue screen một cách ổn định
Thế là tôi đọc tài liệu viết trình bảo vệ màn hình Windows, ghi lại các giá trị hiển thị trên màn hình xanh của mình, rồi làm qua loa trình bảo vệ màn hình Windows đầu tiên và cũng là cuối cùng của tôi
Cho vui, tôi gửi mail cho nhóm Windows NT để báo về thứ mình làm, và vài tuần sau nhóm build NT quyết định chơi khăm Dave Cutler
Họ cài trình bảo vệ màn hình màn hình xanh của tôi lên một máy chủ build, rút cả chuột lẫn bàn phím ra rồi chờ
Dave Cutler đến xem trạng thái bản build NT mới nhất, bật màn hình lên và thấy màn hình xanh. Ông di chuột nhưng không có phản ứng, gõ bàn phím cũng không có phản ứng
Rồi chuyện ngoài dự đoán xảy ra. Ông với tay nhấn nút nguồn của máy chủ build để khởi động lại. NOOOOOOOOOOOOOOOOOOOOO
Tôi rốt cuộc không bao giờ nghe được dư âm hay hậu quả của trò đùa đó. Quyền lực lớn đi kèm trách nhiệm lớn
Tôi cũng cài nó, và vài đồng nghiệp ngồi quanh tôi cũng cài cùng thứ đó
CTO ghé qua vì một cuộc họp sáng sớm, thấy màn hình nào cũng hiện thứ đó và hơi hoảng, tưởng là virus đang lây lan hoặc lỗi phần mềm
Tôi cũng muốn giới thiệu cuốn “Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft” mà vài tuần trước có người đã đề xuất
Tôi vẫn đang đọc, nhưng nó thật sự rất thú vị, và khiến tôi nghĩ giá mà mình cũng tham gia vào lịch sử đó. Đặc biệt là phần dogfooding một hệ điều hành hoàn toàn mới. Chỉ tiếc là sớm hơn thời của tôi vài năm
Nhờ cuốn đó, tôi nghe có vẻ am hiểu hơn nhiều so với thực tế, và hào hứng hơn hẳn với toàn bộ lĩnh vực ấy so với chỉ vài ngày trước
Tôi nhận được offer, nhưng cuối cùng không nhận công việc đó
Liên quan còn có bài này: https://blog.codinghorror.com/showstopper/
Phần khiến tôi thấy thú vị là hypervisor của Xbox không phải do phía desktop làm ra mà dựa trên Azure, và thay vì game Xbox phụ thuộc vào một hệ điều hành duy nhất trên thiết bị, chúng được đóng gói cùng với hệ điều hành, nên gần với container hơn một chút
Dave nói ông cũng đang làm việc để cho chạy các tác vụ machine learning trên các thiết bị Xbox Cloud Gaming đang nhàn rỗi. Tôi chưa từng nghĩ rằng giữa Azure và Xbox lại có mối liên kết về kiến trúc như vậy
Ví dụ, file thực thi của game thực ra được mã hóa trên đĩa game, và ngay cả việc dump binary thật đang chạy cũng gần như bất khả thi. RAM cũng được mã hóa
Ngoài ra, một trong những lý do TPM hiện đại được đưa vào bên trong CPU là để ngăn người ta sniff bus TPM như họ từng làm trên Xbox
Tôi từng làm trong đội kernel Windows, và câu chuyện tôi thích nhất về DC là ông ghét kiến trúc Itanium đến mức về cơ bản đã khiến x64 thành hiện thực
Ông làm việc cùng AMD và gần như tự mình thúc đẩy việc đó, liên tục gõ code trong văn phòng góc của mình
Ý tưởng là “gộp nhiều lệnh, đôi khi có độ dài bit thay đổi, vào một word, rồi để người viết compiler tìm ra nhóm lệnh tối ưu; như vậy phần triển khai sẽ đơn giản hơn và có thể nhanh hơn”, nhưng nếu compiler không tìm được nhóm tối ưu đó thì lại chậm hơn các thiết kế truyền thống như x86
Hẳn phải có một nhân vật rất cấp cao nào đó bên trong Intel thật sự mê ý tưởng này. Trong suốt lịch sử Intel với tư cách một hãng vi xử lý lớn, họ đã thử ba lần và thất bại cả ba
Khi đó tôi không xem AMD64 là ý tưởng hay, vì nó chỉ là “thêm những thứ giống cũ”. Dù vậy, việc Dave góp phần dọn bỏ đống hỗn tạp đã gần như giết chết cuộc cách mạng RISC là một việc tốt
Hy vọng một ngày nào đó tôi cũng có thể tạo ra thứ ấn tượng đến vậy trong thời gian rảnh
Đáng tiếc cho Microsoft, chiến lợi phẩm đó lại thuộc về Linux trên x86-64
Một trong những khoảnh khắc mang tính quyết định nhất trong sự nghiệp kỹ sư phần mềm của tôi là khoảng 6–7 năm trước, khi tôi đọc mã nguồn NT bị rò rỉ đồng thời đọc Showstopper[1]
Bản rò rỉ NT đặc biệt cuốn hút vì nó bao gồm toàn bộ lịch sử tác giả, nên có thể thấy chính xác Dave Cutler đã làm việc trên những file nào. Cuốn sách cũng đi sâu vào những chuyện như quá trình các kernel module có section có thể phân trang, bản thân điều đó đã rất thú vị
Trong sách có cảnh Cutler bước vào và chỉnh sửa mạnh một routine assembly cụ thể, và trong mã nguồn thật bạn có thể thấy chính xác routine đó là gì
Code của Cutler là C code thật sự đẹp, và chắc chắn đến giờ vẫn vậy. Nó ảnh hưởng lớn đến cách tôi viết C code theo phong cách NT
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
Phỏng vấn lịch sử truyền miệng David Cutler của Computer History Museum cũng rất hay
Part 1: https://youtu.be/29RkHH-psrY
Part 2: https://youtu.be/SVgSLud50ss
Tôi đã xem vài đoạn của cuộc phỏng vấn mới, nhưng cho đến giờ vẫn chưa chắc có nghe được điều gì mới không
Nhìn lại những gì hai Dave đã nói, họ dành sự chú ý rất lớn cho việc hoàn thiện rồi phát hành, nhưng hầu như không nói gì về kế hoạch dài hạn hay chiến lược bảo mật thực tế
Tất cả đều là chuyện dưới áp lực thương mại, phải đẩy xúc xích ra khỏi máy xay thịt và giảm thất bại xuống mức có thể chấp nhận được
Cũng không có gì đáng ngạc nhiên khi toàn ngành không khá lên và không rẽ sang hướng đúng. Tôi từng nghĩ rồi sẽ có ngày chúng ta đạt tới bảo mật dựa trên capability, nhưng giờ có vẻ như sẽ mãi mắc kẹt với người họ hàng gần như vô giá trị của nó: các cờ quyền hạn của ứng dụng
Tôi lo cho tương lai
Chỉ cần một quý hoặc vài năm đủ tốt để biện minh cho việc thăng chức từ VP lên SVP, từ SVP lên CEO. Không ai quy trách nhiệm hay trừng phạt một người đã chuyển sang vai trò mới sau 3 năm vì những lựa chọn thiển cận họ đưa ra ở vai trò trước đó
Nói vậy không có nghĩa Cutler là kiểu lãnh đạo như thế. Chỉ là rõ ràng ông ấy chịu áp lực từ trên xuống về việc phát hành và duy trì dòng doanh thu. Như ông nói ở đầu buổi phỏng vấn, ông thật sự ghét việc xuất xưởng kèm bug, rất thất vọng về chất lượng của kỹ sư phần mềm trong ngành, và cũng cực kỳ ghét việc các quản lý chương trình/dự án coi mọi bug như một trường hợp góc hiếm gặp. Tôi đồng ý với cả ba điểm
Phần lớn bug tôi gửi lên cũng bị coi là “trường hợp góc”, nhưng tôi gặp vấn đề đó hằng ngày, và trong cơ sở dữ liệu đã có nhiều issue trùng lặp, hoặc bug của tôi lại bị đánh dấu trùng với một báo cáo sớm hơn
Tôi đã trải qua nhiều thập kỷ trong ngành này, toàn bộ đều ở Big Tech, và vẫn chưa thấy công ty nào không rốt cuộc khuất phục trước cùng một kiểu áp lực như vậy, dù các kỹ sư và quản lý tuyến đầu thúc đẩy sửa bug trước khi phát hành và yêu cầu các bản cập nhật sửa bug thường xuyên hơn
Đó là một điểm bán hàng lớn, nhưng lại không chạm tới phần lớn người dùng. Thực tế nhiều người cảm thấy “tại sao tôi cần thứ này?”, và nó khiến hệ điều hành trông như không dành cho “người dùng phổ thông”
Khái niệm bảo mật đầu thập niên 1990—điều gì tạo nên bảo mật và nó liên quan tới ai, ở mức nào—không phù hợp với kỳ vọng hay trình độ hiện đại ngày nay
Có thể sẽ mất một thời gian để làm cho đúng. Trong lúc đó, tôi hy vọng một phương án thay thế dựa trên runtime đơn nhất, nửa vời, thụt lùi và củng cố hiện trạng sẽ không thắng thế
[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
Đây có thể là sản phẩm kinh tế lớn nhất mà phần mềm đã “đóng góp” cho chúng ta. Một hợp đồng ràng buộc kiểu “chúng tôi sẽ nhận tiền, nhưng không hứa hẹn gì cả, đồ gà!”
Ngược lại, ra thị trường thứ hai thì bị trừng phạt
Tôi rất mong được nghe toàn bộ phần này
Bất kể cảm xúc với con người ông ấy hay công ty nơi ông ấy làm việc, Cutler là một kỹ sư phần mềm có ảnh hưởng rất lớn thông qua công việc với OpenVMS và Windows NT. Tôi nghĩ ông không được nhắc tới thường xuyên như những người ở Bell Labs, Stallman, Linus hay Stroustrup