2025-06-27 Top Stories #

Các nhà nghiên cứu đã thiết kế một vật thể hình kim tự tháp mới, luôn ổn định khi rơi trên cùng một mặt, xác minh một phỏng đoán toán học và có thể có các ứng dụng tiềm năng trong thiết kế tàu vũ trụ.
Một bài viết kể về những hạn chế của việc đo lường tiến độ công việc bằng số lượng dòng code, và thông qua câu chuyện Bill Atkinson tối ưu hóa code đã khơi gợi cuộc thảo luận về tối ưu hóa code và đánh giá hiệu suất.
Dự án QEMU cấm sử dụng trình tạo code AI, vì các vấn đề pháp lý và cấp phép của code do AI tạo ra chưa rõ ràng, có thể gây ra rủi ro bản quyền.
Richard Feynman khuyên nên bắt đầu nghiên cứu từ những vấn đề đơn giản, nhấn mạnh rằng những vấn đề thực sự có giá trị là những vấn đề có thể giải quyết hoặc đóng góp, và khuyến khích tìm vị trí nghiên cứu của riêng mình.
Các thử nghiệm cho thấy SteamOS 3.7 vượt trội hơn Windows 11 về hiệu năng chơi game, đặc biệt là trên thiết bị Lenovo Legion Go S.
Lưới điện mặt trời siêu nhỏ ở Puerto Rico đã duy trì thành công nguồn cung cấp điện trong thời gian mất điện trên toàn đảo, thể hiện tiềm năng của năng lượng tái tạo.
AlphaGenome do DeepMind phát triển có thể dự đoán tác động của các biến thể trình tự DNA đối với các quá trình sinh học, dự kiến sẽ cung cấp để sử dụng phi thương mại thông qua API.
Anthropic ra mắt tính năng mới, cho phép các nhà phát triển xây dựng và lưu trữ các ứng dụng do AI điều khiển trực tiếp trong ứng dụng Claude mà không cần triển khai.
Libxml2 thông báo sẽ không còn tuân theo chính sách cấm vận an ninh, coi các vấn đề an ninh là xử lý lỗi thông thường, gây ra cuộc thảo luận về bảo trì dự án mã nguồn mở và báo cáo an ninh.
Dân số nhà tù ở Hoa Kỳ đã giảm đáng kể, dự kiến sẽ giảm khoảng 60% trong thập kỷ tới, chủ yếu là do giảm tội phạm vị thành niên.

Một hình dạng mới giống kim tự tháp luôn đáp xuống cùng một mặt #

A new pyramid-like shape always lands the same side up

https://www.quantamagazine.org/a-new-pyramid-like-shape-always-lands-the-same-side-up-20250625/

Vào ngày 25 tháng 6 năm 2025, Elise Cutts đã xuất bản một bài viết về toán học và kỹ thuật, giới thiệu một loại vật thể hình kim tự tháp mới - một tứ diện chỉ có thể nằm ổn định trên một mặt của nó. Phát hiện này xác nhận một phỏng đoán từ nhiều thập kỷ trước.

Bài viết bắt đầu bằng việc xem xét lại quan điểm của Plato vào năm 360 trước Công nguyên rằng vũ trụ được cấu tạo từ năm hình dạng hình học, được gọi là đa diện. Mặc dù những hình dạng này đã được nghiên cứu trong hàng ngàn năm, nhưng ngay cả tứ diện đơn giản nhất vẫn còn nhiều bí ẩn chưa được giải đáp. Ví dụ, làm thế nào để đóng gói các tứ diện đều một cách dày đặc nhất, và những loại tứ diện nào có thể được cắt và ghép lại thành một hình lập phương.

Các nhà toán học John Conway và Richard Guy đã đặt ra một câu hỏi vào năm 1966: liệu có thể xây dựng một tứ diện làm từ vật liệu đồng nhất, có trọng lượng phân bố đều, chỉ có thể nằm trên một mặt của nó hay không. Nếu đặt một hình dạng “đơn ổn định” như vậy trên bất kỳ mặt nào khác, nó sẽ lật sang mặt ổn định của nó. Vài năm sau, chính họ đã trả lời câu hỏi này, chỉ ra rằng một tứ diện đơn ổn định đồng nhất như vậy là không thể. Nhưng nếu cho phép phân bổ trọng lượng không đồng đều thì sao?

Dávid Papp của Đại học Bang North Carolina đã đề cập rằng điều này dường như là hiển nhiên, vì đó là cách đồ chơi lật đật hoạt động: chỉ cần đặt một vật nặng ở dưới đáy. Nhưng điều này chỉ áp dụng cho các hình dạng nhẵn hoặc tròn hoặc cả hai. Đối với một đa diện có các cạnh sắc và mặt phẳng, việc thiết kế một hình dạng luôn lật sang cùng một mặt không hề đơn giản.

Gábor Domokos, một nhà toán học tại Đại học Công nghệ và Kinh tế Budapest, từ lâu đã quan tâm đến vấn đề cân bằng. Năm 2006, ông và các đồng nghiệp của mình đã phát hiện ra một hình dạng có tên là gömböc, có đặc tính khác thường là “đơn đơn ổn định” - nó chỉ có thể cân bằng ở hai điểm (một điểm ổn định và một điểm không ổn định, giống như cạnh của một đồng xu), không có điểm nào khác. Nếu bạn cố gắng cân bằng nó ở những nơi khác, nó sẽ lăn đến điểm ổn định.

Domokos muốn biết liệu một đa diện sắc cạnh cũng có thể có các thuộc tính tương tự hay không. Vì vậy, phỏng đoán của Conway đã thu hút ông. Ông và các sinh viên Gergő Almádi, Krisztina Regős và Robert Dawson của Đại học Saint Mary’s ở Canada đã chứng minh vào năm 2023 rằng, thực sự có thể phân bổ trọng lượng của một tứ diện sao cho nó chỉ nằm trên một mặt. Ít nhất là về mặt lý thuyết.

Almadi, Dawson và Domokos muốn xây dựng hình dạng này, một nhiệm vụ khó khăn hơn nhiều so với họ dự kiến. Giờ đây, họ đã trình bày mô hình vật lý hoạt động đầu tiên của hình dạng này trong một bản in trước được công bố ngày hôm qua. Tứ diện này nặng 120 gram, cạnh dài nhất dài 50 cm, được làm từ sợi carbon nhẹ và vonfram carbide đậm đặc. Để hoạt động, nó phải được thiết kế chính xác đến mức độ một phần mười gram và một phần mười milimet. Nhưng cấu trúc cuối cùng luôn lật sang một mặt như mong đợi.

Công trình này cho thấy vai trò quan trọng của thử nghiệm và trò chơi trong nghiên cứu toán học. Nó cũng có các ứng dụng thực tế tiềm năng, chẳng hạn như trong việc thiết kế tàu vũ trụ tự sửa lỗi. Papp nói rằng nghiên cứu này cho phép các nhà toán học “thực sự đánh giá cao những điều chúng ta chưa từng biết trước đây, và mức độ hiểu biết của chúng ta hiện tại sâu sắc đến mức nào.”

Vào năm 2022, Almadi, khi đó là một sinh viên đại học khao khát trở thành kiến trúc sư, đã tham gia lớp học cơ học của Domokos. Domokos thấy anh là một người siêng năng và không ngừng suy nghĩ sâu sắc. Vào cuối học kỳ, Domokos yêu cầu anh thiết kế một thuật toán đơn giản để khám phá cách tứ diện cân bằng. Không giống như khi Conway ban đầu đặt ra câu hỏi và chỉ có thể sử dụng bút chì và giấy để chứng minh sự tồn tại của tứ diện đơn ổn định thông qua suy luận toán học trừu tượng, Almadi đã có máy tính sau nhiều thập kỷ. Anh ta có thể tìm kiếm một lượng lớn các hình dạng có thể có bằng phương pháp vét cạn. Cuối cùng, chương trình của Almadi đã tìm thấy tọa độ của bốn đỉnh của một tứ diện, khi được gán một phân bố trọng lượng cụ thể, có thể làm cho nó trở thành đơn ổn định. Conway đã đúng.

Almadi đã tìm thấy một tứ diện đơn ổn định, nhưng có thể có những tứ diện khác. Chúng có chung thuộc tính gì? Mặc dù đây có vẻ là một câu hỏi đơn giản, nhưng một tuyên bố như “một tứ diện là đơn ổn định” không thể dễ dàng được mô tả bằng một công thức đơn giản hoặc một tập hợp các phương trình. Nhóm nghiên cứu nhận ra rằng, trong bất kỳ tứ diện đơn ổn định nào, ba cạnh liên tiếp (nơi các mặt gặp nhau) phải có các thuộc tính cụ thể.

HN | Độ nóng: 613 điểm | 151 bình luận | Tác giả: robinhouston #

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

