Top các câu chuyện trên HackerNews ngày 2025-06-19 #

《Nhà phát triển đầu to》 chủ trương đơn giản hóa code bằng quy tắc 80/20, tránh trừu tượng hóa quá sớm, và đề xuất “kiểm thử trung gian” hữu dụng hơn kiểm thử đơn vị, thông qua cách thức hài hước tự trào.
Tác giả vô tình hồi sinh trình theo dõi torrent đã ngừng hoạt động, phát hiện 3,1 triệu peer, tiết lộ rủi ro tập trung và nguy cơ pháp lý, cuối cùng phải đóng cửa dịch vụ vì lựa chọn tên miền thanh toán bằng thẻ tín dụng.
Nền tảng thể dục nguồn mở Workout.cool hồi sinh dự án bỏ hoang với giấy phép MIT, hỗ trợ triển khai cục bộ, nhưng một số người dùng báo cáo lỗi tải, tác giả gốc kêu gọi hợp tác.
Anthropic khuyên khi xây dựng AI Agent nên ưu tiên sử dụng API LLM cơ bản và mô hình đơn giản, nhấn mạnh việc hiểu code nền tảng và tránh phụ thuộc quá mức vào framework trong các tình huống đơn giản.
Scrappy cho phép người dùng nhanh chóng tạo ứng dụng cá nhân thông qua kéo thả đối tượng và một ít JavaScript, chủ trương quay trở lại thao tác trực tiếp thay vì tạo code bằng AI.
Iran cáo buộc WhatsApp làm rò rỉ thông tin người dùng và yêu cầu xóa phần mềm này, nhưng Meta nhấn mạnh mã hóa đầu cuối, các chuyên gia chỉ ra rằng vẫn còn rủi ro về metadata.
Kiểm toán viên thành phố New York Brad Lander gây tranh cãi vì đi cùng những người bị ICE giam giữ bên ngoài tòa án di trú, cáo buộc liên bang thiếu bằng chứng, sự kiện bị tiêu đề đánh lừa.
Thư viện bzip2 được viết lại bằng Rust giúp tăng tốc độ nén và giải nén từ 5-15%, loại bỏ sự phức tạp trong quá trình biên dịch C, có thể trở thành giải pháp thay thế chính thức của Linux.
Mô hình trọng số mở MiniMax-M1 có số lượng tham số đạt 456 tỷ, hỗ trợ ngữ cảnh 1 triệu token, cần nhiều H200 GPU để chạy, chi phí sau khi lượng tử hóa có thể giảm xuống dưới 10.000 đô la.
Bài viết so sánh Google Dịch với lĩnh vực lập trình, chỉ ra rằng mặc dù LLM có thể xử lý cấu trúc code, nhưng khó đối phó với ngữ cảnh văn hóa và ẩn dụ trừu tượng, cần trải qua “mùa đông AI” để vượt qua giới hạn.

Nhà Phát Triển Đầu Óc Grug (2022) #

The Grug Brained Developer (2022)

《Grug Brained Developer》 là một cuốn sách hướng dẫn hài hước về phát triển phần mềm, được viết bởi Grug, một nhà phát triển tự xưng là “đầu óc nhỏ bé”. Mặc dù Grug không cho rằng mình thông minh, nhưng nhiều năm kinh nghiệm lập trình đã dạy cho anh ta một số bài học quý giá. Cuốn sách này nhằm mục đích cung cấp kiến thức và lời khuyên dễ tiêu hóa cho các nhà phát triển trẻ tuổi một cách nhẹ nhàng và hài hước, đồng thời giúp Grug tự mình ghi nhớ những điều quan trọng, chẳng hạn như đã ăn gì vào bữa sáng hoặc có mặc quần hay không.

Cuốn sách bắt đầu bằng việc thảo luận về kẻ thù muôn thuở trong phát triển phần mềm - sự phức tạp. Grug ví sự phức tạp như một con quỷ, nó lẻn vào cơ sở mã, khiến công việc vốn rõ ràng trở nên hỗn loạn và nguy hiểm. Grug tin rằng vũ khí tốt nhất để chống lại sự phức tạp là học cách nói “không”, tức là từ chối những tính năng và trừu tượng không cần thiết để giữ cho mã đơn giản. Mặc dù điều này có thể bất lợi cho sự phát triển nghề nghiệp, vì “có” là từ kỳ diệu để nhận được nhiều phần thưởng và vị trí lãnh đạo hơn, nhưng Grug khẳng định rằng “không” là từ kỳ diệu của anh ta.

Đôi khi, sự thỏa hiệp là cần thiết, đặc biệt là khi không có đủ nguồn lực. Trong trường hợp này, Grug khuyên bạn nên sử dụng từ “ổn thôi” và tìm kiếm giải pháp 80/20, tức là sử dụng 20% mã để đạt được 80% chức năng. Một giải pháp như vậy có thể không hoàn hảo, nhưng đủ để đáp ứng hầu hết các nhu cầu, đồng thời tránh được con quỷ phức tạp.

Cuốn sách cũng thảo luận về việc phân tách mã (hay còn gọi là “tách yếu tố”). Grug tin rằng không nên phân tách ứng dụng quá sớm, vì mọi thứ đều trừu tượng và khó nắm bắt trong giai đoạn đầu của dự án. Anh ta khuyên bạn nên để hệ thống “hình thành” trước, sau đó tìm kiếm các điểm phân tách phù hợp. Một điểm phân tách tốt nên có giao diện hẹp với các phần còn lại của hệ thống, có thể ẩn sự phức tạp bên trong.

Grug cũng đề cập đến tầm quan trọng của việc kiểm thử (testing). Mặc dù anh ta tôn trọng việc kiểm thử, nhưng anh ta hoài nghi về một số phương pháp kiểm thử, chẳng hạn như yêu cầu viết kiểm thử trước khi viết mã. Anh ta thích viết kiểm thử sau giai đoạn tạo mẫu, khi mã bắt đầu ổn định. Grug nhấn mạnh rằng, lúc này phải rất kỷ luật, không được không viết kiểm thử chỉ vì “nó hoạt động trên máy của tôi”, vì mã như vậy không có gì đảm bảo sẽ hoạt động trên các máy khác hoặc trong tương lai.

Cuối cùng, Grug tin rằng thử nghiệm lý tưởng không phải là unit test cũng không phải là end-to-end test, mà là thử nghiệm nằm giữa hai loại này. Unit test tuy hữu ích, nhưng dễ bị hỏng khi các triển khai thay đổi, gây khó khăn cho việc tái cấu trúc (refactoring). End-to-end test tuy có thể hiển thị hoạt động của toàn bộ hệ thống, nhưng khi chúng thất bại thì rất khó hiểu nguyên nhân, đôi khi các nhà phát triển chọn bỏ qua chúng. Grug khuyên rằng, kiểm thử nên giúp khởi động dự án trong giai đoạn đầu của dự án, nhưng đừng mong đợi chúng sẽ cung cấp giá trị lâu dài.

HN | Độ nóng: 1010 điểm | 496 bình luận | Tác giả: smartmic #

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

Trong các công ty nhỏ và các công ty công nghệ lớn, nhiều người vẫn sử dụng câu lệnh in để gỡ lỗi thay vì sử dụng trình gỡ lỗi.
Học cách sử dụng trình gỡ lỗi là một siêu năng lực nhỏ, có thể giúp bạn hiểu hệ thống dễ dàng hơn.
Một số lập trình viên giàu kinh nghiệm có xu hướng sử dụng câu lệnh in và tự kiểm tra mã thay vì trình gỡ lỗi.
Trình gỡ lỗi hữu ích nhất khi bạn chưa hiểu rõ về lĩnh vực vấn đề, trong khi gỡ lỗi bằng cách in hữu ích hơn khi bạn hiểu rất rõ về mã.
Phát triển game khác với phát triển Web về mặt gỡ lỗi, phát triển game phụ thuộc nhiều hơn vào trình gỡ lỗi, trong khi phát triển Web, do tính chất phân tán của nó, phù hợp hơn với việc sử dụng nhật ký (logging).
Hiểu cả hai phương pháp gỡ lỗi và sử dụng chúng một cách mạnh dạn khi thích hợp.
Ngay cả trong các game AAA phức tạp, nếu mã do chính bạn viết, bạn thường không cần sử dụng trình gỡ lỗi.
Không thể có chuyện một người viết một game AAA từ đầu.
Trong các lĩnh vực phức tạp, trạng thái biến đổi tồn tại lâu dài, quản lý bộ nhớ chính xác và kết xuất hình ảnh, trình gỡ lỗi có thể hữu ích hơn.
Môi trường phân tán cũng có thể sử dụng trình gỡ lỗi, mặc dù cần một số thiết lập bổ sung.

Hồi sinh một torrent tracker đã chết và tìm kiếm 3 triệu peer #

