2025-07-17 Top Stories

2025-07-17 Top Stories #

  1. Lần đầu tiên thị phần Linux trên thị trường máy tính để bàn Hoa Kỳ vượt quá 5%, chủ yếu nhờ các vấn đề của Windows, sự phổ biến của Steam Deck và những cải tiến của Linux.
  2. Hacker Ukraine hợp tác với tình báo quân sự, đã phá hủy thành công cơ sở hạ tầng IT của nhà sản xuất máy bay không người lái Nga Gaskar Integration, dẫn đến gián đoạn sản xuất và hoạt động.
  3. Trình phân giải DNS công cộng 1.1.1.1 của Cloudflare bị gián đoạn toàn cầu do lỗi cấu hình, ảnh hưởng kéo dài 62 phút, không phải do tấn công hoặc BGP hijacking.
  4. Bằng cách thực hiện các chứng minh logic quy mô nhỏ trong tâm trí, có thể giúp lập trình viên viết mã hiệu quả và chính xác hơn, giảm thời gian gỡ lỗi.
  5. Phiên bản Firefox 141 của Mozilla hỗ trợ WebGPU trên Windows, cải thiện hiệu suất xử lý đồ họa của các ứng dụng web, dự kiến sẽ mở rộng sang các nền tảng khác.
  6. Phiên bản Helix Editor 25.07 được phát hành, bổ sung trình duyệt tệp, màu tài liệu LSP và các tính năng mới của chế độ lệnh, với sự tham gia phát triển của 195 người đóng góp.
  7. Mozilla khởi động chiến dịch thu thập ý kiến người dùng, mời người dùng tham gia thảo luận về định hướng phát triển tương lai của Firefox và tổ chức sự kiện AMA cộng đồng.
  8. Tác giả chia sẻ kinh nghiệm chuyển sang sử dụng Python, cho rằng cú pháp của nó đơn giản và hệ sinh thái hoàn thiện, phù hợp để xây dựng các ứng dụng AI.
  9. Tilck là một kernel nhỏ tương thích với Linux, hỗ trợ kiến trúc i686 và RISCV64, phù hợp cho mục đích thử nghiệm và giáo dục ở chế độ kernel.
  10. Nghiên cứu GPUHammer cho thấy tấn công Rowhammer vào bộ nhớ GPU là khả thi trên thực tế, có thể sửa đổi dữ liệu của người dùng khác trong môi trường chia sẻ.

Linux Đạt 5% Thị Phần Máy Tính Để Bàn tại Hoa Kỳ #

Linux Reaches 5% Desktop Market Share in USA

https://ostechnix.com/linux-reaches-5-desktop-market-share-in-usa/

Linux Đạt 5% Thị Phần Máy Tính Để Bàn Tại Mỹ

Linux đã chính thức vượt qua cột mốc quan trọng 5% thị phần máy tính để bàn tại Hoa Kỳ, đây là một cột mốc quan trọng đối với lĩnh vực mã nguồn mở và cộng đồng Linux. Nhiều người có thể coi Linux là một lựa chọn thích hợp, nhưng dữ liệu mới cho thấy một sự thay đổi lớn đang diễn ra.

Dữ liệu Thị phần: Linux Đạt 5,03% tại Hoa Kỳ

Theo số liệu thống kê toàn cầu của StatCounter, tính đến tháng 6 năm 2025, Linux chiếm 5,03% thị phần hệ điều hành máy tính để bàn tại Hoa Kỳ. Dữ liệu này cho thấy sự tăng trưởng đáng kể của Linux, trong khi thị phần của Windows đã giảm gần 13% so với cùng kỳ năm ngoái. Trên thị trường máy tính để bàn Hoa Kỳ, Windows vẫn chiếm ưu thế với 63,2% thị phần, OS X và macOS cộng lại chiếm khoảng 24%, Linux chiếm 5,03%, danh mục chưa xác định là 4,76% và Chrome OS là 2,71%.

Tại Sao Ngày Càng Có Nhiều Người Chuyển Sang Linux?

Sự tăng trưởng thị phần của Linux không phải là ngẫu nhiên, có một số lý do rõ ràng dẫn đến việc Linux ngày càng trở nên phổ biến:

  1. Vấn đề của Windows: Nhiều người dùng cảm thấy mệt mỏi với các động thái của Microsoft, vòng đời của Windows 10 sắp kết thúc và mọi người đang tìm kiếm các giải pháp thay thế thay vì chỉ nâng cấp phần cứng cho Windows 11. Những lo ngại về xâm phạm quyền riêng tư, phần mềm quảng cáo và các bản cập nhật bắt buộc cũng đang thúc đẩy người dùng rời xa Windows.
  2. Lĩnh vực Mới của Game: Thiết bị chơi game Steam Deck dựa trên hệ thống Linux, mang đến cho Linux một nhóm game thủ mới, những người thích sự mạnh mẽ và linh hoạt của Linux.
  3. Sự Phát Triển của Chính Linux: Linux ngày càng trở nên thân thiện với người dùng hơn, các bản phân phối như Ubuntu và Linux Mint đã có những cải tiến đáng kể về giao diện. Quyền riêng tư là ưu tiên hàng đầu của nhiều người, Linux cung cấp một giải pháp thay thế mã nguồn mở tuyệt vời. Linux có thể làm cho phần cứng cũ trở nên sống động, kéo dài tuổi thọ của máy tính. Hệ sinh thái phần mềm không ngừng phát triển, các công cụ như Wine nâng cao khả năng tương thích với nhiều ứng dụng phổ biến.

Thị Phần Linux Có Thể Cao Hơn

Mặc dù thị phần 5,03% là rất đáng khích lệ, nhưng số lượng người dùng Linux thực tế có thể cao hơn. Nhiều người dùng Linux coi trọng quyền riêng tư sử dụng các công cụ có thể ẩn hệ điều hành hoặc thay đổi user agent, điều này có thể dẫn đến việc một số người dùng Linux bị nhận dạng sai. Ngoài ra, danh mục “chưa xác định” có thể bao gồm một phần các hệ thống Linux đang chạy một cách kín đáo. Chrome OS, mặc dù được liệt kê riêng, nhưng thực tế dựa trên ChromiumOS mã nguồn mở với nhân Linux. Nếu thị phần của Linux và Chrome OS được hợp nhất, thị phần của gia đình Linux sẽ đạt 7,74%.

Nhiều Người Dùng Chuyển Sang Linux Hơn

Thị phần 5% không chỉ là một thành tích đáng tự hào, nó còn đánh dấu sự quan tâm ngày càng tăng đối với các hệ điều hành thay thế. Điều này cho thấy nhu cầu về các giải pháp mã nguồn mở đang tăng lên trong số những người dùng máy tính để bàn. Khả năng hiển thị của sự tăng trưởng này có thể mang lại “hiệu ứng quả cầu tuyết” cho cộng đồng Linux. Khi ngày càng có nhiều người áp dụng Linux, nhiều người dùng nhiệt tình và các nhà phát triển lành nghề hơn bị thu hút, đóng góp vào sự cải tiến liên tục của Linux, làm cho hệ sinh thái trở nên mạnh mẽ hơn.

Hướng Tới Tương Lai

Quá trình phát triển của Linux diễn ra chậm và ổn định, đồng thời tăng tốc trong những năm gần đây. Phải mất tám năm để tăng từ 1% lên 2%, 2,2 năm để tăng từ 2% lên 3% và chỉ 0,7 năm để tăng từ 3% lên 4%. Giờ đây, Linux đã vượt quá 5% thị phần tại Hoa Kỳ, sự tăng trưởng theo cấp số nhân này cho thấy chúng ta đang ở trong một xu hướng tăng đầy hứa hẹn. Đây là một kỷ nguyên Linux thú vị và tác giả tin rằng điều tốt nhất vẫn còn ở phía trước.

HN | Độ nóng: 885 điểm | 521 bình luận | Tác giả: marcodiego #

https://news.ycombinator.com/item?id=44580682

  • Thị phần Linux desktop tăng có thể là do mọi người không còn sử dụng máy tính truyền thống nữa mà chuyển sang điện thoại và máy tính bảng
  • Thị phần Linux desktop tăng lên do sự phổ biến của Steam Deck, nhưng việc Microsoft tối ưu hóa game Windows có thể ảnh hưởng đến xu hướng này
  • Steam Deck chạy môi trường Linux desktop, khác với Android
  • Hệ thống Android không thực sự chạy nhân Linux, mà có rất nhiều mã vá
  • Mặc dù Android và desktop Linux khác nhau ở cấp độ kernel, nhưng chúng dùng chung kernel Linux
  • Có thể chạy phần mềm Linux điển hình trên Android thông qua Termux
  • Waydroid cho phép chạy phần mềm Android trên điện thoại GNU/Linux
  • Từ góc độ người dùng, độ nặng nhẹ của container ảo không quan trọng
  • Ngay cả khi Android và desktop Linux dùng chung ở cấp độ kernel, chúng không tương thích ở cấp độ user space
  • Việc dùng chung kernel Linux có ý nghĩa quan trọng trong thực tế, ví dụ: các cải tiến kernel từ phát triển Android có thể mang lại lợi ích cho các bản phân phối Linux tiêu chuẩn
  • Việc biên dịch mainline Linux kernel khiến người ta nhận ra vai trò của kernel vượt xa những gì người ta tưởng tượng
  • Việc thống kê riêng Android và desktop Linux là vì mục đích thuận tiện, chứ không phải vì lý do kỹ thuật
  • Khi thảo luận về thị phần Linux, điều quan trọng là phải tập trung vào việc sử dụng kernel, điều này phụ thuộc vào trọng tâm cụ thể
  • Windows Subsystem for Linux (WSL) có được tính vào thị phần Linux hay không phụ thuộc vào mục đích đánh giá

Tin tặc Ukraine phá hủy cơ sở hạ tầng CNTT của nhà sản xuất máy bay không người lái Nga #

Ukrainian hackers destroyed the IT infrastructure of Russian drone manufacturer

https://prm.ua/en/ukrainian-hackers-destroyed-the-it-infrastructure-of-a-russian-drone-manufacturer-what-is-known/

Tin tặc Ukraine phá hủy cơ sở hạ tầng CNTT của nhà sản xuất máy bay không người lái Nga: Những gì đã biết