Có người sở hữu mô hình được đề cập trong bài viết, đề nghị liên hệ Bob Dawson.
Có người tạo một trang web để hiển thị mô hình, nhưng hình ảnh cần nhấp vào liên kết để xem.
Có người đề cập rằng trang web không hỗ trợ hiển thị hình ảnh, chỉ có thể cung cấp liên kết.
Có người bày tỏ đánh giá không cao về trang web, nhưng cho rằng việc cung cấp liên kết là có thể chấp nhận được.
Có người đề nghị cải thiện độ đậm và độ tương phản của văn bản.
Có người cố gắng lưu trang web vào Internet Archive nhưng không thành công.
Có người hy vọng được xem video trình diễn trên YouTube.
Có người cho rằng mô hình này không chỉ là hình dạng, mà là kết quả của việc thao tác cao độ khối tâm.
Có người giải thích tại sao mô hình lại nghiêng về phía sau trước rồi mới nghiêng sang một bên theo một hướng.
Có người thảo luận về cách thiết kế một phiên bản của quy trình nghiêng ba bước.
Có người chỉ ra rằng, nếu vật thể phải có mật độ đồng đều, hình lồi và không chứa bất kỳ khoảng trống nào, thì không thể chọn vị trí khối tâm của nó.
Có người cho rằng, chỉ cần vị trí khối tâm giống nhau, thì dù mật độ không đồng đều, vật thể cũng sẽ thể hiện hành vi tương tự.

-2000 Dòng code (2004) #

-2000 Lines of code (2004)

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

Bài viết này kể về việc vào đầu năm 1982, nhóm phần mềm Lisa bắt đầu thử nghiệm đo lường tiến độ công việc của các kỹ sư bằng cách theo dõi số dòng code mà mỗi người viết mỗi tuần, nhằm hoàn thành việc phát hành phần mềm trong sáu tháng tới. Ban quản lý thiết kế một biểu mẫu yêu cầu mỗi kỹ sư nộp vào thứ Sáu hàng tuần, trong đó có việc điền số dòng code đã viết trong tuần đó.

Nhân vật chính của bài viết là Bill Atkinson, tác giả của Quickdraw, đồng thời là nhà thiết kế giao diện người dùng chính, người có vai trò quan trọng đối với sự thành công của dự án Lisa. Ông cho rằng việc đo lường năng suất phần mềm bằng số dòng code là ngớ ngẩn, vì mục tiêu của ông là viết các chương trình nhỏ và nhanh nhất có thể, trong khi chỉ số số dòng code chỉ khuyến khích viết code cẩu thả, phình to và dễ mắc lỗi. Gần đây, ông đã tối ưu hóa cơ chế tính toán vùng của Quickdraw, bằng cách viết lại hoàn toàn engine vùng bằng một thuật toán đơn giản hơn, tổng quát hơn, sau một số điều chỉnh, giúp tăng tốc độ thao tác vùng lên gần sáu lần. Sản phẩm phụ là việc viết lại cũng tiết kiệm được khoảng 2000 dòng code.

Khi Bill Atkinson hoàn thành công việc tối ưu hóa và lần đầu tiên cần điền vào biểu mẫu của ban quản lý, ông đã suy nghĩ một lúc về phần số dòng code, sau đó điền vào con số: -2000. Bài viết không chắc chắn về phản ứng của ban quản lý đối với điều này, nhưng quả thực vài tuần sau, họ đã ngừng yêu cầu Bill điền vào biểu mẫu và ông rất vui vẻ tuân theo.

Phần cuối của bài viết đề cập đến một hệ thống đánh giá, với điểm tổng thể là 4.72 (điểm cao nhất), và hiển thị một số bình luận của độc giả. Các nhà bình luận thường cho rằng câu chuyện này mang tính giáo dục cao, và các nhà quản lý IT nên học hỏi từ đó. Một số nhà bình luận đề cập rằng bất kỳ công cụ hữu ích nào cũng có thể bị sử dụng một cách ngớ ngẩn, và việc đánh giá hiệu suất công việc bằng số dòng code là không phù hợp. Cũng có những nhà bình luận chia sẻ kinh nghiệm của bản thân, họ đã giảm số dòng code thông qua việc tối ưu hóa code, nâng cao hiệu quả hoạt động và chức năng của code, nhưng cách đánh giá hiệu suất dựa trên tiêu chuẩn số dòng code lại bỏ qua những thành quả này.

Cuối bài viết cung cấp khu vực bình luận của người dùng, cho phép độc giả để lại quan điểm của mình, và đề cập rằng nội dung văn bản của câu chuyện này được cấp phép theo Creative Commons License.

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

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

Thông qua tối ưu hóa thuật toán, có thể giảm 60K dòng code xuống còn 5K dòng, hiện thực dịch vụ lightweight không trạng thái bộ nhớ.
Trong lập trình tồn tại rất nhiều lĩnh vực chưa biết, cần phải không ngừng học tập.
Kiến thức về thuật toán và cấu trúc dữ liệu có thể được lĩnh hội một cách tự nhiên trong công việc thực tế, sau đó mới có thể biết tên của chúng và các sách liên quan.
Thông qua việc viết lại backend PHP cũ, sử dụng ngôn ngữ Go có thể cải thiện đáng kể tốc độ phản hồi.
Khi còn trẻ đã “phát minh” ra cấu trúc dữ liệu Trie, sau này phát hiện ra nó đã có tên, phù hợp với các trường hợp sử dụng cụ thể.
Năm 16 tuổi đã “phát minh” ra file CSV, vì lười thiết lập SQL cho Discord bot.
Mô hình ngôn ngữ lớn (LLMs) giỏi cung cấp tên và từ khóa tìm kiếm cho các gợi ý mơ hồ.
Thông qua việc đọc những cuốn sách hay về cấu trúc dữ liệu và thuật toán, có thể nhanh chóng theo kịp những bình luận kiểu này.
Càng biết nhiều, càng biết mình không biết nhiều.
Một nửa độ khó đến từ thuật ngữ chuyên môn, sau khi học được thuật ngữ chuyên môn, mọi người sẽ cho rằng bạn là thiên tài.
Thuật ngữ của lý thuyết đồ thị nghe có vẻ phức tạp, nhưng logic cơ bản hầu hết mọi người đều có thể hiểu được.
Thông qua việc học kiến thức cơ bản về thuật toán đồ thị, có thể hiểu được phần lớn thuật ngữ lý thuyết đồ thị.
Thông qua việc vẽ đồ thị và thao tác thủ công các ví dụ, có thể hiểu rõ hơn về vấn đề và giải pháp.
Thông qua việc giải quyết vấn đề thực tế, có thể hiểu vấn đề như Feynman, chứ không chỉ đơn thuần là ghi nhớ câu trả lời.
Phản đối các cuộc phỏng vấn thuật toán kiểu LeetCode, cho rằng chúng không liên quan đến công việc thực tế.

Định nghĩa chính sách cấm sử dụng các trình tạo mã AI #

Define policy forbidding use of AI code generators

https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048

Trang web này là về tuyên bố chính sách của dự án QEMU về việc sử dụng trình tạo mã AI.

Dự án QEMU gần đây đã cập nhật tài liệu của mình, làm rõ chính sách đối với việc sử dụng trình tạo mã AI. Tài liệu đề cập rằng, mặc dù trình tạo mã AI đã thu hút được sự quan tâm rộng rãi, nhưng hiện tại vẫn chưa có sự đồng thuận rộng rãi về các diễn giải pháp lý và tác động cấp phép của mã do các công cụ này tạo ra. Mặc dù các nhà cung cấp có thể tuyên bố rằng không có vấn đề gì và có thể chọn giấy phép tự do, nhưng cách giải thích này không đáng tin cậy vì họ có xung đột lợi ích. Hiện tại, cũng không có sự đồng thuận rộng rãi về tác động cấp phép của trình tạo mã được đào tạo trên nhiều giấy phép khác nhau.

Bản gốc Chứng nhận Nhà phát triển (DCO) yêu cầu người đóng góp tuyên bố rằng họ có quyền đóng góp mã theo giấy phép dự án được chỉ định. Do thiếu sự đồng thuận về giấy phép cho đầu ra của trình tạo mã AI, việc tuyên bố tuân thủ các điều khoản (b) hoặc (c) của DCO là không đáng tin cậy nếu bản vá chứa mã được tạo như vậy.

Do đó, dự án QEMU quyết định hiện tại không chấp nhận các đóng góp đã biết hoặc nghi ngờ sử dụng trình tạo mã AI. Các công cụ này vẫn còn ở giai đoạn đầu của quá trình phát triển phần mềm được hỗ trợ bởi AI, các vấn đề pháp lý cuối cùng sẽ được giải quyết và các công cụ cũng sẽ trưởng thành, chúng ta có thể mong đợi một số công cụ được sử dụng an toàn trong các dự án phần mềm tự do.

Chính sách hiện tại của dự án QEMU là nghiêm ngặt và an toàn, sau đó có thể được nới lỏng. Đồng thời, các yêu cầu ngoại lệ cũng có thể được xem xét tùy theo từng trường hợp cụ thể. Tuyên bố chính sách được ký bởi Daniel P. Berrangé và được Kevin Wolf, Stefan Hajnoczi và Alex Bennée xem xét.