Resurrecting a dead torrent tracker and finding 3M peers

https://kianbradley.com/2025/06/15/resurrecting-a-dead-tracker.html

Kian Bradley đã chia sẻ trên blog của mình về trải nghiệm hồi sinh một torrent tracker đã chết và tìm thấy 3 triệu peer. Anh ấy bắt đầu bằng việc tải xuống các tệp Linux ISO, nhưng tốc độ rất chậm, vì vậy đã kiểm tra tab tracker trong qBittorrent và thấy rằng hầu hết các tracker đã không hoạt động. Điều này khiến anh ấy suy nghĩ, nếu tiếp quản những tên miền không hoạt động này, sẽ có bao nhiêu client cố gắng kết nối?

Anh ấy giải thích rằng tracker là thành phần cốt lõi của giao thức BitTorrent, chúng trỏ đến các peer khác để chia sẻ tệp torrent. Nếu không có tracker, sẽ không ai có thể chia sẻ tệp, điều này thể hiện một nguồn tập trung chính của giao thức torrent. Nếu tracker không được bảo trì hoặc buộc phải ngừng hoạt động, người dùng sẽ gặp sự cố. Mặc dù có Mainline DHT, một giải pháp thay thế tìm kiếm peer phi tập trung hơn, nhưng nó không hoàn hảo, phụ thuộc vào các node khởi tạo, dễ bị tấn công Sybil và trong trường hợp của anh ấy, DHT không tìm thấy bất kỳ peer nào.

Kian, khi kiểm tra danh sách các tracker được đánh dấu là “Host not found”, đã nhận thấy rằng tên miền udp://open.demonii.si:1337/announce có sẵn. Anh ấy đã mua tên miền thông qua Dynadot và khởi động một VPS ẩn danh. Anh ấy ánh xạ tên miền đến VPS và thiết lập opentracker, phần mềm torrent tracker được sử dụng rộng rãi và mạnh mẽ nhất. Anh ấy cung cấp các bước chi tiết để cài đặt và cấu hình opentracker trên Ubuntu 24.04.

Trước khi khởi động opentracker, Kian đã thấy lưu lượng truy cập lớn trên cổng UDP 1337. Sau khi khởi động tracker, khoảng một giờ sau, nó đạt đỉnh khoảng 1,7 triệu torrent khác nhau và 3,1 triệu peer. Anh ấy cũng cung cấp một liên kết đến http://open.demonii.si:1337/stats?mode=everything, hiển thị số liệu thống kê chi tiết.

Về tính hợp pháp, Kian đề cập rằng khi ngành công nghiệp thu âm và các tổ chức kiện tụng khác truy lùng các torrent tracker, họ chủ yếu nhắm vào các phần công khai của hệ thống. Các phán quyết pháp lý đối với các trang web như The Pirate Bay phụ thuộc vào cách chúng làm nổi bật các bộ phim nổi tiếng, bán quảng cáo và cung cấp các tệp .torrent, điều này được coi là bằng chứng về sự xúi giục, tức là cố ý tạo điều kiện cho hành vi vi phạm bản quyền. Anh ấy đặt câu hỏi, việc lưu trữ cơ sở hạ tầng tracker mà không quảng cáo có cấu thành “xúi giục” không? Đây là một trường hợp khó chứng minh hơn. Anh ấy nhận ra rằng nhiều torrent, dù được cung cấp miễn phí hay được bảo vệ bản quyền, đều sử dụng tracker này. Nhưng anh ấy nhanh chóng nhận ra mình đã phạm sai lầm vì đã thanh toán cho tên miền bằng thẻ tín dụng. Sau khi xác nhận rằng nó hoạt động, anh ấy nhanh chóng tắt VPS và xóa tên miền.

Cuối cùng, Kian đề cập rằng tên miền này hiện đã có sẵn trở lại và rất dễ tìm thấy những tên miền chưa được nhận dạng như thế này. Nếu bạn muốn phục vụ công chúng, các tên miền như open.demonii.si có thể được đăng ký.

HN | Độ nóng: 624 điểm | 195 bình luận | Tác giả: k-ian #

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

Bản thân việc vận hành một trình theo dõi không phải là bất hợp pháp, điều quan trọng là cách xử lý các yêu cầu gỡ bỏ hợp pháp và cơ sở hạ tầng xung quanh
Ngay cả khi hợp pháp, bạn vẫn có thể bị quấy rối vì bị kiện, chi phí kiện tụng cao và bất lợi cho người bình thường
Về lý thuyết có thể kiện, nhưng trên thực tế chi phí kiện tụng rất tốn kém, đặc biệt là chi phí luật sư
Ngay cả khi thắng kiện, bạn vẫn có thể bị thiệt hại do quá trình kiện tụng, vì vậy tốt nhất là tránh kiện tụng
Chính phủ hoặc những người có quyền lực có thể trừng phạt bạn thông qua các thủ tục pháp lý vô tận, ngay cả khi họ biết sẽ thua
Không có giới hạn kỹ thuật nào về số lượng vụ kiện có thể được đệ trình chống lại một người cùng một lúc, nhưng Hoa Kỳ có luật chống SLAPP
Gửi thư yêu cầu ngừng và chấm dứt có thể hiệu quả hơn kiện tụng, vì nhiều hacker sẽ hành động nhanh chóng
Hiệu ứng ớn lạnh của luật bản quyền khiến mọi người không dám tham gia vào các hoạt động hoàn toàn hợp pháp
Ngành công nghiệp truyền thông có thể nhận được các khoản tiền phạt khổng lồ vì những thiệt hại được tuyên bố, khiến các nhà cung cấp dịch vụ lưu trữ không sẵn lòng bảo vệ khách hàng của họ
Các công ty có thể thử gửi những lá thư cứng rắn trước để tiết kiệm chi phí ra tòa trực tiếp
Ngay cả khi không công bố, bạn vẫn có thể nhận được thông báo gỡ bỏ, nhưng kiện tụng cần tuyên bố thiệt hại
Hiệp hội Công nghiệp Ghi âm không cần kiện tụng để khiến cuộc sống của đối phương trở nên đau khổ thông qua các thư luật sư hợp pháp
Kiện những kẻ quấy rối ra tòa án đòi bồi thường thiệt hại nhỏ có thể là một chiến lược hiệu quả, vì chi phí sẽ cao hơn đối với họ
Trong hầu hết các trường hợp, mọi người sẽ không hành động, ngay cả khi về mặt lý thuyết họ có thể
Hiệp hội Công nghiệp Ghi âm sẽ không thực hiện các hành động có thể gây rủi ro cho họ, vì vậy họ tránh hành vi quấy rối này
Hiệu ứng ớn lạnh có thể đàn áp các phát ngôn hoàn toàn hợp pháp, ngay cả khi chỉ nhận được thông báo gỡ bỏ, bạn cũng có thể không hành động

Show HN: Workout.cool – Nền tảng huấn luyện thể hình mã nguồn mở #

Show HN: Workout.cool – Open-source fitness coaching platform

https://github.com/Snouzy/workout-cool

workout.cool là một nền tảng huấn luyện viên thể hình toàn diện, cho phép người dùng tạo kế hoạch tập luyện, theo dõi tiến trình và truy cập vào cơ sở dữ liệu bài tập khổng lồ bao gồm hướng dẫn chi tiết và trình diễn video.

Nguồn gốc và động lực của dự án: Dự án này bắt nguồn từ một sứ mệnh cá nhân, nhằm mục đích phục hồi và cải thiện nền tảng thể hình trước đó. Là một người đóng góp chính cho dự án workout.lol ban đầu, tác giả đã chứng kiến hành trình và quá trình bị bỏ rơi của nó.

Câu chuyện đằng sau workout.cool:

Người đóng góp ban đầu: Tác giả từng là người đóng góp chính cho workout.lol.
Thách thức thương mại: Dự án ban đầu gặp phải những trở ngại đáng kể trong việc thiết lập quan hệ đối tác video bài tập, không tìm được nhà cung cấp video đáng tin cậy.
Bán dự án: Do những vấn đề hợp tác này, dự án đã được bán cho một bên khác.
Bỏ rơi: Chủ sở hữu mới nhanh chóng nhận ra chi phí cấp phép video bài tập quá cao, bắt đầu nản lòng và từ bỏ toàn bộ dự án.
Nỗ lực phục hồi: Trong 9 tháng qua, tác giả đã cố gắng liên hệ lại với các bên liên quan mới.
Không phản hồi: Mặc dù đã thử 15 lần, nhưng không nhận được phản hồi nào.
Khởi đầu mới: Tác giả quyết định tạo một triển khai hoàn toàn mới, hiện đại, thay vì để công việc có giá trị này biến mất.