Vào lúc 15:53 ngày 15 tháng 7 năm 2025, tin tặc Ukraine, hợp tác với bộ phận tình báo quân sự, đã vô hiệu hóa thành công hoạt động của Gaskar Integration, một trong những nhà sản xuất máy bay không người lái lớn nhất của Nga. Cuộc tấn công này đã phá hủy hơn 47TB dữ liệu quan trọng, khóa các hệ thống nội bộ và dừng hoạt động hiệu quả của nhà máy.

Theo “Pryamiy” trích dẫn nguồn tin tình báo quân sự, nhóm tin tặc BO Team và nhóm Liên minh mạng Ukraine, với sự hỗ trợ tình báo của các chuyên gia tình báo quân sự, đã tấn công thành công cơ sở hạ tầng mạng và máy chủ của Gaskar Integration, một trong những nhà cung cấp máy bay không người lái chính cho quân đội Nga.

Thông tin về nhóm tin tặc “BO Team” tham gia cuộc tấn công đang lan truyền trong cộng đồng hoạt động mạng trên Telegram.

Tội phạm mạng Ukraine đã thu được hơn 47TB thông tin kỹ thuật liên quan đến việc sản xuất máy bay không người lái của Nga. Bao gồm dữ liệu cho thấy nhà sản xuất máy bay không người lái Nga hợp tác chặt chẽ với Trung Quốc. Tất cả thông tin trên máy chủ của nhà sản xuất đã bị phá hủy, bao gồm 10TB tài liệu sao lưu.

Do cuộc tấn công mạng, Internet, các chương trình sản xuất và kế toán của doanh nghiệp không thể hoạt động, và công việc của trung tâm R&D của Gaskar đã bị tê liệt. Ngoài ra, tất cả các cửa của nhà máy sản xuất máy bay không người lái đều bị khóa và nhân viên buộc phải sử dụng lối thoát hiểm.

Dữ liệu bị đánh cắp bao gồm các bảng câu hỏi bảo mật của nhân viên công ty và quan trọng nhất là tài liệu kỹ thuật hoàn chỉnh về sản xuất máy bay không người lái, đã được chuyển giao cho các chuyên gia liên quan của Lực lượng vũ trang Ukraine.

Chúng tôi xin nhắc bạn rằng các chuyên gia mạng của Tổng cục Tình báo chính của Bộ Quốc phòng Ukraine đã đóng cửa trang web của Đường sắt Nga, thực hiện một cuộc tấn công mạnh mẽ.

Trước đó, các chuyên gia mạng GUR đã tấn công Regiontransservice của Nga và đóng cửa tất cả các dịch vụ.

HN | Độ nóng: 589 điểm | 401 bình luận | Tác giả: doener #

https://news.ycombinator.com/item?id=44579902

  • Việc xây dựng lại toàn bộ cơ sở hạ tầng là một nhiệm vụ to lớn, đặc biệt khi nó được quản lý bởi nhiều người trong nhiều năm.
  • Việc khôi phục cơ sở hạ tầng từ đầu rất khó khăn, đặc biệt khi liên quan đến việc cần phải nhớ lại tại sao một số cài đặt lại như vậy.
  • Ngay cả khi có tài liệu và kiểm thử, tình hình thực tế cũng có thể rất phức tạp.
  • Một phòng thí nghiệm cá nhân đã nhanh chóng khôi phục hoạt động, dựa vào các bản sao lưu và phần cứng cũ, sau khi thiết bị bị cảnh sát tịch thu.
  • Cảnh sát tiến hành khám xét và tịch thu mà không có bằng chứng đầy đủ, gây ra sự khó chịu lớn cho các bên liên quan.
  • Hành vi khám xét và tịch thu của cảnh sát có thể gây ra những ảnh hưởng lâu dài đến cuộc sống cá nhân, thậm chí dẫn đến chấn thương tâm lý.
  • Hành vi của cảnh sát có thể dẫn đến việc mọi người mất niềm tin vào cảnh sát và hệ thống tư pháp hình sự.
  • Ngay cả khi cuối cùng các vật phẩm bị tịch thu được trả lại, các bên liên quan cũng có thể cảm thấy tức giận và bất lực vì thời gian chờ đợi và sự không chắc chắn kéo dài.

Sự cố Cloudflare 1.1.1.1 ngày 14 tháng 7 năm 2025 #

Cloudflare 1.1.1.1 Incident on July 14, 2025

https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/

Vào ngày 14 tháng 7 năm 2025, Cloudflare đã thực hiện các thay đổi đối với cấu trúc liên kết dịch vụ của mình, dẫn đến sự cố ngừng hoạt động của dịch vụ 1.1.1.1 ở biên, khách hàng sử dụng trình phân giải DNS công cộng 1.1.1.1 đã gặp phải thời gian ngừng hoạt động là 62 phút, đồng thời dịch vụ Gateway DNS cũng gặp phải tình trạng suy giảm dịch vụ gián đoạn. Dịch vụ phân giải 1.1.1.1 của Cloudflare không thể truy cập Internet từ 21:52 UTC và kết thúc vào 22:54 UTC, hầu hết người dùng 1.1.1.1 trên toàn cầu đều bị ảnh hưởng. Đối với nhiều người dùng, việc không thể sử dụng trình phân giải 1.1.1.1 để phân giải tên miền có nghĩa là hầu hết tất cả các dịch vụ Internet đều không thể sử dụng được. Sự cố này có thể được quan sát trên Cloudflare Radar.

Sự cố này là do lỗi cấu hình trong hệ thống kế thừa được sử dụng để duy trì quảng cáo địa chỉ IP của Cloudflare lên Internet. Đây là một sự cố toàn cầu. Trong thời gian ngừng hoạt động, trình phân giải 1.1.1.1 của Cloudflare không khả dụng trên toàn cầu. Cloudflare xin lỗi sâu sắc về sự cố này. Nguyên nhân gốc rễ là do lỗi cấu hình nội bộ, chứ không phải là kết quả của một cuộc tấn công hoặc BGP hijacking. Trong blog này, chúng ta sẽ thảo luận về nguyên nhân thất bại, tại sao nó xảy ra và những biện pháp chúng tôi đang thực hiện để đảm bảo rằng tình huống này không xảy ra nữa.

Bối cảnh: Cloudflare đã ra mắt dịch vụ phân giải DNS công cộng 1.1.1.1 vào năm 2018. Kể từ khi được công bố, 1.1.1.1 đã trở thành một trong những địa chỉ IP phân giải DNS phổ biến nhất, bất kỳ ai cũng có thể sử dụng miễn phí. Hầu hết tất cả các dịch vụ của Cloudflare đều được cung cấp cho Internet thông qua một phương pháp định tuyến được gọi là Anycast, một công nghệ nổi tiếng được thiết kế để cho phép các dịch vụ phổ biến được cung cấp ở nhiều vị trí khác nhau trên Internet để tăng dung lượng và hiệu suất. Đây là cách tốt nhất để đảm bảo rằng chúng tôi có thể quản lý lưu lượng truy cập của mình trên toàn cầu, nhưng đồng thời, nó cũng có nghĩa là nếu có vấn đề với việc quảng cáo không gian địa chỉ này, nó có thể dẫn đến một sự cố toàn cầu.

Cloudflare thông báo các tuyến Anycast này đến Internet để gửi lưu lượng truy cập đến các địa chỉ này và được phục vụ bởi các trung tâm dữ liệu của Cloudflare. Hầu hết các dịch vụ của Cloudflare đều được cung cấp trên toàn cầu, chẳng hạn như trình phân giải DNS công cộng 1.1.1.1, nhưng một phần dịch vụ được giới hạn đặc biệt ở một khu vực cụ thể. Các dịch vụ này là một phần của bộ bản địa hóa dữ liệu (DLS) của chúng tôi, cho phép khách hàng định cấu hình Cloudflare theo nhiều cách để đáp ứng các nhu cầu tuân thủ của họ ở các quốc gia và khu vực khác nhau. Một trong những cách Cloudflare quản lý các nhu cầu khác nhau này là đảm bảo rằng các địa chỉ IP dịch vụ chính xác chỉ có thể được Internet truy cập ở những nơi cần thiết, để lưu lượng truy cập của bạn có thể được xử lý chính xác trên toàn cầu. Một dịch vụ cụ thể có một “cấu trúc liên kết dịch vụ” phù hợp, nghĩa là lưu lượng truy cập của dịch vụ chỉ nên được định tuyến đến một nhóm vị trí cụ thể.

Dòng thời gian sự kiện:

  • 6 tháng 6 năm 2025 17:38: Vấn đề được đưa vào, không có ảnh hưởng. Đã thực hiện thay đổi cấu hình cho dịch vụ DLS chưa được đưa vào sản xuất. Thay đổi cấu hình này vô tình bao gồm tham chiếu đến dịch vụ phân giải 1.1.1.1, cũng như tiền tố liên quan đến dịch vụ phân giải 1.1.1.1.
  • 14 tháng 7 năm 2025 21:48: Ảnh hưởng bắt đầu. Đã thực hiện thay đổi cấu hình cho cùng một dịch vụ DLS. Thay đổi này gắn một vị trí thử nghiệm vào một dịch vụ không sản xuất; bản thân vị trí này không hoạt động, nhưng thay đổi này đã kích hoạt việc làm mới cấu hình mạng toàn cầu.
  • 14 tháng 7 năm 2025 21:52: Lưu lượng DNS toàn cầu bắt đầu giảm xuống dịch vụ phân giải 1.1.1.1.
  • 14 tháng 7 năm 2025 21:54: Sự kiện không nhân quả liên quan: BGP origin hijacking 1.1.1.0/24 bị lộ do Cloudflare rút lại các tuyến. Đây không phải là nguyên nhân gây ra lỗi dịch vụ, mà là một vấn đề không liên quan vì tiền tố này đột nhiên trở nên hiển thị do Cloudflare rút lại.
  • 14 tháng 7 năm 2025 22:01: Ảnh hưởng được phát hiện. Cảnh báo sức khỏe dịch vụ nội bộ bắt đầu phát ra cho trình phân giải 1.1.1.1.
  • 14 tháng 7 năm 2025 22:01: Sự kiện được tuyên bố.
  • 14 tháng 7 năm 2025 22:20: Khắc phục được triển khai. Bắt đầu thực hiện khôi phục để khôi phục cấu hình trước đó. Để đẩy nhanh việc khôi phục hoàn toàn dịch vụ, một thao tác được kích hoạt thủ công đã được xác minh tại vị trí thử nghiệm, sau đó được thực hiện.
  • 14 tháng 7 năm 2025 22:54: Ảnh hưởng kết thúc. Cảnh báo trình phân giải được xóa, lưu lượng DNS khôi phục về mức bình thường trên tiền tố trình phân giải.
  • 14 tháng 7 năm 2025 22:55: Sự kiện được giải quyết.

