UNIX V2 "Beta" năm 1972 được hồi sinh

 (tuhs.org)
2 điểm bởi GN⁺ 2025-02-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • Phân tích pháp chứng s1/s2 của các băng DMR đã dựng được một hệ thống UNIX có thể hoạt động, trong đó s1 là UNIX INIT DECtape chứa kernel và s2 chứa phần lớn các tệp phân phối
  • Kernel s1 là kernel UNIX có thể đọc bằng máy sớm nhất từng được xác nhận cho đến nay, nằm giữa V1 và V2, và có thể chạy cả a.out của V1 lẫn V2
  • Kích thước core người dùng đã tăng lên 16 KiB (8K words) như V2, nhưng syscall table giống V1 và kernel unix-jun72 nên không bao gồm syscall của V2
  • Điều kiện khởi động rất khắt khe nên chỉ trình giả lập PDP-11/20 của aap khởi động được kernel, còn SIMH và Ersatz-11 dừng trước login prompt
  • Ảnh đĩa RF được công bố chỉ chứa các tệp từ s1/s2, có thể khởi động trên trình giả lập của aap, và theo cách hoạt động của init(7), có vẻ /usr đã nằm trên RF

UNIX V2 “Beta” được khôi phục từ băng s1/s2

  • Kết quả phân tích pháp chứng các băng DMR cho thấy có thể tạo ra một hệ thống hoạt động được từ các băng s1/s2
    • DMR tapes là bộ băng được đem ra phân tích
    • Băng s1 là UNIX INIT DECtape chứa kernel
    • Băng s2 chứa phần lớn các tệp phân phối
  • Kernel s1 là kernel UNIX có thể đọc bằng máy sớm nhất từng được xác nhận cho đến nay, nằm giữa V1 và V2
    • Kernel unix-jun72 chưa chỉnh sửa chỉ hỗ trợ a.out của V1
    • Kernel s1 có thể mặc định chạy cả a.out của V1 và V2
    • Kích thước core người dùng tăng từ 8 KiB (4K words) lên 16 KiB (8K words)
  • Syscall table giống với kernel V1 và unix-jun72
    • Không bao gồm syscall của V2
    • Xét về syscall thì gần với V1, còn về kích thước core và khả năng chạy nhị phân V2 thì mang đặc tính của V2, nên được xem là “V2 beta”
  • Có thể chạy ed, cc, a.out trên hệ thống
    • Trong phiên ví dụ, hệ thống đã viết, biên dịch và chạy chương trình hello world!