Tại sao workout.cool tồn tại: Ai đó phải đứng lên. Cộng đồng thể hình mã nguồn mở xứng đáng được đối xử tốt hơn là những lời hứa suông và các nền tảng bị bỏ rơi. Tác giả không xây dựng nền tảng này vì lợi nhuận. Đây không chỉ là sự phục hồi, mà là một sự tiến hóa. workout.cool đại diện cho tất cả những gì mà dự án ban đầu có thể trở thành, với độ tin cậy, phương pháp hiện đại và sự bảo trì mà cộng đồng mã nguồn mở thể hình xứng đáng có được.

Đến từ cộng đồng, phục vụ cộng đồng: Tác giả không chỉ là nhà phát triển mà còn là một người dùng, người từ chối làm cộng đồng của chúng ta thất vọng. Tác giả đã đích thân trải qua sự thất vọng khi chứng kiến một công cụ yêu thích dần biến mất. Giống như nhiều người trong số các bạn, tác giả có các bài tập đã lưu, tiến trình đã theo dõi và các thói quen được xây dựng xung quanh nền tảng. Nhiệm vụ của tác giả là cứu và phục hồi. Nếu bạn là một phần của cộng đồng workout.lol ban đầu, chào mừng trở lại! Nếu bạn là người mới, chào mừng đến với tương lai của quản lý nền tảng thể hình.

Bắt đầu nhanh:

Điều kiện tiên quyết: Node.js 18+, Docker hoặc cơ sở dữ liệu bên ngoài PostgreSQL, pnpm.
Trang dự án cũng cung cấp hướng dẫn về cách bắt đầu sử dụng dự án, bao gồm các bước cài đặt dependencies, thiết lập database, chạy development server, v.v.

Kiến trúc dự án, lộ trình, đóng góp, triển khai và tài nguyên: Trang này cũng bao gồm kiến trúc của dự án, lộ trình phát triển trong tương lai, cách đóng góp cho dự án, hướng dẫn triển khai và các liên kết đến các tài nguyên liên quan.

Giấy phép và tài trợ: Dự án workout.cool sử dụng giấy phép MIT và cung cấp các tùy chọn tài trợ cho dự án để hỗ trợ sự phát triển của nó.

Người đóng góp: Trang cuối cùng liệt kê danh sách những người đã đóng góp cho dự án.

HN | Độ nóng: 519 điểm | 163 bình luận | Tác giả: surgomat #

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

Tác giả gốc Vincenius cảm thấy vui mừng khi dự án được bảo trì lại và khen ngợi những cải tiến về UI.
surgomat bày tỏ sự sẵn sàng hợp tác với tác giả gốc Vincenius và hoan nghênh sự trở lại của anh ấy.
gnarlouse cho rằng Workout.cool có thể được tích hợp vào API lên lịch tự động của anh ấy để lên kế hoạch cho cuộc sống và chế độ ăn uống.
repeekad đoán rằng có thể người trong ngành đã mua workout.lol để ngăn chặn các giải pháp thay thế miễn phí trở nên phổ biến và lo lắng về tương lai của Workout.cool.
koakuma-chan cho rằng nội dung bài đăng được tạo bởi AI và việc nhấp vào tiếp tục không hoạt động.
surgomat giải thích rằng máy chủ có thể không xử lý được do lưu lượng truy cập cao từ HN, đề xuất nhân bản kho lưu trữ và tự chạy.
xeromal bày tỏ sự khinh miệt đối với toàn bộ cuộc thảo luận.
minimalist đề cập đến dự án wger và dự án body.build, cho rằng chúng là trình quản lý thể dục/tập luyện/dinh dưỡng tự lưu trữ được cấp phép FLOSS AGPL.
Kovah đã thử Wget nhưng từ bỏ vì trải nghiệm người dùng kém và các vấn đề về ứng dụng di động, hiện đang sử dụng LiftLog.
riedel, gonzalohm, ElijahLynn và lucasverra báo cáo lỗi “Lỗi tải bài tập”.
toyetic cho rằng Workout.cool phù hợp cho người mới bắt đầu và đề xuất phát triển ứng dụng di động và lưu các bài tập cụ thể làm thói quen để theo dõi lâu dài.
gavmor đề xuất thêm chức năng xuất và chia sẻ dữ liệu giữa các giao diện người dùng khác nhau.

Xây Dựng Các AI Agent Hiệu Quả #

Building Effective AI Agents

https://www.anthropic.com/engineering/building-effective-agents

Bài viết này được Anthropic phát hành vào ngày 19 tháng 12 năm 2024, thảo luận về các phương pháp triển khai thành công các tác nhân mô hình ngôn ngữ lớn (LLM) trong các ngành công nghiệp khác nhau. Bài viết chỉ ra rằng việc triển khai thành công thường không phụ thuộc vào các framework phức tạp hoặc các thư viện chuyên dụng, mà là sử dụng các mẫu đơn giản, có thể kết hợp được. Bài viết chia sẻ kinh nghiệm hợp tác với khách hàng và tự xây dựng các tác nhân, đồng thời cung cấp các lời khuyên thiết thực cho các nhà phát triển để xây dựng các tác nhân hiệu quả.

Tác nhân là gì? Tác nhân có thể có nhiều định nghĩa. Một số khách hàng coi tác nhân là các hệ thống hoàn toàn tự chủ, chúng có thể hoạt động độc lập trong thời gian dài và sử dụng nhiều công cụ khác nhau để hoàn thành các nhiệm vụ phức tạp. Những người khác sử dụng thuật ngữ này để mô tả các triển khai có quy tắc hơn, tuân theo các quy trình làm việc được xác định trước. Anthropic phân loại tất cả các biến thể này là hệ thống tác nhân, nhưng vạch ra một ranh giới kiến trúc quan trọng giữa quy trình làm việc và tác nhân: quy trình làm việc là một hệ thống điều phối LLM và các công cụ thông qua các đường dẫn mã được xác định trước, trong khi tác nhân là một hệ thống trong đó LLM hướng dẫn động quy trình và việc sử dụng công cụ của chính nó, kiểm soát cách thức hoàn thành nhiệm vụ.

Khi nào (và khi nào không) sử dụng tác nhân Khi xây dựng ứng dụng LLM, bạn nên tìm giải pháp đơn giản nhất và chỉ tăng độ phức tạp khi cần thiết. Điều này có thể có nghĩa là không xây dựng hệ thống tác nhân nào cả. Hệ thống tác nhân thường hy sinh độ trễ và chi phí để có hiệu suất tác vụ tốt hơn, vì vậy cần phải xem xét sự đánh đổi này có hợp lý hay không. Khi cần thêm độ phức tạp, đối với các tác vụ được xác định rõ ràng, quy trình làm việc cung cấp khả năng dự đoán và nhất quán, trong khi tác nhân là lựa chọn tốt hơn khi cần tính linh hoạt và ra quyết định dựa trên mô hình.

Khi nào và làm thế nào để sử dụng framework Có nhiều framework có thể giúp việc triển khai hệ thống tác nhân dễ dàng hơn, bao gồm LangGraph của LangChain, framework AI Agent của Amazon Bedrock, Rivet (một trình xây dựng quy trình làm việc LLM GUI kéo và thả) và Vellum (một công cụ GUI khác để xây dựng và kiểm tra quy trình làm việc phức tạp). Các framework này đơn giản hóa việc bắt đầu bằng cách hợp lý hóa các tác vụ cấp thấp tiêu chuẩn như gọi LLM, xác định và phân tích cú pháp công cụ và liên kết các lệnh gọi. Tuy nhiên, chúng thường tạo ra các lớp trừu tượng bổ sung, có thể che khuất các gợi ý và phản hồi cơ bản, khiến việc gỡ lỗi trở nên khó khăn hơn. Chúng cũng có thể khiến mọi người tăng thêm độ phức tạp trong khi một thiết lập đơn giản hơn là đủ. Bạn nên các nhà phát triển sử dụng trực tiếp LLM API: nhiều mẫu có thể được triển khai bằng một vài dòng code. Nếu sử dụng framework, hãy đảm bảo hiểu code cơ bản. Các giả định sai về code cơ bản là một nguồn lỗi phổ biến của khách hàng.

Các khối xây dựng, quy trình làm việc và tác nhân Bài viết tiếp theo khám phá các mẫu phổ biến của hệ thống tác nhân được thấy trong sản xuất. Bắt đầu với các khối xây dựng cơ bản - LLM tăng cường, tăng dần độ phức tạp, từ quy trình làm việc kết hợp đơn giản đến tác nhân tự chủ.