Tài liệu cũng đề cập rằng, chính sách của dự án QEMU là từ chối bất kỳ đóng góp nào được cho là chứa hoặc bắt nguồn từ nội dung do AI tạo ra, bao gồm các công cụ tương tự như ChatGPT, Claude, Copilot, Llama, v.v. Sự phổ biến của việc phát triển phần mềm được hỗ trợ bởi AI mang lại nhiều vấn đề và rủi ro pháp lý, đặc biệt là nội dung do các mô hình ngôn ngữ lớn (LLMs) tạo ra.

Cộng đồng QEMU yêu cầu người đóng góp chứng minh rằng các bản vá của họ tuân thủ các quy tắc của Chứng nhận Nhà phát triển (DCO). Để đáp ứng DCO, người đóng góp bản vá phải hiểu đầy đủ bản quyền và trạng thái cấp phép của nội dung mà họ đóng góp cho QEMU. Đối với trình tạo nội dung AI, bản quyền và trạng thái cấp phép của đầu ra là không rõ ràng, không có cơ sở pháp lý được chấp nhận rộng rãi. Nếu tài liệu đào tạo đã biết, nó thường bao gồm một lượng lớn tài liệu có các điều khoản cấp phép/bản quyền bị hạn chế. Ngay cả khi tất cả tài liệu đào tạo được biết là giấy phép nguồn mở, nó có thể chứa nhiều điều khoản và không phải tất cả các điều khoản đều tương thích với các yêu cầu cấp phép của QEMU.

Dự án QEMU không sẵn lòng hoặc không thể chấp nhận rủi ro pháp lý không tuân thủ. Do đó, dự án QEMU yêu cầu người đóng góp tránh sử dụng trình tạo nội dung AI khi có ý định gửi cho dự án và sẽ từ chối bất kỳ đóng góp nào nếu đã biết hoặc nghi ngờ sử dụng AI. Chính sách này không áp dụng cho các mục đích sử dụng AI khác, chẳng hạn như nghiên cứu API hoặc thuật toán, phân tích tĩnh hoặc gỡ lỗi, miễn là đầu ra của chúng không được bao gồm trong đóng góp.

Các công cụ chịu ảnh hưởng bởi chính sách này bao gồm Copilot của GitHub, ChatGPT của OpenAI, Claude của Anthropic và Code Llama của Meta, cũng như các tác nhân tạo mã/nội dung được xây dựng dựa trên các công cụ này. Khi các công cụ AI trưởng thành và tình hình pháp lý được làm rõ, chính sách này có thể phát triển. Trong thời gian này, dự án QEMU sẽ đánh giá các yêu cầu ngoại lệ đối với chính sách này trên cơ sở từng trường hợp cụ thể. Để được ngoại lệ, người đóng góp cần chứng minh rằng đầu ra của công cụ có trạng thái cấp phép và bản quyền rõ ràng so với mô hình đào tạo và mã của nó để đáp ứng các yêu cầu của người bảo trì dự án.

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

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

Phần mềm nguồn mở và phần mềm tự do đặc biệt dễ bị xâm phạm hoặc có nguy cơ trở thành miền công cộng trong tương lai của mã do AI tạo ra.
Mã do AI tạo ra có thể khiến các chỉnh sửa tiếp theo của con người trở thành các tác phẩm phái sinh không hợp lý.
Phần mềm độc quyền ít bị tổn hại hơn trong cả hai trường hợp, đòi hỏi chủ sở hữu bản quyền mang tính suy đoán phải dịch ngược các tệp nhị phân của họ.
Lạm dụng bản quyền và ý tưởng cốt lõi của việc phủ nhận quyền sở hữu trí tuệ đều gây tổn hại đến lợi ích công cộng.
AI có thể làm cho bản quyền (và copyleft) trở nên dư thừa về mặt kinh tế.
Một khi AI có thể tạo ra toàn bộ hệ điều hành, lợi ích của tất cả các mô hình cấp phép hiện tại sẽ biến mất.
Hiện tại, hầu hết các dự án phần mềm nguồn mở phải coi mã AI là không thể sử dụng được.
Khi công nghệ phát triển, chi phí tạo mã bằng AI có thể giảm xuống rất thấp.
Một khi mô hình AI đủ tốt, ngay cả khi tính phí với mức giá đắt đỏ hiện tại, nó cũng sẽ khiến tất cả con người thất nghiệp.
Hãy xem xét chi phí sử dụng LLM để sao chép toàn bộ hệ thống Linux, các mô hình hiện tại chưa đủ tốt, vì vậy vấn đề này hiện không thể giải quyết được với bất kỳ giá nào.

Giải quyết vấn đề gì (1966) #

What Problems to Solve (1966)

http://genius.cat-v.org/richard-feynman/writtings/letters/problems

Trang web này là một bài viết của Richard Feynman, có tiêu đề “Những vấn đề cần giải quyết”. Bài viết bắt đầu bằng việc Feynman nhận được thư từ học trò của mình, Koichi Mano, trong đó Mano đề cập rằng anh đang nghiên cứu “lý thuyết mạch lạc và ứng dụng của nó trong sự truyền sóng điện từ qua bầu khí quyển nhiễu loạn”, một vấn đề khiêm tốn và thực tế. Feynman bày tỏ sự lo lắng về Mano trong thư trả lời, vì ông tin rằng Mano đã bị ảnh hưởng sai lệch và có một sự hiểu lầm về những gì là một vấn đề có giá trị.

Feynman chỉ ra trong thư rằng những vấn đề thực sự có giá trị là những vấn đề mà bạn thực sự có thể giải quyết hoặc giúp giải quyết, những vấn đề mà bạn thực sự có thể đóng góp một điều gì đó. Ông tin rằng nếu một vấn đề khoa học chưa được giải quyết và chúng ta thấy con đường để giải quyết nó, thì vấn đề đó là vĩ đại. Ông khuyên Mano nên bắt đầu với những vấn đề đơn giản hơn hoặc khiêm tốn hơn, cho đến khi tìm thấy một vấn đề mà anh có thể giải quyết một cách dễ dàng, bất kể những vấn đề đó nhỏ nhặt đến đâu. Feynman nhấn mạnh rằng niềm vui thành công và niềm vui giúp đỡ người khác (ngay cả khi trả lời câu hỏi của những đồng nghiệp kém năng lực hơn bạn) không nên bị tước đoạt vì một sự hiểu lầm về giá trị.

Feynman đề cập rằng khi ông gặp Mano, ông đang ở đỉnh cao của sự nghiệp và dường như chỉ quan tâm đến những vấn đề gần gũi với thần thánh. Nhưng đồng thời, ông còn có một nghiên cứu sinh tiến sĩ khác, Albert Hibbs, đang nghiên cứu vấn đề gió thổi qua mặt nước như thế nào để tạo thành sóng. Feynman chấp nhận anh ta, vì Hibbs đã đến gặp ông với một vấn đề mà anh ta muốn giải quyết. Feynman thừa nhận rằng vấn đề ông giao cho Mano là một sai lầm, ông đã không để Mano tự tìm vấn đề, mà thay vào đó để lại cho Mano một quan niệm sai lầm về những gì thú vị, thú vị hoặc quan trọng.

Feynman chia sẻ vô số vấn đề mà ông từng nghiên cứu, những vấn đề mà Mano có thể coi là không đáng kể, nhưng ông thích thú và tự hào về chúng, vì đôi khi ông có thể thành công một phần. Những vấn đề này bao gồm: thí nghiệm về hệ số ma sát trên bề mặt được đánh bóng cao để hiểu cách thức hoạt động của ma sát; các đặc tính đàn hồi của tinh thể phụ thuộc vào lực giữa các nguyên tử như thế nào; làm thế nào để làm cho kim loại mạ bám vào vật thể bằng nhựa; neutron khuếch tán từ uranium như thế nào; sự phản xạ của sóng điện từ từ màng thủy tinh mỏng; sự phát triển của sóng xung kích trong vụ nổ; thiết kế bộ đếm neutron; tại sao một số nguyên tố bắt electron từ quỹ đạo L thay vì quỹ đạo K; làm thế nào để gấp giấy để tạo ra một loại đồ chơi trẻ em cụ thể (gọi là flexagons); mức năng lượng của hạt nhân nhẹ; và lý thuyết nhiễu loạn (Feynman đã dành nhiều năm nghiên cứu nhưng không thành công), v.v. Ông cũng bao gồm tất cả các vấn đề lý thuyết lượng tử “vĩ đại hơn”.

Feynman nhấn mạnh rằng không có vấn đề nào là quá nhỏ hoặc quá tầm thường nếu chúng ta thực sự có thể tạo ra sự khác biệt cho vấn đề đó. Ông nói với Mano rằng anh không phải là vô danh, ít nhất là đối với vợ và con anh, và nếu anh có thể trả lời câu hỏi của đồng nghiệp, anh sẽ không vô danh trong số các đồng nghiệp của mình lâu dài. Feynman nói với Mano rằng anh không nên cảm thấy mình vô danh - đó là một cách sống buồn bã. Ông khuyến khích Mano tìm vị trí của mình trên thế giới và đánh giá bản thân một cách công bằng, không dựa trên những lý tưởng ngây thơ thời trẻ của mình, cũng như không dựa trên việc tưởng tượng sai về lý tưởng của giáo viên mình.