Ràng buộc khi khởi động và ảnh đĩa RF

  • Môi trường có thể khởi động được rất hạn chế
  • Quy trình cài đặt gốc là khởi động từ s1 rồi khôi phục tệp từ s2
    • Trình giả lập của aap không hỗ trợ TC11 nên rất khó cài đặt trực tiếp từ các băng s1/s2
  • Cấu hình thực tế được thực hiện bằng cách vòng qua việc tạo ảnh đĩa RF
    • Trích xuất các tệp từ băng s1 và đặt chúng vào một đĩa RF trống
    • Cài kernel unix-jun72 rồi khởi động từ RF trong SIMH
    • Trích xuất các tệp còn lại của s2
    • Cuối cùng dùng hex editor để thay kernel unix-jun72 bằng kernel s1
  • Ảnh RF được tạo ra chỉ chứa các tệp đến từ s1/s2
    • Có thể tải tại Research-UNIX-V2-Beta
    • Có cung cấp liên kết tải trực tiếp s1s2unix_rf.img
    • Ảnh này khởi động được trên trình giả lập của aap nhưng không khởi động được trên SIMH
  • Chương trình init(7) không mount RK vào /usr
    • Hành vi này cho thấy /usr đã được lưu trên RF

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-21
Ý kiến trên Hacker News

  • Điều này làm tôi nhớ đến một câu đùa nghe được trong bài nói chuyện của Brian Kernighan. Chuyện kể rằng Ken Thompson đã tạo ra một trình soạn thảo văn bản, trình biên dịch B và bộ khung quản lý tệp vào/ra chỉ trong 3 tuần, và thứ đó cuối cùng trở thành UNIX
    Ý chính của câu đùa là ngày nay chúng ta có vẻ kém hiệu quả hơn họ một chút

    • Ken rõ ràng là một lập trình viên hạng siêu đẳng, và nếu một người như vậy có thể tập trung trong 3 tuần thì thực sự làm được rất nhiều thứ
      Tôi nhớ là vợ anh ấy đã đưa bọn trẻ sang Anh, nên Ken có thể toàn quyền làm bất cứ điều gì mình muốn. Dĩ nhiên, ngay cả trước khi viết UNIX đầu tiên, ông ấy cũng đã có rất nhiều kinh nghiệm rồi
      Với những lập trình viên đã có sẵn một dự án trong đầu, đây là điều đáng thử một lần. Rời công việc và gia đình trong 3 tuần đến một nơi như cabin, mang theo các sách và tài liệu cần thiết, rồi cắt Internet. Nếu có thể thì dùng điện thoại phổ thông và xem mình đi được xa đến đâu
      Tuy vậy, đó nên là một dự án đã được suy nghĩ kỹ từ trước và thậm chí đã viết sẵn một ít mã. Nghĩ kỹ hơn thì dự án cấp thấp gần như không phụ thuộc thư viện bên ngoài sẽ phù hợp nhất với kiểu thử nghiệm này. Nếu là dự án dựa vào cả đống thư viện bên thứ ba thì rất dễ bị mắc kẹt khi phát sinh vấn đề mà không có Internet, và Ken cũng đã chọn một dự án phù hợp
    • Đây là cuộc phỏng vấn: https://www.youtube.com/watch?v=EY6q5dv_B-o
      Dài một tiếng và Thompson kể rất nhiều câu chuyện thú vị. Kernighan làm rất tốt vai trò để Thompson tự do nói chuyện
    • Một câu đùa kiểu hiện đại là Ken Thompson đã cùng Rob Pike và Robert Griesemer thiết kế Go trong lúc chờ biên dịch C / C++
    • Tôi tò mò không biết các nhà phát triển UNIX thời kỳ đầu đã đạt tới mức năng suất này bằng cách nào
      Họ có làm kiểu 9 giờ đến 5 giờ như đi làm bình thường không, hay là gạt mọi thứ khác trong đời sang một bên và chuyển sang goblin mode để hoàn thành cho xong
    • 80% đầu tiên của chức năng dự án đôi khi tiến triển rất nhanh. Nhất là khi bạn thấy hứng thú và động lực mạnh
      Nhưng 20% còn lại kéo dài như một cái đuôi rất dài, và thường trở thành cực hình khiến động lực cạn kiệt

  • Thú vị đến mức cả Spock cũng phải kinh ngạc. Tôi muốn học cách biên dịch trình giả lập PDP-11 trên Mac

    • Việc biên dịch trình giả lập khá dễ. Hãy xem simh. Nó rất dễ di chuyển nên gần như sẽ chạy ngay
      Sau đó bạn có thể thử cài bản phân phối 2.11BSD. Nó được tài liệu hóa rất tốt và ra đời sau khi nhiều hỗn loạn của Unix thời kỳ đầu đã qua đi. Sau đó nữa, nghịch RT-11 cũng rất vui, tôi thậm chí còn viết được vài ứng dụng nhỏ trên đó
    • https://opensimh.org/
      Cũng chạy tốt trên Apple Silicon
    • Cảm giác như vừa dùng máy dò kim loại tìm thấy một thánh tích tôn giáo
    • Dễ quá! Tôi sẽ tự làm một cái bằng cổng NAND

  • Thật tuyệt
    Đây là lần đầu tôi thấy mọi người thực sự dùng ed cho công việc thật
    Tôi cũng tò mò không biết còn ai phải xử lý ed nữa. Gần đây tôi phải kết nối vào một hệ thống cực kỳ cũ không có vi, nên tôi đã tự làm một trình soạn thảo; nếu ai cần một trình soạn thảo cho hệ thống cổ xưa thì cứ liên hệ tôi. Nó không quá hào nhoáng
    Phần mềm này và công trình của những người tạo ra nó cùng các nhà nghiên cứu thật đáng kinh ngạc, và tôi dành sự kính trọng cho những kỹ sư đích thực

    • Tôi nhớ là vào thập niên 1960, trên hệ thống chia sẻ thời gian Honeywell qua Teletype ASR-33, tôi đã dùng một trình soạn thảo kiểu giống ed
      Tôi không nhớ rõ chi tiết, nhưng khi tạo tệp mới thì chạy bằng make . Nếu gõ make love thì nó sẽ in not war trước khi vào trình soạn thảo
    • Không phải ed, nhưng rõ ràng chịu ảnh hưởng từ nó: tôi đủ lớn để từng làm bài kiểm tra ở trường dạy đánh máy bằng edlin của MS-DOS 3.3
      Từ đó về sau tôi không dùng lại nó nữa, và vài năm sau khi có thể dùng Xenix thì tôi cũng không dùng ed. vi là lựa chọn thay thế tỉnh táo hơn nhiều
    • Tháng 8 tôi đã dùng ed trong Termux trên điện thoại để viết http://canonical.org/~kragen/sw/dev3/justhash.c
      Có người nói rằng bàn phím ảo Android quá kinh khủng đối với vi nên họ dùng ed trên điện thoại, và đúng là như vậy nên tôi đã thử. Trên điện thoại, ed tệ hơn vi một chút, nhưng cả hai tệ theo những cách khác nhau
      Với HeliBoard, việc nhập lệnh ed trên bàn phím dễ hơn vi rất nhiều, nhưng vài lần tôi bị rối vì trạng thái bộ đệm mà nếu là vi thì đã không nhầm. Có thể luyện tập sẽ khá hơn, nhưng cuối cùng tôi vẫn quay lại vi
    • Vào giữa thập niên 90 tôi có một chiếc AT&T 3B2, và trên đó chỉ có ed, dùng với terminal DEC VT-102
      ed thì vẫn dùng được, nhưng theo tiêu chuẩn hiện đại thì chẳng vui vẻ gì. Dù vậy, so với đầu ra máy teletype thì được dùng trên màn hình hẳn đã là một bước tiến khổng lồ
      Nói thêm, chiếc 3B2 khoảng 1 MIP đó có thể phục vụ khoảng 20 người dùng đồng thời
    • Một trong những công việc tư vấn đầu tiên của tôi là viết hướng dẫn ed cho hệ thống Coherent
      Tôi dùng ed thường xuyên, thực ra hôm qua cũng vừa dùng. Vì tôi cần chỉnh sửa thứ gì đó mà không xóa màn hình
      Trước đó nữa, tôi còn từng làm một trình soạn thảo cho các ảnh thẻ được lưu trên đĩa, rất nguyên thủy

  • Thỉnh thoảng tôi thích đọc mailing list tuhs. Thật hay khi thấy những cái tên như Ken Thompson, Rob Pike, cùng nhiều cái tên ít nổi tiếng hơn nhưng đã tham gia vào UNIX thời kỳ đầu và hiện trường điện toán khi đó

  • Giống như khảo cổ học phần mềm

    • Một trong nhiều lý do tôi không thích thời đại SaaS là chuyện như thế này sẽ không bao giờ xảy ra nữa. Sẽ không có ai vào năm 2075 khởi động một bản Notion hay Figma cũ vì mục đích nghiên cứu hoặc hoài niệm
      Nó hoàn toàn tạm thời và dùng một lần, giống như văn hóa được tạo ra và tiêu thụ trên mạng xã hội hay nhiều khía cạnh khác của văn hóa Internet. Không có lịch sử và cũng không có tương lai
      SaaS không chỉ ở mức đóng kín, mà trên thực tế thường gần như bị ràng buộc theo nghĩa đen vào một bản cài đặt duy nhất. Có thể lưu trữ nó và khởi động ở nơi khác, nhưng làm vậy sau nhiều năm mà không có đội ngũ ban đầu sẽ là công việc lớn hơn rất nhiều so với việc khởi động Unix năm 1972 trên trình giả lập của PC hiện đại
      Unix đó có tài liệu hướng dẫn và được thiết kế để cài đặt, chạy trong nhiều môi trường triển khai khác nhau. SaaS thì gần giống một mớ hổ lốn mà chỉ người tạo ra mới có thể triển khai, không nhất thiết vì chủ ý mà vì không có các lực tiến hóa gây áp lực buộc nó phải được làm theo cách đó
      Nhiều trường hợp còn đan xen nội bộ với các SaaS khác, đến mức có thể phải lưu trữ và khôi phục toàn bộ trạng thái của đám mây, như thể phần mềm độc quyền đang bị chỉnh sửa tại chỗ trên một máy tính toàn cục duy nhất
    • Không ngầu như nghe có vẻ đâu

  • Có ai có thể cho tài liệu tham khảo về ý nghĩa của các quyền đối với tập tin đó không? Tôi đoán được đại khái, nhưng tìm mãi vẫn không thấy nội dung nào về quyền của Unix v2
    Kết quả ls trông quen thuộc, chỉ có phần sdrwrw là lạ

    • Trong chuỗi thảo luận trên mailing list có người đã liên kết đến một trang manual được trích xuất
      https://gitlab.com/segaloco/v1man/-/blob/master/man1/stat.1?...
      Trong sdrwrw, cột đầu tiên là s hoặc l, nghĩa là small hoặc large. Cột thứ hai là d, x, u, -, lần lượt có nghĩa là thư mục, có thể thực thi, setuid, hoặc không có gì. Phần còn lại là các bit đọc/ghi cho chủ sở hữu và người không phải chủ sở hữu

  • hello world mà 1328 byte à? Phình to rồi đấy!

    • Tôi nhớ đến một compiler trước đây hay đùa bằng cách nhét thơ dài vào mọi binary. Chắc bạn đã nghe về magic number rồi, nhưng cái đó thì đúng là có magic sonnet
      Tôi nghĩ đó là compiler Rust thời kỳ đầu, nhưng không tìm được tài liệu liên quan. Cũng có thể là Go
      Sửa lại: tìm thấy rồi. 'rust-lang/rust#13871: "hello world" contains Lovecraft quotes' https://github.com/rust-lang/rust/issues/13871
    • https://github.com/pts/minilibc686 của tôi có thể làm hello world bằng printf trên i386 trong dưới 1 KiB. hello world bằng write thì dưới 170 byte
    • Đến lúc tôi tinh chỉnh Unix của mình rồi!

  • Tuyệt thật. Có thể bước qua cánh cổng thời gian đó và sống trong thực tại thay thế không?

    • Ý là thời xăng pha chì được dùng, khói thuốc lá hiện diện khắp nơi như điều hiển nhiên, và amiăng được dùng cho mọi thứ có thể nghĩ ra ấy à? Đó đúng là một thập kỷ quyến rũ, nhưng chất lượng cuộc sống có lẽ đã tăng lên rất nhiều kể từ sau đó
    • Làm được đấy. Chỉ cần mua một terminal VT thật. Ví dụ như https://www.ebay.com/itm/176698465415?_skw=vt+terminal&itmme... như vậy
      Kiếm adapter để nối nó với máy tính, rồi chạy *nix bạn muốn trên simh là được. Tôi khuyên tham khảo https://jstn.tumblr.com/post/8692501831
      Sau khi làm cho nó chạy được, hãy đẩy máy chủ ra sau bàn hoặc giấu ở chỗ khuất tầm mắt, là bạn có thể sống như năm 1980

  • Khi thử khôi phục băng RF, ngay cả việc chỉ xem các tập tin văn bản đơn giản cũng cho thấy phần đệm mà DOS hay các tập tin .iso không sử dụng
    Ngay cả trên bản phân phối 2.11 BSD, cơ chế xếp ô và trình quản lý cửa sổ mặc định vẫn phải được cài trên hệ điều hành gốc. Vì thế bạn mới phải dùng KDE hoặc trình quản lý cửa sổ X11