2025-07-04 Top Stories #

Collin Richards đã chuyển tmux từ ngôn ngữ C sang ngôn ngữ Rust, mất 6 tháng, dịch thủ công mã và chia sẻ kinh nghiệm sửa lỗi.
Trang web chính thức của Đánh giá Khí hậu Quốc gia Hoa Kỳ đã đóng cửa, công chúng không thể tiếp cận thông tin quan trọng về biến đổi khí hậu, các nhà khoa học lo ngại rằng hành động này có thể làm tăng nguy cơ gây hại cho công chúng.
Trình ghi chú AI được sử dụng rộng rãi trong các cuộc họp Zoom, một số người cho rằng nó làm giảm tương tác giữa các cá nhân, nhưng cũng được coi là một công cụ hữu ích để nâng cao hiệu quả.
Các nhà thiên văn học đã phát hiện ra vật thể giữa các vì sao thứ ba 3I/ATLAS, có tốc độ nhanh nhất, quỹ đạo bất thường và dự kiến khó quan sát.
Armin Ronacher thảo luận về những hạn chế của MCP, nhấn mạnh rằng việc sử dụng trực tiếp các công cụ mã hiệu quả hơn và trình bày các ứng dụng thực tế của việc kết hợp mã với LLM.
Couchers.org chính thức kết thúc giai đoạn Beta, ra mắt phiên bản 1.0, nâng cao trải nghiệm du lịch bụi và sự an toàn của cộng đồng.
Tác giả thảo luận về những thách thức trong việc xây dựng AI Agent, chỉ ra các vấn đề về quản lý ngữ cảnh và độ tin cậy, đồng thời kêu gọi tập trung hơn vào việc tạo ra giá trị thực tế.
Một bài viết kể về kinh nghiệm gỡ lỗi một lỗi khó tái hiện trong kernel Linux, giới thiệu chi tiết quy trình và phương pháp gỡ lỗi.
Một nhà nghiên cứu bảo mật đã sử dụng GitHub API để quét các commit đã bị xóa, phát hiện ra các bí mật bị rò rỉ và nhấn mạnh rằng ngay cả khi xóa commit, bí mật vẫn có thể được tìm thấy.
Bài viết thảo luận về chiến thuật lý thuyết được gọi là “Pháo binh nông dân” trong phiên bản thứ năm của “Ngục tối và Rồng”, sử dụng các lỗ hổng trong quy tắc để gây ra sát thương lớn cho kẻ thù.

Giới thiệu tmux-rs #

Introducing tmux-rs

https://richardscollin.github.io/tmux-rs/

Bài viết này giới thiệu quá trình Collin Richards chuyển tmux từ ngôn ngữ C sang ngôn ngữ Rust. Tác giả đã dành khoảng 6 tháng để chuyển đổi cơ sở mã của tmux từ C sang Rust, đạt được 100% mã Rust. Quá trình này liên quan đến việc chuyển đổi khoảng 67.000 dòng mã C thành khoảng 81.000 dòng mã Rust (không bao gồm chú thích và dòng trống).

Tác giả ban đầu thử sử dụng công cụ C2Rust để chuyển đổi mã. C2Rust là một trình biên dịch chuyển đổi C sang Rust. Mặc dù việc thiết lập có chút phức tạp, nhưng một khi chạy, nó đã chuyển đổi thành công cơ sở mã tmux sang mã Rust. Tuy nhiên, mã được tạo ra hầu như không thể bảo trì và lớn hơn ba lần so với mã C gốc. Tác giả đã cố gắng tái cấu trúc thủ công những đoạn mã này, nhưng vẫn cần thường xuyên xem mã C gốc để hiểu ý định của chương trình. Cuối cùng, tác giả đã từ bỏ kết quả đầu ra của C2Rust và quyết định dịch thủ công tất cả các tệp từ ngôn ngữ C sang ngôn ngữ Rust.

Trong quá trình xây dựng, tác giả trước tiên cần hiểu cách tmux được xây dựng, cụ thể là autotools. Anh ấy đã học cách thêm hoặc xóa các tệp trong autogen.sh và cách sửa đổi Makefile được tạo để liên kết đến thư viện tĩnh được tạo bởi crate Rust của mình. Quá trình này có nghĩa là quá trình xây dựng không đơn giản như chạy cargo build. Tác giả đã viết một tập lệnh build.sh nhỏ, tập lệnh này sẽ gọi cargo, sau đó chạy make. Trong quá trình này, tác giả đã cố gắng chia dự án thành các mini crate, nhưng do crate không thể có phụ thuộc vòng tròn, và do có thể gặp sự cố liên kết khi liên kết nhiều thư viện Rust vào cùng một tệp nhị phân, nên cuối cùng đã quyết định đặt mọi thứ vào cùng một crate.

Ban đầu, tác giả dịch từng tệp một, nhưng khi dịch một tệp lớn và gặp khó khăn trong việc gỡ lỗi, anh ấy đã thay đổi quy trình phát triển, thay vào đó chỉ dịch một hàm một lần và chạy nhanh build.sh giữa các lần dịch để đảm bảo mọi thứ đều ổn. Quá trình này có nghĩa là cần thêm các tệp tiêu đề bổ sung vào mã C cho các hàm vốn là tĩnh. Quy trình phát triển mới như sau: sao chép tệp tiêu đề của hàm C, chú thích phần thân hàm C, sau đó triển khai hàm đó trong Rust. Miễn là hàm có chú thích #\[unsafe(no\_mangle)\] extern “C" và chữ ký chính xác, mã C sẽ liên kết đến triển khai Rust.

Sau khi dịch khoảng một nửa số tệp C, tác giả bắt đầu suy nghĩ xem quy trình xây dựng hiện tại có hơi ngớ ngẩn hay không. Vì phần lớn mã hiện được viết bằng Rust, anh ấy nên xây dựng một tệp nhị phân Rust và liên kết đến một thư viện C. Đây chính xác là những gì có thể được thực hiện bằng crate cc. Tác giả đã thiết lập một tệp build.rs, liệt kê các tệp C cần biên dịch và sử dụng cc::Build::new().compile(“foo”) để biên dịch.

Trong quá trình dịch mã, tác giả đã đưa vào nhiều lỗi (bug). Anh ấy chia sẻ quá trình tìm và sửa một số lỗi trong số đó. Ví dụ: một hàm đơn giản sau khi dịch đã khiến chương trình bị sập. Thông qua gỡ lỗi, tác giả phát hiện ra vấn đề là do mã C sử dụng khai báo ngầm định, dẫn đến kiểu trả về không chính xác, do đó gây ra lỗi phân đoạn (segmentation fault). Bằng cách thêm khai báo hàm chính xác, vấn đề đã được giải quyết.

HN | Độ nóng: 546 điểm | 191 bình luận | Tác giả: Jtsummers #

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

tmux-rs là một trình quản lý phiên tmux dựa trên Rust, tác giả coi nó như một dự án sở thích, tương tự như làm vườn, nhưng có nhiều lỗi phân đoạn hơn.
Một số người bình luận cho rằng, không nhất thiết phải có lý do để xây dựng một cái gì đó mới, dự án sở thích có thể mang lại những kết quả bất ngờ.
Có người đề cập rằng, không phải dự án nào cũng cần phải thay đổi thế giới, việc viết lại fzf sang ngôn ngữ Rust cũng xuất phát từ sự hứng thú học hỏi các thuật toán tìm kiếm mờ và các kênh Rust.
Có ý kiến cho rằng, Rust có thể làm cho một số công cụ như fzf trở nên tốt hơn, vì fzy được viết lại bằng ngôn ngữ C tuy nhanh, nhưng kết quả không hữu ích khi tìm kiếm lịch sử bash.
Trong phần bình luận có đề cập, mọi người làm nhiều việc vì niềm vui, đó là cách chúng ta học hỏi và khám phá thế giới.
Một người bình luận đã trích dẫn lời của Knuth, cho rằng việc để các nhà khoa học máy tính tự do làm những gì họ muốn là cách thúc đẩy sự tiến bộ của lĩnh vực này.
Có người cho rằng, việc suy nghĩ quá nhiều về các dự án cá nhân và ngôn ngữ sử dụng đã cản trở sự phát triển của họ với tư cách là một kỹ sư phần mềm mới vào nghề.
Trong phần bình luận có đề cập, việc làm những điều “chỉ vì” có thể giúp bạn học được một số kỹ năng hoặc thông tin quan trọng.
Có người cho rằng, hỏi “tại sao” có thể là một câu hỏi hợp lý, và “vì niềm vui” cũng có thể là một câu trả lời hợp lý.
Có ý kiến cho rằng, các hình thức giải trí khác nhau có giá trị khác nhau đối với người khác.
Trong phần bình luận có đề cập, không nhất thiết cần một lý do để viết lại phần mềm bằng một ngôn ngữ khác, ví dụ như tmux.
Một người bình luận tò mò, tại sao tmux lại nhận được nhiều sự chú ý hơn screen, screen có thể chỉ là do đặt tên không hay.
Trong phần bình luận có đề cập, việc sử dụng unsafe trong Rust có thể là do một số thao tác mà C cho phép không thể biên dịch được trong Rust, chẳng hạn như các phép toán trên con trỏ và chuyển đổi kiểu.