Khối xây dựng cơ bản: LLM tăng cường Khối xây dựng cơ bản của hệ thống tác nhân là LLM được tăng cường với các tính năng tăng cường như truy xuất, công cụ và bộ nhớ. Các mô hình hiện tại có thể chủ động sử dụng các khả năng này - tạo các truy vấn tìm kiếm của riêng chúng, chọn các công cụ phù hợp và xác định thông tin nào cần giữ lại. Bạn nên tập trung vào hai khía cạnh quan trọng của việc triển khai: tùy chỉnh các khả năng này cho các trường hợp sử dụng cụ thể và đảm bảo chúng cung cấp giao diện đơn giản, có tài liệu rõ ràng cho LLM. Mặc dù có nhiều cách để triển khai các tính năng tăng cường này, nhưng một phương pháp là thông qua Giao thức ngữ cảnh mô hình (Model Context Protocol) được phát hành gần đây, cho phép các nhà phát triển tích hợp với một hệ sinh thái ngày càng tăng của các công cụ của bên thứ ba thông qua một triển khai máy khách đơn giản.

Quy trình làm việc: Chuỗi gợi ý Chuỗi gợi ý chia một tác vụ thành một loạt các bước, trong đó mỗi lệnh gọi LLM xử lý đầu ra của lệnh gọi trước đó. Có thể thêm các kiểm tra chương trình (“cổng” trong hình bên dưới) vào bất kỳ bước trung gian nào để đảm bảo rằng quy trình vẫn đi đúng hướng. Quy trình làm việc chuỗi gợi ý phù hợp với các tình huống mà tác vụ có thể dễ dàng và rõ ràng được chia thành các tác vụ con cố định. Mục tiêu chính là trao đổi độ trễ để có độ chính xác cao hơn bằng cách làm cho mỗi lệnh gọi LLM trở nên dễ dàng hơn.

Quy trình làm việc: Định tuyến Định tuyến phân loại đầu vào và hướng nó đến một tác vụ tiếp theo chuyên dụng. Quy trình làm việc này cho phép tách biệt các mối quan tâm và xây dựng các gợi ý chuyên biệt hơn. Nếu không có quy trình làm việc này, việc tối ưu hóa cho một loại đầu vào có thể làm giảm hiệu suất của các đầu vào khác. Quy trình làm việc định tuyến phù hợp với các tác vụ phức tạp, trong đó có các danh mục khác nhau có thể được xử lý riêng và việc phân loại có thể được xử lý chính xác bởi LLM hoặc mô hình/thuật toán phân loại truyền thống hơn.

Quy trình làm việc: Song song hóa LLM đôi khi có thể đồng thời làm việc trên các tác vụ và tổng hợp đầu ra của chúng theo phương pháp lập trình. Quy trình làm việc này, tức là song song hóa, có hai biến thể chính: phân chia và bỏ phiếu. Phân chia là chia một tác vụ thành các tác vụ con độc lập chạy song song. Bỏ phiếu là chạy cùng một tác vụ nhiều lần để có được đầu ra đa dạng. Song song hóa có hiệu quả trong các tác vụ con có thể được chia để song song hóa tốc độ hoặc khi cần nhiều quan điểm hoặc thử nghiệm để có kết quả tin cậy hơn.

Quy trình làm việc: Chỉ huy-Công nhân Trong quy trình làm việc chỉ huy-công nhân, một LLM trung tâm sẽ phân chia tác vụ một cách linh hoạt, ủy thác chúng cho các LLM công nhân và tổng hợp kết quả của chúng.

HN | Độ nóng: 500 điểm | 85 bình luận | Tác giả: Anon84 #

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

Bài viết định nghĩa rõ ràng ý nghĩa của “AI Agent” (tác nhân AI), tức là hệ thống tự động điều hướng quy trình và sử dụng công cụ của chính nó.
Phân biệt “Agent” (tác nhân) và “Workflow” (quy trình làm việc), đồng thời mô tả một số mẫu workflow hữu ích.
Có tác giả chia sẻ nội dung bài viết qua video, nhận được phản hồi tốt.
Có người cho rằng xây dựng hệ thống từ đầu mà không sử dụng framework là một thử nghiệm giáo dục tốt, nhưng framework tốt có thể giúp dễ dàng thử nghiệm các LLM khác nhau.
Có người cho rằng việc thay đổi API không phải là nút thắt cổ chai, mà là vấn đề hành vi hoặc sự khác biệt về khả năng giữa các mô hình.
Framework thường làm tăng thêm sự phức tạp, tính không minh bạch và sự không nhất quán của API.
Có người cho rằng sau khi có đủ khả năng quan sát, thử nghiệm, v.v., liệu có nên mặc định sử dụng framework hay không trở thành một vấn đề thực sự.
Có người khuyên nếu không phải là một công ty khởi nghiệp hoàn toàn mới, tốt nhất nên sử dụng trực tiếp API để khởi động sản phẩm V0.
Có người cảm thấy việc xây dựng hệ thống phức tạp bằng ngôn ngữ không kiểu (untyped language) là khó hiểu, đặc biệt khi AI hoặc ML duy nhất là các lệnh gọi API.
Có người nhấn mạnh rằng việc thay đổi API trong quá trình thử nghiệm là một điều vô cùng khó khăn, việc sử dụng một bộ cài đặt có thể thay đổi khóa và biến có thể đơn giản hóa quá trình này một cách đáng kể.
Có người khuyên dùng các thư viện (chứ không phải framework) cung cấp sự trừu tượng hóa cho các LLM khác nhau.
Framework nếu có cấu trúc về khả năng quan sát, đánh giá, triển khai, bảo mật đám mây, v.v., cũng có thể giúp chuẩn bị cho sản xuất.
Định nghĩa về workflow trong bài viết bị cho là không chính xác, workflow của các engine hiện đại không đi theo các đường dẫn mã được xác định trước.
Có người cho rằng sự khác biệt giữa workflow và agent nằm ở “mức độ hướng dẫn”, workflow có cấu trúc và quy tắc nhiều hơn, trong khi agent tự do hơn.
Có người nhấn mạnh rằng LLM không đủ tin cậy nếu không có “giàn giáo” thông qua một ví dụ về workflow đánh dấu ngôn ngữ.
Có người cho rằng workflow trong các hệ thống hiện đại thường không thể đoán trước được, chúng thường thực hiện một trong một nhóm các công cụ dựa trên phản hồi từ lệnh gọi trước đó (ví dụ: lệnh gọi LLM).

Scrappy – Tạo các ứng dụng nhỏ cho bạn và bạn bè của bạn #

Scrappy – Make little apps for you and your friends

https://pontus.granstrom.me/scrappy/

Bài viết này được John Chang và Pontus Granström viết, thảo luận về khái niệm và tiềm năng của phần mềm tự chế. Bài viết giới thiệu Scrappy, một công cụ nguyên mẫu nghiên cứu do họ cùng phát triển, một công cụ để tạo ra các ứng dụng “thô sơ” chỉ dành cho cá nhân và bạn bè của họ sử dụng. Họ hy vọng sẽ cụ thể hóa hình dạng của phần mềm tự chế bằng cách chia sẻ công cụ này và một số ví dụ về các ứng dụng được tạo bằng nó.

Scrappy là gì? Scrappy cho phép người dùng tạo “Scrapps”, tức là các ứng dụng dành cho các nhu cầu cụ thể. Bài viết minh họa các tình huống ứng dụng của Scrappy thông qua một vài ví dụ, bao gồm luyện tập số học cho học sinh tiểu học, bộ đếm số người tham gia sự kiện địa phương, đồng hồ tính chi phí cuộc họp và công cụ theo dõi công việc nhà hàng tuần, v.v. Mặc dù những ứng dụng này có thể không đủ tinh tế hoặc hấp dẫn, nhưng chúng được tạo ra theo sở thích cá nhân và có thể đáp ứng các nhu cầu cụ thể.

Trải nghiệm tạo ứng dụng Scrappy Scrappy cung cấp một canvas đối tượng tương tác vô hạn, với quy trình làm việc tương tự như Figma, Miro hoặc Google Slides. Người dùng có thể kéo các đối tượng như nút, trường văn bản và nhãn lên canvas, đồng thời sửa đổi thuộc tính đối tượng thông qua bảng kiểm tra. Ví dụ: đối tượng nút có thuộc tính “Khi nhấp vào”, chứa mã JavaScript. Khi nút được nhấp vào, mã đó sẽ chạy, chẳng hạn như ghi lại nội dung của trường văn bản vào một nhãn đóng vai trò là nhật ký. Người dùng có thể xây dựng ứng dụng từng bước, điều chỉnh và sắp xếp lại các đối tượng, đồng thời đính kèm một lượng nhỏ mã vào chúng.