Ảnh hưởng: Bất kỳ lưu lượng nào được gửi đến Cloudflare thông qua dịch vụ phân giải 1.1.1.1 của các địa chỉ IP này đều bị ảnh hưởng. Các tuyến tương ứng của các địa chỉ này cũng bị ảnh hưởng.

Mô tả lỗi kỹ thuật và cách xảy ra: Lỗi dịch vụ phân giải 1.1.1.1: Như đã đề cập ở trên, thay đổi cấu hình vào ngày 6 tháng 6 đã đưa một lỗi vào cấu trúc liên kết dịch vụ của dịch vụ DLS tiền sản xuất. Vào ngày 14 tháng 7, một thay đổi thứ hai đã được thực hiện đối với dịch vụ: một vị trí trung tâm dữ liệu ngoại tuyến đã được thêm vào dịch vụ…

HN | Độ nóng: 527 điểm | 352 bình luận | Tác giả: nomaxx117 #

https://news.ycombinator.com/item?id=44578490

  • Nhiều người dùng không thể sử dụng trình phân giải 1.1.1.1 để phân giải tên miền, dẫn đến việc không thể sử dụng tất cả các dịch vụ Internet.
  • Nếu danh sách máy chủ DNS có hai máy chủ DNS, thì máy chủ thứ hai có bị sập không, nếu không, tại sao không chuyển sang máy chủ thứ hai.
  • Vấn đề với 1.1.1.1 là việc sử dụng công nghệ Anycast thay vì bản thân DNS.
  • Cloudflare khuyến nghị người dùng định cấu hình 1.1.1.1 và 1.0.0.1 làm máy chủ DNS, nhưng sự cố này đã khiến quảng cáo BGP của Cloudflare cho hai đoạn IP này không hợp lệ.
  • Nên sử dụng Cloudflare làm một trong các máy chủ DNS, máy còn lại sử dụng một công ty hoàn toàn khác.
  • Khi thiết lập dịch vụ DNS thủ công trong mạng Wi-Fi công cộng, bạn cần tắt và bật thường xuyên, rất rắc rối.
  • DNS chỉ là một dịch vụ tra cứu, có thể được lọc, nhưng cuối cùng là “nguồn thực”.
  • Trong cài đặt Android, bạn chỉ có thể cung cấp tên máy chủ của một nhà cung cấp DNS riêng, không thể cung cấp trực tiếp địa chỉ IP.
  • DNS riêng của Android đề cập đến ‘DNS over HTTPS’, thường chỉ chấp nhận tên máy chủ.
  • Android 11 trở lên hỗ trợ DoH và DoT.
  • Lưu lượng DoH (DNS-over-HTTPS) tương đối ổn định, vì hầu hết người dùng DoH sử dụng tên miền cloudflare-dns.com để truy cập trình phân giải DNS công cộng.
  • Máy chủ DoH có thể phân giải thành nhiều địa chỉ IP, thậm chí phân giải thành các địa chỉ IP khác nhau cho các máy khách khác nhau.
  • Nhiều máy khách không hỗ trợ máy chủ dự phòng DoH giữa các tổ chức, nhưng DNS thông thường thì có.
  • Một số thiết bị/bộ định tuyến không có máy chủ DNS chính và dự phòng, mà luân phiên chúng một cách ngẫu nhiên, điều này có nghĩa là người dùng sử dụng Cloudflare một nửa thời gian và Google DNS nửa còn lại.

Để trở thành một lập trình viên giỏi hơn, hãy viết những chứng minh nhỏ trong đầu #

To be a better programmer, write little proofs in your head

https://the-nerve-blog.ghost.io/to-be-a-better-programmer-write-little-proofs-in-your-head/

Bài viết này được Matthew Prast viết vào ngày 14 tháng 7 năm 2025, với chủ đề làm thế nào để trở thành một lập trình viên giỏi hơn bằng cách thực hiện các chứng minh nhỏ trong đầu. Bài viết đưa ra một khái niệm đơn giản: trong quá trình lập trình, hãy xây dựng các chứng minh trong đầu để đảm bảo mã hoạt động như mong đợi. Phương pháp này nghe có vẻ đơn giản, nhưng việc thực hành nó mà không làm gián đoạn quy trình lập trình đòi hỏi rất nhiều luyện tập. Khi đã thành thạo, bạn sẽ thấy mã hoạt động bình thường ngay từ lần thử đầu tiên hoặc thứ hai, cảm giác giống như phép thuật.

Bài viết đề cập đến một số phương pháp suy luận trong lập trình:

  1. Tính đơn điệu (Monotonicity): Trong toán học, hàm đơn điệu là hàm không “lùi bước”, tức là hàm đơn điệu tăng chỉ có thể tăng hoặc giữ nguyên, trong khi hàm đơn điệu giảm chỉ có thể giảm hoặc giữ nguyên. Trong lập trình, khái niệm tính đơn điệu mơ hồ hơn, nhưng nó nắm bắt được ý tưởng về một quá trình chỉ có thể tiến theo một hướng. Ví dụ, checkpointing là một ví dụ về tính đơn điệu. Nếu bạn có một script cần thực hiện nhiều tác vụ theo trình tự, bạn có thể giữ một số thông tin trạng thái trên đĩa để ghi lại số lượng tác vụ bạn đã hoàn thành. Nếu script bị crash, nó có thể kiểm tra trạng thái trên đĩa, sau đó khởi động lại từ trạng thái chưa thực hiện sớm nhất. Checkpointing có nghĩa là con trỏ “bước hiện tại” trong script chỉ có thể di chuyển về phía trước, vì script không thể lùi lại và thực hiện lại các bước đã hoàn thành. Theo nghĩa này, script tiến triển đơn điệu, và nếu script cuối cùng hoàn thành thành công, nó sẽ thực hiện chính xác từng bước một lần.
  2. Tiền điều kiện và hậu điều kiện (Pre- and post-conditions): Tiền điều kiện và hậu điều kiện là các phương pháp chỉ định các ràng buộc về hành vi của hàm. Tiền điều kiện của một hàm là điều kiện được giả định là đúng trước khi hàm chạy, đây có thể là các điều kiện về đầu vào của hàm, hoặc là các tuyên bố chung hơn về trạng thái hoặc môi trường của chương trình. Hậu điều kiện của một hàm là điều kiện được giả định là đúng sau khi hàm trả về. Nếu tiền điều kiện của hàm đúng trước khi hàm chạy, và hậu điều kiện không đúng sau khi hàm hoàn thành, thì hàm chưa được triển khai chính xác, ít nhất là theo các ràng buộc đã chỉ định. Những khái niệm này rất đơn giản (thậm chí hiển nhiên), bản thân chúng không phải là kỹ thuật chứng minh, nhưng chỉ cần theo dõi chúng một cách hình thức có thể giúp ích cho việc suy luận của bạn.
  3. Bất biến (Invariants): Bất biến của code là một điều kiện luôn đúng trước, trong và sau khi code chạy, bất kể điều gì xảy ra. Giống như tiền điều kiện và hậu điều kiện, bất biến có thể liên quan đến hầu hết mọi thứ. Suy nghĩ về tính nhất quán dưới dạng bất biến rất hữu ích - trong những trường hợp này, bất biến là “cấu trúc dữ liệu này nhất quán/hợp lệ”, và bạn cần chứng minh với bản thân rằng code duy trì bất biến này trong mọi trường hợp. Một cách đơn giản là chia code thành các “bước” nguyên tử và chứng minh rằng mỗi bước riêng lẻ duy trì bất biến. Sau đó, bạn có thể kết luận rằng bất kể bước nào chạy hoặc thứ tự chúng chạy như thế nào, bất biến sẽ được duy trì. Một trong những bất biến nổi tiếng nhất là phương trình kế toán, nền tảng của kế toán kép. Phương trình kế toán nói một cách đại khái rằng tổng số tiền ghi nợ trên sổ sách của công ty phải bằng tổng số tiền ghi có. Rất dễ chứng minh rằng nếu kế toán kép được thực hiện chính xác, nó sẽ duy trì bất biến này: đối với mỗi giao dịch, sự gia tăng (hoặc giảm) của tất cả các tài khoản có phải bằng sự gia tăng (hoặc giảm) của tất cả các tài khoản nợ. Rất dễ thấy rằng nếu bên nợ và bên có cân bằng trước giao dịch, thì chúng cũng sẽ cân bằng sau giao dịch. Do đó, bất biến luôn được duy trì.
  4. Cô lập (Isolation): Tác giả tin chắc rằng “nghề thủ công” phần mềm (hoặc nên như vậy) tập trung vào việc không phá vỡ bất cứ điều gì, sửa đổi hoặc tăng cường các hệ thống hiện có. Khi thực hiện các sửa đổi đối với cơ sở code, việc biết cách chứng minh rằng hành vi bạn không có ý định thay đổi thực sự không thay đổi là rất hữu ích.

Bài viết nhấn mạnh rằng bằng cách thực hiện những suy luận này trong quá trình lập trình, có thể giúp các lập trình viên viết code nhanh hơn và chính xác hơn.

HN | Độ nóng: 433 điểm | 161 bình luận | Tác giả: mprast #

