Một năm được tài trợ cho việc phát triển FreeBSD

 (daemonology.net)
2 điểm bởi GN⁺ 2025-06-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong bối cảnh việc bảo trì FreeBSD/EC2 và kỹ thuật phát hành xung đột trong quỹ thời gian tình nguyện của một người, khoản tài trợ 1 năm từ Amazon đã giúp có thể đồng thời thực hiện vận hành phát hành và cải thiện nền tảng EC2
  • Khoản tài trợ có quy mô danh nghĩa 40 giờ mỗi tháng thông qua GitHub Sponsors, nhưng khối lượng công việc thực tế trung bình là 50 giờ mỗi tháng; thời gian được chia khoảng 20/20/10 giờ cho các vấn đề EC2, tiến trình phát hành và các công việc kỹ thuật phát hành khác
  • Trong 1 năm, tác giả đã quản lý các bản phát hành FreeBSD 13.4, 14.2, 13.5, 14.3, đồng thời xử lý các hạng mục ưu tiên như xử lý tín hiệu tắt máy trên AWS Graviton và hotplug thiết bị trên EC2
  • Để bắt các đợt hồi quy hiệu năng khởi động, tác giả đã benchmark các bản build EC2 AMI hằng tuần từ năm 2018, rồi tìm và sửa các nguyên nhân gây chậm trễ liên quan đến kích thước đĩa gốc, gieo entropy EFI, nhóm giao dịch ZFS và thay đổi IMDSv2 IPv6
  • Dù vai trò này vẫn tiếp tục sau khi tài trợ kết thúc, thời gian có thể dành ra để trực tiếp sửa lỗi sát ngày phát hành hoặc tiếp tục đẩy nhanh danh sách tính năng EC2 sẽ giảm đi

Điểm nghẽn trước tài trợ và phân bổ thời gian

  • Việc bảo trì FreeBSD/EC2 đã được duy trì từ khi FreeBSD lần đầu khởi động trên Amazon EC2 vào năm 2010, và đến tháng 11/2023 còn được bổ sung thêm vai trò trưởng nhóm kỹ thuật phát hành FreeBSD
  • Chỉ với các khoản tài trợ nhỏ từ Antithesis và FreeBSD/EC2 Patreon thì rất khó gánh cả hai vai trò
    • Danh sách tính năng cần triển khai bị đình trệ
    • Dù phát hiện hiện tượng bất thường cũng thường phải hoãn lại vì không có thời gian điều tra
    • Đầu năm 2024, mối lo về việc khó có thể làm một “người phụ trách tốt” cho nền tảng FreeBSD/EC2 ngày càng lớn
  • Tháng 4/2024, khi tìm được người phụ trách có ngân sách tại Amazon, các cuộc thảo luận về lịch trình, phạm vi và quy trình đã diễn ra, và Amazon quyết định tài trợ trong 1 năm qua GitHub Sponsors
  • Phạm vi tài trợ là 40 giờ mỗi tháng cho cả kỹ thuật phát hành FreeBSD và phát triển FreeBSD/EC2
    • Tác giả đã nói rằng hai mảng này phụ thuộc lẫn nhau nên việc chỉ tài trợ một bên là không thực tế
    • Khối lượng thực tế tăng lên trung bình khoảng 50 giờ mỗi tháng
    • Trung bình là 20 giờ cho các vấn đề riêng của EC2, 20 giờ cho tiến trình phát hành FreeBSD và 10 giờ cho các công việc liên quan khác của kỹ thuật phát hành, nhưng dao động theo từng tháng là khá lớn