Cuối cùng, Feynman chúc Mano may mắn và hạnh phúc, và kết thúc bức thư bằng một giọng điệu chân thành.

HN | Độ nóng: 466 điểm | 58 bình luận | Tác giả: jxmorris12 #

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

Bài viết này là một bức thư tuyệt đẹp, chứa đựng trí tuệ về cuộc sống.
Trong thế giới và sự nghiệp phát triển nhanh chóng, chúng ta thường bỏ qua tầm quan trọng của việc giải quyết các vấn đề nhỏ.
Sự hứng thú và đam mê có thể nâng cao đáng kể hiệu quả công việc và khả năng sáng tạo của chúng ta.
Duy trì thái độ nghi ngờ và đặt câu hỏi trong công việc là rất quan trọng, điều này giúp nâng cao chất lượng sản phẩm.
Kỹ sư đặt câu hỏi không phải là từ chối, mà là tìm kiếm giải pháp tốt hơn.
Ngay cả dưới sự quản lý và hệ thống Jira, chúng ta cũng nên duy trì sự nhiệt tình và sáng tạo đối với công việc.
Feynman không chỉ là một thiên tài, mà còn là một người giỏi diễn đạt và suy nghĩ triết học.
Feynman có thể đơn giản hóa các khái niệm phức tạp, giúp chúng dễ hiểu.
Feynman nhấn mạnh việc đơn giản hóa ngôn ngữ, tránh sự phức tạp không cần thiết.
Mặc dù có công việc lương cao, nhưng một số người không cảm thấy nhiệt huyết với công việc của mình.
Một số người cho rằng nên theo đuổi những công việc ý nghĩa hơn, chẳng hạn như giải quyết các vấn đề biến đổi khí hậu.
Một số người cho rằng việc sử dụng kỹ năng kỹ thuật phần mềm để giúp người khác tìm thấy cuộc sống hạnh phúc hơn gần với mục tiêu của họ hơn là chỉ xây dựng phần mềm.
Một số người cho rằng, mặc dù không phải là sản phẩm mang tính cách mạng, nhưng những phần không phô trương trong cơ sở hạ tầng cũng quan trọng không kém.
Những công việc quan trọng nhất trên thế giới thường bị đánh giá thấp, chẳng hạn như giáo dục, dọn dẹp và chăm sóc.
Một số người cho rằng, phần lớn thời gian của con người là lao động, vì vậy không nên cảm thấy bất mãn khi làm việc trong văn phòng có điều hòa.
Một số người cho rằng, với tư cách là kỹ sư phần mềm, bạn cũng có thể tham gia giải quyết các vấn đề lý thuyết quan trọng.
Một số người cho rằng, sự tò mò là chìa khóa thúc đẩy chúng ta khám phá và hiện thực hóa ý tưởng.
Một số người cho rằng, chúng ta thường bỏ qua giá trị của công việc hàng ngày và khao khát làm một điều gì đó vĩ đại hơn, có tác động lớn hơn.

Các trò chơi chạy nhanh hơn trên SteamOS so với Windows 11, theo thử nghiệm của Ars #

Games run faster on SteamOS than Windows 11, Ars testing finds

https://arstechnica.com/gaming/2025/06/games-run-faster-on-steamos-than-windows-11-ars-testing-finds/

Bài viết này nói về so sánh hiệu năng chơi game giữa SteamOS và Windows 11. Bài viết bắt đầu bằng việc đề cập rằng gần một thập kỷ trước, các thử nghiệm của Ars Technica cho thấy SteamOS hoạt động kém hơn đáng kể so với Windows trên các phiên bản Linux của trò chơi Steam. Tuy nhiên, tình hình hiện tại đã khác, các thử nghiệm của Ars Technica trên Lenovo Legion Go S cho thấy các trò chơi gần đây chạy ở tốc độ khung hình cao hơn trên SteamOS 3.7 so với Windows 11.

Bài viết giải thích thêm rằng, mặc dù người dùng có thể cài đặt Windows trên Steam Deck kể từ khi nó ra mắt vào năm 2022, nhưng Valve không cung cấp hỗ trợ chính thức “Windows on Deck” cho việc sử dụng phần cứng thay thế này. Ngược lại, Lenovo Legion Go S là thiết bị chơi game cầm tay đầu tiên được thiết kế rõ ràng để hoạt động với Windows 11 (phần cứng lần đầu ra mắt vào tháng 1) hoặc SteamOS (phần cứng lần đầu ra mắt vào tháng 5, cùng với phiên bản SteamOS mới được thiết kế cho phần cứng AMD không phải của Valve).

Để kiểm tra tác động của việc lựa chọn hệ điều hành đối với hiệu năng, nhóm thử nghiệm đã bắt đầu với phiên bản SteamOS của Legion Go S (do Lenovo cung cấp) và thử nghiệm năm trò chơi 3D cao cấp được phát hành trong năm năm qua, sử dụng các công cụ benchmark tích hợp và hai mức đồ họa/độ phân giải khác nhau. Sau đó, họ cài đặt Windows 11 trên máy chơi game cầm tay, tải xuống các trình điều khiển (drivers) cập nhật từ trang web hỗ trợ của Lenovo và chạy lại các benchmark tương tự trên Windows thông qua Steam.

Bài viết đề cập rằng, trong quá trình thử nghiệm, Doom: The Dark Ages không thể được thử nghiệm trên Windows do trò chơi báo cáo trình điều khiển đã lỗi thời. Khi điều tra vấn đề này, họ đã tìm ra một phương pháp để thay thế trình điều khiển đồ họa Legion Go chính thức của Lenovo (lần cuối cập nhật vào tháng 1) bằng trình điều khiển tương thích AMD được cập nhật hơn do ASUS phát hành cho ROG Ally (lần cuối cập nhật vào tháng 5). Các trình điều khiển cập nhật này cung cấp một sự tương đồng gần hơn với các trình điều khiển có trong SteamOS, nhưng sẽ không phù hợp với trải nghiệm “khui hộp” của người dùng Legion Go S Windows, những người không gặp thêm rắc rối khi tìm và cài đặt trình điều khiển “không chính thức” từ các nguồn khác.

Bài viết cuối cùng chỉ ra rằng, theo các biểu đồ đi kèm, SteamOS cho thấy sự cải thiện đáng kể về tốc độ khung hình trong bốn trong số năm trò chơi được thử nghiệm. Chỉ có Borderlands 3 hiển thị hiệu năng tương đương trên cả hai hệ điều hành, với Windows có tốc độ khung hình cao hơn một chút trong benchmark của trò chơi đó. Trong một số trò chơi, việc thay đổi hệ điều hành có thể dẫn đến giảm tốc độ khung hình từ 8% đến 36%.

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

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

Hiệu năng chơi game Steam trên Linux là tốt nhất thông qua Proton + Wayland (Niri)
Tốc độ khung hình tổng thể tăng lên sau khi chuyển từ X11/Xfce sang Wayland/Niri
Các phiên bản game Windows chạy thông qua Proton có hiệu năng tốt hơn so với các phiên bản Linux gốc
Người dùng Linux có thiết bị chơi game chuyên dụng có hiệu năng tốt, trong khi người dùng có phần cứng không đủ mạnh phù hợp hơn với Windows
Các studio port game bên thứ ba của Linux có thể không có chất lượng mã cao như mã gốc và nguồn lực phát triển hạn chế
Các khoản đầu tư và tiến bộ của Proton khiến nó ngày càng khó bị các lớp tương thích khác cạnh tranh
Các port mã nguồn được tối ưu hóa tốt có thể nhanh hơn phiên bản Windows chạy thông qua Proton, nhưng không có đủ động lực để chứng minh chi phí và khó khăn
Các game như Factorio và Minecraft có các port Linux nhận được nỗ lực tương đương với các phiên bản Windows
Các game RPG thế giới mở AAA có thể hoạt động tốt hơn trên Proton, ngay cả khi có port Linux gốc
Các phiên bản game Windows được QA trên Windows, có thể gặp phải các nút thắt và trường hợp đặc biệt của Windows API, trong khi Linux Native API có thể có các nút thắt và trường hợp đặc biệt khác
Các studio port Linux bên thứ ba có thể được trả tiền để làm việc trên Proton
Nên tránh sử dụng Proton khi so sánh phiên bản Windows và phiên bản Linux
DXVK giúp một số game chạy tốt hơn trên Windows so với Native
Nên khuyến khích các nhà phát triển biên dịch phiên bản Linux và sử dụng DXVK-Native khi cần thiết
Trình điều khiển Nvidia của Linux có thể khóa card đồ họa ở tần số cơ bản theo mặc định, trong khi trình điều khiển Windows cho phép nó tăng tốc
Một số game có thể không phản hồi khi thực hiện một hành động cụ thể lần đầu tiên, ví dụ: không có hiệu ứng nổ khi ném lựu đạn
Hệ sinh thái desktop Linux không hỗ trợ nhiều tính năng game PC cao cấp, chẳng hạn như HDR, Nvidia GPU, VR, v.v.
Linux không hỗ trợ Nvidia GPU thực tế là Nvidia không hỗ trợ Linux và giữ cho trình điều khiển độc quyền
Nếu Linux thiếu các tính năng cần thiết, thì Linux là không khả thi đối với những người dùng cần các tính năng đó
Cá nhân không mua sản phẩm Nvidia
Linux đang đạt được tiến bộ trong hỗ trợ VR, mặc dù cần một số công việc và giải pháp
Linux sẽ hỗ trợ nhiều tính năng mới, nhưng sẽ luôn có những tính năng mới khác không được hỗ trợ
Tình hình hỗ trợ HDR trên Linux, chẳng hạn như hỗ trợ HDR trên Steam Deck
Hỗ trợ HDR của Nvidia trên Linux vẫn còn vấn đề, trình điều khiển bị sập
Linux không thiếu tính năng, mà là thiếu sự trau chuốt