https://news.ycombinator.com/item?id=44573409

  • Tìm kiếm nhị phân và các biến thể của nó. Việc tìm kiếm nhị phân điểm cuối bên trái và điểm cuối bên phải rất khó mã hóa chính xác, cần xem xét tính bất biến của vòng lặp.
  • 90% lập trình viên chuyên nghiệp mắc lỗi khi triển khai tìm kiếm nhị phân thông thường, phổ biến nhất là vô tình rơi vào vòng lặp vô hạn.
  • Tính bất biến của vòng lặp là cách để thu được lợi ích tối đa từ các phương pháp hình thức mà không cần DSL.
  • Lỗi phổ biến nhất trong tìm kiếm nhị phân là vấn đề tràn số nguyên khi tính điểm giữa.
  • Kiểu int tích hợp của Python có độ chính xác tùy ý, vì vậy công thức tính toán tránh tràn không cần thiết trong Python.
  • Trong ngôn ngữ C, tràn số nguyên vẫn là một vấn đề, vì kiểu int không phù hợp để sử dụng làm chỉ mục.
  • Sử dụng tìm kiếm nhị phân làm câu hỏi phỏng vấn, người ta thấy rằng hầu hết các ứng viên có trình độ cao không thể viết một triển khai không có lỗi trong vòng 20 phút.
  • Nhiều người không thể viết đúng tìm kiếm nhị phân vì giao diện giảng dạy không phù hợp.
  • Cú pháp nửa khoảng trái kín phải hở của Python tránh được các vấn đề về ranh giới bao gồm.
  • Nhiều phương pháp cắt chuỗi tuân theo cú pháp này của Python, cú pháp cắt chuỗi của JavaScript, Java và Golang cũng tương tự.
  • Sử dụng tìm kiếm nhị phân làm câu hỏi phỏng vấn có thể không phải là một lựa chọn tốt, vì nó có thể chỉ sàng lọc ra những người đã luyện tập leetcode.
  • Điều quan trọng hơn trong một cuộc phỏng vấn là kiểm tra phương pháp giải quyết vấn đề của ứng viên, thay vì chỉ xem họ có thể giải quyết vấn đề ngay lập tức hay không.

Phát hành WebGPU trên Windows trong Firefox 141 #

Shipping WebGPU on Windows in Firefox 141

https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-on-windows-in-firefox-141/

Mozilla Gfx Team Blog đã đăng một bài viết mới, thông báo rằng trong phiên bản Firefox 141, người dùng Windows sẽ có thể trải nghiệm các tính năng của WebGPU. WebGPU là một giao diện xử lý đồ họa hiện đại, cho phép người dùng thực hiện các tính toán và kết xuất hiệu năng cao trên các trang web, điều này rất quan trọng để cải thiện hiệu suất của trò chơi trên web, trực quan hóa và tính toán cục bộ. Mozilla rất hào hứng với sự ra mắt của WebGPU và tin rằng nó sẽ cải thiện đáng kể giới hạn hiệu suất của các ứng dụng web.

Bài viết đề cập rằng người dùng có thể tìm thấy hướng dẫn về WebGPU tại webgpufundamentals.org, thử các ví dụ WebGPU và đọc tài liệu API trên MDN. WebGPU dựa trên hai tiêu chuẩn W3C: WebGPU và WGSL, Mozilla đã tham gia vào việc phát triển các tiêu chuẩn này từ năm 2017.

WebGPU đã có sẵn trên Google Chrome từ năm 2023 và dự kiến sẽ ra mắt trên Safari 26 vào mùa thu năm nay. Mặc dù Firefox 141 chỉ bật WebGPU trên Windows, nhưng Mozilla có kế hoạch mở rộng nó sang các nền tảng Mac và Linux trong vài tháng tới, và cuối cùng cũng sẽ hỗ trợ Android. Windows là nền tảng ưu tiên hàng đầu vì phần lớn người dùng đều ở đây, nhưng Mozilla cũng mong muốn kích hoạt WebGPU trên các nền tảng khác.

Triển khai WebGPU của Firefox dựa trên WGPU, một thư viện Rust cung cấp một giao diện thống nhất, có thể di động để truy cập các API đồ họa cấp thấp của nền tảng cơ bản, bao gồm Direct3D 12, Metal và Vulkan. WGPU là một dự án mã nguồn mở độc lập, Mozilla là một trong những người đóng góp chính. Nếu bạn là một nhà phát triển Rust quan tâm đến hỗ trợ WebGPU của Firefox, WGPU là một điểm khởi đầu tuyệt vời.

WebGPU là một API lớn và phức tạp. Ưu tiên hiện tại của Mozilla là đảm bảo các ứng dụng và trình diễn WebGPU có khả năng hiển thị cao có thể chạy trơn tru và tin rằng nó sẽ đáp ứng tốt nhiều trường hợp sử dụng trong Firefox 141. Tuy nhiên, vẫn còn rất nhiều việc phải làm để cải thiện hiệu suất và tuân thủ các thông số kỹ thuật. Ví dụ: Firefox sử dụng giao tiếp giữa các tiến trình không đệm để chuyển các yêu cầu từ nội dung web đến tiến trình sandbox GPU, điều này gây ra chi phí đáng kể. Vấn đề này đã được giải quyết trong Bug 1968122 và sẽ xuất hiện trong Firefox 142. Firefox hiện sử dụng bộ hẹn giờ khoảng thời gian để thông báo cho GPU khi nào tác vụ hoàn thành, điều này gây ra độ trễ đáng kể cho nhiều ứng dụng hoàn thành tác vụ nhanh chóng. Mozilla đang cải thiện điều này và theo dõi tiến trình trong Bug 1870699. Firefox vẫn chưa hỗ trợ phương thức importExternalTexture của WebGPU, phương pháp này cho phép GPU đọc trực tiếp nội dung video đã giải nén từ bộ giải mã. Bạn có thể theo dõi tiến trình trong Bug 1827116.

Bài viết kết luận bằng cách khuyến khích người dùng dùng thử WebGPU trong Firefox và báo cáo các vấn đề gặp phải trong thành phần WebGPU của Bugzilla. Mozilla mong muốn được thấy những gì người dùng có thể tạo ra khi sử dụng WebGPU trong Firefox.

HN | Độ nóng: 336 điểm | 137 bình luận | Tác giả: Bogdanp #

https://news.ycombinator.com/item?id=44579317

  • Thật thú vị khi nhóm Firefox triển khai chức năng WebGPU trên Windows
  • Có một công ty đang đưa Unreal Engine lên trình duyệt và xây dựng WebGPU RHI tùy chỉnh cho Unreal Engine 5
  • Đã cung cấp liên kết trình diễn kỹ thuật, nhưng hiện tại chỉ hoạt động trên các trình duyệt dựa trên Chromium và một số điện thoại Android
  • Một số người dùng gặp sự cố tải trên Android Chrome và Linux Firefox
  • WebGPU chưa được hỗ trợ trên Linux, đây có thể là nguyên nhân gây ra sự cố tải
  • Một người dùng hỏi liệu có phiên bản tương thích với Firefox hay không và liệu nó có hoạt động trong Firefox 141 trên Windows hay không
  • Một người dùng đề cập rằng họ cũng gặp sự cố tải trên Chrome và Safari trên macOS
  • Một người dùng đã chia sẻ một liên kết thay thế, liên kết này có thể tải nhanh hơn trên Chromium
  • Một người dùng cho rằng trải nghiệm sử dụng API đồ họa hiện đại không tốt bằng thời đại OpenGL, cần phải tạo lại trình bao bọc tùy chỉnh để phù hợp với các nền tảng khác nhau
  • Một người dùng cho rằng mục tiêu của API đồ họa là đưa mã và dữ liệu vào GPU nhanh nhất có thể, chứ không phải dễ sử dụng
  • Một người dùng cho rằng WebGPU là một trình bao bọc tốt cho tính toán và kết xuất trong trình duyệt, dễ khám phá và trực quan hơn WebGL
  • Một người dùng cho rằng mỗi phiên bản D3D chính mới đều cải thiện khả năng sử dụng, trong khi Metal đạt được sự cân bằng giữa khả năng sử dụng và chi phí thấp
  • Một người dùng cho rằng khả năng sử dụng của OpenGL đã giảm kể từ cuối những năm 1990, Vulkan không may tiếp tục xu hướng này
  • Một người dùng cho rằng WebGPU đã cải thiện trải nghiệm nhà phát triển so với WebGL
  • Một người dùng cho rằng công nghệ WebGPU đã lỗi thời so với các tiêu chuẩn đồ họa hiện đại và không đủ trực quan
  • Một người dùng cho rằng WebGPU không ưu tiên việc kết xuất các đường hoặc điểm chất lượng cao, người dùng cần tự học các kỹ thuật như SDFs và Beziers

Helix Editor 25.07 #

Helix Editor 25.07

https://helix-editor.com/news/release-25-07-highlights/

Điểm nổi bật của phiên bản Helix 25.07 Ngày 15 tháng 7 năm 2025 Phiên bản Helix 25.07 rất được mong đợi cuối cùng đã được phát hành. Phiên bản này có những thay đổi lớn đối với các thành phần cốt lõi của Helix và bổ sung nhiều tính năng mới đáng chú ý. Tổng cộng có 195 người đóng góp đã tham gia vào các thay đổi của phiên bản này. Xin cảm ơn tất cả những người đã làm cho phiên bản này trở nên khả thi. Nếu bạn là người mới sử dụng Helix, Helix là một trình soạn thảo văn bản theo kiểu modal hỗ trợ đa lựa chọn, giao thức máy chủ ngôn ngữ (LSP), tree-sitter và hỗ trợ thử nghiệm giao thức bộ điều hợp gỡ lỗi (DAP).

Giới thiệu tính năng mới Trình duyệt tệp Phiên bản 25.07 bổ sung trình duyệt tệp vào e. Trình duyệt tệp là một trình chọn, tương tự như thành phần UI kiểu kính viễn vọng trong Helix. Giống như các trình chọn khác, bạn có thể tìm kiếm mờ trong các tùy chọn. Nhấn Enter để chọn một thư mục sẽ mở một trình duyệt tệp mới trong thư mục đó, chọn một tệp sẽ mở tệp đó. Điều này rất hữu ích để xem các thư mục theo cấu trúc phân cấp. Ngược lại, trình duyệt tệp thông thường (f) sẽ mở một trình chọn đệ quy chứa nội dung của thư mục. Đối với các dự án lớn, trình duyệt tệp có thể là một công cụ chính xác hơn.

Màu tài liệu LSP Một tính năng đáng chú ý trong đặc tả giao thức máy chủ ngôn ngữ (LSP) là yêu cầu màu tài liệu. Yêu cầu này cho phép máy khách (Helix) hỏi máy chủ ngôn ngữ (như tailwindcss-language-server hoặc vscode-css-language-server) những phạm vi nào trong tài liệu tương ứng với màu RGB. Trong phiên bản 25.07, Helix hiện có thể yêu cầu màu tài liệu từ máy chủ ngôn ngữ và hiển thị các mẫu màu (một hộp nhỏ) nội tuyến. Điều này hoàn toàn giống với tính năng gợi ý nội tuyến LSP - hiển thị kiểu - nhưng áp dụng cho màu sắc.