Vận hành phát hành theo quý và cải thiện build

  • Theo lịch phát hành theo quý của FreeBSD được công bố vào tháng 7/2024, tác giả đã quản lý 4 bản phát hành trong 1 năm
    • FreeBSD 13.4: tháng 9/2024
    • FreeBSD 14.2: tháng 12/2024
    • FreeBSD 13.5: tháng 3/2025
    • FreeBSD 14.3: dự kiến phát hành ngày 10/6/2025
  • Mỗi bản phát hành bao gồm việc thúc đẩy merge mã, duyệt hoặc từ chối yêu cầu merge, phối hợp với các nhóm khác, build và kiểm thử image, viết thông báo và sửa các vấn đề trong quá trình build phát hành
    • Thông thường sẽ build 3 bản Beta, 1 bản Release Candidate và bản Release cuối cùng
    • Phần lớn công việc dồn vào tháng trước ngày phát hành, tức “Beta Month”, là tháng thứ hai của mỗi quý
    • FreeBSD 13.5 mất 33,5 giờ, còn FreeBSD 14.2 mất 79 giờ
    • Càng về cuối vòng đời của nhánh stable thì số hạng mục bị hỏng thường càng giảm, nên khối lượng công việc phát hành cũng có xu hướng giảm
    • FreeBSD 14.1 không được theo dõi, nhưng thời gian cho kỹ thuật phát hành có lẽ gần 100 giờ, và FreeBSD 15.0 có khả năng còn nhiều hơn đáng kể
  • Trong kỹ thuật phát hành nói chung, công việc song song hóa build phát hành cũng được thực hiện
    • Khi số lượng EC2 AMI tăng lên, thời gian cài FreeBSD vào VM image chiếm tỷ trọng lớn hơn cả bản thân quá trình build
    • Mã phát hành đã được song song hóa, nhưng xuất hiện lỗi build ngắt quãng, và do toàn bộ build phát hành mất khoảng 24 giờ nên rất khó cô lập nguyên nhân
    • Nguyên nhân cuối cùng là thiếu đúng một dòng Makefile để tạo thư mục trước khi cài file
    • Sau khi sửa, thời gian build phát hành giảm từ khoảng 22 giờ xuống còn khoảng 13 giờ, và việc mở rộng các flavour EC2 AMI từng bị trì hoãn vì thời gian build cũng trở nên khả thi
  • Các vấn đề về tính tái lập của build cũng bắt đầu được kiểm tra định kỳ bằng EC2
    • Trong quá trình kiểm thử image snapshot hằng tuần, tác giả khởi chạy instance EC2 để build AMI của chính mình
    • So sánh disk image được tạo ra với image gốc bằng diffoscope
    • Việc kiểm thử định kỳ đã phát hiện nhiều vấn đề; một số được tự sửa, một số được chuyển cho các nhà phát triển khác

