Công bố mã nguồn tích lũy hơn 40 năm khi nghỉ hưu

 (dunfield.themindfactory.com)
5 điểm bởi GN⁺ 2023-11-04 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một nhà phát triển đã công bố mã nguồn tích lũy hơn 40 năm nhân dịp nghỉ hưu, cho phép mọi người trực tiếp xem xét các hệ thống cũ, công cụ và dự án cá nhân
  • Phạm vi công bố bao gồm cả hệ điều hành và kernel, như kernel đa tiến trình/tác vụ cho ARM, hệ điều hành cho CPU 6809, và các OS đời đầu từ thời Altair 1980
  • Cũng cung cấp các công cụ phát triển cấp thấp như Micro-C Compiler, cross assembler, disassembler, trình giả lập 8052 và debugger
  • Nhiều tiện ích cho công việc trên PC được công bố rộng rãi, gồm DOSBox, tiện ích DOS, đồng bộ tệp, xử lý ZIP, tạo gói cài đặt và trình soạn thảo văn bản
  • Bao gồm cả các dự án phần cứng cá nhân như radio nghiệp dư, điều khiển hồng ngoại RS-232, Ethernet TTY, điều khiển X10 và robot để đọc 1.500 DVD, nên có giá trị lưu trữ lớn

Mục đích công bố và tài liệu hướng dẫn

  • Nhân dịp nghỉ hưu, tác giả công bố mã nguồn tích lũy hơn 40 năm thuộc nhóm “những thứ tôi đã viết”
  • Mục đích công bố là để người khác có thể sử dụng hữu ích các đoạn mã này, hoặc học hỏi từ một phần trong đó
  • Trang công bố cũng dẫn tới các tài liệu sau:

Hệ điều hành, kernel, máy ảo, mô phỏng

  • ARMOS: kernel đa tiến trình/tác vụ cho ARM
  • CUBIX: hệ điều hành cho CPU 6809
  • DMF: OS đời đầu từ thời Altair 1980
  • DVM: Dunfield Virtual Machine
  • SIMSYS: hệ thống liên quan đến Altair, D6809, H8, Horizon, Mod8
  • MONITORS: monitor cho nhiều bộ xử lý nhúng
  • 8051ICE: trình giả lập in-circuit sử dụng EMILY
  • EMILY52: trình giả lập 8052

Compiler, assembler, debugger, công cụ hỗ trợ phát triển

  • MICRO-C: Micro-C Compiler
  • MCSAMPLE: chương trình ví dụ Micro-C
  • XASM: cross assembler và công cụ
  • DISASM: cross disassembler
  • DMS: debugger Dunfield MicroScope
  • DESMO: Debug Scripting Monitor
  • DDSIDE: Dunfield Development Systems IDE
  • BLDTOOL: công cụ hỗ trợ tác vụ build
  • PUBSRC: công cụ bảo trì mục mã nguồn công khai
  • HFC: Help File Compiler
  • ESL: Extensible Script Language

Tiện ích DOS, tệp, đĩa, chỉnh sửa và đóng gói

  • DBBD: đĩa mềm khởi động DosBox
  • DBUTIL: tiện ích DosBox
  • DD_DBSRC: cây mã nguồn DosBox
  • DOSUTIL: nhiều tiện ích DOS
  • FDI: Floppy Disk Image
  • IMDSRC: ImageDisk
  • EDT: trình soạn thảo văn bản EDT
  • ELF: công cụ chỉnh sửa tên tệp dài
  • FTOOLS: nhiều công cụ cho thao tác tệp
  • SYNC: đồng bộ hai cây thư mục
  • ZDIR: liệt kê tệp bên trong ZIP và touch
  • MAR: MicroARchiver từng dùng để nén tệp cài đặt
  • MKPKG: tạo tệp cài đặt dạng gói .exe đơn lẻ
  • ESP: vá chuỗi trong tệp thực thi
  • PT: công cụ PaperTape
  • MICROCAD: chương trình vẽ CAD rất nhỏ