Tính năng mới của chế độ lệnh Chế độ lệnh (:) được sử dụng để thực thi các lệnh có thể nhập. Ví dụ: :write là một lệnh có thể nhập, nó chấp nhận một tham số tùy chọn. :quit cũng là một lệnh có thể nhập, nó không chấp nhận bất kỳ tham số nào. Cú pháp của chế độ lệnh rất tinh tế. Nó phải đơn giản để các thao tác phổ biến như :write path/to/doc.md dễ nhập. Nhưng nó cũng cần các công cụ để thoát khoảng trắng, như trong :write ‘a b.txt’. Đối với một số lệnh, việc có cú pháp tùy chỉnh hoặc có thể mở rộng là hữu ích, chẳng hạn như :run-shell-command < lệnh phức tạp dành riêng cho shell >. Phiên bản 25.07 bao gồm việc viết lại hoàn toàn tất cả mã để phân tích cú pháp và biểu diễn các tham số, cũng như cung cấp khả năng hoàn thành cho dòng lệnh. Điều này khắc phục một số vấn đề về phân tích cú pháp và hoàn thành, chẳng hạn như cố gắng hoàn thành tên tệp có khoảng trắng, đồng thời giới thiệu hai tính năng mới: cờ và mở rộng.

Cờ Cờ hoạt động giống như các cờ bạn truyền trong lệnh shell. Chúng được thiết kế để bao gồm các trường hợp bạn muốn thực thi một lệnh với hành vi được sửa đổi một chút. Cho đến nay, cờ chỉ được sử dụng cho một số ít lệnh: dòng lệnh :write (bất kỳ lệnh nào bắt đầu bằng :write) và :sort. Phiên bản 25.07 đã xóa lệnh :rsort và thay thế bằng :sort –reverse hoặc viết tắt là :sort -r. Các lệnh :write hiện chấp nhận cờ –no-format. Thông thường, nếu tài liệu hiện tại được định cấu hình để tự động định dạng, bạn muốn định dạng tài liệu hiện tại, nhưng đôi khi việc ghi tệp nguyên trạng sẽ hữu ích. Đây là những trường hợp sử dụng tuyệt vời cho cờ: bạn không cần các lệnh có thể nhập bổ sung để tinh chỉnh các chi tiết nhỏ. Cờ được hiển thị trong hộp thông tin của lệnh có thể nhập và phiên bản dài (chẳng hạn như –reverse) có thể được tự động hoàn thành.

Mở rộng Mở rộng giới thiệu một cú pháp đặc biệt để nội suy các giá trị. Chúng phần lớn tuân theo khái niệm mở rộng của Kakoune, với một số điều chỉnh nhỏ. Các biến có thể được viết dựa trên trạng thái trình soạn thảo hiện tại có thể được viết là %{variable_name}. %{buffer_name} in tên tài liệu tiêu điểm hiện tại được hiển thị trong dòng trạng thái, %{cursor_line} in số dòng được lập chỉ mục 1 của con trỏ chính. Có thể sử dụng %sh{..} để mở rộng thực thi các lệnh shell. Kết hợp với việc mở rộng biến ở trên và lệnh :echo đơn giản mới (in ra dòng trạng thái), một lệnh như thế này in git blame của dòng hiện tại trên dòng trạng thái: :echo %sh{git blame -L %{cursor_line},+1 %{buffer_name}} Tên biến và loại mở rộng (chẳng hạn như sh cho lệnh shell hoặc u cho Unicode) đều có thể được tự động hoàn thành.

Phân tích cú pháp có thể mở rộng Mục đích ban đầu của việc khám phá viết lại là xem xét lại cách phân tích cú pháp dòng lệnh. Sau những thay đổi trong phiên bản 25.07, chế độ lệnh phân tích cú pháp và hoàn thành tên tệp tốt hơn, cho phép cờ và mở rộng, đồng thời cũng có thể chuyển sang các phương pháp phân tích cú pháp khác trong dòng. Các lệnh có thể nhập :set-option và :toggle-option hiện sử dụng bộ giải tuần tự luồng của serde_json để phân tích cú pháp các giá trị cấu hình phức tạp, chẳng hạn như danh sách. Các lệnh shell như :run-shell-command và :pipe không còn cố gắng phân tích cú pháp dòng lệnh sau tên lệnh. Vì vậy, bạn không cần phải đoán cách thoát khỏi các quy tắc phân tích cú pháp của Helix, sau đó là các quy tắc phân tích cú pháp của shell của bạn - địa ngục trích dẫn cuối cùng.

Tree-house Trong chu kỳ phiên bản này, chúng tôi đã thay thế các crates tương tác với Tree-sitter, thêm các crates mới được xây dựng từ đầu và xóa các liên kết chính thức cũng như nhiều mã cũ trong Helix. Phần còn lại của bài viết này sẽ thảo luận chi tiết về Tree-sitter và Tree-house. Bạn muốn tìm hiểu thêm chi tiết về những thay đổi kể từ Helix 25.01.1? Vui lòng xem nhật ký thay đổi để biết bộ thay đổi mã hoàn chỉnh.

Tree-sitter Bạn chưa quen với Tree-sitter? Ở cấp độ cao, nó là một framework để tạo và sử dụng các trình phân tích cú pháp nhanh, chịu lỗi. Trong tệp grammar.js, bạn có thể viết các quy tắc trình phân tích cú pháp thông qua cú pháp DSL, sau đó sử dụng công cụ tree-sitter CLI để tạo và kiểm tra trình phân tích cú pháp. Các công cụ như trình soạn thảo sau đó có thể sử dụng trình phân tích cú pháp bạn đã xác định với thư viện Tree-sitter C hoặc các liên kết dành riêng cho ngôn ngữ để phân tích cú pháp và thao tác cây cú pháp. Mục đích sử dụng cây cú pháp của bạn tùy thuộc vào trí tưởng tượng của bạn! Máy chủ ngôn ngữ có thể sử dụng Tree-sitter làm trình phân tích cú pháp của chúng, các công cụ khác biệt như Difftastic có thể tạo ra các khác biệt nhận biết cú pháp và các máy chủ ngôn ngữ như Codebook có thể thực hiện quét kiểm tra chính tả nhận biết cú pháp. Ngay cả GitHub cũng sử dụng tree-sitter để điều hướng mã và làm nổi bật một số ngôn ngữ.

Một công cụ rất mạnh để xử lý cây phân tích cú pháp là truy vấn Tree-sitter. Truy vấn là một cách khớp mẫu để khớp với các cây con và chụp các nút để sử dụng trong tương lai. Đối với trình soạn thảo, bạn có thể sử dụng một truy vấn, thường được gọi là highlights.scm, để chụp một nút cây, chẳng hạn như từ khóa Rust, để làm nổi bật văn bản của nút theo chủ đề hiện tại. Giống như cây cú pháp, việc áp dụng truy vấn chỉ bị giới hạn bởi trí tưởng tượng của bạn. Chúng tôi hiện đang sử dụng các truy vấn trong Helix để làm nổi bật, thụt lề và các đối tượng văn bản (xác định các hàm, tham số, v.v.). Trong tương lai, việc thu gọn mã, kiểm tra chính tả và điều hướng mã cũng có thể sử dụng truy vấn tree-sitter.

Lịch sử trong Helix Helix thậm chí còn dựa vào Tree-sitter để làm nổi bật cú pháp trước khi phát hành công khai ban đầu, thông qua các liên kết Rust chính thức đến thư viện C, tức là crate tree-sitter. Crate tree-sitter bao bọc thư viện C và khá cấp thấp. Chúng tôi cũng cần một trình làm nổi bật, được cung cấp bởi một crate riêng biệt: tree-sitter-highlight. tree-sitter-highlight cung cấp một trình làm nổi bật cú pháp, nó chấp nhận một truy vấn cho một ngôn ngữ và văn bản tài liệu cần làm nổi bật, đồng thời có thể lặp lại để tạo ra các sự kiện làm nổi bật. Helix có thể sử dụng trình lặp làm nổi bật khi hiển thị tài liệu có thể xem được. Điều này hoạt động ngay lập tức đối với tree-sitter-highlight và các trường hợp sử dụng đơn giản của chúng tôi (chẳng hạn như làm nổi bật tài liệu một lần), tree-sitter-highlight là tất cả những gì bạn cần. Vấn đề với tree-sitter-highlight là nó không hoạt động gia tăng. Việc tạo một trình lặp làm nổi bật mới có nghĩa là phân tích cú pháp lại hoàn toàn tài liệu cũng như phân tích lại truy vấn. Điều này là lãng phí vì Tree-sitter có thể sử dụng lại truy vấn. Ngoài ra, việc phân tích cú pháp trong Tree-sitter có thể hoạt động gia tăng: bạn có thể cung cấp cho Tree-sitter cây cú pháp cũ và nó sẽ phân tích cú pháp phiên bản mới của tài liệu nhanh hơn.

HN | Độ nóng: 316 điểm | 142 bình luận | Tác giả: matrixhelix #

https://news.ycombinator.com/item?id=44574815

  • Trình soạn thảo Helix có nhiều tính năng, có thể sử dụng mà không cần cấu hình hoặc cài đặt plugin, nhưng các phím tắt khác với Vim có thể khiến người dùng quen với Vim cảm thấy bối rối và khó chịu.
  • Một số người dùng khuyên dùng evil-helix, một nhánh mềm của Helix giới thiệu các phím tắt Vim, giải quyết vấn đề về phím tắt.
  • Một số người dùng cho rằng, vì hầu hết các trình soạn thảo trực tuyến và máy trạm đều có phím tắt Vim, nên họ không muốn từ bỏ sự linh hoạt này.
  • Có ý kiến cho rằng, nếu có thể đạt được năng suất cao hơn trên máy của mình, thì có thể từ bỏ sự linh hoạt của phím tắt trên các máy khác.
  • Một số người dùng cho rằng, hầu hết các plugin không thay đổi căn bản cách tương tác với văn bản, vì vậy không nên từ bỏ việc sử dụng chỉ vì plugin không khả dụng trên các máy khác.
  • Một số người dùng cho biết, họ có thể dễ dàng chuyển đổi giữa các phím tắt Helix và Vim, đồng thời có thể thích ứng với logic của Helix.
  • Một số người dùng đề cập rằng, mô hình danh từ-động từ của Helix khác với mô hình động từ-danh từ của Vim, điều này có thể khiến một số người dùng khó thích nghi.
  • Helix thiếu chức năng lặp lại chỉnh sửa, chức năng này được thực hiện thông qua ‘.’ trong Vim, điều này có thể ảnh hưởng đến hiệu quả chỉnh sửa.
  • Một số người dùng cho rằng, chế độ chỉnh sửa của Helix cần được chú ý nhiều hơn, điều này có thể làm phân tán sự tập trung vào nhiệm vụ lập trình.
  • Một số người dùng đề cập rằng, Helix không hỗ trợ phím ‘.’, vì mô hình của nó là không có gì được chọn sau khi thực hiện thao tác, do đó không thể suy ra ý định lặp lại lần chỉnh sửa cuối cùng.
  • Một số người dùng mô phỏng chức năng ‘.’ trong Helix bằng cách lưu macro.
  • Một số người dùng cho rằng, việc hoàn toàn bỏ qua tính hữu dụng của phím lặp lại hoặc macro là hơi vội vàng.
  • Một số người dùng cho biết, họ đã chuyển từ Vim sang Helix và thích Helix hơn, đặc biệt là khả năng chọn nhiều và hỗ trợ LSP của nó.
  • Helix đang thêm ngôn ngữ Scheme để cấu hình có thể lập trình, điều này sẽ cho phép nhiều trạng thái và hành vi theo ngữ cảnh hơn.
  • Một số người dùng bị cản trở ý định thử Helix vì các phím tắt Vim.