Xử lý nguồn trên Graviton và hotplug trong FreeBSD/EC2

  • Hai tính năng chính mà Amazon ưu tiên yêu cầu cho FreeBSD/EC2 là power driver cho instance AWS Graviton và hotplug thiết bị
  • Power driver cho Graviton xử lý đường dẫn mà EC2 API dùng để thông báo cho hệ điều hành rằng máy sẽ tắt
    • Nếu không có tính năng này, FreeBSD sẽ bỏ qua tín hiệu tắt máy, rồi vài phút sau EC2 sẽ cắt nguồn ảo sau khi timeout
    • “Nút nguồn” trên hệ thống Graviton là một GPIO pin, và chi tiết của nó nằm trong đối tượng ACPI _AEI
    • Mã đã được bổ sung để tìm thông tin đó trong ACPI và truyền cấu hình sang driver bộ điều khiển GPIO PL061
    • Khi GPIO pin được assert, bộ điều khiển tạo interrupt, kích hoạt sự kiện ACPI “power button” và dẫn tới tắt hệ thống
  • Bảng ACPI do EC2 cung cấp chỉ định GPIO pin đó phải được cấu hình là “Pull Up”, nhưng bộ điều khiển PL061 không có điện trở pullup/pulldown
    • Linux âm thầm bỏ qua lỗi cấu hình GPIO nên vấn đề không lộ ra
    • FreeBSD thì vô hiệu hóa thiết bị sau khi cấu hình thất bại
    • Có vẻ lỗi EC2 này sẽ được sửa trên các hệ thống Graviton trong tương lai, nhưng hiện tại FreeBSD/EC2 AMI được thêm quirk ACPI_Q_AEI_NOPULL để bỏ qua cờ GPIO PullUp trong đối tượng _AEI
  • Hotplug, đặc biệt là hot unplug, đòi hỏi nhiều công việc hơn do nhiều vấn đề khác nhau chồng lên nhau trên nhiều loại instance EC2
    • Một số hệ thống Graviton bị rò rỉ việc giữ chỗ virtual IRQ trong lúc PCI attach, và sau 67 lần attach/detach EBS volume thì cạn IRQ, khiến kernel FreeBSD panic
      • Nguyên nhân nằm ở mã định tuyến interrupt PCI kiểu legacy, và một thiết lập boot loader đã được thêm vào để tắt đoạn mã đó trên EC2
    • Một số hệ thống Graviton dùng trạng thái nguồn của thiết bị PCI làm tín hiệu để xác định hệ điều hành đã dùng xong thiết bị và sẵn sàng eject hay chưa
      • Đây được xem là lỗi EC2, và hiện tại quirk ACPI_Q_CLEAR_PME_ON_DETACH được dùng để thay đổi một số bit trong thanh ghi quản lý nguồn PCI trước khi eject
    • Trên x86 và Graviton của các thế hệ instance EC2 mới hơn, driver FreeBSD nvme bị panic sau khi PCIe unplug
      • Vấn đề này đã được chuyển cho maintainer của driver nvme
    • Trên một số instance EC2 x86 và Graviton, sau khi eject vẫn còn thiết bị “ghost” trên PCI bus, chặn việc attach thiết bị mới
      • Firmware Nitro quản lý PCI bus và thiết bị PCI theo cách bất đồng bộ, tạo ra một khoảng vài ms mà thiết bị đã bị unplug nhưng PCI bus vẫn báo là còn tồn tại
      • Linux quét lại bus theo chu kỳ nên thường thua trong cuộc đua này, còn FreeBSD thì quét lại PCI bus ngay sau detach nên thường nhìn thấy ghost
      • Hiện tại quirk ACPI_Q_DELAY_BEFORE_EJECT_RESCAN thêm độ trễ 10ms trước khi quét lại PCI bus sau tín hiệu eject
  • PCIe yêu cầu sau khi nhấn nút “attention” để yêu cầu eject thiết bị thì phải đợi 5 giây, và nếu có lần nhấn thứ hai thì yêu cầu eject sẽ bị hủy
    • Trên EC2 không có người nhấn nút vật lý, và cũng không có cơ chế nhấn lại nút ảo, nên độ trễ này là không cần thiết
    • Một tunable của boot loader đã được thêm vào để đặt timeout bằng 0 trên EC2
  • Với script kiểm thử hotplug, có thể khởi chạy instance EC2 rồi dùng EC2 API để lặp lại việc plug/unplug EBS volume, qua đó xác minh FreeBSD có thể attach/detach liên tiếp 300 lần hay không
    • Nếu sau này có thể được truy cập sớm vào các loại instance EC2, công cụ này có thể được dùng để xác nhận hotplug có hoạt động đúng hay không