Các trang web lưu trữ các báo cáo khí hậu lớn của Hoa Kỳ bị gỡ xuống #

Websites hosting major US climate reports taken down

https://apnews.com/article/climate-change-national-assessment-nasa-white-house-057cec699caef90832d8b10f21a6ffe8

Ngày 1 tháng 7 năm 2025, một báo cáo cho thấy trang web chính thức của Đánh giá Khí hậu Quốc gia Hoa Kỳ dường như đã bị đóng, gây khó khăn cho chính quyền tiểu bang và địa phương cũng như công chúng trong việc tiếp cận thông tin về biến đổi khí hậu. Các báo cáo đánh giá khí hậu này được thực hiện theo quy định của pháp luật, nhằm giúp các cấp chính quyền và công chúng hiểu được tác động của sự nóng lên toàn cầu và các biện pháp ứng phó. Các nhà khoa học chỉ ra rằng những báo cáo có thẩm quyền, được bình duyệt này có thể tiết kiệm tiền bạc và cứu sống con người.

Báo cáo đề cập rằng Nhà Trắng, đơn vị chịu trách nhiệm cho các đánh giá này, cho biết thông tin liên quan sẽ được lưu trữ tại NASA để tuân thủ luật pháp, nhưng không cung cấp thêm chi tiết. Mặc dù việc tìm kiếm trên trang web của NASA vẫn chưa tìm thấy các báo cáo đánh giá liên quan, nhưng NASA và Cơ quan Quản lý Khí quyển và Đại dương Quốc gia (NOAA) vẫn chưa đưa ra phản hồi.

Kathy Jacobs, một nhà khoa học khí hậu tại Đại học Arizona, bày tỏ lo ngại về điều này, cho rằng nếu Đánh giá Khí hậu Quốc gia không còn khả dụng, đây là một sự can thiệp nghiêm trọng vào thông tin khoa học và khả năng tiếp cận thông tin của công chúng, có thể làm tăng nguy cơ mọi người bị tổn hại do biến đổi khí hậu. John Holdren, cố vấn khoa học của cựu Tổng thống Obama và là nhà khoa học khí hậu tại Đại học Harvard, cũng chỉ ra rằng các đánh giá khí hậu rất hữu ích cho các quan chức ở mọi cấp, giúp họ đưa ra quyết định về xây dựng cơ sở hạ tầng.

Nhà khoa học khí hậu Katharine Hayhoe cho biết, các đánh giá quốc gia này hữu ích hơn các báo cáo khí hậu quốc tế do Liên Hợp Quốc công bố bảy năm một lần, vì chúng mang tính địa phương và chi tiết hơn. Các đánh giá quốc gia không chỉ được các nhà khoa học khác bình duyệt mà còn được Viện Hàn lâm Khoa học Quốc gia và các cơ quan liên bang kiểm tra tính chính xác. Jacobs nhấn mạnh rằng việc che giấu các báo cáo này là kiểm duyệt khoa học, và điều này gây nguy hiểm cho đất nước.

Ngoài ra, báo cáo cũng đề cập rằng chính quyền Trump đã thông báo cho các tác giả tình nguyện của đánh giá khí hậu vào mùa xuân rằng họ không còn cần dịch vụ của họ nữa và đã chấm dứt hợp đồng với một công ty tư nhân chịu trách nhiệm điều phối trang web và báo cáo. Trang web khí hậu chính của NOAA gần đây cũng đã chuyển sang một trang web khác, nội dung trên mạng xã hội và blog đã bị cắt giảm hoặc xóa.

Tóm lại, sự kiện này được giới khoa học coi là một sự phá hoại nghiêm trọng đối với cơ sở hạ tầng khoa học, và các nhà khoa học kêu gọi công chúng chú ý đến vấn đề này để đảm bảo có thể ứng phó một cách an toàn với những thách thức do biến đổi khí hậu gây ra.

HN | Độ nóng: 529 điểm | 353 bình luận | Tác giả: geox #

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

Chính phủ này có rất nhiều dấu hiệu đáng báo động về việc đàn áp ngôn luận, cắt giảm tài trợ nghiên cứu, cắt giảm các dự án xã hội, tăng cường mức độ và cường độ trục xuất, trục xuất người vì quan hệ chính trị, các chính sách kinh tế gây tổn hại không cần thiết, cũng như sự bất tài, dối trá và tham nhũng phổ biến.
Phần thưởng của chính quyền Trump là một nước Mỹ trắng hơn và phụ nữ trở lại bếp, mục tiêu rõ ràng.
Hoa Kỳ có hàng hóa trại tập trung chính thức, phần thưởng là tái thiết nạn diệt chủng và chế độ nô lệ.
Chính quyền Trump công khai về nạn diệt chủng và chế độ nô lệ, Bộ Ngoại giao Hoa Kỳ hiện có một “Văn phòng tái định cư”.
Chính sách diệt chủng và nô lệ của chính quyền Trump là phóng đại, không có dấu hiệu nào cho thấy họ đang thực hiện hoặc lên kế hoạch diệt chủng hoặc nô lệ.
Nạn diệt chủng và chế độ nô lệ có định nghĩa rõ ràng, không nên làm loãng vì những lời buộc tội mang tính cảm xúc.
Chính sách trục xuất của chính quyền Trump là trục xuất, không phải bán nô lệ hàng loạt.
Nạn diệt chủng có thể được thực hiện bí mật dưới vỏ bọc của các chính sách hợp pháp, nếu hiện tại có nạn diệt chủng, có thể hầu hết mọi người không biết, thậm chí có thể ẩn giấu ngay trước mắt.
Cần hiểu các khái niệm về diệt chủng và thanh lọc sắc tộc, sau đó có thể chọn thông tin từ nhiều phương tiện truyền thông khác nhau.
Thanh lọc sắc tộc đối với tôi nghe giống như Rwanda hoặc Nam Tư, điều này chưa xảy ra ở Hoa Kỳ.
Một số người có thể muốn dành “diệt chủng” cho những trường hợp tồi tệ nhất, trong khi những người khác muốn sử dụng một thuật ngữ rộng hơn bao gồm cả diệt chủng.
Một số người cũng đang cố gắng thúc đẩy việc sử dụng thuật ngữ “diệt chủng văn hóa”, được sử dụng cho những trường hợp không liên quan đến giết người hàng loạt.
Theo các vụ trục xuất hiện tại (mà tôi phản đối) thì không phải là diệt chủng cũng không phải là thanh lọc sắc tộc. Hoa Kỳ không cố gắng loại bỏ dân số Latinh của đất nước dựa trên chủng tộc, mặc dù việc trục xuất người nhập cư bất hợp pháp rất thô bạo, nhưng còn lâu mới đạt đến mức độ diệt chủng hoặc thanh lọc sắc tộc được định nghĩa hợp lý.

Các trình ghi chú AI đang tràn ngập các cuộc gọi Zoom khi nhân viên chọn bỏ họp #

AI note takers are flooding Zoom calls as workers opt to skip meetings

https://www.washingtonpost.com/technology/2025/07/02/ai-note-takers-meetings-bots/

Bài viết này thảo luận về hiện tượng trí tuệ nhân tạo (AI) thay thế người ghi chép là con người trong các cuộc họp. Bài viết bắt đầu bằng việc đề cập đến một người tên là Clifton Sellers, người đã tham gia một cuộc họp Zoom vào tháng trước, trong đó số lượng robot nhiều hơn con người. Ông nhớ lại rằng, bao gồm cả ông, có sáu người trong cuộc họp, trong khi mười người tham gia khác là các ứng dụng ghi chú do AI điều khiển, chúng được sử dụng để ghi lại, phiên âm và tóm tắt nội dung cuộc họp. Một số trợ lý AI hỗ trợ những người thực sự có mặt, trong khi những người khác đại diện cho những người không xuất hiện nhưng đã gửi một robot chỉ có thể nghe mà không thể nói. Sự mất cân bằng giữa con người và máy móc này khiến Sellers lo lắng rằng mong muốn hiện đại về tối ưu hóa do AI điều khiển có thể bắt đầu cản trở sự tương tác giữa con người với nhau.

Bài viết cũng đề cập đến những quan điểm khác nhau của độc giả về trình ghi chú AI trong các cuộc họp. Một số người dùng bày tỏ lo ngại về quyền riêng tư, lo lắng rằng AI có thể làm giảm sự tương tác giữa con người với nhau và nếu chỉ có AI tham gia cuộc họp, cuộc họp có thể trở nên vô nghĩa. Trong khi những người khác lại cho rằng trình ghi chú AI rất hữu ích. Những bình luận này phản ánh sự nghi ngờ và đánh giá cao của mọi người đối với trình ghi chú AI.

HN | Độ nóng: 294 điểm | 360 bình luận | Tác giả: tysone #

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