Firefox sẽ đi đâu tiếp theo? #

Where’s Firefox going next?

https://connect.mozilla.org/t5/discussions/where-s-firefox-going-next-you-tell-us/m-p/100698#M39094

Trang web này là một bài đăng trên diễn đàn Mozilla Connect, chủ đề là “Where’s Firefox going next? You tell us.” (Firefox sẽ đi đâu tiếp theo? Hãy cho chúng tôi biết.), được khởi xướng bởi jboscacci, một nhân viên của Mozilla. Nội dung chính của bài đăng bao gồm:

  1. Thử nghiệm mới và phản hồi của người dùng: Mozilla đang thử nghiệm một phương pháp khảo sát nhanh mới để hiểu nhu cầu và mong đợi của người dùng. Những phản hồi này sẽ giúp định hình các tính năng tương lai của Firefox và cho phép người dùng liên hệ trực tiếp hơn với nhóm phát triển. jboscacci nhấn mạnh tầm quan trọng của phản hồi người dùng đối với sự phát triển của Firefox, đề cập đến các tính năng như nhóm tab, tab dọc, hồ sơ người dùng (profiles), hình nền trang tab mới, PWA và ghim vào thanh tác vụ đều được triển khai dựa trên phản hồi của người dùng.
  2. Kế hoạch AMA (Ask Me Anything) cộng đồng: Mozilla đang xem xét cách tương tác với cộng đồng và lên kế hoạch tổ chức một sự kiện AMA cộng đồng, mời các quản lý sản phẩm Firefox tham gia. Bài đăng mời người dùng đặt câu hỏi để giúp lên kế hoạch cho sự kiện AMA và đưa ra một câu hỏi thú vị ở cuối bài đăng, hỏi người dùng con vật nào đại diện tốt nhất cho phong cách duyệt web Firefox của họ.
  3. Phản hồi của người dùng tilwiti: tilwiti đã chia sẻ phong cách duyệt web của mình trong bài đăng và đưa ra một số đề xuất và câu hỏi. Anh ấy đề cập đến nhu cầu về tính năng chia đôi màn hình, kỳ vọng về giao diện và tính linh hoạt của chủ đề trên Android, cũng như sự tập trung vào phát triển trình duyệt Firefox. Anh ấy cũng đề cập đến sự hỗ trợ lâu dài của mình dành cho Firefox và đưa ra các câu hỏi về công việc hàng ngày của nhóm Firefox, phản hồi trên Reddit, sự tham gia vào nghiên cứu người dùng, việc thiếu hỗ trợ ngôn ngữ Cyrillic trong các tính năng AI, cải tiến tính năng Orbit, v.v.
  4. Các câu hỏi khác của người dùng tilwiti: tilwiti cũng đề cập đến những lo ngại về số lượng người dùng và vấn đề đóng băng YouTube, cũng như sự hoài niệm về các dịch vụ Pocket và Fakespot. Anh ấy cũng hỏi về dữ liệu đo từ xa của Mozilla, cũng như phản ứng của người dùng đối với các thay đổi về đo từ xa hoặc điều khoản dịch vụ.
  5. Phản hồi của người dùng Kvin: Kvin cảm ơn nhóm Firefox vì những nỗ lực phát triển và đưa ra ba đề xuất cho sự phát triển trong tương lai của Firefox: tối ưu hóa, tính năng và thiết kế. Anh ấy nhấn mạnh tầm quan trọng của việc tối ưu hóa phiên bản PC và đề cập đến nhu cầu cải tiến toàn diện trình duyệt thường xuyên.

Toàn bộ bài đăng mang không khí cởi mở và tương tác, khuyến khích người dùng tham gia thảo luận, chia sẻ ý tưởng và câu hỏi của họ để giúp nhóm Firefox hiểu rõ hơn về nhu cầu của người dùng và cải thiện trình duyệt.

HN | Độ nóng: 311 điểm | 507 bình luận | Tác giả: ReadCarlBarks #

https://news.ycombinator.com/item?id=44575794

  • Xu hướng marketing/PR của Mozilla coi các thành viên cộng đồng như trẻ mẫu giáo, giọng điệu này gây xao nhãng và phản cảm.
  • Có người ủng hộ Firefox, nhưng không hài lòng với cách Mozilla tham gia cộng đồng, cho rằng nó thiếu chân thành.
  • Có người cho rằng chất lượng viết bài của Mozilla kém, đầy những điều vô nghĩa và thông tin không liên quan.
  • Có người chỉ trích thông tin mà Mozilla cung cấp trong quá trình cài đặt nhàm chán và vô dụng, so với Windows, cài đặt sau khi cài Firefox phức tạp hơn.
  • Có người đề cập rằng, mặc dù Chrome cũng có vấn đề của nó, nhưng ít nhất nó thường có thể hoạt động bình thường mà không cần các thiết lập bổ sung như Firefox.
  • Có người tức giận về cách Mozilla sử dụng biểu tượng cảm xúc và cảm ơn người dùng, cho rằng đây là biểu hiện đạo đức giả.
  • Có người chỉ ra rằng, Mozilla là một tổ chức phi lợi nhuận có sứ mệnh, lập trường chính trị của họ là công khai, không nên cảm thấy tức giận vì họ sử dụng biểu tượng cảm xúc hoặc cảm ơn người dùng.
  • Có người nhấn mạnh rằng, vấn đề chính của họ là sự không chân thành của Mozilla, chứ không phải giọng điệu cụ thể mà họ sử dụng.

Tôi đang chuyển sang Python và thực sự thích nó #

I’m switching to Python and actually liking it

https://www.cesarsotovalero.net/blog/i-am-switching-to-python-and-actually-liking-it.html

Bài viết này chia sẻ về trải nghiệm của tác giả khi chuyển sang sử dụng Python và thực sự yêu thích nó. Bài viết được đăng vào ngày 15 tháng 7 năm 2025, thời gian đọc ước tính khoảng 18 phút.

Tác giả bắt đầu sử dụng Python nhiều hơn để lập trình khoảng 6 tháng trước, lý do là sự trỗi dậy của trí tuệ nhân tạo (AI). Tác giả cho rằng AI là cơ hội kiếm tiền lớn nhất hiện nay, và Python là ngôn ngữ lập trình trên thực tế trong lĩnh vực AI. Mặc dù trước đây tác giả cũng đã sử dụng Python, nhưng chỉ giới hạn ở việc viết các script nhỏ, chẳng hạn như một script để thu thập metadata video từ kênh YouTube và xuất ra dưới dạng file JSON, script này tự động chạy hàng tuần thông qua GitHub Actions. Tác giả cho rằng sử dụng Python thuận tiện hơn so với sử dụng lệnh batch, không chỉ vì cú pháp của Python thân thiện hơn mà còn vì trình thông dịch Python được tích hợp sẵn trong tất cả các bản phân phối Unix.

Tác giả đề cập rằng, cho đến gần đây anh mới bắt đầu coi trọng Python, đó là sau khi anh muốn xây dựng các ứng dụng AI thực tế (như RAG, Agents, GenAI tools, v.v.). Anh nhận thấy Python và hệ sinh thái xung quanh nó đã được cải thiện rất nhiều trong vài thập kỷ qua, ví dụ như Python sở hữu một hệ sinh thái thư viện và công cụ hoàn chỉnh để xử lý và phân tích dữ liệu, trở nên nhanh hơn thông qua các trình biên dịch tĩnh được tối ưu hóa như Cython, và đã làm rất tốt trong việc che giấu những di sản xấu xí của nó (ví dụ: __init__, __new__…) để làm cho cú pháp của nó trở nên thanh lịch hơn, phù hợp với các nhà phát triển có gu thẩm mỹ tốt.

Trong bài viết, tác giả chia sẻ các công cụ, thư viện, cấu hình và các phương pháp tích hợp khác mà anh sử dụng để xây dựng ứng dụng Python. Anh nhấn mạnh rằng, có một khoảng cách lớn giữa việc sử dụng Python để xây dựng các ứng dụng “sẵn sàng cho sản xuất” và quy trình làm việc thông thường dựa trên Jupyter notebook hoặc script. Tác giả thích sử dụng cấu trúc monorepo (backend và frontend) để tổ chức các dự án Python, vì anh không thích code bị phân tán trong nhiều repository, cho rằng điều này bất lợi cho việc tìm kiếm, và đối với một nhà phát triển duy nhất, nhiều repository thường là không cần thiết, anh có xu hướng giữ mọi thứ đơn giản nhất có thể, biên dịch, kiểm tra, container hóa và triển khai từ một vị trí duy nhất.

Bài viết cũng trình bày chi tiết cấu trúc dự án, bao gồm quy trình làm việc GitHub Actions, cấu hình VSCode, tài liệu, backend API, lưu trữ dữ liệu, Jupyter notebook, tool script, source code, cấu hình Docker, Makefile, file cấu hình dự án Python, file README, v.v. Tác giả nhấn mạnh rằng dự án nên tự chứa, bao gồm tài liệu, cơ sở hạ tầng xây dựng/triển khai và các file cần thiết khác để chạy.