Theo dõi hồi quy hiệu năng khởi động và mở rộng AMI

  • Ngoài hai hạng mục ưu tiên cao nhất của Amazon, khoảng một nửa thời gian dành cho EC2 được dùng cho các vấn đề FreeBSD/EC2 khác
  • Cuối năm 2023 và đầu năm 2024, các instance FreeBSD/EC2 đôi khi khởi động lâu hơn dự kiến, và trong bài kiểm thử snapshot hằng tuần phải tăng thời gian chờ sau khi khởi chạy instance trước khi thử SSH
  • Để xử lý vấn đề hiệu năng, tác giả đã benchmark thời gian khởi động của các bản build EC2 AMI hằng tuần từ năm 2018
    • Trong quá trình này, hơn 10.000 instance EC2 đã được khởi chạy
    • Tác giả bắt đầu tạo các biểu đồ hiệu năng khởi động của FreeBSD
    • Thu thập dữ liệu mới và cập nhật biểu đồ hiện đã được đưa vào quy trình kiểm thử snapshot hằng tuần
  • Nhiều nguyên nhân gây chậm khởi động đã được tìm ra và sửa
    • Từ tuần đầu tiên của năm 2024, thời gian khởi động FreeBSD chậm hơn khoảng 3 lần, và nguyên nhân được lần theo đến một commit tăng kích thước đĩa gốc từ 5GB lên 6GB
      • Sau khi xác nhận với phía Amazon, việc tăng kích thước đĩa gốc lên 8GB đã khôi phục hiệu năng về mức trước đó
    • Trên dòng Graviton 2, vấn đề gieo entropy cho kernel khiến thời gian khởi động bị kéo dài
      • Kernel FreeBSD sẽ dừng quá trình khởi động cho đến khi thu thập đủ entropy để tạo số ngẫu nhiên an toàn
      • Đã có mã nhận seed an toàn từ firmware Nitro qua EFI boot loader, nhưng trên EC2 nó không được thực thi, và trên Graviton 2 thì yêu cầu 2048 byte rất chậm
      • Lời gọi đó vốn nằm trong mã Lua của menu boot đã được chuyển sang vị trí Lua thích hợp trong boot loader để nó luôn chạy dù menu có bị tắt hay không
      • Sau đó, thay vì lấy 2048 byte trực tiếp, hệ thống lấy 64 byte entropy EFI rồi mở rộng bằng PBKDF2 để phù hợp với đầu vào API 2048 byte, giúp thời gian khởi động FreeBSD arm64/base/UFS giảm từ khoảng 25 giây xuống khoảng 8 giây
    • Image ZFS khởi động chậm hơn UFS, và mức chậm không phụ thuộc vào kích thước đĩa mà phụ thuộc vào lượng dữ liệu trên đĩa
      • makefs đặt mọi thứ vào một nhóm giao dịch duy nhất, và khi ZFS attach, hệ thống duyệt và xác minh nhóm giao dịch gần nhất, phải đọc và xử lý toàn bộ metadata file trên đĩa
      • Mark Johnston đã giải quyết bằng cách để filesystem ghi một nhóm giao dịch cao hơn, để nhóm giao dịch đơn lẻ đó không còn bị coi là “gần nhất”
      • Thời gian khởi động của image ZFS giảm từ khoảng 22 giây xuống khoảng 11 giây
    • Sau khi thêm hỗ trợ IPv6 cho port net/aws-ec2-imdsv2-get vào tháng 12/2024, một vấn đề khởi động đã nhanh chóng được phát hiện
      • Port này cung cấp giao diện dòng lệnh cho EC2 Instance MetaData Service
      • Nó thử IPv6 trước, nhưng cấu hình IMDS mặc định của instance lại chỉ hỗ trợ IPv4, trong khi timeout TCP mặc định 75 giây vẫn giữ nguyên
      • Sau khi sửa, hệ thống thử IPv4 trước và giảm timeout xuống 100ms
  • Các flavour FreeBSD AMI cũng được mở rộng
    • Trước đây chỉ có base và cloud-init
    • AMI small loại bỏ debug symbol, LLDB, thư viện 32-bit, bộ kiểm thử FreeBSD, Amazon SSM Agent và AWS CLI, giúp giảm dung lượng đĩa từ khoảng 5GB xuống còn khoảng 1GB
    • AMI builder cung cấp FreeBSD AMI Builder AMIs, giúp người dùng dễ tạo FreeBSD AMI tùy chỉnh
  • Khi số bản build snapshot hằng tuần tăng lên với tổ hợp 4 flavour AMI, 2 filesystem, 2 kiến trúc và 3 phiên bản FreeBSD, tác giả cũng dọn dẹp các image cũ và EBS snapshot liên quan
    • Tài khoản AWS dùng cho kỹ thuật phát hành FreeBSD nhận được tài trợ từ Amazon, nhưng chi phí vẫn là của ai đó
    • Một shell script đã được viết để xóa 336TB EBS snapshot