Mật độ thông tin trong cuộc họp thấp là do mọi người lười lên kế hoạch trước cho chương trình nghị sự và phân công bài tập trước cuộc họp, dẫn đến việc cuộc họp không thể tập trung vào việc giải quyết vấn đề và tạo ra giá trị.
Mục đích thực sự của cuộc họp nằm ở việc quản lý các mối quan hệ, chứ không phải bản thân chủ đề cuộc họp, do đó những người tập trung vào công việc thực tế ghét các cuộc họp, trong khi những người định hướng nghề nghiệp lại thích chúng.
Một số người sắp xếp các cuộc họp và cuộc gọi điện thoại vì công việc của họ nhàm chán và muốn tìm người trò chuyện.
Amazon cấm bài tập trước cuộc họp, yêu cầu mọi người đọc tài liệu trước khi cuộc họp bắt đầu, để mọi người đều ở cùng một vạch xuất phát khi thảo luận.
Vai trò của những người đóng góp cá nhân cấp cao thật đáng buồn, vì họ cần đồng thời đảm nhiệm vai trò của người quản lý sản phẩm, người quản lý dự án và người quản lý nhân sự, trong khi các vai trò tập trung lại làm việc trong một lĩnh vực tự giới hạn.
Các cuộc họp định kỳ đứng (stand-up meeting) về cơ bản là vô dụng, nếu cuộc họp không đủ quan trọng để chuẩn bị tài liệu hoặc chương trình nghị sự, thì nên hủy bỏ.
Để cuộc họp hiệu quả, người tham gia cần hiểu bối cảnh, việc “làm bài tập về nhà” trước cuộc họp có thể đảm bảo rằng mọi người không lãng phí thời gian trong cuộc họp để chờ ai đó đọc báo cáo lần đầu tiên hoặc tìm hiểu những gì người khác đã biết.
Phương pháp đọc im lặng của Amazon cho phép mọi người để lại nhận xét trong các khu vực cần thảo luận, để cuộc họp có thể chỉ tập trung vào những điểm này.
Đôi khi mục đích của cuộc họp là để một phó chủ tịch bận rộn lắng nghe một đề xuất và nói “có”, trong trường hợp này không thể hủy cuộc họp vì ai đó chưa chuẩn bị.

Các nhà thiên văn học khám phá 3I/ATLAS – Vật thể giữa các vì sao thứ ba ghé thăm Hệ Mặt Trời #

Astronomers discover 3I/ATLAS – Third interstellar object to visit Solar System

https://www.abc.net.au/news/science/2025-07-03/3i-atlas-a11pl3z-interstellar-object-in-our-solar-system/105489180

Các nhà thiên văn học đã phát hiện ra vật thể liên sao thứ ba đến từ bên ngoài hệ Mặt Trời của chúng ta. Vật thể này, được đặt tên là 3I/ATLAS, rất có thể là một sao chổi và nó di chuyển nhanh hơn bất kỳ vật thể liên sao nào được phát hiện trước đây. 3I/ATLAS đang bay về phía Mặt Trời của chúng ta với tốc độ khoảng 60 km mỗi giây. Theo Jonti Horner, một nhà thiên văn học tại Đại học Southern Queensland, không có gì trong hệ Mặt Trời có thể gây ra việc một vật thể tiếp cận với tốc độ đáng kinh ngạc như vậy. Trong số ba vật thể liên sao mà chúng ta đã quan sát được, đây là vật thể nhanh nhất cho đến nay.

Trước đây, chỉ có hai vật thể liên sao được theo dõi khi đi vào hệ Mặt Trời của chúng ta - ‘Oumuamua và sao chổi 2I/Borisov. Phát hiện này vô cùng thú vị. Khi vật thể này được phát hiện lần đầu tiên vào đầu tuần này, cộng đồng thiên văn học đã bắt đầu thảo luận về vật thể liên sao tiềm năng này. Do được phát hiện tương đối sớm, chúng ta có ít nhất tám tháng để quan sát nó. Vật thể này ban đầu được phát hiện bởi kính viễn vọng ATLAS ở Chile vào ngày 1 tháng 7. Các quan sát tiếp theo đã xác nhận quỹ đạo của nó rất bất thường, hầu như không bị ảnh hưởng bởi lực hấp dẫn của Mặt Trời. Mãi đến ngày hôm qua, các nhà khoa học tại Trung tâm Tiểu hành tinh của Hoa Kỳ mới xác nhận rằng vật thể này là một vật thể liên sao và suy đoán rằng nó có thể là một sao chổi dựa trên hình ảnh cho thấy nó có một cái đuôi ngắn. Cần có thêm các quan sát để xác nhận điều này và thu thập thêm chi tiết về vật thể này.

Ước tính hiện tại là 3I/ATLAS sẽ đến gần Mặt Trời nhất vào cuối tháng 10, sau đó quay trở lại vùng bên ngoài hệ Mặt Trời bên ngoài Sao Mộc trước tháng 3 năm sau. Thật không may, khi 3I/ATLAS đến gần Mặt Trời nhất và sáng nhất, Trái Đất sẽ ở phía bên kia của hệ Mặt Trời, điều này khiến chúng ta khó nhìn thấy nó hơn. Nếu chúng ta ở trên Sao Hỏa, chúng ta sẽ có thể nhìn thấy nó khá tốt. Nó sẽ không đến quá gần Sao Hỏa, nhưng nó sẽ gần Sao Hỏa hơn Trái Đất. Do 3I/ATLAS có thể hiện đang trải qua một đợt bùng nổ - sự tăng độ sáng đột ngột do bụi và khí thải ra từ vật thể - nên rất khó theo dõi kích thước của nó. Oumuamua có hình dạng “xì gà”, khiến nó ít sáng hơn. Oumuamua là một vật thể khá nhỏ, các ước tính về kích thước của 2I/Borisov dao động từ khoảng 1 km đến hơn 16 km. Giáo sư Jonti Horner cho biết vật thể này có thể lớn hơn một chút, có thể rộng từ vài trăm mét đến một km, hoặc thậm chí có thể lớn hơn, điều này là lớn, nhưng không đặc biệt.

Với những hình ảnh đầu tiên từ Đài quan sát Vera C. Rubin được công bố vào tuần trước, chúng ta có thể phát hiện ra nhiều vật thể liên sao hơn. Cho đến nay, các vật thể liên sao rất hiếm, nhưng với các kính viễn vọng tốt hơn như Đài quan sát Rubin, chúng ta có thể bắt được nhiều vật thể hơn khi chúng đến. Chúng ta đã phát hiện ra ba vật thể liên sao trong vòng chưa đầy một thập kỷ bằng công nghệ hiện có. Đài quan sát Rubin có thể có khả năng tìm kiếm vật thể cao hơn một bậc… điều này cho thấy chúng ta có thể phát hiện ra một vài vật thể như vậy mỗi năm. Trong 10 giờ hoạt động đầu tiên, đài quan sát đã phát hiện ra hơn 2000 tiểu hành tinh chưa từng được biết đến trước đây. Điều này giống như một cái nhìn trộm vào tương lai.

HN | Độ nóng: 276 điểm | 145 bình luận | Tác giả: gammarator #

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

3I/ATLAS là vật thể liên sao thứ ba ghé thăm hệ mặt trời, với độ lệch tâm quỹ đạo lớn hơn 6, cao hơn nhiều so với 1I và 2I với 1.2 và 3.3.
3I/ATLAS hiện tại chỉ là một điểm trên bầu trời, khó xác định liệu nó có hoạt động hay không. Nếu nó không hoạt động (như một tiểu hành tinh), thì đường kính của nó có thể từ 8-22 km.
Nếu 3I/ATLAS hoạt động, thì nó có thể trông lớn hơn do bụi thoát ra.
3I/ATLAS sẽ không đến gần bất kỳ hành tinh nào một cách đặc biệt, nó sẽ đến gần mặt trời nhất ở khoảng cách 1.35 AU vào trước lễ Halloween, di chuyển với tốc độ 68 km/giây.
Quỹ đạo của 3I/ATLAS là nghịch hành, điều này là ngẫu nhiên đối với các vật thể liên sao.
Vài tuần tới sẽ rất thú vị đối với các nhà nghiên cứu.
Ngày tiếp cận gần nhất của 3I/ATLAS là ngày 29 tháng 10 năm 2025, hiện đang đi qua quỹ đạo của Sao Mộc.
Sự rộng lớn của không gian là không thể tưởng tượng được, nhỏ bé so với bất kỳ điểm tham chiếu nào trên Trái Đất.
Sự rộng lớn của đại dương có thể được sử dụng để so sánh và hiểu sự rộng lớn của không gian, nhưng vẫn không thể thực sự hiểu được.
Một trong những mô tả hay nhất về hệ mặt trời là “Nếu Mặt Trăng chỉ là 1 pixel” của Josh Worth.
Kích thước và khoảng cách của hệ mặt trời có thể được hiểu rõ hơn bằng cách du hành với tốc độ ánh sáng.
Du hành không gian có thể giống như chiến tranh, những khoảng thời gian nhàm chán kéo dài bị gián đoạn bởi những khoảnh khắc kinh hoàng tột độ.
Quỹ đạo hành tinh là một phương pháp thu nhỏ tỷ lệ quỹ đạo của các hành tinh và đặt chúng vào cảnh quan.
Mô hình hệ mặt trời có thể được so sánh bằng tỷ lệ của một sân bóng đá kiểu Mỹ, với Mặt Trời là lớn nhất và các hành tinh bên trong có kích thước bằng hạt cát.
Câu chuyện ngắn của Primo Levi mô tả sự không đầy đủ của ngôn ngữ và phép đo của chúng ta khi mô tả vũ trụ.
Đường chân trời trên bãi biển chỉ cách khoảng 5 km hoặc 3 dặm.
Cuộc sống không thể có cảm giác về tỷ lệ khi sống trong một vũ trụ rộng lớn như vậy.
“Hoạt động” của 3I/ATLAS đề cập đến việc nó có sao chổi hay không.
Độ lệch tâm của 3I/ATLAS đề cập đến hình dạng quỹ đạo của nó.
Hiện tại không có đủ dữ liệu để xác định hình dạng của 3I/ATLAS.
Nếu một vật thể có kích thước như vậy va vào Sao Hỏa với tốc độ 90 km/giây, hậu quả sẽ là thảm khốc.