Tác giả cũng giới thiệu bộ công cụ Python mà anh sử dụng, bao gồm uv làm công cụ quản lý và xây dựng package Python, ruff làm công cụ kiểm tra và định dạng code Python nhanh chóng, và tyty làm trình kiểm tra kiểu (type checker) cho Python. Tác giả cho rằng những công cụ này giúp giữ cho codebase sạch sẽ và dễ bảo trì, đồng thời giúp anh phát hiện sớm các lỗi kiểu trong quá trình phát triển.

HN | Độ nóng: 310 điểm | 483 bình luận | Tác giả: cesarsotovalero #

https://news.ycombinator.com/item?id=44579717

  • Sử dụng logic mã như “if not API_KEY or not CHANNEL_ID:” sẽ khiến người dùng cảm thấy bối rối, vì thực tế chỉ cần hai câu lệnh if độc lập để kiểm tra API_KEY và CHANNEL_ID riêng biệt.
  • Sử dụng toán tử := có thể đơn giản hóa mã và giảm thời gian phát triển.
  • Đối với các công cụ nội bộ, việc để os.environ["API_KEY"] trực tiếp gây ra KeyError là một cách tiếp cận rõ ràng và đủ mô tả.
  • Toán tử hải mã (walrus operator) của Python có thể gây khó hiểu, vì nó cho phép biến được truy cập bên ngoài câu lệnh if.
  • Phạm vi biến của Python phức tạp hơn vẻ ngoài của nó, nó thực sự có ba phạm vi biến: toàn cục, cục bộ và khối ngoại lệ.
  • Các biến ngoại lệ không được ràng buộc sau khối ngoại lệ, điều này khác với câu lệnh if, trong đó các biến chắc chắn đã được xác định.
  • JavaScript trước ES5 cũng có các đặc tính phạm vi khối tương tự, nhưng chỉ giới hạn ở các biến được giới thiệu trong khối catch.
  • Có thể quản lý phạm vi khối bằng cách đổi tên biến, nhưng điều này có thể dẫn đến giảm hiệu suất.
  • Ngoại lệ như một ngoại lệ đối với phạm vi biến rất thú vị, vì nó là trường hợp duy nhất không thể duy trì ràng buộc.
  • Trong câu lệnh if, các biến trong biểu thức được kiểm tra chắc chắn đã được xác định, điều này khác với vòng lặp for.
  • Python không có phạm vi khối, phạm vi nhỏ nhất là cấp độ hàm.
  • Các biến trong list comprehension không bị rò rỉ ra phạm vi bên ngoài, điều này dẫn đến một số tình huống kỳ lạ.
  • Phạm vi biến của Python không bị giới hạn bởi khối, mà bị giới hạn bởi hàm.
  • Sử dụng toán tử hải mã có thể truy cập phạm vi “có thể gán” trong cùng.

Tilck: Một kernel nhỏ gọn tương thích Linux #

Tilck: A tiny Linux-compatible kernel

https://github.com/vvaltchev/tilck

Tilck là một kernel đơn nhân mang tính giáo dục, được thiết kế để tương thích với Linux ở cấp độ nhị phân. Hiện tại, nó hỗ trợ kiến trúc i686 và RISCV64. Quy mô nhỏ và thiết kế đơn giản của Tilck khiến nó trở thành một nền tảng lý tưởng để thử nghiệm ở chế độ kernel, đồng thời vẫn giữ được khả năng chạy cùng một mã người dùng (user mode) như kernel Linux. Tính năng này khá hiếm trong các kernel mang tính giáo dục. Do đó, để xây dựng chương trình cho Tilck chỉ cần một toolchain gcc-musl từ bootlin.com. Không giống như hầu hết các kernel giáo dục khác, Tilck không yêu cầu một bộ ứng dụng được viết tùy chỉnh, nó có thể chạy trực tiếp các chương trình Linux phổ biến, chẳng hạn như bộ BusyBox.

Về kế hoạch trong tương lai, Tilck có thể được ứng dụng rộng rãi trong các hệ thống nhúng yêu cầu tính xác định hoàn toàn và độ trễ cực thấp. Nếu may mắn, Tilck có thể lấp đầy khoảng trống giữa Linux nhúng và các hệ điều hành thời gian thực (real-time operating system) điển hình (như FreeRTOS hoặc Zephyr). Tilck đã chạy trên RISCV64 và sẽ được chuyển sang kiến trúc ARM trong tương lai. Nó cũng có thể được điều chỉnh để chạy trên các CPU không có MMU. Vì một trong những trọng tâm thiết kế của Tilck là tiêu thụ cực kỳ ít RAM, nên nó rất phù hợp cho những trường hợp sử dụng này. Hiện tại, Tilck có thể khởi động và chạy trên máy QEMU chỉ với 3 MB bộ nhớ.

Ngoài ra, các kế hoạch còn bao gồm việc bổ sung hỗ trợ cơ bản cho mạng và lưu trữ, mặc dù các chi tiết cụ thể vẫn chưa được xác định. Hỗ trợ mạng có thể chỉ giới hạn ở UDP + IP (ít nhất là trong giai đoạn đầu) và có thể chỉ khả dụng trên một số card mạng hạn chế. Hỗ trợ lưu trữ cũng tương tự: sẽ không hỗ trợ tất cả các loại thiết bị khối (block device), kernel có thể chỉ triển khai một số hệ thống tập tin (có thể chỉ có fat32 và ext2). Khả năng tương thích với hệ thống tập tin FUSE cũng sẽ được xem xét.

Một cột mốc quan trọng của dự án sẽ là hỗ trợ mạng và lưu trữ cho một SoC cụ thể (chẳng hạn như Raspberry Pi).

HN | Độ nóng: 262 điểm | 51 bình luận | Tác giả: chubot #

https://news.ycombinator.com/item?id=44578510

  • TILCK là một điểm trung gian thú vị giữa xv6 và một nhân Linux đầy đủ, chạy trên các bo mạch phát triển RISC-V chi phí thấp như LicheeRV Nano
  • TILCK hiện không hỗ trợ mạng hoặc thiết bị khối, cũng như không có hỗ trợ đa nhân
  • TILCK sử dụng RAM image để cung cấp hỗ trợ FAT, chủ yếu dành cho initrd
  • Các phiên bản Linux ban đầu cũng chỉ là một trình giả lập terminal cho PC console, điểm khởi đầu của TILCK tương tự như vậy
  • Khả năng khởi động nhanh và chạy Doom (framebuffer) của TILCK gây ấn tượng
  • Tệp README của TILCK có nội dung phong phú và thú vị, đáng để các nhà phát triển hệ điều hành đọc
  • TILCK được đánh dấu là dành cho mục đích giáo dục, nhưng cũng có thể phù hợp với các thiết bị nhúng nhỏ
  • TILCK là một đơn nhân nhỏ, xác định, triển khai khoảng 100 системные вызовы Linux, phù hợp cho mục đích giáo dục, và cũng được lên kế hoạch như một nhân RTOS tương thích Linux
  • Việc TILCK thiếu hỗ trợ đa người dùng là một nhược điểm, hy vọng tác giả xem xét lại điều này
  • Khả năng tương thích hệ thống tệp của TILCK là một trở ngại lớn hơn, đối với các tình huống yêu cầu quyền sở hữu và cài đặt quyền của tệp, TILCK có thể không tốt bằng các nền tảng đã được thử nghiệm trong thực tế
  • Tác giả đang xem xét viết một lớp khối, VFS và trình điều khiển AHCI cho TILCK, cũng như các thành phần như máy chủ ZFS và NFS, mặc dù điều này đòi hỏi một lượng lớn công việc mã hóa
  • Có người bày tỏ sự nghi ngờ về giá trị giáo dục của TILCK và việc sử dụng tiềm năng của nó trong sản xuất hệ thống nhúng, cho rằng nó không đủ mạnh về bảo mật thông tin và tính mạnh mẽ của dữ liệu

GPUHammer: Các cuộc tấn công Rowhammer vào bộ nhớ GPU là khả thi #

GPUHammer: Rowhammer attacks on GPU memories are practical

https://gpuhammer.com/

GPUHammer: Tấn công Rowhammer vào bộ nhớ GPU là khả thi trên thực tế

GPUHammer là nghiên cứu đầu tiên trình bày tấn công lật bit Rowhammer vào bộ nhớ GPU, đặc biệt nhắm vào bộ nhớ GDDR6 trong NVIDIA A6000 GPU. Kẻ tấn công có thể gây ra lật bit trong tất cả các bank DRAM được thử nghiệm, ngay cả khi có các biện pháp phòng thủ bên trong DRAM như TRR, thông qua code CUDA ở cấp độ người dùng. Những lần lật bit này cho phép người dùng GPU độc hại sửa đổi dữ liệu của người dùng khác trong môi trường chia sẻ, phân chia thời gian. Trong bằng chứng khái niệm, các nhà nghiên cứu đã sử dụng những lần lật bit này để sửa đổi mô hình DNN của nạn nhân, giảm độ chính xác của mô hình từ 80% xuống 0.1%, chỉ bằng một lần lật bit. Bật mã sửa lỗi (ECC) có thể giảm thiểu rủi ro này, nhưng ECC có thể làm giảm hiệu suất của khối lượng công việc suy luận ML trên A6000 GPU tới 10%.

Rowhammer là một lỗ hổng phần cứng, việc kích hoạt nhanh chóng các hàng bộ nhớ sẽ gây ra lật bit trong các hàng bộ nhớ liền kề. Lỗ hổng này đã được nghiên cứu rộng rãi trên CPU và bộ nhớ dựa trên CPU của nó (như DDR3, DDR4 và LPDDR4) kể từ năm 2014. Tuy nhiên, khi các khối lượng công việc AI và ML quan trọng hiện đang chạy trên các GPU riêng biệt trên đám mây, việc đánh giá tính dễ bị tấn công của bộ nhớ GPU đối với các cuộc tấn công Rowhammer trở nên rất quan trọng.

Rowhammer trên bộ nhớ GDDR dựa trên GPU khó khăn hơn vì những lý do sau:

  • GDDR6 có độ trễ cao hơn và tốc độ làm mới nhanh hơn, khiến việc “gõ” (hammering) trở nên khó khăn hơn.
  • Ánh xạ địa chỉ DRAM chưa biết trong bộ nhớ GDDR làm phức tạp việc tạo ra các mẫu hiệu quả.
  • Các biện pháp giảm thiểu bên trong DRAM trong GDDR là không minh bạch và không được ghi lại.