Bài viết cũng cung cấp video, cho thấy tác giả tạo một bộ đếm số người tham gia sự kiện như thế nào. Video trình bày quá trình thêm trường số, nút, trường sức chứa địa điểm và hiển thị cảnh báo khi số lượng người quá đông. Ứng dụng Scrappy là đa người dùng trực tuyến, trạng thái ứng dụng được duy trì và đồng bộ hóa, tương tự như các tài liệu trực tuyến như Google Sheets hoặc Figma. Ngoài ra, ứng dụng Scrappy luôn ở trạng thái hoạt động, không có sự khác biệt giữa chỉnh sửa và chạy, người dùng có thể chỉnh sửa ứng dụng trong khi bạn bè của họ đang sử dụng. Người dùng cũng có thể chia sẻ có chọn lọc các phần cụ thể của ứng dụng, chẳng hạn như chỉ chia sẻ phần số người vào và ra.

Tại sao tạo Scrappy? Động lực của dự án là tái cấu trúc việc tạo và sử dụng phần mềm. Là một phần của phong trào “tiểu tính toán”, “lập trình giải trí” và “phần mềm tự nấu”, các tác giả muốn giải phóng người dùng cuối, cho phép họ thể hiện bản thân mà không cần phải là lập trình viên chuyên nghiệp. Họ hy vọng sẽ chuyển thế giới từ phần mềm sản xuất hàng loạt, công nghiệp hóa sang các công cụ cá nhân hóa hơn, thậm chí dùng một lần, có thể được thiết kế cho các môi trường xã hội cụ thể và dễ dàng sửa đổi và điều chỉnh. Họ được truyền cảm hứng từ sự đơn giản của các công cụ như Notion, tldraw và mmm.page, nhưng muốn trao cho mọi người khả năng tương tác và lập trình phong phú hơn.

Đối tượng mục tiêu của Scrappy là ai? Trong quá trình thiết kế nguyên mẫu, người dùng lý tưởng của Scrappy không rõ ràng. Khi hệ thống được xây dựng, một số hình mẫu người dùng tiềm năng dần xuất hiện. Những người dùng này bao gồm những người tối ưu hóa quy trình muốn sử dụng phần mềm để cải thiện quy trình kinh doanh, giáo viên và học sinh, cũng như các lập trình viên chuyên nghiệp như các tác giả, những người không thích lập trình vì sự phức tạp trong quá trình lập trình làm tăng thêm ma sát.

Bài viết kết luận rằng mặc dù họ nhận ra khả năng của các hệ thống dựa trên AI sử dụng LLMs để tạo mã, nhưng họ đã cố ý chọn tập trung thiết kế vào thao tác trực tiếp và kiểm soát của người dùng.

HN | Độ nóng: 408 điểm | 130 bình luận | Tác giả: 8organicbits #

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

Có người thích tinh thần Scrappy, nhưng cho rằng nó, với tư cách là một giải pháp được quản lý, phụ thuộc vào các công cụ SaaS, không phù hợp để sử dụng lâu dài.
Có người có xu hướng sử dụng các công nghệ cơ bản như HTML/CSS/JS và PHP để xây dựng các dự án cá nhân, vì chúng không phụ thuộc vào trình duyệt và chi phí bảo trì thấp.
Có người đưa ra khái niệm TiddlyWiki, cho rằng nó là một ứng dụng Web hoàn chỉnh, có thể tự sao chép, phù hợp với nhu cầu cá nhân hóa quy mô nhỏ.
Có người đang xây dựng một môi trường thời gian chạy HTML tự sửa đổi lấy cảm hứng từ TiddlyWiki, cho phép người dùng xây dựng “ứng dụng HTML” trong một tệp HTML duy nhất.
Có người hỏi liệu công nghệ này có phù hợp với phương pháp siêu phương tiện hay không, và khám phá xem có sách hoặc công cụ liên quan nào hỗ trợ công nghệ này không.
Có người đề cập đến chức năng “ghi tại chỗ” của TiddlyWiki, nhấn mạnh khả năng tồn tại tối thượng của nó trong việc bảo trì wiki/sổ tay gia đình.
Có người mong muốn có một framework có thể tự sao chép như TiddlyWiki, nhưng đơn giản hơn và có thể tích hợp Markdown và HTML tốt hơn.
Có người đánh giá cao việc Hyperclay không yêu cầu cài đặt ứng dụng, cho rằng nó kết hợp sự đơn giản của TiddlyWiki và ưu điểm của mạng chia sẻ.
Có người bày tỏ lo ngại về việc cần chạy máy chủ để chia sẻ TiddlyWiki, cho rằng điều này không đơn giản đối với người dùng bình thường.

Iran yêu cầu người dân xóa WhatsApp khỏi thiết bị của họ #

Iran asks its people to delete WhatsApp from their devices

https://apnews.com/article/iran-whatsapp-meta-israel-d9e6fe43280123c9963802e6f10ac8d1

Đài truyền hình quốc gia Iran vào ngày 18 tháng 6 năm 2025 đã kêu gọi người dân xóa WhatsApp khỏi điện thoại thông minh của họ, tuyên bố rằng ứng dụng này thu thập thông tin người dùng và gửi nó cho Israel mà không có bằng chứng cụ thể. WhatsApp bày tỏ lo ngại về điều này, cho rằng những báo cáo sai lệch này có thể trở thành cái cớ để chặn dịch vụ của họ, đặc biệt là khi người dân cần dịch vụ của họ nhất. WhatsApp nhấn mạnh rằng họ sử dụng công nghệ mã hóa đầu cuối, đảm bảo rằng chỉ người gửi và người nhận mới có thể đọc được tin nhắn, trong khi các nhà cung cấp dịch vụ trung gian không thể giải mã được.

WhatsApp cho biết trong một tuyên bố: “Chúng tôi không theo dõi vị trí chính xác của người dùng, không lưu giữ hồ sơ tin nhắn của mỗi người và không theo dõi tin nhắn được gửi giữa các cá nhân. Chúng tôi không cung cấp thông tin hàng loạt cho bất kỳ chính phủ nào.” Tuy nhiên, Gregory Falco, một chuyên gia an ninh mạng tại Đại học Cornell, chỉ ra rằng metadata của WhatsApp không được mã hóa, điều này có nghĩa là có thể thu thập thông tin về cách người dùng sử dụng ứng dụng. Ngoài ra, chủ quyền dữ liệu cũng là một vấn đề, vì các trung tâm dữ liệu của WhatsApp không nhất thiết phải nằm ở quốc gia của người dùng, điều này khiến cho việc bảo mật và tin tưởng dữ liệu trở nên phức tạp hơn.

Iran đã nhiều lần chặn các nền tảng truyền thông xã hội trong vài năm qua, nhưng nhiều người đã vượt qua các hạn chế thông qua proxy và mạng riêng ảo (VPN). Trong các cuộc biểu tình lớn nổ ra vào năm 2022 do một phụ nữ qua đời trong khi bị cảnh sát đạo đức giam giữ, Iran đã chặn WhatsApp và Google Play, nhưng lệnh cấm này đã được dỡ bỏ vào cuối năm ngoái. WhatsApp từng là một trong những ứng dụng nhắn tin phổ biến nhất ở Iran, bên cạnh Instagram và Telegram.

HN | Độ nóng: 341 điểm | 467 bình luận | Tác giả: rdrd #

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

Tuyên bố của Meta sử dụng từ ngữ khéo léo, trên thực tế có thể đang theo dõi vị trí chung, ghi lại tin nhắn nhóm và cung cấp thông tin cụ thể cho chính phủ khi được yêu cầu.
Nếu Meta bí mật cung cấp quyền truy cập backdoor cho một số cơ quan tình báo, giống như Microsoft với chương trình PRISM hoặc AT&T với chương trình 641A, có thể không ai phát hiện ra, do đó Meta không phải chịu hậu quả bất lợi thực tế nào.
Meta cũng nói dối về những việc khác, không có lý do gì để không nói dối bây giờ, vì họ dường như không bị trừng phạt nhiều sau khi bị bắt gặp nói dối.
Có người đặt câu hỏi liệu Meta có bao giờ cố ý nói dối hay không và yêu cầu cung cấp ví dụ.
Ủy ban Châu Âu phát hiện ra rằng Facebook đã cung cấp “thông tin gây hiểu lầm” khi mua lại WhatsApp vào năm 2014, đặc biệt là về vấn đề chia sẻ dữ liệu người dùng.
Có người đề cập đến việc Meta “vô tình” đặt lại cài đặt quyền riêng tư của người dùng là một hành vi nói dối.
Có người cho rằng “giảm giá tới 50%” trong quảng cáo của doanh nghiệp là một tuyên bố đúng về mặt kỹ thuật, nhưng trên thực tế hầu hết các sản phẩm chỉ được giảm giá rất nhỏ.
Có người cho rằng những luật sư giỏi nhất làm việc cho các công ty lớn này, họ giỏi soạn thảo các điều khoản và điều kiện, khiến công ty không bị bắt gặp nói dối trước tòa ngay cả khi có hành vi sai trái.
Có người cho rằng việc theo dõi mạng máy chủ cục bộ Android đến ứng dụng, vốn là bất hợp pháp theo GDPR, có thể được coi là hành vi nói dối của Meta.
Có người chỉ ra rằng ngay cả khi mọi người phát hiện ra hành vi sai trái của Meta, cũng không có hậu quả thực chất nào.
Có người nhấn mạnh rằng ngay cả sau khi phát hiện ra hành vi sai trái, cũng không ai thực sự quan tâm.
Có người cho rằng, mặc dù truyền thông bị kiểm soát bởi một số ít người, nhưng vẫn có rất nhiều người quan tâm đến các vấn đề như quyền riêng tư, bảo hiểm y tế, môi trường, v.v.