Công cụ: Code Là Tất Cả Những Gì Bạn Cần #

Tools: Code Is All You Need

https://lucumr.pocoo.org/2025/7/3/tools/

Armin Ronacher đã chia sẻ những quan điểm và suy nghĩ của mình về MCP (Model Context Protocol) trên blog của anh. Đầu tiên, anh khẳng định rằng mặc dù anh không phản đối ý tưởng của MCP, nhưng anh cho rằng MCP có hai vấn đề chính trong ứng dụng thực tế: nó không thực sự có thể kết hợp được, hầu hết các kết hợp đều được thực hiện thông qua suy luận; nó yêu cầu quá nhiều thông tin ngữ cảnh, mỗi lần gọi công cụ đều tiêu tốn nhiều ngữ cảnh hơn so với việc viết và chạy mã trực tiếp.

Anh minh họa điều này bằng một thí nghiệm: thử sử dụng MCP của GitHub và công cụ gh CLI để hoàn thành một tác vụ GitHub, bạn sẽ thấy rằng công cụ gh CLI hiệu quả hơn trong việc sử dụng ngữ cảnh và có thể đạt được kết quả mong muốn nhanh hơn.

Mặc dù có người cho rằng MCP có thể là hướng phát triển trong tương lai, Armin Ronacher cho rằng, theo phân tích dữ liệu hiện tại của anh, MCP hiện tại luôn khó sử dụng hơn so với việc viết mã, chủ yếu là do nó dựa vào suy luận. Anh đề cập rằng, phương pháp thúc đẩy số lượng công cụ tăng lên hiện nay bao gồm một lớp lọc, tức là chuyển tất cả các công cụ cho LLM (Large Language Model - Mô hình ngôn ngữ lớn) và yêu cầu nó lọc theo nhiệm vụ trong tay.

Anh cho rằng, ngay cả trong các nhiệm vụ phi lập trình, theo miền cụ thể, việc tạo mã cũng là một lựa chọn tốt hơn, vì nó có thể kết hợp tốt hơn. Anh lấy ví dụ “thay thế bản thân bằng shell script” để minh họa rằng nhiều tác vụ thủ công thực sự có thể được tự động hóa bằng phần mềm, thách thức là tìm người sẵn sàng viết phần mềm. Nếu bạn làm việc trong một môi trường ngách và bản thân bạn không phải là lập trình viên, bạn có thể không cầm một cuốn sách lập trình lên để học cách viết code, hoặc có thể không tìm được một nhà phát triển sẵn sàng cung cấp cho bạn một phần mềm tùy chỉnh để giải quyết vấn đề cụ thể của bạn.

Armin Ronacher cũng thảo luận về vấn đề quy mô của tự động hóa, nhấn mạnh rằng chìa khóa của tự động hóa là tự động hóa những việc sẽ xảy ra lặp đi lặp lại. Bạn sẽ không tự động hóa một thay đổi một lần sẽ không bao giờ xảy ra nữa. Bạn sẽ bắt đầu tự động hóa những thứ mà máy móc thực sự có thể mang lại cho bạn sự gia tăng năng suất, bởi vì bạn có thể làm một hoặc hai lần, tìm ra cách làm cho nó hoạt động, sau đó để máy móc lặp lại nó một nghìn lần.

Anh lấy ví dụ về blog của mình, gần đây anh đã chuyển đổi toàn bộ blog từ reStructuredText sang Markdown. Anh đã để LLM thực hiện chuyển đổi này thông qua code, thay vì chuyển đổi trực tiếp. Anh yêu cầu LLM phân tích reStructuredText thành AST (Abstract Syntax Tree - Cây cú pháp trừu tượng), sau đó chuyển đổi nó thành Markdown AST, và cuối cùng hiển thị thành HTML. Bằng cách này, anh có một bước chuyển đổi trung gian và một kết quả cuối cùng có thể so sánh được. Sau đó, anh yêu cầu LLM viết một script để so sánh HTML cũ và HTML mới, và thực hiện so sánh sự khác biệt sau một số dọn dẹp cơ bản. Anh yêu cầu LLM xem xét những lỗi chuyển đổi nào có thể chấp nhận được và bù đắp cho điều đó trong script. Cuối cùng, anh yêu cầu LLM tạo một script thứ ba để anh có thể chạy trên đầu ra của hàng trăm tệp, phân tích sự khác biệt, sau đó quay lại vòng lặp đại lý để thực hiện một lần lặp khác.

Thông qua quá trình này, Armin Ronacher cuối cùng đã tin tưởng vào quá trình chuyển đổi này, vì anh có thể xem xét phương pháp. Anh cũng đã thử để một LLM khác đánh giá code và các thay đổi do một LLM khác viết, điều này mang lại cho anh sự tự tin cao hơn, khiến anh tin rằng quá trình đang diễn ra sẽ không làm mất dữ liệu. Anh cho rằng đây là một quy trình cơ học về cơ bản là đúng, anh có thể quan sát và kiểm tra ngẫu nhiên. Tình huống xấu nhất là, hồi quy là những lỗi cú pháp Markdown nhỏ, nhưng bản thân văn bản sẽ không bị phá hủy. Anh cũng chỉ ra rằng, do suy luận tương đối hằng định, chi phí suy luận trong quá trình này tăng lên khi các bước lặp và kích thước mẫu tăng lên, nhưng không phụ thuộc vào tổng số tài liệu anh muốn chuyển đổi. Cuối cùng, anh đã để LLM luôn chạy trên tất cả các tài liệu, nhưng nỗ lực để chạy 15 tài liệu cũng gần giống như 150 tài liệu, vì bước phân tích dựa trên LLM cuối cùng không còn nhiều thứ cần xem xét nữa (nó đã bỏ qua tất cả các khác biệt nhỏ trong tệp).

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

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

Ứng dụng thực tế của mô hình ngôn ngữ lớn (LLM) chủ yếu là lấp đầy khoảng trống giữa hai giao diện cố định, độ tin cậy của nó đến từ chính giao diện chứ không phải từ suy luận và tạo của mô hình.
Giá trị của LLM phụ thuộc vào khả năng mô hình hóa dữ liệu, logic và các hành động trong lĩnh vực của code và công cụ hiện có.
LLM có thể được so sánh với máy in 3D, hoạt động tốt trong việc kết nối nhanh các bộ phận, nhưng cần các giải pháp bền bỉ và chắc chắn hơn về độ tin cậy và khả năng mở rộng.
Chu kỳ cường điệu của máy bay không người lái và thực tế ảo (VR) tương tự như LLM, phạm vi ứng dụng thực tế hẹp hơn.
Có người chỉ ra rằng AR (thực tế tăng cường) chứ không phải VR là xu hướng phát triển công nghệ trong tương lai.
Có người cho rằng điện thoại thông minh có thể là hình thức tương tác cuối cùng của con người với dữ liệu, chúng ta có thể không làm tốt hơn được nữa.
Tương tác giữa người với người quan trọng hơn tương tác giữa người với dữ liệu, đây có thể là lý do VR khó vượt qua điện thoại thông minh.
Máy bay không người lái rất phổ biến trong các cuộc xung đột hiện đại, sự cường điệu của chúng không phải là sai sự thật.
Ứng dụng thực tế của máy bay không người lái và VR có thể chưa đạt đến đỉnh điểm.
Có người cho rằng, nếu chi phí cơ hội bằng không, thì “quá sớm” là một biến thể của sai lầm.
Việc giao hàng bằng máy bay không người lái và việc mọi người dành nhiều thời gian trong VR thực sự đang diễn ra, nhưng quy mô nhỏ hơn nhiều so với sự cường điệu.
Việc áp dụng các dịch vụ LLM không yêu cầu đầu tư phần cứng trả trước, đây có thể là lý do khiến nhiều công ty nhanh chóng tham gia.
Tồn tại một quan điểm cho rằng việc áp dụng LLM trên quy mô lớn có thể biến thành một vấn đề trách nhiệm pháp lý lớn.
Có người cho rằng, LLM có thể cần tìm một “ứng dụng sát thủ” trước khi chi phí bảo trì của nó trở nên quá cao.
Có người nghi ngờ liệu LLM có đang ở trong một bong bóng rõ ràng giống như blockchain hay không.
Có người cho rằng, ứng dụng thực tế của LLM có thể phù hợp với sự cường điệu và được cường điệu hóa quá mức như điều quan trọng nhất kể từ thời Gutenberg.
Có người chỉ ra rằng, nếu quy mô ứng dụng của LLM không đạt được như mong đợi, thì nó thực sự đã không xảy ra.