Phần cứng, truyền thông, điều khiển, dự án cá nhân

  • DARC: Dunfield Amateur Radio Controller
  • HTX242: điều khiển bộ thu phát radio nghiệp dư RS HTX-242
  • ICOMCIV: mã giao diện ICOM CI-V cho radio nghiệp dư
  • IR232: điều khiển từ xa hồng ngoại học lệnh qua serial RS-232
  • ETTY: Ethernet TTY
  • SNIFF: Ethernet sniffer
  • DLM: Data Line Monitor
  • ITS: Interactive Terminal Switch
  • DDLINK: DavesDataLink để truyền tệp qua COM, LPT, NET
  • SERCNCT: chuyển đổi nhiều thiết bị trên một cổng COM
  • DBOX: bộ điều khiển Sony VCR
  • DVDROBOT: robot được tạo để đọc 1.500 DVD
  • EPROM: bộ lập trình EPROM
  • 8031DWG: mẫu thiết kế dựa trên 8031
  • X10CTRL: điều khiển thiết bị X10 từ PC
  • RINGSW: switch distinctive ring cho đường dây điện thoại
  • PC100: trình giả lập terminal VT-100
  • LABTOOLS: nhiều công cụ phòng lab/kiểm thử
  • CAM: dự án dành cho trẻ em khuyết tật phát triển
  • MACMON: giám sát/ghi log việc sử dụng mạng của trẻ em
  • TRANZTCL: công cụ phát triển Verifone TRANZ PointOfSale

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-11-04
Các ý kiến trên Hacker News

  • Xem qua DOSUTIL.ZIP thì thấy các chương trình C đơn giản và thanh nhã thật sự rất hay
    Điều ấn tượng nữa là phần lớn chỉ dùng 1–2 dòng #include chuẩn của C, và trong 20.000 dòng mã C chỉ có 24 chỗ #if
    Trải nghiệm đọc một codebase như thế này đã truyền cảm hứng khi bắt đầu làm Cosmopolitan Libc

    • Nếu chỉ có một mục tiêu build, có thể giảm rất nhiều macro #if
    • Các trình biên dịch C thời xưa bỏ qua đủ loại lỗi mà trình biên dịch C hiện đại sẽ bắt đúng
    • Ở phía Rust, tôi viết một HTTP listener đơn giản chỉ có một route, vậy mà Cargo kéo về khoảng 105 dependency để build
      Dù vậy, nếu so sánh tương đương thì đúng là chỉ có 2 câu lệnh use
    • Ngược lại, trong C cũng có bảng băm được triển khai chỉ bằng macro. Khá tuyệt: https://troydhanson.github.io/uthash/

  • Quy ước True=7 trong STYLE.TXT khá lạ lẫm
    Nội dung nói rằng do kinh nghiệm với mã cấp thấp và phần cứng, để “giảm thiểu những thứ có thể sai ở tầng thấp”, tác giả tận dụng việc trong C 0==FALSE, !0==TRUE nên đôi khi dùng 7 làm giá trị đúng thay vì 1
    Đây là lựa chọn theo thói quen rằng chênh lệch 3 bit tốt hơn chênh lệch 1 bit, nhưng nếu thật sự có lỗi phần cứng 1 bit như vậy thì phần lớn hệ thống cũng đã hỏng, nên chính tác giả cũng thừa nhận là ngốc nghếch
    Tôi thắc mắc ngày xưa việc bit ngẫu nhiên bị lật làm hỏng câu điều kiện có phổ biến không

    • Cho dù có chuyện đó đi nữa, không thể coi mọi câu điều kiện như Boolean ba trạng thái được
      Còn phải quyết định trong trường hợp lỗi thì giả định nhánh nào chạy an toàn, đếm số bit của từng điều kiện rồi nếu số bit 1 nhiều hơn 0 thì coi là đúng hay không, và liệu có ghi log hoặc báo cho người vận hành rằng bit đã bị lật mà không có sửa lỗi hay không
      Có những nơi mã phát hiện lỗi hữu ích, nhưng chỉ quy định true là 7 thì chưa đủ
    • Thực ra tác giả cũng gần như thừa nhận đó là một thói quen ngốc nghếch, và cho rằng nó còn làm ý định kém rõ ràng hơn
      Dù vậy, đọc tài liệu phong cách này rất thú vị, và tôi thích việc ông ấy công khai toàn bộ như thế. Chắc chắn sẽ có công cụ rất hợp với ai đó
    • Khi kiểm tra một đường dữ liệu nối tiếp có hoạt động hay không, người ta dùng 0xA5(1010 0101) để gửi một chuỗi bit xen kẽ hơi biến thể
      Đó là cách nhằm kiểm tra càng nhiều khả năng hỏng hóc càng tốt trong một lần
    • Nếu đã lo đến mức đó thì TRUE=7 không phải là giải pháp thật sự
      Nếu là biến Boolean thì với mỗi điều kiện đều phải xử lý if (var == TRUE), else if (var == FALSE), và trường hợp các giá trị khác thì làm gì; bản thân đoạn mã xử lý đó cũng không được lỗi
      Hơn nữa, việc lật bit có thể ảnh hưởng đến biến dùng trong switch, các điều kiện như if (i > 17), con trỏ, địa chỉ trả về trên stack, và cả chính mã chương trình
      Cùng lắm đây chỉ là một giải pháp rất cục bộ, việc triển khai cũng không hề nhỏ nhặt, nên khó coi là quy ước chuẩn
    • Không hẳn là vấn đề phổ biến, mà gần với kiểu “vì có thể xảy ra nên chỗ nào dễ thì thử chặn lại”
      Cá nhân tôi có lẽ sẽ dùng -1

  • Thật tiếc vì đã không lưu giữ cẩn thận mã cũ
    Từ game Rắn săn mồi là chương trình không tầm thường đầu tiên, tiện ích đầu tiên viết bằng assembly, driver thiết bị đầu tiên cho máy in Centronics, cho đến lịch vạn niên làm bằng Pascal trong một giờ khi đang nôn nao nặng vì bài tập đại học, tôi đều nghĩ chúng nhỏ nhặt và không đáng lưu
    Kết cục là không còn lại mã nào trước cuối thập niên 1990. Các lập trình viên trẻ nên lưu giữ mã của mình cho tốt

    • Trẻ con bây giờ dùng Git và nhiều hub lưu trữ, nên mã ít khi biến mất; vấn đề này có lẽ chỉ thế hệ chúng ta mới gặp
      Tất nhiên nếu các dịch vụ “miễn phí” đó đóng cửa thì sẽ thành vấn đề, nên self-hosting cũng hữu ích
    • Tôi còn giữ khá nhiều mã cũ, nhưng xấu hổ quá nên không muốn xem lại
    • Tôi cũng tương tự. Tôi từng làm cả chương trình bảng tính cho DOS, có biểu đồ modeX và công thức, rồi vài game và vài virus nữa
      Hồi đó TSR trông như phép thuật. Có lẽ chúng vẫn nằm đâu đó trong mấy đĩa mềm ở tầng hầm nhà mẹ tôi

  • Bài tác giả hồi tưởng chuyện suýt chết vào năm 2019 cũng đáng đọc: https://dunfield.themindfactory.com/2019.htm

    • Rất ám ảnh. Nó làm tôi nhớ đến bố vợ tôi, người bị đau tim năm 2015 và 90% tim bị tổn thương
      Kết quả xét nghiệm tệ đến mức có bác sĩ từ chối điều trị vì sợ ông ấy có thể chết bất cứ lúc nào trong lúc khám
      Vậy mà đến giờ ông ấy vẫn sống, sinh hoạt bình thường và thứ Bảy nào cũng chạy ngoài bãi biển. Kết quả xét nghiệm không cải thiện và ông ấy luôn hụt hơi, nhưng trông như một người đơn giản là từ chối chết
      Giống câu bác sĩ trong liên kết nói: “trông anh khá hơn nhiều so với những gì ghi trên giấy tờ”
    • Tôi thắc mắc tại sao các bác sĩ lại như vậy
      Trong bài có đoạn nói ngay cả những việc “ôm con, ngủ trên giường của mình, ăn uống, và làm một chút việc bằng tay” cũng đều bị phủ nhận; khi cha tôi bị bạch cầu và viêm phổi, không khá lên và không thể tháo ống thở, các bác sĩ cũng khăng khăng nói y hệt rằng ông sẽ bị tàn tật suốt đời
    • Kỳ lạ là nó làm tôi nhớ đến The Shadow Out of Time của H. P. Lovecraft
    • U ám, nhưng cuối cùng trông giống như một kết thúc có hậu

  • Thật sự rất hay. Tôi đã nhiều lần nghĩ rằng một ngày nào đó mình cũng muốn làm điều tương tự
    Nó giống như nhận di sản từ ông bà vậy. Chắc hẳn sẽ có những viên ngọc thật sự và những món đồ kỳ lạ lẫn trong đống linh tinh và rác rưởi, nhưng toàn bộ chúng kể câu chuyện về những con người có thật đã sống một cuộc đời phong phú và thú vị
    Chỉ vài điểm nổi bật thì không thể khắc họa đúng cuộc đời đó

    • Tại sao phải đợi đến khi nghỉ hưu mới làm? Không thể làm ngay bây giờ sao?
    • Giá mà tôi giữ lại được chút gì đó trong những thứ mình đã làm suốt 40 năm lập trình, nhưng mỗi lần chuyển sang công ty mới là tôi đều để lại tất cả
      May mắn là vẫn còn bộ cấp phát bộ nhớ thương mại tôi làm vào cuối thập niên 90. Nó chạy đơn luồng và chỉ hỗ trợ Metrowerks CodeWarrior cùng MacOS cũ, nhưng từng là bộ cấp phát nhanh nhất và ít lỗi nhất trên Mac
      Khi MacOS X ra đời thì nó trở nên vô dụng, và giờ tôi cũng không biết còn ai quan tâm không
      Như đã nói hôm qua, tôi đã mất mã nguồn Trapeze (https://en.wikipedia.org/wiki/Trapeze_(spreadsheet_program)). Có lẽ tôi chưa từng nghĩ đến việc lưu giữ các sản phẩm của mình để sau này chia sẻ khi không còn ai bận tâm nữa

  • Thật tuyệt. So với lịch sử code của tôi sau này, những thứ này có cảm giác như mã nguồn thuần khiết
    Đến năm 2040, code của tôi có lẽ sẽ cho thấy dấu vết dùng đầy những thư viện và framework “giờ chẳng ai dùng nữa”
    Không phải chuyện tốt hay xấu, chỉ là phản ánh thời đại mà thôi

    • Nếu không tự lưu trữ các dependency đó, sau này có thể chẳng ai đọc đúng hoặc build được code
      Các thực hành phát triển đang thịnh hành ngày nay tạm bợ và mong manh đến đáng kinh ngạc. Rất ít dự án hiện nay có thể bị bỏ mặc mà sống sót 10 năm, nói gì đến 40 năm
    • Những thứ như pip install và npm install này rồi sẽ đều trở nên vô dụng

  • Tôi cho rằng tiện ích có ảnh hưởng nhất là ImageDisk
    Nó được dùng để bảo tồn đĩa mềm từ nhiều loại máy tính khác nhau bằng IBM PC, và rất nhiều phần mềm cũ trên bitsavers.org và archive.org đã được khôi phục bằng công cụ này

  • Trong A Deepness in the Sky của Vernor Vinge có một xã hội loài người hàng nghìn năm sau, nơi gần như mọi phần mềm đều đã được viết, vấn đề chỉ là tìm ra chúng
    Vì vậy các lập trình viên-nhà khảo cổ lục lọi kho lưu trữ, và nếu cần thì chạy code trong emulator nằm trong emulator nằm trong emulator: https://garethrees.org/2013/06/12/archaeology/
    Bạn cũng đã góp vào một kho báu mà ai đó sẽ hưởng lợi, dù là ngày mai hay 5.000 năm nữa

    • Các kỹ sư yêu thích Vinge đặc biệt thích chi tiết rằng người ta thường nghĩ lịch của thời hiện đại, tức tương lai xa, dựa trên lần đầu tiên con người đặt chân lên Mặt Trăng, nhưng thực ra lại dựa trên Unix Epoch

  • Như một trò đùa về lần sửa lỗi cuối cùng ngay trước khi nghỉ hưu, tôi thử xem micro-cad thì gặp lỗi 404
    URL: https://dunfield.themindfactory.com/dnld/sc/MICROCAD.ZIP
    Hành vi mong đợi là có thể tải xuống tệp .zip

    • Có vẻ toàn bộ nằm kèm trong file zip MCSAMPLE
    • Tôi cũng gặp cùng lỗi 404. Không có nhiều chương trình CAD nguyên bản, nên tôi rất muốn xem cái này

  • Tuyệt vời. Tôi đã tích lũy được vài “kinh thánh” cá nhân luôn để bên cạnh khi làm với một ngôn ngữ cụ thể hoặc các tác vụ tự động hóa, và cũng học được khá nhiều cách tổ chức từ HN
    Tuy nhiên, chúng có cảm giác quá cá nhân và chuyên biệt theo quá trình suy nghĩ của tôi nên tôi chưa từng nghĩ đến việc công khai
    Nhưng sau khi xem những tài liệu như thế này, tôi thấy được truyền cảm hứng. Đây là một ý tưởng thật sự tuyệt vời, và nếu có thể, tôi cũng muốn ủng hộ tiền cho dự án nghỉ hưu này để bày tỏ sự cảm kích

    • Tôi tò mò “kinh thánh” ở đây chính xác là gì
      Và cũng muốn biết bạn đã học được những cách tổ chức nào. Tôi luôn quan tâm đến việc học các mẹo năng suất hoặc phần mềm của người khác
    • Tôi cũng có khá nhiều kiểu kinh thánh như vậy
      Nếu bạn quan tâm, tôi muốn thử trao đổi tệp với nhau. Tôi nghĩ mình có thể học được nhiều từ tài liệu của bạn. Tên người dùng Gmail của tôi giống tên người dùng HN