Brad Lander bị giam giữ bởi các đặc vụ liên bang đeo mặt nạ bên trong tòa án nhập cư #

Brad Lander detained by masked federal agents inside immigration court

https://www.thecity.nyc/2025/06/17/brad-lander-arrest-ice-immigration-court/

Bài viết này đưa tin về sự việc Kiểm toán viên thành phố New York Brad Lander bị các đặc vụ liên bang bắt giữ bên ngoài một tòa án nhập cư ở Manhattan. Brad Lander đồng thời cũng là ứng cử viên thị trưởng trong cuộc bầu cử sơ bộ của đảng Dân chủ vào thứ Ba tới. Sự việc bắt đầu khi Lander đến thăm tòa án nhập cư, ông đã cố gắng hộ tống một người đàn ông rời khỏi tòa án.

Sau hơn bốn giờ bị giam giữ, Lander cuối cùng đã được thả mà không bị buộc tội nào, nhờ sự can thiệp của Thống đốc bang New York Kathy Hochul. Sau khi được thả, ông nói với những người ủng hộ rằng, mặc dù ông biết mình sẽ được xét xử công bằng và được bảo vệ quyền lợi, nhưng Edgardo, người nhập cư bị giam giữ cùng ông, sẽ bị giam giữ trong một cơ sở giam giữ của ICE, mất đi quyền được xét xử công bằng.

Trước đó, Lander đã ba lần quan sát các phiên điều trần nhập cư liên bang và hộ tống người nhập cư rời khỏi các phiên điều trần thường lệ của tòa án. Vào khoảng giữa trưa, ông và Edgardo nắm tay nhau rời khỏi tòa án nhập cư, từ chối buông tay ngay cả khi các đặc vụ liên bang cố gắng tách họ ra. Trong cảnh hỗn loạn, Lander liên tục yêu cầu các đặc vụ xuất trình trát tư pháp và tuyên bố “các anh không có quyền bắt giữ công dân Hoa Kỳ”, sau đó ông bị còng tay.

Các đặc vụ liên bang đưa ông vào thang máy, một thành viên trong đội an ninh của Sở Cảnh sát New York cũng đi cùng. Một phóng viên nghe thấy một đặc vụ nói với một đặc vụ khác trước khi Lander bị bắt: “Anh muốn bắt giữ kiểm toán viên à?”

Các nhà chức trách liên bang thực sự muốn bắt giữ ông. Trợ lý Bộ trưởng Bộ An ninh Nội địa Tricia McLaughlin cho biết trong một tuyên bố rằng Brad Lander đã bị bắt vì hành hung nhân viên thực thi pháp luật và cản trở các quan chức liên bang, đồng thời nhấn mạnh “không ai được đứng trên luật pháp, nếu bạn tấn công nhân viên thực thi pháp luật, bạn sẽ phải đối mặt với hậu quả”. Tài khoản X chính thức của Bộ An ninh Nội địa trên Twitter cũng đưa ra những tuyên bố tương tự, đồng thời cáo buộc các chính trị gia tìm kiếm các vị trí cao hơn đang phá hoại sự an toàn của lực lượng thực thi pháp luật để có được những khoảnh khắc lan truyền trên mạng.

Bản tin đề cập rằng video của THE CITY cho thấy Lander nắm chặt người bị ICE bắt giữ, nhưng không cho thấy ông tấn công bất kỳ ai. Vụ bắt giữ Lander đã gây ra sự phẫn nộ rộng rãi, nhiều quan chức dân cử và ứng cử viên thị trưởng đã tập trung tại số 26 Quảng trường Liên bang, yêu cầu thả ông ngay lập tức. Trong số đó có ủy viên hội đồng Zohran Mamdani, người đồng ủng hộ Lander tranh cử thị trưởng.

Thống đốc Kathy Hochul đã viết trên mạng xã hội: “Đây là điều vô nghĩa”, và đích thân đến số 26 Quảng trường Liên bang vào chiều muộn hôm đó, ôm vợ của Lander, rồi bước vào tòa nhà. Bà nói với các phóng viên rằng bà đến đây để ủng hộ Lander và tất cả những người đang ở trong tình huống này, đồng thời nói rằng điều này là không thể dung thứ được.

Người phát ngôn của Thị trưởng Eric Adams, Kayla Mamelak Altus, đã đưa ra một tuyên bố bốn giờ sau khi Lander bị bắt, nói rằng “hôm nay không nên tập trung vào Brad Lander”, mà là đảm bảo rằng tất cả người dân New York - bất kể tình trạng giấy tờ của họ như thế nào - đều cảm thấy đủ an toàn để sử dụng các nguồn lực công cộng, chẳng hạn như gọi 911, đưa con đến trường, đến bệnh viện hoặc ra tòa, thay vì trốn trong bóng tối. Trước đó, ít nhất hai đồng minh chính trị của Adams đã chế nhạo Lander trên mạng, bao gồm cả cựu Chánh văn phòng Thị trưởng Frank Carone, người đã chế nhạo đây là một màn trình diễn “giải Oscar”.

HN | Độ nóng: 323 điểm | 295 bình luận | Tác giả: sjsdaiuasgdia #

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

Tiêu đề bài viết không khớp với nội dung thực tế, tiêu đề trên Hacker News đã bị sửa đổi.
Không có bằng chứng nào cho thấy đó là đặc vụ liên bang, vì họ từ chối tiết lộ danh tính.
Mọi người có thể rút súng vì nhầm tưởng bị bắt cóc.
Bây giờ bất kỳ ai cũng có thể giả làm đặc vụ ICE để bắt giữ các nhân chứng quan trọng tại tòa án mà không bị ràng buộc bởi luật pháp.
Anh ta thực sự bị bắt vì yêu cầu xem lệnh khám xét.
Anh ta bị buộc tội cản trở hoạt động thực thi pháp luật liên bang và tấn công quan chức.
Yêu cầu xem lệnh khám xét bị coi là cản trở hoạt động thực thi pháp luật liên bang.
Bây giờ chúng ta đang sống trong một “xã hội hậu sự thật”.
Giới truyền thông tạo ra tin giả để thu hút lượt nhấp, kích động cảm xúc, bán sản phẩm hoặc đưa tin tồi tệ.
Tiêu đề của Hacker News đã được cập nhật để phù hợp với câu chuyện thực tế.
Giới truyền thông tạo ra ảo ảnh để che đậy sự thiếu hụt sự thật, thay vì tạo ra sự thật sai lệch.
Chúng ta đang sống trong một thế giới siêu thực, trong đó mọi biểu tượng đều là một mô phỏng che đậy sự thiếu hụt sự thật.
Không có cái gọi là tin tốt hay tin xấu, mọi thứ đều là mô phỏng.
Kinh nghiệm của con người rất phức tạp và không thể đơn giản đối lập “sự thật” với “mô phỏng”.
Baudrillard không phải là nhà hậu cấu trúc luận hay hậu hiện đại, ông phản đối hậu cấu trúc luận và giữ khoảng cách với chủ nghĩa hậu hiện đại.

Crate Bzip2 chuyển từ C sang 100% Rust #

Bzip2 crate switches from C to 100% Rust

https://trifectatech.org/blog/bzip2-crate-switches-from-c-to-rust/

Bài viết này được Folkert de Vries đăng vào ngày 17 tháng 6 năm 2025, chủ đề là về một bản cập nhật quan trọng của thuật toán nén dữ liệu bzip2. Bài viết thông báo về việc phát hành bzip2 phiên bản 0.6.0, phiên bản này mặc định sử dụng thuật toán bzip2 được triển khai bằng Rust, tức là libbz2-rs-sys. Bản cập nhật này giúp bzip2 crate (một gói trong trình quản lý gói của Rust) cải thiện về hiệu suất và dễ dàng biên dịch đa nền tảng hơn.