Couchers chính thức ra mắt phiên bản beta #

Couchers is officially out of beta

https://couchers.org/blog/2025/07/01/releasing-couchers-v1

Trang web Couchers.org thông báo chính thức kết thúc giai đoạn thử nghiệm Beta, ra mắt phiên bản 1.0. Sau năm năm xây dựng và phát triển, bao gồm giai đoạn Alpha và giai đoạn Beta kéo dài, nền tảng và cộng đồng cuối cùng đã sẵn sàng để quảng bá trên quy mô lớn. Lần phát hành này đánh dấu một định hướng chiến lược mới, một trang đích được thiết kế lại và một loạt các tính năng mới được giới thiệu, nhằm nâng cao các chức năng cốt lõi của Couchsurfing.

Trọng tâm của chiến lược mới là cam kết trở thành cộng đồng Couchsurfing an toàn, lành mạnh và năng động nhất. Điều này đã phát triển so với kế hoạch ban đầu, làm rõ hơn lập trường của Couchers, không còn phụ thuộc vào cái bóng của các nền tảng khác. Ngoài ra, trang đích mới được ra mắt nhằm mục đích truyền đạt rõ ràng hơn các giá trị và đặc điểm của Couchers, đồng thời giải thích ý nghĩa của cộng đồng cho những người mới và những người đã từng Couchsurfing.

Việc phát hành phiên bản 1.0 có nghĩa là các chức năng cốt lõi của nền tảng đã được dọn dẹp và sẵn sàng để mọi người sử dụng. Phiên bản 0.9.9 vài tháng trước cũng đã thực hiện rất nhiều công việc dọn dẹp. Sau lần phát hành này, Couchers sẽ tập trung vào việc mở rộng nền tảng và phát triển các tính năng mới để giúp người dùng kết nối tốt hơn với các thành viên khác.

Các tính năng mới bao gồm:

Trang đích được thiết kế lại: Trang mới truyền đạt rõ ràng Couchers là gì, đại diện cho điều gì và có thể tìm thấy gì sau khi đăng ký. Điều này giúp thu hút nhiều thành viên phù hợp hơn.
Cải thiện chức năng tham khảo: Người dùng giờ đây có thể cho biết liệu họ có sống cùng hoặc tiếp đón ai đó hay không (chúng tôi sẽ không nhắc bạn để lại tham khảo) và có thể gửi phản hồi riêng cho nhóm an toàn thông qua quy trình tham khảo (không hiển thị trên tham khảo công khai). Điều này giúp nhóm an toàn hiểu rõ hơn về tình hình và giữ cho nền tảng an toàn.
Tìm thành viên nhanh hơn: Trang tìm kiếm bản đồ được thiết kế lại, Nicole đã dành nhiều tháng để xây dựng lại và Aapeli đã giúp xây dựng một số chức năng backend mới, giúp tăng tốc đáng kể tốc độ tìm kiếm.
Thông báo đẩy mới: Giới thiệu thông báo đẩy, bao gồm cả trên máy tính và thiết bị di động, cũng như thêm nhiều loại thông báo mới cho các phản hồi lồng nhau trong các cuộc thảo luận và các yêu cầu tiếp đón đang chờ xử lý, v.v.
Bộ chọn ngôn ngữ và bản dịch: Đã triển khai bộ chọn ngôn ngữ và đang tích cực dịch nền tảng sang các ngôn ngữ khác ngoài tiếng Anh.
Chức năng an toàn và kiểm duyệt: Đã ra mắt các chức năng mới để tăng cường tính bảo mật của nền tảng, bao gồm xóa bạn bè, chặn (và bỏ chặn) người dùng, thêm cờ báo cáo vào thẻ sự kiện, v.v.
Lộ trình công khai: Để giao tiếp tốt hơn về các tính năng và cải tiến đang được phát triển, Chris đã lãnh đạo một nhóm để tạo và duy trì lộ trình công khai, đây là một nguồn tài nguyên tuyệt vời để tìm hiểu những gì chúng tôi đang làm và mong đợi điều gì.
Hệ thống thăm dò hoạt động: Nếu người dùng được đặt ở trạng thái tiếp đón nhưng đã lâu không đăng nhập, hệ thống sẽ thỉnh thoảng gửi thông báo hỏi xem họ có còn quan tâm đến việc tiếp đón hay không. Điều này giúp giảm số lượng yêu cầu được chuẩn bị kỹ lưỡng mà người đi du lịch gửi đến những người chủ nhà không bao giờ đọc thông báo.

HN | Độ nóng: 240 điểm | 117 bình luận | Tác giả: laurentlb #

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

Có người đã ngừng tiếp đón khách Couchsurfing vì không thích việc người khác bình luận về thiết kế khăn tắm nhà mình.
Có người cho rằng Couchsurfing đã trở nên thương mại hóa vào năm 2020, không còn miễn phí nữa, do đó mất đi sự hấp dẫn.
Có người cho rằng Couchsurfing đã biến thành một cộng đồng với mục đích hẹn hò, thu hút những nhóm người khác nhau.
Người đồng sáng lập Couchers cho biết mục tiêu của họ là khôi phục những mặt tốt nhất của Couchsurfing và phát triển nó hơn nữa.
Có người cho rằng, đối với những cộng đồng như Couchsurfing, nên có sự kiểm duyệt tốt hơn trước khi đăng tải các bình luận.
Có người cho rằng, việc vừa tiếp đón khách Couchsurfing vừa phải đảm nhận trách nhiệm của người điều hành diễn đàn khiến nhiều người e ngại.
Có người cho rằng, các nền tảng như Airbnb cũng nên có cơ chế kiểm duyệt bình luận tương tự.
Có người chia sẻ về những vị khách kỳ lạ và những đánh giá tiêu cực không hợp lý mà họ gặp phải khi là chủ nhà Airbnb.
Có người cho rằng, một số đánh giá tiêu cực xuất phát từ những lý do cá nhân kỳ lạ, chứ không phải vấn đề của sản phẩm hoặc dịch vụ.
Có người cho rằng, việc đưa ra đánh giá tiêu cực là không phù hợp đối với các dịch vụ phi lợi nhuận như Couchsurfing.
Có người cho rằng, việc đưa ra đánh giá tiêu cực là có thể chấp nhận được đối với các dịch vụ thương mại như Airbnb.
Có người đã đưa ra một kế hoạch gian lận về Airbnb, nhưng bị chỉ ra là thực tế không khả thi.

Nên xây dựng cái gì thay vì AI agents #

What to build instead of AI agents

https://decodingml.substack.com/p/stop-building-ai-agents

Tác giả đặt ra một câu hỏi, đó là “Học máy là gì?” và giới thiệu ngắn gọn về tầm quan trọng của học máy. Tác giả nhấn mạnh rằng, mặc dù học máy có ứng dụng trong nhiều lĩnh vực, nhưng nhiều người vẫn chưa biết nhiều về các nguyên tắc và khái niệm đằng sau nó.

Tác giả giải thích định nghĩa cơ bản của học máy, đó là học máy là một kỹ thuật cho phép máy tính học hỏi từ dữ liệu và đưa ra quyết định. Nó liên quan đến các thuật toán và mô hình thống kê, những thuật toán và mô hình này có thể học hỏi từ dữ liệu và đưa ra dự đoán hoặc quyết định mà không cần lập trình rõ ràng.

Bài viết trình bày chi tiết ba loại học máy chính: học có giám sát, học không giám sát và học tăng cường. Mỗi loại đều có các tình huống ứng dụng và ưu nhược điểm cụ thể.

Học có giám sát: Học có giám sát liên quan đến việc sử dụng dữ liệu huấn luyện được gắn nhãn để huấn luyện mô hình, để mô hình có thể dự đoán đầu ra. Ví dụ: dự đoán giá nhà trong tương lai bằng cách phân tích dữ liệu giá nhà trong quá khứ.
Học không giám sát: Học không giám sát được sử dụng để khám phá các mẫu và cấu trúc trong dữ liệu mà không cần bất kỳ dữ liệu được gắn nhãn nào. Ví dụ: thuật toán phân cụm có thể được sử dụng để chia khách hàng thành các nhóm khác nhau.
Học tăng cường: Học tăng cường là một phương pháp học tập chiến lược, huấn luyện mô hình thông qua phần thưởng và hình phạt, cho phép mô hình đưa ra các quyết định tối ưu. Phương pháp học tập này đặc biệt hữu ích trong lĩnh vực trò chơi và robot.

Tác giả liệt kê các ứng dụng của học máy trong các ngành khác nhau, bao gồm chăm sóc sức khỏe, tài chính, bán lẻ và xe tự lái, v.v. Mỗi ứng dụng đều cho thấy học máy có thể giúp giải quyết các vấn đề phức tạp và nâng cao hiệu quả như thế nào.