Các Lưới Điện Vi Mô Năng Lượng Mặt Trời của Puerto Rico Đánh Bại Tình Trạng Mất Điện #

Puerto Rico’s Solar Microgrids Beat Blackout

https://spectrum.ieee.org/puerto-rico-solar-microgrids

Bài viết này kể về cách các microgrid năng lượng mặt trời ở Puerto Rico duy trì nguồn điện trong thời gian mất điện trên toàn đảo. Bài viết bắt đầu bằng việc đề cập rằng vào ngày 16 tháng 4 năm 2024, Puerto Rico đã trải qua tình trạng mất điện trên toàn đảo, nhưng thị trấn Adjuntas, nằm ở vùng núi trung tâm của hòn đảo, nhờ sự kết hợp giữa microgrid thử nghiệm, tấm năng lượng mặt trời và các cơ sở lưu trữ năng lượng, nhiều doanh nghiệp và cư dân đã duy trì được nguồn điện. Trong khi các khu vực khác phải đợi hơn 24 giờ hoặc thậm chí lâu hơn để khôi phục nguồn điện.

Bài viết tiếp tục mô tả một loạt các vấn đề gián đoạn điện mà mạng lưới điện cũ kỹ của Puerto Rico đang phải đối mặt. Những vấn đề này là do hàng thập kỷ quản lý yếu kém và thiếu đầu tư vào cơ sở hạ tầng lưới điện. Cơn bão Maria năm 2017 đã tàn phá lưới điện, khiến Puerto Rico chìm trong bóng tối trong nhiều tháng và gây ra cái chết của gần 3.000 người. Sau cơn bão, Cơ quan Điện lực Puerto Rico (PREPA) đã hợp tác với các tổ chức tư nhân với hy vọng sửa chữa lưới điện. Cơ quan Quản lý Khẩn cấp Liên bang (FEMA) đã trao hơn 20 tỷ đô la Mỹ tiền cứu trợ thiên tai liên bang để cải thiện lưới điện và tăng cường khả năng phục hồi của nó. Tuy nhiên, bộ máy quan liêu và các rào cản chính trị ở Puerto Rico và Hoa Kỳ đại lục đã cản trở phần lớn việc chi tiêu số tiền này.

Bài viết đề cập rằng Bộ Năng lượng Hoa Kỳ có kế hoạch phân bổ lại 365 triệu đô la Mỹ ban đầu dành cho năng lượng mặt trời trên mái nhà cho cơ sở hạ tầng lưới điện chủ yếu dựa vào nhiên liệu hóa thạch của Puerto Rico. Quyết định này đã gây ra sự phản đối mạnh mẽ từ ngành công nghiệp năng lượng mặt trời của Puerto Rico và Hạ nghị sĩ New York Nydia Velazquez. Velazquez cho rằng số tiền này ban đầu được dùng để phục vụ các cộng đồng dễ bị tổn thương trên đảo.

Bất chấp tình hình chính trị hỗn loạn và những khó khăn về nguồn vốn liên bang, sự phát triển rộng rãi của các hệ thống năng lượng mặt trời kết hợp lưu trữ năng lượng trên đảo Puerto Rico vẫn tiếp tục, các hệ thống này được tài trợ tư nhân thông qua cho thuê, vay hoặc thỏa thuận mua bán điện (PPA). Mỗi tháng, có khoảng 4.000 hệ thống năng lượng mặt trời kết hợp lưu trữ pin được đưa vào hoạt động trên đảo, các thiết bị này được kết nối với lưới điện, nhưng cũng có thể hoạt động trong thời gian mất điện.

Bài viết cuối cùng đề cập rằng thị trấn Adjuntas đã áp dụng một phương pháp thử nghiệm hơn. Tổ chức phi lợi nhuận về môi trường địa phương Casa Pueblo của thị trấn đã hợp tác với các nhà nghiên cứu từ Phòng thí nghiệm Quốc gia Oak Ridge thuộc Bộ Năng lượng Hoa Kỳ để phát triển một phương pháp kết nối nhiều microgrid để trao đổi điện lẫn nhau mà không cần kết nối với lưới điện của Puerto Rico. Chiến lược này được gọi là điều phối lưới điện, đảm bảo rằng ngay cả khi lưới điện gặp sự cố, điện vẫn có thể lưu thông giữa các microgrid.

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

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

Ở châu Âu, người ta thường lắp đặt các tấm pin mặt trời nhỏ trên ban công và cắm trực tiếp vào ổ cắm trên tường để sử dụng.
Hoa Kỳ không cho phép sử dụng ổ cắm điện làm đầu vào cho tấm pin mặt trời, nhưng có thể cắm trực tiếp thiết bị điện vào pin.
Hoa Kỳ bắt đầu xuất hiện các hệ thống năng lượng mặt trời tương tự như ở châu Âu, cần thợ điện lắp đặt bảng điều khiển thông minh để ngăn dòng điện trả ngược về lưới.
Hệ thống năng lượng mặt trời ở Hoa Kỳ cần lắp đặt thiết bị ngăn dòng điện trả ngược về lưới.
Bộ vi biến tần năng lượng mặt trời sẽ tự động tắt khi phát hiện không có điện áp đường dây, ngăn dòng điện trả ngược về lưới.
Nếu không có điện áp lưới, bộ biến tần sẽ ngừng cung cấp điện.
Thiết bị năng lượng mặt trời sẽ tắt hoàn toàn khi mất điện, không còn cung cấp điện cho các thiết bị như tủ lạnh, nhưng có thể kết nối trực tiếp thiết bị điện với pin.
Công suất phát điện năng lượng mặt trời rất nhỏ, thường khoảng một kilowatt, công suất này không đáng kể đối với một hộ gia đình bình thường.
Ở một số khu vực pháp lý, việc lắp đặt các thiết bị năng lượng mặt trời trên mái nhà không cần giấy phép xây dựng, nhưng hầu như luôn cần giấy phép điện.
Để tiết kiệm chi phí, đừng mua bộ pin di động mà hãy mua bộ biến tần năng lượng mặt trời tất cả trong một và pin giá đỡ máy chủ.
Cách đơn giản nhất và rẻ nhất (không nối lưới) là nhờ thợ điện thêm một bảng tải quan trọng được cấp nguồn từ đầu ra của bộ biến tần vào bảng điều khiển chính.
Một cách đơn giản hơn là lắp đặt một bộ ngắt mạch năng lượng mặt trời và thiết bị khóa vật lý để cách ly nguồn điện công cộng và bộ ngắt mạch năng lượng mặt trời.
Thay đổi mô hình sử dụng là cốt lõi để giải quyết vấn đề thiếu hụt năng lượng.
Giải pháp đơn giản hơn là không yêu cầu người dùng làm bất cứ điều gì, tự động quay trở lại nguồn điện lưới khi năng lượng mặt trời hoặc pin không đủ.
Thay đổi mô hình sử dụng sẽ làm tăng gánh nặng tâm lý, không thể chấp nhận được đối với hầu hết mọi người.

AlphaGenome: AI để hiểu rõ hơn về bộ gen #

AlphaGenome: AI for better understanding the genome

https://deepmind.google/discover/blog/alphagenome-ai-for-better-understanding-the-genome/

Bài viết này giới thiệu một công cụ trí tuệ nhân tạo (AI) mới có tên là AlphaGenome, được thiết kế để dự đoán một cách toàn diện và chính xác hơn cách các biến thể đơn lẻ hoặc đột biến trong trình tự DNA của con người ảnh hưởng đến một loạt các quá trình sinh học, đặc biệt là những quá trình điều chỉnh gen. Sự phát triển của AlphaGenome được hưởng lợi từ những tiến bộ công nghệ, cho phép mô hình xử lý các trình tự DNA dài và đưa ra các dự đoán có độ phân giải cao.

Mô hình AlphaGenome chấp nhận trình tự DNA dài tới 1 triệu chữ cái (tức là cặp base) làm đầu vào và dự đoán hàng nghìn thuộc tính phân tử, mô tả hoạt động điều chỉnh của nó. Nó cũng có thể đánh giá tác động của các biến thể di truyền hoặc đột biến bằng cách so sánh các dự đoán của trình tự đột biến với trình tự không đột biến. Các thuộc tính được dự đoán bao gồm vị trí bắt đầu và kết thúc của gen trong các loại tế bào và mô khác nhau, vị trí cắt nối, sản lượng RNA và những base DNA nào có thể tiếp cận được, ở gần nhau hoặc được các protein cụ thể liên kết. Dữ liệu huấn luyện có nguồn gốc từ các liên minh công cộng lớn bao gồm ENCODE, GTEx, 4D Nucleome và FANTOM5, những liên minh này đã đo lường các thuộc tính này bằng thực nghiệm, bao gồm các mô hình điều chỉnh gen quan trọng trong hàng trăm loại tế bào và mô của người và chuột.