Bài viết bắt đầu bằng một câu hỏi: Tại sao vẫn còn quan tâm đến thuật toán từ những năm 90 này ngày nay, mặc dù nó hiện được sử dụng rất ít? Tác giả giải thích rằng nhiều giao thức và thư viện vẫn cần hỗ trợ bzip2 để tuân thủ các đặc tả của chúng, do đó nhiều dự án vẫn phụ thuộc vào bzip2 ở sâu trong cây phụ thuộc của chúng. Tác giả đã sử dụng kinh nghiệm từ dự án zlib-rs để hiện đại hóa việc triển khai bzip2.

Bài viết sau đó trình bày chi tiết những cải tiến về hiệu suất của việc triển khai bằng Rust so với việc triển khai bằng C. Về mặt nén, việc triển khai bằng Rust thường nhanh hơn việc triển khai bằng C, mặc dù trong một số trường hợp, hiệu suất của cả hai là tương đương. Đối với bzip2, mức nén cho biết lượng bộ nhớ được sử dụng, nhưng không ảnh hưởng nhiều đến hiệu suất. Bài viết cung cấp một số dữ liệu so sánh hiệu suất cụ thể, cho thấy sự cải thiện về hiệu suất của việc triển khai bằng Rust trong việc nén và giải nén ở các mức nén và loại tệp khác nhau.

Bài viết cũng đề cập đến lợi thế của việc biên dịch đa nền tảng. Các dự án Rust sử dụng các phụ thuộc C thường có thể được biên dịch đa nền tảng ngay lập tức, nhưng nếu có vấn đề, lỗi có thể khó gỡ lỗi. Bằng cách loại bỏ các phụ thuộc C và sử dụng mã Rust, sự phức tạp của việc biên dịch C biến mất, giúp việc biên dịch đa nền tảng trở nên đơn giản, đặc biệt là khi biên dịch sang WebAssembly, Windows hoặc Android.

Ngoài ra, bài viết đề cập rằng theo mặc định, libbz2-rs-sys không xuất các ký hiệu, điều này có nghĩa là nó sẽ không xung đột với các phụ thuộc khác. Nếu một dự án Rust cần xuất các ký hiệu, nó có thể được bật thông qua một cờ tính năng.

Bài viết cũng đề cập đến lợi ích của việc sử dụng MIRI để chạy thử nghiệm, MIRI là một thời gian chạy thử nghiệm của Rust, có thể chạy các chương trình chứa mã unsafe. Điều này không chỉ có lợi cho việc triển khai bzip2 mà còn cho phép các thư viện hoặc ứng dụng cấp cao hơn sử dụng bzip2 chạy trên MIRI.

Cuối cùng, bài viết đề cập đến kết quả kiểm toán, cuộc kiểm toán đã phát hiện ra một lỗi logic (một lỗi offset) và sửa một số hạn chế của fuzzer. Ngoài ra, không có vấn đề lớn nào được tìm thấy.

Bài viết kết thúc bằng lời cảm ơn đến các cá nhân và tổ chức tham gia dự án, bao gồm Alex Crichton, Radically Open Security và NLnet Foundation.

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

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

Bản triển khai bzip2 của Trifecta Tech có khả năng thay thế bản triển khai chính thức đang được sử dụng trong các bản phân phối Linux.
Bản triển khai bzip2 chính thức đã không được cập nhật kể từ năm 2019, có thể có nghĩa là dự án đã hoàn thành.
Tốc độ nén tăng 10-15% và tốc độ giải nén tăng 5-10% là một tính năng mới hấp dẫn.
Việc tối ưu hóa mã để tăng tốc có thể phải trả giá bằng khả năng đọc mã.
Việc dịch cơ sở mã hiện có sang Rust có thể làm cho mọi thứ trở nên phức tạp hơn.
Ubuntu đã bắt đầu sử dụng sudo được viết bằng Rust, cho thấy sự chuyển đổi này là khả thi.
Ai đó cần phải thực hiện công việc để triển khai một phiên bản tương thích C ABI.
Dự án uutils nhằm mục đích viết lại các công cụ GNU.
Có người hy vọng những công cụ này sẽ trở thành công cụ mặc định.
Có người cho rằng giấy phép MIT là một sai lầm, vì điều đó có nghĩa là không thể chuyển mã được cấp phép GPL sang các dự án được cấp phép MIT.
Có người không thích sự phức tạp của các công cụ GNU, cho rằng việc viết lại từ đầu là một tính năng.
Có người hy vọng hiệu suất của các công cụ sẽ được cải thiện.
Có người đề cập đến ripgrep và tokei so với các công cụ mà chúng thay thế có hiệu suất được cải thiện đáng kể.
Có người cho rằng việc gọi các công cụ là “thay thế” là không phù hợp, vì chúng không hoàn toàn thay thế các công cụ ban đầu.
Có người chỉ ra rằng các công cụ GNU bản thân chúng là sự thay thế cho các công cụ BSD, và các công cụ BSD là sự thay thế cho các công cụ AT&T.
Có người hài lòng với bash, cho rằng nó không phải là một dự án lỗi thời.
Có người đồng ý rằng “X nhưng được viết lại bằng Z” là một cách tiếp thị tồi tệ.

MiniMax-M1: Mô hình suy luận hybrid-attention quy mô lớn, trọng số mở #

MiniMax-M1 open-weight, large-scale hybrid-attention reasoning model

https://github.com/MiniMax-AI/MiniMax-M1

MiniMax-M1 là mô hình suy luận chú ý hỗn hợp quy mô lớn, mở trọng số đầu tiên trên toàn cầu. Mô hình này sử dụng kiến trúc Mixture of Experts (MoE) và cơ chế chú ý chớp nhoáng, được phát triển dựa trên mô hình MiniMax-Text-01 trước đó, bao gồm 456 tỷ tham số, mỗi token kích hoạt 45,9 tỷ tham số. Tương tự như MiniMax-Text-01, mô hình M1 hỗ trợ gốc độ dài ngữ cảnh 1 triệu token, gấp 8 lần DeepSeek R1. Cơ chế chú ý chớp nhoáng của MiniMax-M1 giúp cải thiện hiệu quả tính toán trong quá trình thử nghiệm, ví dụ, khi tạo 100K token, M1 chỉ tiêu thụ 25% FLOPs so với DeepSeek R1. Những đặc tính này khiến M1 đặc biệt phù hợp để xử lý các tác vụ phức tạp đòi hỏi đầu vào dài hạn và suy nghĩ sâu sắc.

MiniMax-M1 được đào tạo thông qua học tăng cường (RL) quy mô lớn, liên quan đến các vấn đề đa dạng từ suy luận toán học truyền thống đến môi trường kỹ thuật phần mềm thế giới thực dựa trên sandbox. Một framework mở rộng RL hiệu quả đã được phát triển, làm nổi bật hai góc độ: (1) Đề xuất thuật toán CISPO, cắt tỉa trọng số lấy mẫu tầm quan trọng thay vì cập nhật token, hoạt động tốt hơn các biến thể RL cạnh tranh khác; (2) Thiết kế chú ý hỗn hợp tự nhiên nâng cao hiệu quả RL, giải quyết các thách thức riêng khi mở rộng RL trong kiến trúc hỗn hợp. Hai phiên bản của mô hình MiniMax-M1 đã được đào tạo, với ngân sách suy nghĩ lần lượt là 40K và 80K. Trong các bài kiểm tra chuẩn tiêu chuẩn, các mô hình này vượt trội hơn các mô hình mở trọng số mạnh mẽ khác, chẳng hạn như DeepSeek-R1 và Qwen3-235B gốc, trong các tác vụ kỹ thuật phần mềm phức tạp, sử dụng công cụ và ngữ cảnh dài. Với khả năng mở rộng hiệu quả tính toán trong quá trình thử nghiệm, MiniMax-M1 cung cấp một nền tảng mạnh mẽ cho các agent mô hình ngôn ngữ thế hệ tiếp theo để suy luận và ứng phó với các thách thức trong thế giới thực.

Trong các bài kiểm tra chuẩn cốt lõi, hiệu suất của MiniMax-M1 như sau:

Toán học: Trong các tác vụ như AIME 2024, AIME 2025 và MATH-500, MiniMax-M1-80K và MiniMax-M1-40K đều hoạt động tốt hơn Qwen3-235B-A22B và DeepSeek-R1-0528.
Mã hóa chung: Trong các tác vụ LiveCodeBench và FullStackBench, MiniMax-M1 cũng hoạt động tốt hơn các mô hình khác.
Suy luận và kiến thức: Trong các tác vụ GPQA Diamond, HLE (không có công cụ) và ZebraLogic, MiniMax-M1 đạt điểm số cao hơn.
Kỹ thuật phần mềm: Trong tác vụ SWE-bench Verified, MiniMax-M1 đạt điểm cao hơn các mô hình khác.
Ngữ cảnh dài: Trong các tác vụ OpenAI-MRCR (128k và 1M) và LongBench-v2, MiniMax-M1 thể hiện hiệu suất vượt trội.
Sử dụng công cụ agent: Trong các tác vụ TAU-bench (hàng không và bán lẻ), MiniMax-M1 cũng đạt điểm cao hơn các mô hình khác.
Tính xác thực: Trong tác vụ SimpleQA, MiniMax-M1 đạt điểm thấp hơn.
Trợ lý chung: Trong tác vụ MultiChallenge, MiniMax-M1 hoạt động tương đương với các mô hình khác.