Bài viết thảo luận về một số thách thức mà học máy phải đối mặt, chẳng hạn như quyền riêng tư dữ liệu, sự thiên vị và khả năng giải thích. Tác giả nhấn mạnh rằng, mặc dù công nghệ học máy không ngừng phát triển, nhưng những vấn đề này cần được giải quyết thông qua hợp tác liên ngành và đổi mới công nghệ.

Cuối cùng, tác giả tóm tắt tầm quan trọng của học máy và khuyến khích độc giả khám phá thêm lĩnh vực này. Tác giả tin rằng, với sự phát triển không ngừng của công nghệ, học máy sẽ đóng một vai trò quan trọng trong nhiều lĩnh vực trong tương lai.

HN | Độ nóng: 223 điểm | 114 bình luận | Tác giả: giuliomagnifico #

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

Có một vấn đề nghiêm trọng về “kỹ thuật ngữ cảnh” khi xây dựng các agent, cần những ý tưởng mới để khắc phục.
Hướng dẫn agent thông qua bộ kiểm thử là một cơ chế tăng cường mạnh mẽ, hy vọng tư duy mới có thể mở rộng sang các “kỹ năng mềm” khác mà agent cần.
Dành nhiều thời gian để vật lộn với các công cụ hơn là làm việc thực tế.
Đôi khi nghịch ngợm với những công cụ này mà không quan tâm đến năng suất có thể thú vị.
Mọi thứ nên là về việc hoàn thành công việc và tạo ra giá trị.
Chơi đùa với các công cụ trong thời gian riêng của bạn là được, nhưng khi làm việc, bạn nên tập trung vào việc tạo ra giá trị.
Giá trị không phải lúc nào cũng xuất hiện ở một dạng cụ thể, việc theo đuổi năng suất quá mức có thể cản trở việc tạo ra những thứ thú vị và có ý nghĩa lâu dài.
Agent không phải là thú cưng mà là công cụ, nên có thể sử dụng như một công cụ.
Hiểu sâu hệ thống và xây dựng nó, đồng thời tin tưởng nó hoạt động như mong đợi là niềm vui.
Khi xây dựng tệp .md, tài liệu rõ ràng, ngắn gọn và có cấu trúc rõ ràng là đủ, không cần điều chỉnh nhiều.
Khi xây dựng tệp .md, cần xem xét liệu tệp đó có thể đọc được đối với các mô hình ngôn ngữ lớn (LLM) hay không.
Agent đọc tệp .md không đáng tin cậy, cần liên tục nhắc nhở.
Duy trì tài liệu thông qua agent có thể giảm số lần tìm kiếm, nhưng cần quản lý ngữ cảnh liên tục.
Quản lý ngữ cảnh là một thách thức, bao gồm việc tạo ngữ cảnh phù hợp cho các tác vụ song song và đệ quy, v.v.
Việc dựa vào agent để xây dựng ngữ cảnh của riêng nó sẽ “làm ô nhiễm” nó, cần phải liên tục giám sát.
Agent có thể làm tăng khối lượng công việc, nhưng chất lượng sẽ giảm, cần xem xét điều này.
Không có bữa trưa miễn phí, LLMs không thể thay thế hoàn toàn con người.
Gợi ý (prompt) có thể là một cấp độ trừu tượng mới, nhưng gợi ý ít nỗ lực có thể không tăng thêm nhiều giá trị.

Một Higgs-Bugson trong Nhân Linux #

A Higgs-Bugson in the Linux Kernel

https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/

Bài viết này được viết bởi Nikhil Jha, đăng ngày 2 tháng 7 năm 2025, với tiêu đề “A Higgs-bugson in the Linux Kernel”. Bài viết kể về trải nghiệm của tác giả trong việc gỡ lỗi một lỗi khó tái hiện trong nhân Linux (higgs-bugson), lỗi này xuất hiện trong một hệ thống quan trọng có tên Gord, hệ thống này chịu trách nhiệm lưu trữ và phân phối dữ liệu hoạt động giao dịch của công ty. Bài viết trình bày chi tiết kiến thức nền tảng về NFS (Network File System - Hệ thống tệp mạng) và Kerberos, đồng thời khám phá lỗi -EACCES (Quyền bị từ chối) thỉnh thoảng xảy ra khi hệ thống Gord thực hiện sao chép các tệp lớn.

Bài viết bắt đầu bằng việc giới thiệu giao thức NFS, cho phép truy cập vào các hệ thống tệp POSIX thông thường qua mạng. Cài đặt bảo mật mặc định của NFSv3 gần như là “không bảo mật” trên các mạng không tin cậy, máy chủ chỉ kiểm tra xem máy khách có kết nối từ số cổng “đặc quyền” (nhỏ hơn 1024) hay không. Nếu máy khách tuyên bố đại diện cho một người dùng cụ thể để kết nối, máy chủ sẽ tin tưởng máy khách. Tiếp theo, bài viết thảo luận về Kerberos như một tùy chọn bảo mật cho NFS, nó có khả năng mã hóa xác minh danh tính người dùng truy cập tệp.

Bài viết mô tả lỗi -EACCES thỉnh thoảng xảy ra khi hệ thống Gord thực hiện sao chép các tệp lớn, mặc dù các cài đặt quyền của hệ thống tệp là chính xác. Tác giả đã thử giải quyết vấn đề bằng cách tắt Kerberos trong môi trường phát triển, và phát hiện ra rằng sau khi tắt, thao tác sao chép không bao giờ thất bại, điều này gợi ý rằng vấn đề có thể liên quan đến thông tin xác thực Kerberos.

Tiếp theo, bài viết giải thích cách nhân Linux lấy thông tin xác thực Kerberos. Thông thường, các chương trình không gian người dùng sử dụng Kerberos sẽ tìm vị trí bộ nhớ cache thông tin xác thực Kerberos thông qua các biến môi trường hoặc tệp cấu hình. Tuy nhiên, các ứng dụng sử dụng NFS không cần liên kết libkrb5 hoặc biết bất kỳ thông tin nào về Kerberos, chúng chỉ thực hiện các lệnh gọi hệ thống I/O tệp bình thường như khi truy cập hệ thống tệp cục bộ. Nhân lấy thông tin xác thực thông qua một daemon không gian người dùng gốc có tên là rpc_gssd. Khi ứng dụng thực hiện lệnh gọi hệ thống I/O đầu tiên đến một tệp trên NFS, nhân sẽ ghi vào một tệp điểm gắn kết đặc biệt để giao tiếp với rpc_gssd.

Trong quá trình gỡ lỗi, tác giả đã xem nhật ký của rpc_gssd và phát hiện ra rằng nhân đã không yêu cầu thông tin xác thực trong một thời gian. Điều này dẫn đến một ngõ cụt. Để tái hiện lỗi này, tác giả đã thử chạy một thao tác ghi chậm vào cuối tuần, hy vọng bằng cách chạy trong một thời gian dài sẽ buộc khóa hết hạn, từ đó tái hiện lỗi. Tuy nhiên, mặc dù đã chạy thao tác này trên nhiều hộp, nhưng khi kiểm tra vào thứ Hai, không có lỗi nào được tìm thấy.

Sau đó, tác giả đã tạo ra một số tệp ngẫu nhiên lớn (khoảng 200GB), đặt chúng trên điểm gắn kết NFS thử nghiệm và bắt đầu sao chép chúng theo vòng lặp sang một điểm gắn kết NFS thử nghiệm khác trên nhiều hộp hơn. Các thao tác sao chép này cũng không thất bại. Để đảm bảo rằng không phải do may mắn mà không gặp vấn đề, tác giả quyết định tăng số lượng sao chép song song.

Để làm cho thử nghiệm nhẹ nhàng hơn, tác giả đã cân nhắc việc sao chép từ đĩa cục bộ sang NFS thay vì từ NFS sang NFS. Vì đã yêu cầu các hộp có đĩa nhỏ, tác giả quyết định tạo một hệ thống tệp hoàn toàn chứa các tệp ngẫu nhiên lớn trong bộ nhớ của máy thử nghiệm nhỏ. Tác giả đã sử dụng một crate Rust có tên fuser, đây là một triển khai được gõ kiểu của FUSE (Filesystem in USErspace). Khoảng 20 phút sau, tác giả đã tạo một hệ thống tệp giả “chứa” các tệp lớn.

Cuối cùng, bài viết thảo luận về cách chèn mã tùy ý vào thời gian chạy thông qua hệ thống con eBPF (extended Berkeley Packet Filter) của nhân Linux, cũng như sử dụng công cụ bpftrace để thu thập thông tin gỡ lỗi. Tác giả đã viết một tập lệnh bpftrace để theo dõi một vài hàm có vẻ thú vị và in dấu vết ngăn xếp nhân khi trả về EACCES. Bài viết kết thúc bằng việc đề cập đến thiết lập thử nghiệm, bao gồm các tác vụ chạy tiến trình rsync, tập lệnh bpftrace theo dõi trả về -EACCES và phương pháp chụp PCAP khi trả về -EACCES.

HN | Độ nóng: 204 điểm | 45 bình luận | Tác giả: Ne02ptzero #

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