Công việc còn lại và giới hạn sau khi tài trợ kết thúc

  • Ngoài các dự án lớn, nhiều công việc nhỏ vẫn tiếp tục
    • Sửa các lỗi build bị hỏng được phát hiện trong các bản build snapshot hằng tuần
    • Review patch cho driver ENA
    • Hỗ trợ Dave Cottlehuber thêm tính năng build OCI Container và tải lên kho lưu trữ
    • Cải thiện công cụ bsdec2-image-upload để xử lý lỗi nội bộ AWS mềm dẻo hơn
    • Báo cáo một vấn đề bảo mật AWS được phát hiện tình cờ
  • Sau khi tài trợ kết thúc, tác giả vẫn tiếp tục đảm nhiệm vai trò trưởng nhóm kỹ thuật phát hành FreeBSD và maintainer của nền tảng FreeBSD/EC2
    • FreeBSD 15.0 dự kiến đến vào tháng 12
    • Năm 2026 sẽ tiếp nối với 14.4, 15.1, 14.5 và 15.2
  • Khi thời gian có thể đầu tư giảm đi, cách làm tự tay sửa các vấn đề sát ngày phát hành sẽ trở nên khó hơn
    • Các tính năng đến muộn sẽ có khả năng bị loại khỏi bản phát hành nhiều hơn là được sửa cho kịp
    • Việc có thể đưa OCI Containers vào từ FreeBSD 14.2 là nhờ thời gian được tài trợ giúp đảm bảo các mảnh ghép cần thiết được tích hợp đầy đủ
  • Ở phía EC2, việc kiểm thử hồi quy hiệu năng khởi động đã được thiết lập nên các vấn đề liên quan có khả năng bị bắt được, nhưng danh sách tính năng có thể tiếp tục bị đình trệ nếu không có thêm thời gian
    • Tự động mở rộng filesystem khi mở rộng EBS volume
    • Cải thiện cấu hình tự động cho nhiều network interface và hotplug network interface
    • Rolling AMI “pre-patched”
    • Website tạo file EC2 user-data để cài package, chạy daemon, v.v.
    • Khởi động lại công việc FreeBSD/Firecracker và đưa nó thành nền tảng được hỗ trợ
  • Khoản tài trợ từ Amazon là một cơ hội lớn hơn nhiều so với những gì phần lớn nhà phát triển mã nguồn mở nhận được, và khi nó kết thúc, điều đọng lại vừa là sự tiếc nuối vừa là lòng biết ơn đối với những gì đã làm được

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-06-07
Ý kiến trên Hacker News

  • Hay quá. Từ hôm nay, trang tải xuống của ziglang.org đã thêm FreeBSD, nên người dùng FreeBSD có thể nhận các bản build nhánh master được build tự động từ CI
    Giờ FreeBSD được hỗ trợ như một mục tiêu cross-compile hạng nhất, bao gồm cả liên kết libc, nên những lệnh như zig cc -o hello hello.c -target riscv64-freebsd cũng chạy được
    Nếu có phụ thuộc C/C++, bạn có thể đưa chúng vào hệ thống build của Zig để build, nên có vẻ cả những dự án khá phức tạp cũng có thể cross-compile cho FreeBSD một cách dễ dàng. Hy vọng điều này giúp nhiều dự án hơn bổ sung hỗ trợ FreeBSD và kiểm thử CI

    • Cross-compile của Zig rất tuyệt, và thật vui khi FreeBSD đã được đưa vào danh sách mục tiêu được hỗ trợ
    • Zig có giấy phép thân thiện với BSD, còn FreeBSD đã bao gồm LLVM trong hệ thống cơ bản, nên tôi tự hỏi liệu một ngày nào đó Zig cũng sẽ được đưa vào hệ thống cơ bản không
      Sẽ thật tốt nếu có một lựa chọn thay thế C được công nhận chính thức

  • Ở đây có khá nhiều đoạn thú vị
    “Từ tuần đầu tiên của năm 2024, quá trình khởi động FreeBSD đột nhiên chậm đi khoảng 3 lần. Sau khi bisect các commit, nguyên nhân là commit tăng kích thước đĩa root từ 5GB lên 6GB. Vì sao lại thế? Hỏi những người quen ở Amazon thì câu trả lời nằm đâu đó giữa ‘ma thuật’ và ‘tốt nhất là không nên biết’, và điều quan trọng là khi tăng đĩa root lên 8GB, hiệu năng đã trở lại mức trước đây”

    • Giới hạn kích thước object ban đầu của S3 là 5GB, và bài viết năm 2006 cũng ghi như vậy: https://aws.amazon.com/blogs/aws/amazon_s3/
      Không rõ điều này có liên quan đến vách đá hiệu năng quan sát được hay không
    • Dù vậy giờ thì tôi thật sự muốn biết
    • Tôi tò mò không biết mất bao lâu để bisect một vấn đề như thế. Mỗi lần đều phải build image rồi reboot VM à?

  • Tôi đọc thấy phía laptop cũng có nhiều việc đang được làm, và BSD Foundation đã đầu tư 750.000 đô la vào mảng này
    Bao gồm các triển khai như trạng thái tiết kiệm điện S0ix; có thể xem dự án tại đây: https://github.com/FreeBSDFoundation/proj-laptop

    • Đúng vậy, rất nhiều việc đang được tiến hành. Tôi chỉ viết về phần việc mình đang làm thôi ;-)

  • Tôi thật sự rất kính trọng cperciva
    Không hiểu anh ấy làm thế nào để vừa làm tất cả những việc này vừa lo được Tarsnap

    • Đến một thời điểm nào đó, bạn có thể dùng tiền để mua thời gian. Chẳng hạn như tự sửa vòi nước bị rò hay gọi thợ ống nước, tự khôi phục lại tấm thạch cao tầng hầm sau khi thợ điện tháo ra hay gọi chuyên gia
      Công bằng mà nói, một phần thời gian dành cho việc này là lấy từ Tarsnap, nhưng ít hơn tôi tưởng rất nhiều

  • Tôi đã kỳ vọng Amazon chi tiêu và đóng góp nhiều hơn, nhưng về cơ bản có vẻ họ chỉ muốn trả tiền cho mức hỗ trợ FreeBSD tối thiểu
    Amazon không có trong danh sách nhà tài trợ FreeBSD [1], Google năm ngoái chỉ tài trợ 9.000 đô la, còn Apple thì không có. Microsoft ít nhất có trong danh sách, đáng ghi nhận. Meta/Facebook cũng vắng mặt
    Các công ty này dùng FreeBSD và OpenBSD, tiếp tục hưởng lợi từ chúng, nên về cơ bản tôi đã kỳ vọng họ sẽ tài trợ hằng năm
    [1] https://freebsdfoundation.org/our-donors/donors/?donationYea...

    • Tất nhiên sẽ tốt nếu Amazon đóng góp nhiều hơn, nhưng việc không có tên trong danh sách nhà tài trợ của FreeBSD Foundation không có nghĩa là họ không hỗ trợ FreeBSD
      Ví dụ, khoản tiền trả cho tôi không đi qua Foundation. Nếu phải đoán, trong số hoạt động phát triển FreeBSD được tài trợ bằng tiền doanh nghiệp, phần do Foundation hỗ trợ có lẽ khoảng 10%
      10% đó quan trọng vì có thể tập trung vào “những gì FreeBSD cần” chứ không phải cụ thể là “những gì công ty X cần”, nhưng dù vậy vẫn chỉ là một phần nhỏ
    • Câu chuyện này không cho thấy toàn cảnh
      Thứ nhất, nó chỉ cho thấy ảnh chụp nhanh các khoản quyên góp cho Foundation trong một năm cụ thể, nên dĩ nhiên không thể hiện lịch sử quyên góp
      Thứ hai, nó cũng không cho thấy đóng góp phát triển. Những nội dung như vậy thường có thể xem tóm tắt trong ghi chú phát hành của từng bản [1]
      [1] https://www.freebsd.org/releases/
    • Tôi thắc mắc vì sao Microsoft lại tài trợ. Phần mở rộng Hyper-V không hoàn thiện như trên Linux, và cũng không có bản port .NET do Microsoft hỗ trợ
      Tôi cũng không nghĩ ra dịch vụ Microsoft nào, dù là cloud hay không, chạy trên *BSD
    • Trong nhóm FAANG, Amazon thuộc dạng làm ít nhất cho phần mềm tự do và nguồn mở

  • Tôi từng muốn dùng FreeBSD làm gateway/tường lửa/DNS/DHCP server ở nhà, nhưng có vẻ không có driver cho NIC 10GbE của tôi nên cuối cùng đã chọn Nix
    Rất lâu trước đây tôi từng dùng FreeBSD làm workstation và đó là một trải nghiệm khá đáng nhớ. Thật vui khi thấy nó vẫn tiếp tục chạy bền bỉ

    • Hạ tầng công ty và cá nhân của tôi đều dùng FreeBSD. Trên FreeBSD, Intel NIC đáng tin cậy 100%, nên tôi chỉ dùng chúng
      Realtek có vẻ vẫn hỏng khi chịu tải, dù các kỹ sư FreeBSD bảo trì driver đã rất nỗ lực. Tôi không phàn nàn, tôi tôn trọng nỗ lực của họ
      Đó là cái giá nhỏ phải trả, và giúp tôi không phải cài một hệ điều hành kém ổn định hơn

  • Tôi nhớ vào khoảng thời FreeBSD 7 hay 8, driver FreeBSD cho những thứ như card Wi‑Fi Atheros từng tốt hơn Linux
    Tôi vẫn thích FreeBSD cho đến khoảng năm 2021, nhưng điều đó thay đổi khi máy tính có các lõi CPU khác nhau trộn lẫn trở nên phổ biến. Ban đầu tôi mua một chiếc RockPro64 có 2 lõi big và 4 lõi little, rồi sau đó mua Intel Alder Lake
    Theo tôi hiểu, scheduler của FreeBSD vẫn chưa xử lý đúng các cấu hình như vậy, nên có vẻ kéo cả hệ thống xuống mẫu số chung thấp nhất theo các lõi chậm

  • Tò mò thôi, ai là người dùng chính của FreeBSD/EC2 nhỉ?

    • Hoàn toàn không biết. Nói nghiêm túc, những người dùng liên hệ với tôi có lẽ chỉ chiếm khoảng 0,1% toàn bộ cơ sở người dùng FreeBSD/EC2
      Tôi thật sự muốn biết ai đang dùng FreeBSD trên EC2
    • Netflix chỉ dùng trên thiết bị edge thôi à?

  • Đây là bài viết cho thấy rất rõ cách hoạt động của việc tài trợ mã nguồn mở từ doanh nghiệp

  • Ai đang dùng FreeBSD có thể giải thích niche mà FreeBSD lấp đầy trong không gian Unix là gì không? Tại sao lại là FreeBSD chứ không phải OpenBSD hay NetBSD đơn giản và nhất quán hơn?
    Nếu câu trả lời là hỗ trợ những thứ như ZFS, driver Nvidia, ELF, thì tại sao không dùng Linux? Tôi hiểu rõ vấn đề của GNU, nhưng ngay cả những thứ như Musl Void cũng có vấn đề sao?
    Tôi thật sự tò mò. Với tôi, FreeBSD tồn tại như một kiểu vùng bóng mờ; tôi vẫn chưa nắm bắt chính xác bản sắc cốt lõi khiến nó tiếp tục vận hành, nhưng tôi biết nó nằm đâu đó

    • Tôi từng làm ở một công ty dịch vụ tài chính dùng FreeBSD cả trên EC2 lẫn bare metal trong datacenter tự quản. Hai tính năng luôn dùng là ZFS và jail
      Mỗi dịch vụ chạy trong jail riêng để cách ly, và một server không quá mạnh cũng có thể chạy tất cả dịch vụ, nên cực kỳ hiệu quả về chi phí
      Đến một thời điểm, chúng tôi migration lên cloud để có cấu hình hybrid, và khi dùng lẫn Linux (k8s) với FreeBSD thì chi phí tăng vọt. Ở datacenter, bạn phải tự mua và thay đĩa, phải ứng phó với những tình huống như hỏa hoạn, và chỉ hiện diện trong một quốc gia; còn AWS cung cấp multi-region cùng nhiều tính năng tốt, và giá cũng tương xứng
      Chúng tôi không tận dụng ZFS quá sâu, nhưng có một lần lớn được cứu khi lỡ xóa một bảng trong DB production: rollback ngay về snapshot ZFS trước đó. Có mất một ít dữ liệu, nhưng với ứng dụng đó uptime quan trọng hơn nên không phải vấn đề lớn. Tôi nhớ là cũng dùng ZFS cho backup
      Tôi đã dùng dtrace vài lần để troubleshoot vấn đề production, và khi đưa Linux vào cụm server FreeBSD, mỗi team tự nhiên chọn một distro khác nhau, thành ra một kiểu sở thú. Dùng FreeBSD trên server thì chỉ có một biến thể
      Tôi vẫn dùng và thích cả hai, nhưng tôi thật sự thích việc FreeBSD là kernel và hệ điều hành được tích hợp thành một thể thống nhất
    • Theo kinh nghiệm của tôi, FreeBSD cung cấp sự cân bằng tốt giữa những yếu tố mà OpenBSD và NetBSD lần lượt coi trọng
      Về mặt lịch sử, FreeBSD ưu tiên CPU Intel, NetBSD mạnh hơn về tính portable, FreeBSD cũng có bảo mật vững chắc, nhưng OpenBSD tập trung hơn vào bảo mật
      Hỗ trợ ZFS của FreeBSD thật sự có thể thay đổi cuộc chơi. Theo tôi biết, Nvidia chỉ mới gần đây cung cấp driver FreeBSD native, còn trong thời gian dài phải cần đến tính năng tương thích kernel Linux của FreeBSD
      Nói cách khác, FreeBSD kết hợp tốt các tính năng mà các BSD khác cung cấp, đồng thời cực kỳ ổn định trên nền tảng phần cứng tôi chủ yếu dùng
    • FreeBSD thiên về throughput theo cách mà OpenBSD chắc chắn không phải, và tôi nghĩ NetBSD cũng không
      NetBSD cạnh tranh bằng tính portable, và có vẻ không dành nhiều thời gian để giữ throughput mạng ở mức cao
      Nhìn chung, tất cả BSD đều ít thay đổi hơn nhiều; điều này có ưu nhược điểm, nhưng tôi nghĩ chúng tốt hơn làm nền tảng để tích hợp
    • FreeBSD có hỗ trợ ZFS tốt hơn Linux vì không vướng vấn đề giấy phép
    • FreeBSD có cơ sở người dùng lớn hơn nhiều so với OpenBSD hay NetBSD. Không thể so sánh được
      Danh mục phần mềm cũng lớn hơn nhiều, và hoàn toàn có thể dùng như một hệ điều hành desktop hiện đại hằng ngày. Với hai cái còn lại thì khó nói như vậy
      Nếu hỏi tại sao không dùng Linux, thì vì tôi không muốn Linux. Nó bị đè nặng quá nhiều bởi lợi ích doanh nghiệp