Bài viết cũng đề cập rằng, để thúc đẩy nghiên cứu khoa học, AlphaGenome sẽ được cung cấp dưới dạng bản xem trước cho mục đích nghiên cứu phi thương mại thông qua AlphaGenome API và có kế hoạch phát hành mô hình này trong tương lai. Các tác giả tin rằng AlphaGenome có thể trở thành một nguồn tài nguyên quý giá cho cộng đồng khoa học, giúp các nhà khoa học hiểu rõ hơn về chức năng bộ gen, sinh học bệnh tật và cuối cùng thúc đẩy những khám phá sinh học mới và phát triển các liệu pháp mới.

AlphaGenome hoạt động bằng cách chấp nhận trình tự DNA dài làm đầu vào, dự đoán nhiều thuộc tính phân tử trong các loại mô và tế bào khác nhau. Hình ảnh động cho thấy AlphaGenome xử lý đầu vào một triệu chữ cái DNA như thế nào và dự đoán các thuộc tính phân tử đa dạng trong các loại mô và tế bào khác nhau. Sự phát triển và ứng dụng của công cụ này báo hiệu một kỷ nguyên khám phá mới trong lĩnh vực bộ gen và các lĩnh vực liên quan, nhờ vào công nghệ AI.

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

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

DeepMind đã làm rất tốt trong nghiên cứu ứng dụng AI có tác động lớn và làm marketing kỹ thuật tốt.
Arc Institute đang cố gắng xây dựng mô phỏng tế bào, có thể giúp ích rất nhiều cho nghiên cứu sinh học.
STATE không phải là mô phỏng, mà là một mô hình đồ thị được huấn luyện để dự đoán các thuộc tính sau khi bị nhiễu.
Điện toán lượng tử có thể giúp tăng tốc AI trong thập kỷ tới, nhưng khó dự đoán.
Mọi người hy vọng xây dựng các mô phỏng xác định thực sự hơn là các mô hình hộp đen không thể hiển thị quy trình làm việc.
DeepMind có thể thành công một phần là do sự hỗ trợ nguồn lực của Google.
Arc Institute đã phát hành một mô hình nhiễu mới, nếu nó có thể vượt qua các chuẩn tuyến tính một cách đáng tin cậy, thì đó sẽ là một bước tiến lớn.
Tiền bạc và nguồn lực chỉ là một phần lý do thành công của DeepMind, có những công ty khác có giá trị tương đương hoặc thậm chí cao hơn nhưng lại không thành công trong việc ứng dụng AI.
Việc mở rộng bộ gen người lên 3.2Gbp có thể tiết lộ những tương tác không thể tưởng tượng được trước đây.
Nhiều vấn đề kỹ thuật hiện tại xoay quanh U-nets và transformers.
Có những công nghệ được áp dụng rộng rãi, chẳng hạn như động cơ nhiệt, điện, nhiên liệu lỏng, bánh răng, thủy tinh, nhựa và máy tính kỹ thuật số, cũng như transformers.
Ý tưởng đặt toàn bộ bộ gen lên blockchain nghe có vẻ mỉa mai, nhưng công nghệ blockchain có thể đóng vai trò trong tương lai.
Google đã đạt được một số tiến bộ trong lĩnh vực sinh học, chẳng hạn như sử dụng exacycle để trình bày kết quả thú vị về gấp và thiết kế protein, đồng thời ra mắt Cloud Genomics để lưu trữ và xử lý các tập dữ liệu lớn để phân tích.
Sundar với tư cách là người lãnh đạo Google còn gây tranh cãi, nhưng lợi nhuận của Google đã tăng trưởng đáng kể dưới sự lãnh đạo của ông.
Chiến lược và khả năng thực thi của Microsoft trong những năm 90 rất xuất sắc, cung cấp các chương trình đào tạo và chứng nhận trên toàn quốc cho các kỹ sư phần mềm và quản trị viên hệ thống trên toàn quốc.

Xây dựng và Lưu trữ Ứng dụng Ứng dụng AI với Claude – Không Cần Triển Khai #

Build and Host AI-Powered Apps with Claude – No Deployment Needed

https://www.anthropic.com/news/claude-powered-artifacts

Hôm nay, chúng tôi giới thiệu khả năng xây dựng, lưu trữ và chia sẻ các ứng dụng tương tác được hỗ trợ bởi AI trực tiếp trong ứng dụng Claude. Giờ đây, các nhà phát triển có thể lặp lại các ứng dụng AI của họ nhanh hơn mà không phải lo lắng về độ phức tạp và chi phí mở rộng.

Xây dựng và lưu trữ các ứng dụng được hỗ trợ bởi Claude Dưới đây là những gì chúng tôi xây dựng: Claude hiện có thể tạo các Artifacts tương tác với Claude thông qua API, biến những Artifacts này thành các ứng dụng được hỗ trợ bởi AI, trong đó mô hình kinh tế thực sự phù hợp để chia sẻ. Khi ai đó sử dụng ứng dụng được hỗ trợ bởi Claude của bạn:

Họ xác thực bằng tài khoản Claude hiện có của họ
Mức sử dụng API của họ được tính vào đăng ký của họ, không phải của bạn
Bạn không phải trả bất kỳ khoản phí nào cho việc sử dụng của họ
Không cần quản lý khóa API Claude viết mã thực tế, điều phối các chức năng AI phức tạp. Bạn có thể xem nó, sửa đổi nó và tự do chia sẻ. Ý tưởng của cộng đồng Người dùng ban đầu đã sử dụng các Artifacts tương tác để xây dựng:
Các trò chơi được hỗ trợ bởi AI với NPC có khả năng ghi nhớ các cuộc hội thoại và thích ứng với lựa chọn của người chơi
Các công cụ học tập điều chỉnh theo trình độ kỹ năng cá nhân và cung cấp hướng dẫn cá nhân hóa
Các ứng dụng phân tích dữ liệu nơi người dùng tải lên tệp CSV và đặt câu hỏi bằng ngôn ngữ tự nhiên
Trợ lý viết lách giúp xử lý mọi thứ, từ kịch bản đến tài liệu kỹ thuật
Quy trình làm việc của Agent điều phối nhiều lệnh gọi Claude để hoàn thành các tác vụ phức tạp

Bắt đầu sử dụng Bắt đầu xây dựng trong ứng dụng Claude bằng cách bật tính năng tương tác mới này. Chỉ cần mô tả những gì bạn muốn tạo và Claude sẽ viết mã cho bạn. Khi bạn làm việc cùng nhau, Claude có thể gỡ lỗi và cải thiện mã của chính mình dựa trên phản hồi của bạn. Khi ứng dụng của bạn đã sẵn sàng, bạn có thể chia sẻ ngay lập tức thông qua một liên kết - không cần quy trình triển khai. Claude chịu trách nhiệm xử lý các chi tiết kỹ thuật, chẳng hạn như prompt engineering, xử lý lỗi và logic điều phối, cho phép bạn hoàn toàn tập trung vào việc biến ý tưởng của mình thành hiện thực.

Bạn có thể làm gì:

Sử dụng Claude API trong Artifacts của bạn
Sử dụng React để xử lý tệp và tạo giao diện người dùng phong phú
Xem, phân nhánh và tùy chỉnh bất kỳ Artifact nào

Hạn chế hiện tại:

Chưa hỗ trợ các lệnh gọi API bên ngoài
Không có bộ nhớ liên tục (persistent storage)
Chỉ giới hạn ở API hoàn thành dựa trên văn bản (text-based completion API)

Tính năng này được cung cấp dưới dạng phiên bản beta cho người dùng gói miễn phí, chuyên nghiệp và tối đa.

HN | Độ nóng: 312 điểm | 136 bình luận | Tác giả: davidbarker #

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