Việc gọi một lỗi trong nhân Linux là “Higgs-Bugson” là không phù hợp, vì sự khó khăn trong việc phát hiện hạt Higgs nằm ở tiết diện sản xuất thấp, tín hiệu phân rã khó tách khỏi nền, thang năng lượng tồn tại không rõ ràng, và sự khó khăn và tốn kém trong việc xây dựng LHC.
Một lỗi xuất hiện trong môi trường production nhưng biến mất khi debug thường được gọi là Heisenbug.
NFS được ví như heroin, ban đầu có vẻ tuyệt vời, nhưng cuối cùng sẽ hủy hoại cuộc đời bạn.
Nhiều người chọn sử dụng NFS vì họ không hiểu rõ vấn đề cốt lõi của họ.
Truy cập tệp đồng thời qua mạng là một vấn đề nan giải, vì nó cố gắng giải quyết vấn đề ở một cấp độ rất kỳ lạ.
Google Docs giải quyết vấn đề ở đúng cấp độ.
Thông thường bạn sẽ mong đợi kernel là nơi cuối cùng xuất hiện lỗi, vì vậy điều này cho thấy NFS đã được thử nghiệm trong thực tế.
Nhiều đoạn code có lỗi, lỗi này là do ai đó quên tuân theo hành vi thực tế được mô tả năm 1997, đó là một sai lầm, sai lầm là điều sẽ xảy ra.
CIFS hoặc Ceph cũng có lỗi.
Mọi người cho rằng thông thường kernel là nơi cuối cùng mong đợi xuất hiện lỗi, do đó cho thấy nó đã được thử nghiệm trong thực tế.
Xu hướng hiện đại là xây dựng các nền tảng dữ liệu khổng lồ, trong khi NFS tránh được kiến trúc phức tạp này.
Nhân Linux cần áp dụng các phương pháp kiểm thử tốt hơn, vì chúng gần như hoàn toàn dựa vào CI đám mây thủ công thay vì code có thể chứng minh là đúng và các bất biến.
Kerberos rất thú vị để quản lý, nhưng cũng là một nguồn hành vi kỳ quặc liên tục.
Nhà phát triển nên chú ý đến các commit message của kernel, điều này rất quan trọng để hiểu các thay đổi code.
Thuật ngữ “Higgs Bugson” thú vị hơn Heisenbug thường được nói đến.
Mọi hành vi đều có vị trí của nó, không có phép thuật.
Có người cảm thấy chất lượng phát hành của nhân Linux trong những năm 2020 đã giảm sút, tệ nhất kể từ giữa những năm 90.
NFS thường chỉ được sử dụng trong môi trường Linux/Windows hỗn hợp, giải pháp đơn giản nhất là tránh sử dụng NFS, đặc biệt là Windows.
NFS có thể chạy trên TCP hoặc UDP và thực sự có logic truyền lại trên UDP.

Tôi đã quét tất cả các “oops commit” trên GitHub để tìm các bí mật bị rò rỉ #

I scanned all of GitHub’s “oops commits” for leaked secrets

https://trufflesecurity.com/blog/guest-post-how-i-scanned-all-of-github-s-oops-commits-for-leaked-secrets

Bài viết này là một bài đăng của khách được viết bởi hacker mũ trắng Sharon Brizinov, giới thiệu cách anh ta quét tất cả các “Oops Commits” đã bị xóa trên GitHub để tìm kiếm các bí mật bị rò rỉ. Bài viết bắt đầu bằng một giới thiệu ngắn gọn về bối cảnh, Sharon Brizinov thường tập trung vào các lỗ hổng cấp thấp và nghiên cứu khai thác các thiết bị OT/IoT, thỉnh thoảng cũng tham gia săn tiền thưởng lỗi. Gần đây, anh đã xuất bản một bài viết trên blog về các bí mật ẩn trong kho lưu trữ GitHub, gây ra một cuộc thảo luận sôi nổi. Sau khi trao đổi với CEO Dylan của Truffle Security và những người khác, anh quyết định khám phá các phương pháp săn bí mật quy mô lớn mới và tạo ra một sơ đồ tư duy bao gồm tất cả các kiến thức, blog, ý tưởng và tài nguyên liên quan.

Bài viết phác thảo cách sử dụng GitHub Event API và dự án GitHub Archive để quét tất cả các Push-Events (các commit bị xóa) có số lượng commit bằng không để tìm kiếm bí mật. Sharon giải thích ý nghĩa của việc xóa một commit trên GitHub và cách xóa commit bằng cách đặt lại HEAD và buộc đẩy (force push), mặc dù vậy, GitHub vẫn giữ lại bản ghi của các commit này. Anh ta trình bày một hướng dẫn về cách tìm các commit đã bị xóa trong kho lưu trữ của riêng bạn và giải thích lý do tại sao ngay cả khi các commit đã bị xóa thông qua force push, GitHub vẫn có thể truy cập được chúng.

Bài viết trình bày chi tiết cách sử dụng GitHub Event API để truy xuất thông tin về các sự kiện xảy ra trên GitHub, bao gồm đẩy code, mở hoặc đóng issue hoặc pull request, tạo kho lưu trữ, thêm nhận xét, fork kho lưu trữ và star kho lưu trữ, v.v. Tác giả chỉ ra rằng không cần API token hoặc xác thực để sử dụng API này và các sự kiện được ghi lại gần như theo thời gian thực.

Tiếp theo, bài viết kể về cách xây dựng các công cụ tự động để tìm kiếm các bí mật có tác động. Sharon đã phát hiện ra các bí mật tiền thưởng lỗi trị giá 25000 đô la bằng cách quét tất cả các sự kiện force push có số lượng commit bằng không kể từ năm 2020. Anh ấy đã hợp tác với Truffle Security để mở mã nguồn một công cụ mới có thể giúp quét các commit ẩn này trong tổ chức GitHub của riêng bạn.

Cuối cùng, bài viết tóm tắt cách ngăn chặn sự xâm phạm chuỗi cung ứng quy mô lớn thông qua một nghiên cứu điển hình. Sharon chia sẻ nghiên cứu và khám phá của mình, cũng như cách sử dụng những kiến thức này để bảo vệ các tổ chức khỏi rủi ro rò rỉ bí mật. Bài viết nhấn mạnh tầm quan trọng của việc GitHub vẫn giữ lại các commit ngay cả sau khi chúng bị xóa và cung cấp một phương pháp mới để tìm kiếm các bí mật đã bị xóa này ở quy mô lớn.

HN | Độ nóng: 187 điểm | 105 bình luận | Tác giả: elza_1111 #

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

Trang “Hoạt động” của GitHub có thể xem tất cả các bản ghi thao tác, bao gồm cả việc ép buộc đẩy các mã nguyên mẫu bị ẩn.
Một số người dùng cho biết chưa từng nghe nói về trang “Hoạt động” của GitHub.
Trang “Hoạt động” của một số dự án trống hoặc chỉ có một vài mục, có thể là một tính năng mới được giới thiệu gần đây.
Trang hoạt động không có dữ liệu trước ngày 7 tháng 3 năm 2023, cho thấy tính năng này có thể chỉ tồn tại trong 2 năm trong lịch sử 17 năm của GitHub.
Một số người dùng chia sẻ những vấn đề tương tự mà họ gặp phải trong quá khứ khi triển khai, tương tự như việc vô tình tiết lộ mật khẩu vào lịch sử bash.
Có đề xuất xóa toàn bộ kho lưu trữ và tải lại để xóa vĩnh viễn các bản ghi này, miễn là không có fork.
Nếu vô tình đẩy nội dung không muốn công khai, có thể giảm thiểu thiệt hại tiềm ẩn hơn nữa bằng cách ép buộc đẩy, xoay vòng khóa ngay lập tức, liên hệ với bộ phận hỗ trợ khách hàng để thu gom rác.
Có người cho rằng, nếu đã xoay vòng khóa thì không cần làm gì thêm, vì không có thêm thiệt hại tiềm ẩn.
Có người chỉ ra rằng không phải tất cả các bí mật đều có thể xoay vòng, chẳng hạn như địa chỉ nhà, và ngay cả khi có thể xoay vòng, cũng không thể đảm bảo 100% vô hiệu.
Có người cho rằng, việc dọn dẹp các bí mật bị rò rỉ có thể tránh được các báo cáo sai trong tương lai, chẳng hạn như máy quét tự động hoặc thợ săn tiền thưởng.
Có người cho rằng, việc khai thác dự án để xem có bí mật nào bị rò rỉ hay không sẽ khuyến khích một kiểu phản mẫu, khiến các tổ chức sợ công bố bất cứ điều gì.
Có người cho biết, có các công cụ tự động có thể quét các bí mật, thậm chí GitHub cũng đang làm, điều này có thể giáo dục các nhà phát triển cẩn thận hơn và hướng đến sự an toàn hơn.
Có người nhắc nhở rằng, việc rò rỉ bí mật AWS có thể gây ra chi phí lớn cho tổ chức, AWS sẽ không trợ giúp.
Có người cho rằng, bằng cách đẩy mã lên các dự án không quan trọng, có thể nhanh chóng phát hiện ra mình có vấn đề này.
Có người cho rằng, không có đánh giá nội bộ và tiêu chuẩn mã hóa nào có thể nắm bắt được tất cả các vấn đề, chỉ có thể hy vọng xây dựng trí nhớ cơ bắp thông qua việc bị tấn công.
Có người cho rằng, mọi thứ đều là an ninh 101, có thể được nắm bắt bằng các công cụ tiêu chuẩn, không nên coi đó là kinh nghiệm học tập.
Có người cho rằng, việc mỗi công ty có một linter miễn phí, hiệu suất cao, chính xác 100% và không có báo cáo sai được kết nối với quy trình xây dựng của họ là không thực tế.
Có người cho rằng, lập trình viên có trách nhiệm học hỏi và ghi nhớ những điều này.