Mặc dù vậy, GPUHammer đã vượt qua những trở ngại này và tấn công thành công GDDR6.

Bước 1: Kỹ thuật đảo ngược ánh xạ GPU DRAM Để tạo ra một cuộc tấn công Rowhammer hiệu quả, trước tiên cần xác định các địa chỉ bộ nhớ được ánh xạ tới cùng một bank DRAM trên NVIDIA GPU. Không giống như CPU, NVIDIA GPU không hiển thị địa chỉ vật lý cho code CUDA ở cấp độ người dùng, điều này gây khó khăn cho việc xác định và “gõ” các hàng DRAM trong cùng một bank. Tuy nhiên, quan sát thấy trình điều khiển NVIDIA GPU ánh xạ nhất quán bộ nhớ ảo tới cùng một bộ nhớ vật lý, chúng tôi đã kỹ thuật đảo ngược offset bộ nhớ ảo thành ánh xạ bank DRAM. Lấy cảm hứng từ kỹ thuật DRAMA, chúng tôi sử dụng sự khác biệt về thời gian giữa các truy cập bộ nhớ cùng bank và khác bank.

Một trở ngại quan trọng là, như trong Hình 1, hiệu ứng truy cập bộ nhớ không đồng nhất (NUMA) khi truy cập các địa chỉ theo cặp gây khó khăn cho việc xác định chính xác các địa chỉ cùng bank. Dựa trên hiểu biết sâu sắc rằng các địa chỉ trong cùng một bank DRAM phải có độ trễ tương tự khi được truy cập riêng lẻ, chúng tôi đã lọc ra những địa chỉ đóng góp vào hiệu ứng NUMA và xác định rõ ràng các địa chỉ được ánh xạ tới cùng một bank DRAM (xem Hình 2). Điều này xác định chính xác các cặp địa chỉ cùng bank cần thiết để tạo ra các mẫu Rowhammer.

Bước 2: Tối đa hóa cường độ “gõ” Tốc độ truy cập bộ nhớ GPU chậm hơn tới 4 lần so với CPU, khiến việc sử dụng “gõ” đơn luồng như trên CPU trở nên khó khăn để đạt được tốc độ kích hoạt cần thiết cho tấn công Rowhammer (xem Hình 3, đường màu xanh lá cây). Để khắc phục điều này, chúng tôi tận dụng tính song song SIMT của GPU, đồng thời khởi động nhiều luồng và warp. Phương pháp đa luồng, đa warp này (xem Hình 3, đường màu cam) loại bỏ thời gian nhàn rỗi trong bộ điều khiển bộ nhớ và đạt được tốc độ “gõ” tối đa có thể. Hình 4 cho thấy những chiến lược này tối đa hóa việc sử dụng bộ điều khiển bộ nhớ như thế nào.

Bước 3: Đồng bộ hóa làm mới, đánh bại các biện pháp giảm thiểu Các công trình trước đây như SMASH và BlackSmith chỉ ra rằng việc đồng bộ hóa “gõ” với làm mới (REF) là chìa khóa để vượt qua các biện pháp phòng thủ bên trong DRAM. Tuy nhiên, các nguyên thủy đồng bộ hóa của CUDA (như __syncthreads()) được sử dụng để đồng bộ hóa các luồng có thể sắp xếp lại việc thực thi warp. Thay vào đó, chúng tôi sử dụng độ trễ ngầm định trên mỗi warp, căn chỉnh sao cho lệnh REF chồng lên độ trễ mà chúng tôi chèn vào để căn chỉnh “gõ” của chúng tôi với làm mới và đánh bại các biện pháp giảm thiểu bên trong DRAM như TRR, đồng thời duy trì thứ tự thực thi warp.

Chúng tôi đã sử dụng GPUHammer trên NVIDIA RTX A6000 (48 GB GDDR6) và quan sát thấy 8 lần lật bit đơn khác nhau trong bốn bank DRAM, lật bit xuất hiện trong tất cả các bank được thử nghiệm (xem Hình 6). Số lượng kích hoạt tối thiểu (TRH) để gây ra lật là khoảng 12K, phù hợp với các phát hiện DDR4 trước đó.

Sử dụng những lần lật này, chúng tôi đã thực hiện cuộc tấn công đầu tiên sử dụng Rowhammer để giảm độ chính xác ML trên GPU. Các công trình trước đây đã chỉ ra rằng việc lật bit quan trọng nhất của số mũ dấu phẩy động trong trọng số mô hình FP16 có thể làm giảm đáng kể độ chính xác của mô hình. Dựa trên hiểu biết sâu sắc này, chúng tôi chứng minh rằng trong cài đặt GPU chia sẻ thời gian, kẻ tấn công có thể định vị dữ liệu của nạn nhân vào các hàng DRAM dễ bị tấn công thông qua xoa bóp bộ nhớ và buộc lật bit ở những vị trí này.

Trong bằng chứng khái niệm của chúng tôi (xem Hình 7), chỉ với một lần lật bit, độ chính xác của tất cả năm mô hình ImageNet DNN được thử nghiệm đã giảm xuống dưới 1%, dẫn đến mất độ chính xác lên đến 80%.

Câu hỏi thường gặp:

  • Những GPU nào dễ bị tấn công? Tôi có bị ảnh hưởng không? Chúng tôi đã xác nhận lật bit Rowhammer trên NVIDIA A6000 GPU được trang bị bộ nhớ GDDR6. Các GPU GDDR6 khác, như RTX 3080, không hiển thị lật bit trong quá trình thử nghiệm, có thể là do sự thay đổi của nhà cung cấp DRAM, đặc tính chip hoặc điều kiện hoạt động (như nhiệt độ). Chúng tôi cũng không quan sát thấy lật bit trên A100 GPU được trang bị bộ nhớ HBM.
  • Tại sao lại thử nghiệm ít GPU như vậy? Đây không phải là một kích thước mẫu nhỏ sao? Không giống như CPU, các mô-đun DRAM có thể dễ dàng thay thế để thử nghiệm, GPU DRAM được hàn, thử nghiệm quy mô lớn tốn kém (GPU có thể tốn hàng nghìn đô la). Code tấn công của chúng tôi có thể được mở rộng sang các GPU Ampere khác và hơn thế nữa, chúng tôi khuyến khích các công việc trong tương lai mở rộng phạm vi thử nghiệm.
  • Làm thế nào để giảm thiểu GPUHammer? Quản trị viên có thể giảm thiểu GPUHammer bằng cách bật ECC, được thực hiện thông qua nvidia-smi -e 1 (sau đó khởi động lại). Tất cả các lần lật bit được quan sát cho đến nay đều là đơn bit và ECC có thể sửa. Tuy nhiên, bật ECC có thể làm giảm hiệu suất trên A6000 tới 10% và giảm dung lượng bộ nhớ 6.25%. Mặc dù vậy, điều này không loại bỏ nguyên nhân gốc rễ của lỗi phần cứng, điều này sẽ yêu cầu thiết kế lại GDDR6 và giới thiệu các biện pháp giảm thiểu theo nguyên tắc như PRAC, đã được đề xuất cho DDR5 trở lên, hoặc các biện pháp giảm thiểu xác suất như PRIDE.
  • Các GPU mới, như H100 hoặc RTX 5090, có bị ảnh hưởng không? Hiện tại là không. H100 (HBM3) và RTX 5090 (GDDR7) có ECC trên chip, điều này có thể che giấu các lần lật bit đơn. Tuy nhiên, các mẫu Rowhammer trong tương lai có thể dẫn đến lật nhiều bit, có thể vượt qua ECC như vậy, như đã được chứng minh bởi cuộc tấn công ECCploit.
  • Các bạn có tiết lộ điều này cho NVIDIA không? Phản hồi của họ là gì? Có. Chúng tôi đã tiết lộ GPUHammer một cách có trách nhiệm cho NVIDIA vào ngày 15 tháng 1 năm 2025 và tiết lộ cho các nhà cung cấp dịch vụ đám mây lớn (AWS, Azure, GCP, v.v.). NVIDIA đã xác nhận vấn đề này và đề xuất bật ECC như một biện pháp giảm thiểu.

Thông tin thêm: Vui lòng tham khảo bài báo của chúng tôi được xuất bản tại USENIX Security 2025…

HN | Độ nóng: 261 điểm | 89 bình luận | Tác giả: jonbaer #

https://news.ycombinator.com/item?id=44577268

  • Tấn công Rowhammer có thể thoát khỏi thế giới ảo khép kín bằng cách trực tiếp thao túng vật lý cơ bản của vũ trụ
  • Bằng cách tạo ra các mẫu trong vũ trụ ảo, có thể ảnh hưởng đến vũ trụ mô phỏng cơ bản
  • Các cuộc tấn công mô phỏng có thể có tác động tiêu cực đến hiệu suất, dẫn đến giảm hiệu suất
  • Nhiều tính toán không yêu cầu bảo mật, nhưng đối với những nơi cần bảo mật, mọi thiết bị kết nối với Internet đều phải an toàn
  • Nếu một tác vụ được cấp quyền truy cập GPU gốc, thì nó đã nằm trong ranh giới bảo mật, các tác vụ không đáng tin cậy không nên được phép truy cập GPU
  • GPU có khả năng chạy các tác vụ không đáng tin cậy, tương tự như cơ chế của bảng trang (page table)
  • Nếu chúng ta đang ở trong một mô phỏng, có thể có nhiều cách thoát tương đương với SysRq hoặc Control-Alt-Delete
  • Chúng ta có thể không nhận thức được các quy tắc vật lý của vũ trụ cha, giống như chúng ta không thể nhận thức được nhiều vật lý hơn
  • Ý tưởng kiểm tra thực tế vật lý bằng cách đập vào tường, tương tự như sự không tin tưởng vào khoa học
  • Các cuộc tấn công mô phỏng có thể khiến chúng ta suy nghĩ về cách tìm các lỗ hổng tương tự trong vũ trụ cấp cao hơn
  • Các cuộc tấn công mô phỏng có thể không tồn tại khả năng trốn thoát trong tất cả các hệ thống, hệ thống không nhất thiết phải chứa lối thoát
  • Thông qua các cuộc tấn công mô phỏng, chúng ta có thể suy nghĩ về cách tìm và khai thác các lỗ hổng trong các hệ thống phức tạp hơn
Facebook X