Việc Anthropic thêm hàm window.claude.complete() vào Artifacts và đóng gói nó thành một sản phẩm mới quan trọng là một chiến lược marketing tốt.
Một số người bình luận bày tỏ sự không hài lòng với hành vi không ổn định của LLM (mô hình ngôn ngữ lớn), cho rằng ngay cả khi liên tục tối ưu hóa lời nhắc, vấn đề vẫn tồn tại.
Có ý kiến cho rằng, việc yêu cầu luôn kiểm tra và gỡ lỗi lời nhắc và logic là cần thiết trong các công cụ phân tích, nhưng cách làm này có thể không phải lúc nào cũng hiệu quả.
Trong phần bình luận, có người mỉa mai rằng, nếu lặp đi lặp lại việc nhấn mạnh “luôn đúng, không bao giờ sai” có thể khiến AI hoạt động.
Một bình luận chỉ ra rằng, các LLM khác nhau phản ứng hoàn toàn khác nhau với cùng một lời nhắc, không thể mong đợi chúng luôn đưa ra kết quả đúng.
Một người dùng cho rằng, không nên trộn lẫn thành kiến cá nhân vào cuộc trò chuyện với mô hình AI.
Một người bình luận đề cập rằng, khi hợp tác với mô hình AI, chỉ la hét vào mô hình là vô ích, cần phải sửa lời nhắc hoặc thêm logic truyền thống để đảm bảo hành vi mong muốn.
Có ý kiến cho rằng, LLM tuy mạnh mẽ, nhưng không phải là vạn năng, cần được sử dụng kết hợp với logic truyền thống.
Một người bình luận bày tỏ lo ngại về yêu cầu bao gồm toàn bộ lịch sử hội thoại trong mỗi lời nhắc, cho rằng điều này không thực tế trong các ứng dụng quy mô lớn.
Một người dùng chia sẻ kinh nghiệm của họ về việc sử dụng công nghệ mới để tạo ra các trang web hoặc ứng dụng thú vị, và chỉ ra rằng chi phí vận hành cao của mô hình AI khiến mô hình này không còn khả thi.
Một người bình luận đề cập rằng, tính năng mới của Anthropic cho phép người dùng sử dụng tài khoản Claude của riêng họ, mức sử dụng API được tính vào đăng ký của người dùng, nhà phát triển không phải trả phí, điều này thay đổi mô hình trước đó.
Có ý kiến cho rằng, Anthropic nên cho phép người sáng tạo tính một tỷ lệ phần trăm nhất định dựa trên hạn ngạch sử dụng của người dùng, hoặc cung cấp cho người sáng tạo một số ưu đãi, để cải thiện cơ chế khuyến khích ở đây.
Một người bình luận đề xuất rằng, bằng cách cho phép người dùng chọn tỷ lệ phần trăm thanh toán hoặc đặt tỷ lệ phần trăm thanh toán theo cấp hợp đồng, có thể xử lý các vấn đề thanh toán vi mô.
Có ý kiến cho rằng, việc chạy mô hình cục bộ có thể là một giải pháp tốt, đặc biệt là đối với các dự án nhỏ.
Một người bình luận đề cập rằng, Firebase gần đây đã ra mắt một số API cục bộ thử nghiệm, có thể liên quan đến điều này.
Có ý kiến cho rằng, “tự mang AI” hoặc “cung cấp khóa truy cập API AI của bạn” có thể trở thành tiêu chuẩn cho nhiều dịch vụ/ứng dụng.
Một người bình luận hy vọng sẽ thấy ngày mà các tác nhân cá nhân có thể đại diện cho chúng ta sử dụng các dịch vụ trả phí tạm thời.

Chính sách “không cấm vận bảo mật” của Libxml2 #

Libxml2’s “no security embargoes” policy

https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/

Libxml2 là một trình phân tích cú pháp XML và bộ công cụ, trong 25 năm kể từ khi phát hành lần đầu, nó đã được sử dụng rộng rãi trong các dự án mã nguồn mở, phần mềm thương mại và các ứng dụng của chính phủ, là một ví dụ điển hình về thành công và thất bại của phong trào mã nguồn mở. Mặc dù nhiều tổ chức sẵn sàng sử dụng phần mềm mã nguồn mở, nhưng tương đối ít tổ chức sẵn sàng giúp duy trì các phần mềm này. Điều này đã khiến người bảo trì hiện tại của libxml2 từ chối lệnh cấm vận an ninh và gây ra các cuộc thảo luận về các điều khoản bảo trì của các dự án tự do và mã nguồn mở.

Lịch sử của Libxml2 có thể bắt nguồn từ libxml gốc do Daniel Veillard viết cho dự án GNOME, còn được gọi là gnome-xml. Phiên bản libxml2 tiếp theo do ông phát triển đã được phát hành vào đầu năm 2000 theo giấy phép MIT, mặc dù các ứng dụng GNOME có xu hướng sử dụng giấy phép GPLv2. Vào đầu những năm 2000, Veillard dường như mong muốn những người khác áp dụng libxml2 bên ngoài dự án GNOME. Libxml2 được viết bằng ngôn ngữ C, nhưng cung cấp các liên kết cho nhiều ngôn ngữ như C++, Java, Pascal, Perl, PHP, Python, Ruby, v.v. Nó triển khai một số lượng lớn các tiêu chuẩn và hỗ trợ nhiều hệ điều hành, tuyên bố đã vượt qua tất cả hơn 1800 thử nghiệm trong bộ thử nghiệm OASIS XML. Trên một trang được Internet Archive thu thập vào năm 2004, không có đề cập đến việc xử lý các báo cáo bảo mật khác với báo cáo lỗi, nhưng tình hình lúc đó đơn giản hơn.

Đến cuối những năm 2000, dự án đã trưởng thành và nhịp độ phát hành chậm lại tương ứng. Veillard tiếp tục duy trì dự án, nhưng sự chú ý của ông chủ yếu tập trung vào những nơi khác. Nick Wellnhofer bắt đầu đóng góp thường xuyên cho dự án từ năm 2013, và đến năm 2017, anh đã làm rất nhiều việc cho dự án, cuối cùng đảm nhận phần lớn công việc phát hành, mặc dù Veillard vẫn là người phát hành chính thức. Wellnhofer cũng có những đóng góp tương tự cho dự án liên quan libxslt (bộ xử lý chuyển đổi ngôn ngữ bảng định kiểu mở rộng để chuyển đổi tài liệu XML sang các tài liệu XML khác hoặc HTML, văn bản thuần túy, v.v.).

Vào tháng 4 năm 2021, Stefan Behnel phàn nàn rằng đã gần 18 tháng kể từ lần phát hành libxml2 cuối cùng. Veillard trả lời rằng lý do là ông quá bận và “cần phải hoàn thành một số việc trước khi phát hành”. Những việc này dường như là một bản sửa lỗi bảo mật cho CVE-2021-3541, một lỗ hổng libxml2 có thể dẫn đến từ chối dịch vụ. Việc phát hành libxml2 2.9.11 và 2.9.12 dường như đánh dấu những đóng góp cuối cùng của Veillard cho dự án. Khi Veillard dần rút lui, Wellnhofer trở thành người bảo trì thực tế của libxml2 và libxslt, nhưng ông đã tạm thời từ chức vào tháng 7 năm 2021. Ông đã tài trợ cho công việc của mình thông qua Chrome Vulnerability Reward Program và các dự án khác của Google, nhưng phần thưởng cho nghiên cứu bảo mật đã giảm nhanh chóng và ông không thấy cách nào để có được mức tài trợ tối thiểu nữa.

Vào tháng 1 năm 2022, Wellnhofer thông báo rằng, nhờ khoản quyên góp từ Google, ông có thể tiếp tục công việc bảo trì libxml2 và libxslt cho đến năm 2022. Ông dự định chuyển dự án sang cơ sở hạ tầng của GNOME và khôi phục việc phát hành, đồng thời thiết lập một phương thức tài trợ phát triển libxml2 chính thức. Cuối cùng, ông đã chọn Open Source Collective làm người quản lý tài chính. Cho đến nay, dự án dường như đã nhận được khoản tài trợ khổng lồ 11000 đô la Mỹ, phần lớn trong số đó là dưới hình thức khoản quyên góp 10000 đô la Mỹ từ Google, đây dường như là số tiền mà Wellnhofer nhận được để duy trì libxml2 cho đến năm 2022.

Đến năm 2025, Wellnhofer đã mở một vấn đề trong kho lưu trữ libxml2 GitLab vào ngày 8 tháng 5, công bố chính sách bảo mật mới của dự án. Ông nói rằng ông dành hàng giờ mỗi tuần để xử lý các vấn đề bảo mật, điều này là không bền vững đối với một tình nguyện viên không được trả lương. Ví dụ, và có thể là giọt nước tràn ly, hiện có bốn lỗi được gắn nhãn bảo mật trong trình theo dõi vấn đề libxml2. Ba trong số đó được mở vào ngày 7 tháng 5 bởi Nikita Sveshnikov, một nhà nghiên cứu bảo mật làm việc cho công ty Positive Technologies. Một trong những vấn đề là về báo cáo về việc tham chiếu con trỏ null có thể dẫn đến từ chối dịch vụ. Nó bao gồm một yêu cầu, yêu cầu Wellnhofer cung cấp số CVE cho lỗ hổng và cung cấp thông tin về ngày vá dự kiến. Cần lưu ý rằng cả libxml2 và GNOME đều không phải là cơ quan cấp số CVE (CNAs).

Có thể tranh luận về giá trị của các lỗ hổng do Sveshnikov và các nhà nghiên cứu khác báo cáo. Wellnhofer tin rằng ông đã sửa khoảng 100 lỗi tương tự và không coi loại lỗi này là quan trọng về mặt bảo mật. Ngay cả khi đó là một lỗ hổng bảo mật hợp lệ, thì cũng rõ tại sao nó có thể gây khó chịu cho người bảo trì. Báo cáo không đến từ người dùng của dự án và không có bản vá nào cố gắng sửa lỗi. Đây là một yêu cầu khác đối với một người bảo trì không được trả lương, để công ty nghiên cứu bảo mật có thể khoe khoang về việc khám phá để quảng bá dịch vụ của mình.