Tất cả các mô hình đều được đánh giá ở nhiệt độ 1.0, top_p là 0.95. Phương pháp luận SWE-bench báo cáo kết quả thu được từ giàn giáo không có agent, sử dụng quy trình định vị hai giai đoạn (không sử dụng bất kỳ cơ chế truy xuất dựa trên embedding nào): đầu tiên là định vị tệp thô, sau đó là định vị chi tiết đến các tệp và phần tử mã cụ thể. Giá trị của mô hình được tính dựa trên một tập hợp con gồm n=486 tác vụ xác minh.

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

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

Để chạy mô hình MiniMax-M1 cần 8 GPU H200 141GB, chi phí khoảng 250.000 đô la
Có thể chạy mô hình trên Mac Studio được trang bị 512GB RAM, chi phí khoảng 8500 đô la
Thông qua lượng tử hóa Q4 hoặc Q8 có thể chạy mô hình trên thiết bị có giá dưới 10.000 đô la
Hiệu suất của mô hình lượng tử hóa nặng có thể không tốt bằng mô hình chưa lượng tử hóa, nhưng tốt hơn mô hình chưa lượng tử hóa có cùng kích thước
Lượng tử hóa Q8 hầu như không làm giảm chất lượng, lượng tử hóa Q4 có thể đo lường được sự giảm chất lượng, nhưng không phải là vấn đề thực tế
Điểm chuẩn có thể không đại diện cho các tình huống sử dụng thực tế, do đó khó đánh giá hiệu suất của mô hình
Bằng cách thêm một lượng lớn xử lý thưa thớt, mô hình này sẽ có thể chạy trên Raspberry Pi
Mô hình MiniMax-M1 đã được xử lý thưa thớt từ mô hình 150T tham số
150 nghìn tỷ tham số đề cập đến số lượng synapse trong não người
Sáu tháng sau, người ta có thể phát hiện ra rằng những người mua GPU H200 đã bị lừa 250.000 đô la, vì chỉ cần lượng tử hóa cụ thể và một số tối ưu hóa là có thể chạy mô hình cục bộ
Không cần thiết phải chạy bất kỳ mô hình nào ngoài lượng tử hóa toàn phần
Lượng tử hóa là hiệu quả và không nên bị nghi ngờ
Mô hình MiniMax-M1 có khoảng 456 tỷ tham số, khoảng 46 tỷ tham số hoạt động tại bất kỳ thời điểm nào
Công ty MiniMax đã phát hành các mô hình M1 và Hailuo 2 trong “Tuần phát hành”, báo cáo kỹ thuật rất đáng đọc
MiniMax M1 gợi nhớ đến chip M1 của Apple
MiniMax là một công ty Trung Quốc, trình tạo video của họ có một cái tên tiếng Trung rất rõ ràng (Hailuo)
Mọi người không mong đợi các công ty đề cập đến quốc gia của họ trên trang dự án
Các công ty không nhất thiết phải công bố quốc gia nơi họ đặt trụ sở trên trang web chính thức của họ
Thông thường cần phải nỗ lực để tìm ra vị trí của một công ty khởi nghiệp
OpenAI đã đề cập đến địa chỉ và địa điểm đăng ký của họ trong điều khoản sử dụng của họ

Google Dịch có thể cho chúng ta biết gì về vibecoding #

What Google Translate can tell us about vibecoding

https://ingrids.space/posts/what-google-translate-can-tell-us-about-vibecoding/

Bài viết này thảo luận về tác động của các mô hình ngôn ngữ lớn (LLMs) đối với lập trình máy tính, và so sánh nó với sự phát triển của công nghệ dịch máy trong lĩnh vực dịch thuật. Tác giả cho rằng, mặc dù có rất nhiều cuộc thảo luận về việc LLMs sẽ dẫn đến việc các lập trình viên mất việc, nhưng những cuộc thảo luận này thường thiếu sự tinh tế. Bài viết khám phá những quan điểm này thông qua việc phân tích sự phát triển của Google Dịch, đặc biệt là những thay đổi kể từ khi chuyển sang dịch máy thần kinh (NMT) vào năm 2016.

Tác giả chỉ ra rằng, mặc dù có người cho rằng sự xuất hiện của Google Dịch đồng nghĩa với sự kết thúc của nghề dịch thuật và phiên dịch, nhưng trên thực tế cơ hội việc làm trong lĩnh vực dịch thuật và phiên dịch lại đang tăng lên. Điều này là do công nghệ dịch máy, mặc dù làm tốt ở một số khía cạnh, nhưng nó không thể xử lý ngữ cảnh, tính mơ hồ và sự nhạy cảm về văn hóa như người dịch. Ví dụ, mặc dù tiếng Na Uy và tiếng Anh rất giống nhau, nhưng tiếng Na Uy thiếu các cách diễn đạt lịch sự, điều này cần được đặc biệt chú ý khi dịch. Google Dịch có thể dịch trực tiếp các câu tiếng Na Uy nghe có vẻ kiêu ngạo, trong khi một người phiên dịch giỏi sẽ cung cấp bản dịch nhạy cảm hơn dựa trên ngữ cảnh.

Bài viết cũng đề cập rằng, ngay cả trong lĩnh vực dịch thuật, công nghệ dịch máy cũng không thể hoàn toàn thay thế người dịch. Tác giả cho rằng, các lập trình viên có thể được coi là người dịch, họ dịch nhu cầu và sắc thái văn hóa của con người thành mã mà máy tính có thể hiểu được. Mặc dù việc liên tục tạo ra các khái niệm trừu tượng mới trong ngôn ngữ lập trình khiến cho việc ứng dụng dịch máy trong ngôn ngữ lập trình đến muộn hơn một chút so với ngôn ngữ tự nhiên, nhưng hiện tại đã có những tiến bộ lớn.

Tác giả kết luận rằng, mặc dù AI trong tương lai có thể có khả năng xử lý ngữ cảnh và tính mơ hồ như con người, nhưng chúng ta sẽ phải trải qua ít nhất một mùa đông AI nữa mới có thể đạt đến trình độ đó. Đồng thời, tác giả cũng đề cập rằng, mặc dù các công cụ LLMs có những hạn chế nhất định, nhưng những tác động tiêu cực bên ngoài của chúng có thể lớn hơn tính hữu dụng của chúng. Nhìn chung, bài viết nhấn mạnh tầm quan trọng của việc thận trọng và nhận thức về sự khác biệt tinh tế trong quá trình phát triển công nghệ.

HN | Độ nóng: 277 điểm | 160 bình luận | Tác giả: todsacerdoti #

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

Google Translate không thể xử lý các vấn đề về ngữ cảnh, tính mơ hồ và sự nhạy cảm về văn hóa trong bản dịch, nhưng LLM có thể xử lý nếu có đủ ngữ cảnh
LLM thể hiện xuất sắc trong việc dịch tiếng Nhật và tiếng Anh, đặc biệt là sau khi được nhắc nhở thích hợp
Thông qua hệ thống dịch đa mô hình, có thể tạo ra kết quả dịch tốt hơn so với một mô hình duy nhất, thậm chí gần bằng trình độ dịch thuật chuyên nghiệp hàng đầu của con người
Đối với công việc phiên dịch không trực tiếp, người phiên dịch có thể tạm thời không cần lo lắng về việc bị thay thế
Công cụ dịch LLM có thể chọn mô hình tốt nhất để dịch và được mô hình đánh giá cuối cùng phê bình, so sánh và tổng hợp bản dịch tốt nhất
Chức năng lựa chọn mức độ trang trọng khi dịch rất quan trọng, Google Translate có xu hướng sử dụng ngôn ngữ quá trang trọng
Tiếng Thụy Điển mặc định sử dụng ngữ vực không chính thức
Cung cấp thêm ngữ cảnh, đặt câu hỏi tiếp theo và suy luận về văn bản là rất quan trọng để dịch
Cần có đủ độ dài cho lời nhắc khi dịch để giảm sự mơ hồ
Mục đích của ứng dụng dịch thuật là hướng dẫn những người không quen thuộc với các vấn đề và chi tiết dịch thuật để có được kết quả dịch tốt hơn
Đối với văn bản dài cần dịch, cần có một phương pháp để xử lý vấn đề cửa sổ ngữ cảnh quá dài, có thể cần tóm tắt nội dung trước đó và các ghi chú về cách xử lý các tên và thuật ngữ cụ thể