Súng Railgun Nông Dân #

Peasant Railgun

https://knightsdigest.com/what-exactly-is-the-peasant-railgun-in-dd-5e/

Bài viết này được viết bởi Sawyer Bohannan, một nhà văn và Dungeon Master (DM) kỳ cựu ở Chicago. Bài viết thảo luận về chiến thuật được gọi là “Peasant Railgun” (Súng ray nông dân) trong D&D 5e (Dungeons & Dragons phiên bản thứ 5). Khái niệm này bắt nguồn từ cuối cuộc khủng hoảng tài chính năm 2008, một bài đăng trên 1d4chan đã đưa ra lý thuyết này, gây ra các cuộc thảo luận sôi nổi giữa các DM và người chơi trong cộng đồng. Peasant Railgun là gì? Peasant Railgun là một chiến thuật lý thuyết, bằng cách thuê 2280 nông dân, xếp họ thành một hàng, sau đó gây ra 300d6 (300 lần tung xúc xắc 6 mặt) sát thương cho kẻ thù bằng cách chuyền một chiếc thang đã tháo rời. Quá trình này chỉ mất một hiệp chiến đấu và có thể được nạp lại và bắn lại trong vòng 12 giây. Peasant Railgun hoạt động như thế nào: Chiến thuật này liên quan đến một số quy tắc khác nhau, bao gồm hành động chuẩn bị (Ready Action), thời gian cần thiết cho một hiệp chiến đấu, không gian chiếm bởi một cá nhân có kích thước trung bình và quy tắc vật rơi (Falling Object rules) trong 5e. Hành động chuẩn bị cho phép người chơi sử dụng hành động phản ứng trong một tình huống cụ thể, trong ví dụ này, người chơi sẽ tháo rời thang và đưa thanh gỗ cho người ở cuối hàng, sau đó hướng dẫn mọi người chuẩn bị chuyền thanh gỗ cho người nông dân phía trước. Khi trận chiến bắt đầu, chuỗi hành động này được kích hoạt, thanh gỗ được chuyền đi hai dặm trong 6 giây, tương đương với tốc độ 1900 dặm một giờ. Cuộc tranh luận giữa vật lý thực tế và quy tắc: Bài viết nhắc nhở người đọc rằng mặc dù chiến thuật này khả thi về mặt quy tắc, nhưng nó không phù hợp với các định luật vật lý thực tế. Nếu được thực hiện theo nghĩa đen, nó sẽ nhanh chóng gặp phải vấn đề. Ví dụ, nông dân có thể bị thương nặng khi chuyền thanh gỗ với tốc độ này, và người bình thường không thể theo dõi một vật thể di chuyển với tốc độ này, chứ đừng nói đến việc chuyền nó. Ngoài ra, ngay cả khi thanh gỗ đến được đầu hàng, nông dân cũng không nhất thiết có thể đánh trúng mục tiêu một cách chính xác. DM có cho phép sử dụng Peasant Railgun không? Tác giả cho rằng, mặc dù “quy tắc hay” là một công cụ thường được các DM sử dụng, nhưng việc cố gắng sử dụng Peasant Railgun có thể vượt quá phạm vi áp dụng của quy tắc này. Cá nhân tác giả cho rằng chiến thuật này có thể là một ý tưởng thú vị cho một cuộc phiêu lưu một lần (one-shot), nhưng hầu hết các DM có thể sẽ không cho phép người chơi sử dụng.

Cuối bài viết, tác giả khuyên người đọc xem các nội dung khác mà họ cung cấp và đề cập rằng bài viết này chứa một số liên kết liên kết (affiliate links), nếu người đọc đăng ký hoặc mua hàng thông qua các liên kết này, tác giả có thể nhận được hoa hồng. Bài viết cũng cung cấp hai liên kết tài nguyên, một là trang wiki 1d4chan về Peasant Railgun và một là trang quy tắc cơ bản về hành động chuẩn bị trong chiến đấu trên D&D Beyond.

HN | Độ nóng: 179 điểm | 140 bình luận | Tác giả: cainxinth #

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

Những tình tiết phi lý do sự sáng tạo của người chơi tạo ra là một trong những phần thú vị nhất của trải nghiệm DnD, nhưng chúng thường dựa vào việc giải thích quá phức tạp hoặc bóp méo các quy tắc, không tuân thủ theo văn bản hoặc ý định của quy tắc.
DM nên xem xét cẩn thận những tuyên bố này, tìm ra nơi trò đùa tan vỡ, và các tác giả DnD cũng ủng hộ DM, các quy tắc không nên chỉ được giải thích từ góc độ mô phỏng, mà là để giúp DM phân xử và điều phối các trận chiến và tương tác.
Trong trường hợp Peasant Railgun, quy tắc không nói rằng các vật phẩm được truyền đi giữ nguyên tốc độ khi được truyền từ sinh vật này sang sinh vật khác, vật phẩm có tốc độ khi được truyền cuối cùng giống như khi được truyền lần đầu tiên.
Các vật phóng được ném hoặc bắn không được tính là “rơi”, nếu một cung thủ bắn một mũi tên đi 100 feet, mũi tên sẽ không nhận được 100 feet “sát thương do rơi”.
Nếu DM muốn khuyến khích và thực hiện những trò hề điên rồ, thì họ hoàn toàn có quyền làm như vậy.
Vấn đề của TFA là nó là một người chơi mô tả những gì họ muốn thử, sau đó cũng mô tả việc thử có thành công hay không và kết quả chính xác.
Mỗi bàn và trò chơi là duy nhất, nó là một thế giới vi mô xã hội, là tất cả đối với một số người, nhưng không phải là một điều đối với bất kỳ ai.
Mọi người đều có luật lệ riêng trong D&D đến mức điểm chung duy nhất của hầu hết các bàn là cách lên cấp và sử dụng phép thuật nào.
Khái niệm luật sư quy tắc không phải do bàn D&D phát minh ra, nhưng việc tạo ra cụm từ này gần như chắc chắn liên quan đến việc ngồi vào bàn.
Trong D&D, việc tìm kiếm các tương tác quy tắc thú vị và bất ngờ là một phần của D&D, việc tìm kiếm các tương tác rõ ràng là phá hoại và vô ý, chỉ đơn thuần là một bài tập trí tuệ, cũng là một phần của D&D.
Mong đợi DM cư xử như một trò chơi điện tử bị lỗi và trao cho bạn sức mạnh tối thượng vì đã tìm thấy một lỗ hổng có thể khai thác trong trò chơi, điều này luôn xảy ra trong D&D, nhưng nó không đáng khen ngợi và không nằm trong tinh thần của sự vật.
Cơ chế D&D là sự đơn giản hóa của thế giới thực, sử dụng các yếu tố nguyên thủy như “kéo cung”, “truyền vật phẩm” và “uống thuốc”, thế giới thực là phân dạng sâu sắc, sử dụng các yếu tố nguyên thủy như “chiều dài ván” và “spin của quark”.
Do đó, sẽ luôn có sự không phù hợp giữa thế giới thực và sự đơn giản hóa, việc tìm ra những khoảng trống này có thể thú vị, nhưng nó không phải là khai thác.
Chúng ta đang chơi các yếu tố nguyên thủy được đơn giản hóa, không phải vật lý của thế giới thực.
Có một sự căng thẳng giữa ba điều: “trình mô phỏng chiến đấu” được tích hợp trong các quy tắc, mô phỏng thế giới và câu chuyện.
“Peasant Railgun” không may mắn không vượt qua tất cả ba bài kiểm tra, nó không phải là một phần của các quy tắc chiến đấu dự kiến, không có ý nghĩa khi mô phỏng thế giới và có thể không phù hợp với tường thuật của chiến dịch vì quá kỳ lạ.
Nếu người chơi đưa ra một cái gì đó thú vị, phù hợp với logic của thế giới và cũng phù hợp với câu chuyện, thì sẽ tìm cách để nó xảy ra.
Các bàn khác nhau thích những thứ khác nhau, vì vậy đây không phải là lời khuyên dùng một lần cho tất cả.
Đủ số lượng nông dân sẽ có tính hủy diệt, phải không? Có được vài nghìn người, ít nhất một số người sẽ gây ra chí mạng trong mỗi vòng. Việc tung xúc xắc có thể khó khăn. Đối với một kẻ thù được trang bị đủ áo giáp, có thể có ý nghĩa hơn khi chỉ cần thực hiện “số lượng chí mạng dự kiến mỗi vòng” hoặc điều gì đó tương tự.
Chúng tôi thậm chí không chắc chắn liệu “chiều dài ván” và “spin của quark” có phải là các yếu tố nguyên thủy hay không.