Nếu Wellnhofer hành động theo kịch bản dự kiến của người bảo trì, ông sẽ dành hàng giờ để sửa lỗi, liên lạc với nhà nghiên cứu và phát hành phiên bản mới của libxml2. Sveshnikov và Positive Technologies sẽ có thêm một mục nữa trong danh sách CVE của họ, nhưng Wellnhofer nhận được gì từ sự sắp xếp này? Thêm công việc, một CVE không mong muốn và lợi ích thực tế không đáng kể cho người dùng libxml2.

Do đó, Wellnhofer thà không tuân thủ lệnh cấm vận và thời hạn xử lý các bản sửa lỗi bảo mật, mà đối xử với các vấn đề bảo mật như bất kỳ lỗi nào khác; vấn đề sẽ được công khai ngay sau khi báo cáo và sửa chữa. Wellnhofer cũng tuyên bố ông từ chức người bảo trì libxslt và nói rằng nó khó có thể được bảo trì lại. Ông nói, điều này càng khó xảy ra hơn khi các nhà nghiên cứu bảo mật “dán mắt vào cổ các tình nguyện viên”. Việc coi các khiếm khuyết bảo mật là lỗi thông thường có thể khiến một số người dùng hạ nguồn lo lắng, nhưng Wellnhofer hy vọng điều này sẽ khuyến khích nhiều đóng góp hơn.

HN | Độ nóng: 280 điểm | 250 bình luận | Tác giả: jwilk #

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

Định nghĩa về lỗ hổng bảo mật quá rộng, dẫn đến việc khó phát hiện ra các vấn đề rủi ro cao thực sự
Nhiều cái gọi là “lỗ hổng bảo mật” thực tế không phải là vấn đề bảo mật thực sự, ví dụ như tấn công từ chối dịch vụ không dẫn đến thiệt hại tài sản hoặc rò rỉ quyền riêng tư
Một số vấn đề được coi là “lỗ hổng bảo mật”, chẳng hạn như chương trình bị treo, thực tế có thể chỉ là lỗi chương trình thông thường
Người bảo trì phần mềm nên xử lý các lỗi phân bổ bộ nhớ (ví dụ: malloc trả về null), thay vì bỏ qua kết quả
Người bảo trì phần mềm có thể viết hàm bao bọc malloc để chương trình bị treo khi phân bổ thất bại, hoặc truyền lỗi trở lại cho người gọi
Coi hành vi không xác định là vấn đề bảo mật tiềm ẩn là có lý, đặc biệt là trong các tiêu chuẩn C và C++
Theo tiêu chuẩn POSIX, việc tham chiếu đến địa chỉ chưa được ánh xạ sẽ dẫn đến tín hiệu SIGSEGV, nhưng việc tối ưu hóa trình biên dịch thực tế có thể bỏ qua điều này
Tối ưu hóa trình biên dịch có thể giả định con trỏ hợp lệ và bỏ qua khả năng hành vi không xác định, điều này có thể dẫn đến các vấn đề bảo mật
Người báo cáo nên cung cấp các giải pháp sửa chữa cụ thể, thay vì chỉ thông báo cho người bảo trì về sự tồn tại của lỗ hổng
Thái độ của người báo cáo có thể quá quan liêu, khiến người bảo trì không muốn hợp tác giải quyết vấn đề
Người báo cáo có thể quan tâm hơn đến việc nhận CVE-ID để thể hiện khám phá của mình, hơn là thực sự quan tâm đến sự an toàn của phần mềm
Người bảo trì có thể không muốn sửa chữa vấn đề vì thái độ không phù hợp của người báo cáo, ngay cả khi việc sửa chữa tương đối đơn giản

Tỷ lệ giam giữ của Mỹ đang giảm #

America’s incarceration rate is in decline

https://www.theatlantic.com/ideas/archive/2025/06/prisoner-populations-are-plummeting/683310/

Bài viết này thảo luận về vấn đề dân số nhà tù ở Mỹ sắp tới sẽ giảm mạnh. Bài viết chỉ ra rằng, Mỹ từ lâu đã sở hữu một trong những hệ thống nhà tù lớn nhất thế giới, nhưng trong thập kỷ tới, dân số nhà tù có thể giảm đáng kể, thậm chí vượt quá mục tiêu của các nhóm cải cách. Năm 2009, dân số nhà tù ở Mỹ đạt đỉnh hơn 1,6 triệu người, nhưng đến cuối năm 2023, con số này đã giảm xuống còn hơn 1,2 triệu người, và dự kiến sẽ tiếp tục giảm xuống còn khoảng 600.000 người, giảm tổng cộng khoảng 60%.

Bài viết nhấn mạnh rằng, để hiểu được sự sụt giảm dân số nhà tù sắp tới, cần phải hiểu mối quan hệ giữa tội phạm và giam giữ giữa các thế hệ. Thành phần dân số nhà tù phản ánh tình hình từ năm đến hai mươi năm trước, vì hầu hết mọi người bắt đầu sự nghiệp phạm tội của họ ở tuổi thiếu niên hoặc đầu tuổi trưởng thành. Lấy dữ liệu năm 2016 làm ví dụ, một người đàn ông trung bình trong nhà tù tiểu bang đã bị bắt chín lần và hiện đang bị giam giữ lần thứ sáu, đang thụ án 16 năm.

Tác giả của bài viết là Keith Humphreys, giáo sư tâm thần học và khoa học hành vi tại Đại học Stanford, đồng thời là tác giả của cuốn sách “Nghiện: Một giới thiệu rất ngắn gọn” và là thành viên của Mạng lưới Chính sách Nghiện Stanford. Bài viết kết thúc bằng việc đề cập đến chủ đề COVID-19, nhưng không đi sâu vào chi tiết.

HN | Độ nóng: 257 điểm | 498 bình luận | Tác giả: paulpauper #

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

Việc giảm số lượng tội phạm vị thành niên, bị bắt và giam giữ có tác động quan trọng đến hệ thống nhà tù, vì tội phạm trẻ tuổi là nguồn chính của hệ thống này.
Tỷ lệ mang thai ở tuổi vị thành niên cũng đang giảm nhanh chóng do tỷ lệ sinh giảm và độ tuổi trung bình của cha mẹ tăng lên, điều này có thể dẫn đến giảm tội phạm vị thành niên.
Hành vi của những người có con trở nên thận trọng hơn, và cha mẹ có thể có nhiều nguồn lực hơn, điều này có thể có nghĩa là tội phạm vị thành niên giảm.
Việc sinh con trở nên khó khăn hơn khi tuổi tác tăng lên, nhưng khi còn trẻ, mặc dù thiếu nguồn lực tài chính, nhưng lại có nhiều năng lượng hơn.
Việc sinh con ở tuổi 40 có thể khiến bạn phải phụ thuộc vào cha mẹ khi con bạn 15 tuổi, và nếu con bạn học đại học, bạn có thể vẫn phải phụ thuộc vào cha mẹ khi bạn bè cùng trang lứa đã nghỉ hưu.
Cha mẹ 60 tuổi có thể vẫn có thể cạnh tranh về thể chất với cha mẹ 35 tuổi.
Tình trạng thể chất và khả năng thức khuya không tỷ lệ thuận với nhau.
Sau khi có con, đặc biệt là trẻ sơ sinh, bạn sẽ phải thức khuya, nhưng so với việc thức khuya để làm việc, việc chăm sóc con cái dễ dàng hơn.
Sinh con ở tuổi 47, bây giờ con 9 tuổi, cảm thấy mệt mỏi hơn vì công việc chứ không phải vì con cái.
Khi tuổi tác tăng lên, việc duy trì thể trạng tốt đòi hỏi những thói quen tốt và may mắn.
Người lớn tập thể dục vừa phải có tỷ lệ thương tích liên quan đến té ngã thấp hơn khi về già so với những người hầu như không tập thể dục.
Sinh con ở tuổi 45, thể trạng tốt hơn so với tuổi 30, cũng khôn ngoan, kiên nhẫn hơn và tình hình tài chính cũng tốt hơn.
Trách nhiệm chăm sóc con cái và cha mẹ có thể tăng lên khi tuổi tác tăng lên, đồng thời sức khỏe của bản thân cũng suy giảm.
Nếu không có bạn đời ổn định, không cần phải vội vàng sinh con, vì thế giới không cần thêm những người phải vật lộn vì tuổi thơ tồi tệ.
Một người chạy bộ 60 tuổi có thể khó tiếp tục chạy bộ nếu giấc ngủ bị gián đoạn bởi tiếng khóc của trẻ sơ sinh vào ban đêm, cộng với những trách nhiệm mới.
Tập thể dục không phải là ưu tiên hàng đầu trong cuộc sống của một số người, họ có thể coi trọng việc hỗ trợ tài chính cho con cái và gia đình hơn.
Cha mẹ 40 tuổi nếu có thể trạng tốt thì hoàn toàn có thể theo kịp con cái.