2025-07-21 Top Stories #

Dự án XMLUI nhằm mục đích mang mô hình Visual Basic đến hệ sinh thái Web và React hiện đại thông qua việc kết hợp đánh dấu XML với các thành phần React và CSS, đơn giản hóa quy trình phát triển.
Ứng dụng của các mô hình ngôn ngữ lớn (LLMs) trong lập trình đã được cập nhật vào mùa hè năm 2025, có khả năng giúp các nhà phát triển loại bỏ lỗi trong mã, nhanh chóng khám phá ý tưởng và tăng tốc công việc.
Sự trỗi dậy hiện tại của các AI Agent đang đối mặt với những thách thức thực tế trong môi trường sản xuất, một hệ thống Agent thành công nên có ngữ cảnh hạn chế, các thao tác có thể kiểm chứng và khả năng ra quyết định của con người.
Hiện tượng chất lượng sản phẩm giảm sút trong xã hội hiện đại có liên quan đến văn hóa hiệu quả của chủ nghĩa tư bản, sự thay đổi trong sở thích của người tiêu dùng và sự lỗi thời có kế hoạch, người tiêu dùng quan tâm nhiều hơn đến sự tiện lợi và tính mới lạ.
Công ty Ring giới thiệu một tính năng mới cho phép cảnh sát truy cập thời gian thực vào camera của người dùng, gây ra tranh cãi về quyền riêng tư và giám sát, bị chỉ trích là chủ nghĩa chuyên chế công nghệ.
Kiến trúc của các mô hình ngôn ngữ lớn (LLMs) không ngừng phát triển về nhúng vị trí, cơ chế chú ý đa đầu và hàm kích hoạt, nhưng vẫn còn những hạn chế trong việc tạo ra thông tin thực tế.
Việc xây dựng chiến lược sao lưu cần xem xét khả năng chấp nhận rủi ro, phạm vi bảo vệ dữ liệu, thời gian ngừng hoạt động có thể chấp nhận và không gian lưu trữ, snapshot đóng vai trò quan trọng trong việc thực hiện sao lưu nhất quán.
Borrowchecker của Rust là cốt lõi của an toàn bộ nhớ, nhưng trong thực tế có những vấn đề về công thái học, hạn chế quá mức việc viết mã hợp lý.
Thông qua việc trình bày một số đoạn mã Python có vẻ trái trực giác, có thể hiểu sâu hơn về cơ chế hoạt động bên trong và một số đặc tính ít được biết đến của nó.
TSMC có kế hoạch bắt đầu xây dựng bốn nhà máy mới trước cuối năm, đặt mục tiêu đưa vào sản xuất wafer 2 nanomet trước cuối năm 2028, sử dụng công nghệ 1.4 nanomet để cải thiện hiệu suất và giảm tiêu thụ điện năng.

XMLUI #

XMLUI

https://blog.jonudell.net/2025/07/18/introducing-xmlui/

Bài viết này được Jon Udell viết, chủ đề là giới thiệu XMLUI, một dự án nhằm mang mô hình Visual Basic đến với Web hiện đại và hệ sinh thái các thành phần dựa trên React.

Bài viết bắt đầu bằng việc hồi tưởng lại giữa những năm 1990, khi mà ngay cả những người không phải là lập trình viên hàng đầu cũng có thể tạo ra các phần mềm hữu ích thông qua Visual Basic và một hệ sinh thái các thành phần phong phú. Các thành phần này có thể được kết hợp để tạo ra các ứng dụng, cho phép các nhà phát triển không chuyên đứng trên vai các nhà phát triển chuyên nghiệp để phát triển. Tuy nhiên, mô hình này đã không tiếp tục được duy trì trong phát triển Web, vì các Web component không hoạt động theo cách tương tự. Dự án XMLUI ra đời chính là để giải quyết vấn đề này, nó sử dụng các thẻ XML để kết hợp các React component và CSS, cho phép các nhà phát triển tạo ra các ứng dụng hiện đại, có tính đáp ứng cao mà không cần phải hiểu sâu về React hoặc CSS.

Bài viết trình bày sự đơn giản và mạnh mẽ của XMLUI thông qua một ví dụ về một ứng dụng nhỏ kiểm tra trạng thái của các tuyến tàu điện ngầm London. Ứng dụng này chỉ sử dụng hơn chục dòng mã XML để hoàn thành các thao tác như định nghĩa hộp chọn, điền dữ liệu, tạo động URL nguồn dữ liệu, liên kết kết quả vào bảng, v.v. Loại mã này dễ đọc và bảo trì, ngay cả khi không phải do chính nhà phát triển viết ra, nó vẫn có thể được hiểu và bảo trì.

Bài viết tiếp tục thảo luận về khái niệm component, đề cập đến một bài viết mà tác giả đã xuất bản năm 1994 về phần mềm component. Vào thời điểm đó, người ta thường tin rằng động cơ của việc tái sử dụng phần mềm sẽ là các thư viện đối tượng cấp thấp, nhưng cuối cùng điều thu hút sự chú ý lại là các component được xây dựng bởi các nhà phát triển chuyên nghiệp và được sử dụng bởi các nhà phát triển nghiệp vụ. Các Visual Basic component bao gồm các chức năng như biểu đồ, giao tiếp mạng, truy cập dữ liệu, phát lại âm thanh và video và quét/chỉnh sửa hình ảnh, các UI control thì bao gồm các nút, hộp thoại, thanh trượt, lưới, v.v. Các control này được sử dụng để xây dựng nhiều hệ thống nghiệp vụ khác nhau.

Bài viết chỉ ra rằng, mặc dù bản thân tác giả là cố vấn cho dự án XMLUI, nhưng ông vẫn tin rằng XMLUI là một lựa chọn mạnh mẽ có thể thay thế tổ hợp công nghiệp JavaScript, nó đáp ứng tất cả các điều kiện phù hợp. XMLUI cung cấp một danh mục component phong phú, bao gồm tất cả các component tương tác dự kiến cũng như các component nền như DataSource, APICall và Queue. Người dùng có thể dễ dàng định nghĩa các component của riêng mình, các component này có thể tương tác với các component gốc cũng như với nhau.

Bài viết cũng đề cập đến khái niệm component do người dùng định nghĩa và trình bày một đoạn mã cho một component có tên là TubeStops. Component này có thể được sử dụng lại và có thể dễ dàng được sử dụng trong bố cục cạnh nhau. Bài viết nhấn mạnh rằng các đoạn mã ngắn của XMLUI dễ đọc và bảo trì, nhưng nếu số lượng dòng mã tăng lên hàng trăm dòng, tình hình sẽ khác. Tác giả đề cập rằng khi một component trở nên quá lớn, ông sẽ thực hiện tái cấu trúc, điều này liên quan đến chi phí trong bất kỳ môi trường lập trình nào, chẳng hạn như tạo và đặt tên tệp, xác định truyền thuộc tính, v.v. Nhưng với sự trỗi dậy của LLM (mô hình ngôn ngữ lớn), tác giả có thể ủy thác nhóm trợ lý AI của mình để thực hiện tái cấu trúc, khiến nó trở nên trôi chảy và liên tục. LLM không hiểu XMLUI ngay từ đầu, nhưng chúng hiểu XML và với sự trợ giúp của MCP (có thể là một loại công cụ hoặc framework nào đó), chúng có thể hiểu đặc biệt về XMLUI.

Bài viết cuối cùng thảo luận về khái niệm tính đáp ứng, chỉ ra rằng đối với các lập trình viên không chuyên về React, thách thức lớn nhất của tính đáp ứng theo phong cách XMLUI không phải là cần phải học gì, mà là cần phải quên gì. Bài viết trình bày cách đạt được tính đáp ứng thông qua việc khai báo thuộc tính và nhúng tham chiếu thông qua một ví dụ ứng dụng. Tác giả đề cập rằng mô hình này được gọi là liên kết dữ liệu phản ứng, tương tự như sự thay đổi trong một ô của bảng tính sẽ lan truyền đến các ô khác tham chiếu đến nó. React là một framework phức tạp mà chỉ các lập trình viên chuyên gia mới có thể làm chủ, nhưng may mắn thay, các lập trình viên chuyên gia xây dựng XMLUI đã hoàn thành công việc này cho bạn. Với tư cách là nhà phát triển XMLUI, có thể cần phải từ bỏ các thói quen mệnh lệnh để thích ứng với quy trình khai báo. Tác giả cũng đề cập đến một số bất ngờ có thể gặp phải khi sử dụng XMLUI, chẳng hạn như chức năng tìm kiếm trong ứng dụng demo XMLUI Invoice, nó cho thấy rằng không cần nút tìm kiếm, DataSource URL có thể phản hồi trực tiếp với việc nhập liệu trong hộp văn bản và bảng có thể phản ứng khi DataSource được làm mới.

HN | Độ nóng: 419 điểm | 214 bình luận | Tác giả: mpweiher #

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

Bài viết của Jon Udell đề cập rằng React thống trị các Web component, nhưng không phải tất cả các nhà phát triển đều có thể sử dụng nó, đặc biệt là những người đã từng có thể sử dụng các Visual Basic component.
Có người ủng hộ XMLUI, cho rằng nó có thể giúp những người đã từng sử dụng các Visual Basic component.
Có người đề cập rằng code hiện tại chỉ có thể chạy trên các trình duyệt hiện đại hỗ trợ JavaScript, tương tự như VB chỉ có thể chạy trên Windows.
Có người cho rằng nền tảng Windows hẹp hơn trình duyệt JavaScript hiện đại và tầm quan trọng của nền tảng Windows đang giảm.
Có người đề cập đã thử các công nghệ tương tự như Polymer và Adobe Flex, nhưng thấy rằng trừu tượng hóa markup không bằng các giải pháp ưu tiên code, như JSX.
Có người bày tỏ sự ngưỡng mộ đối với khái niệm Walt Whitman mà Jon Udell đã đề cập.
Có người so sánh XMLUI với các file .ui của Qt, cho rằng XML có ý nghĩa đối với việc định nghĩa UI.
Có người đề cập đến hiệu suất của Qt trong thế giới không phải Linux, đặc biệt là trên macOS.
Có người đề cập rằng trình khởi chạy game Blizzard sử dụng Qt và hỏi liệu có dự án Qt xuất sắc nào khác không.
Có người đề cập rằng JUCE là phương pháp GUI tốt nhất, vì nó coi mỗi phần tử UI là một lớp C++.
Có người hoài niệm về những ngày mà mọi thứ trong Qt đều là lớp C++, cho rằng ngôn ngữ template không trực quan bằng lớp C++.
Có người đề cập đến sự so sánh giữa JUCE và XMLUI, cho rằng chúng lần lượt đại diện cho các phương pháp UI mệnh lệnh và khai báo.
Có người đề cập rằng JUCE cung cấp toàn quyền kiểm soát và triển khai rõ ràng, trong khi các phương pháp khai báo luôn cần đến lối thoát hiểm.
Có người đề cập đến việc chuyển sang JUCE như một môi trường phát triển ứng dụng đa nền tảng GUI/hiệu năng cao, và cho rằng nó không cần quá nhiều cấu hình CMake.

Lập trình với LLM vào mùa hè năm 2025 – một bản cập nhật #

Coding with LLMs in the summer of 2025 – an update

https://antirez.com/news/154

Bài viết này được viết bởi tác giả antirez, chủ đề là về việc sử dụng các mô hình ngôn ngữ lớn (LLMs) tiên tiến để lập trình vào mùa hè năm 2025. Bài viết thảo luận về cách tận dụng LLMs để mở rộng và tăng cường khả năng của lập trình viên, đồng thời chia sẻ một số ví dụ ứng dụng và đề xuất cụ thể.

Loại bỏ lỗi trong code: Tác giả thông qua việc sử dụng Gemini 2.5 PRO và Claude cùng các LLMs khác để kiểm tra code, có thể loại bỏ lỗi trước khi code gây ảnh hưởng đến người dùng. Lấy ví dụ về việc triển khai Vector Sets của Redis, nhiều lỗi đã được loại bỏ ngay lập tức thông qua LLMs.
Nhanh chóng khám phá ý tưởng: LLMs có thể giúp nhanh chóng kiểm tra xem một ý tưởng có khả thi hay không, bằng cách viết code tạm thời để xem giải pháp có hiệu suất tốt hơn, có đủ tốt hay không, v.v.
Thiết kế cộng tác: LLMs có thể kết hợp với trực giác, kinh nghiệm và gu thẩm mỹ thiết kế của con người, đưa ra một số hướng đi ngớ ngẩn hoặc những ý tưởng rất thông minh. Vai trò của con người là tránh rơi vào các giá trị cực tiểu cục bộ và sai lầm, đồng thời tận dụng kiến thức của LLMs.
Tăng tốc công việc: Thông qua việc viết một phần code theo các đặc tả rõ ràng, LLMs có thể tăng tốc quá trình làm việc.
Mở rộng kỹ thuật: Ngay cả trong các lĩnh vực kỹ thuật mà con người không quen thuộc, LLMs cũng có thể đóng vai trò là sự mở rộng kiến thức, giúp hoàn thành các nhiệm vụ coding.

Bài viết cũng đề cập rằng, một năm rưỡi trước, tác giả đã viết một blog về LLMs và lập trình vào đầu năm 2024, khi đó cho rằng LLMs đã rất hữu ích, nhưng trong 1,5 năm qua, sự tiến bộ của LLMs đã thay đổi hoàn toàn cuộc chơi. Tuy nhiên, để tận dụng tối đa khả năng của LLMs, con người tương tác với LLMs phải có những đặc điểm nhất định và tuân theo một số thực hành.

Từ chối mã hóa không khí trong phần lớn thời gian #

LLMs là những công cụ khuếch đại tốt, nhưng không phải là những người độc tấu giỏi. Mặc dù LLMs có thể viết thành công các phần của cơ sở mã (dưới sự giám sát chặt chẽ) và tăng tốc đáng kể tốc độ phát triển, nhưng khi đối mặt với các mục tiêu không tầm thường, chúng có xu hướng tạo ra các cơ sở mã mong manh, phức tạp và chứa đầy các lựa chọn cực tiểu cục bộ. Hơn nữa, khi độ phức tạp của nhiệm vụ vượt quá một mức nhất định, chúng sẽ hoàn toàn thất bại. Tác giả nhấn mạnh rằng hiện tại, sự kết hợp giữa con người + LLMs có thể đạt được chất lượng công việc cao nhất, nhưng điều này đòi hỏi con người phải có khả năng giao tiếp hiệu quả và kinh nghiệm với LLMs.

Cung cấp nhiều ngữ cảnh #

Khi mục tiêu là thảo luận với LLMs về việc triển khai hoặc sửa lỗi code, cần cung cấp cho LLMs một lượng lớn thông tin, bao gồm các bài báo, phần lớn code base mục tiêu (nếu có thể, là toàn bộ code base), và tất cả những hiểu biết về thao tác cần thiết. Điều này bao gồm các gợi ý về các giải pháp có vẻ tốt nhưng thực tế lại không tối ưu, cũng như các gợi ý về các giải pháp tiềm năng ngay cả khi con người chưa trình bày đầy đủ. LLMs đôi khi có thể tận dụng những điều này để tìm ra con đường đúng đắn.

Sử dụng đúng LLMs #

Tác giả khuyến nghị chủ yếu sử dụng Gemini 2.5 PRO và Claude Opus 4 cho các hoạt động lập trình. Gemini 2.5 PRO mạnh mẽ hơn về mặt ngữ nghĩa, có khả năng phát hiện các lỗi phức tạp hơn và suy luận các vấn đề phức tạp hơn. Claude Opus đôi khi có thể tốt hơn trong việc viết mã mới (đôi khi không), giao diện người dùng dễ chịu hơn và thường cần ít nhất hai LLMs xử lý qua lại các vấn đề phức tạp để mở rộng sự hiểu biết của con người về không gian thiết kế.

Kết luận #

Mặc dù mọi người quan tâm đến các tác nhân có khả năng tự lập trình, nhưng hiện tại, việc sử dụng rõ ràng LLMs và duy trì sự kiểm soát sẽ tối đa hóa tác động của các nhà phát triển phần mềm. Khi AI được cải thiện, nhiều tác vụ mã hóa cuối cùng sẽ được AI thực hiện tốt hơn một cách độc lập, và con người sẽ quyết định làm gì và làm như thế nào, điều này vẫn rất quan trọng. Nhưng hiện tại, quyền kiểm soát cho phép bạn sử dụng LLMs để tạo ra mã sắc bén nhất: tối thiểu khi cần thiết, sử dụng các ý tưởng phức tạp khi cần thiết. Bạn sẽ có thể làm những việc nằm ngoài ranh giới kiến thức/chuyên môn của bạn, đồng thời học được rất nhiều điều trong quá trình này (vâng, bạn có thể học hỏi từ LLMs, giống như bạn có thể học hỏi từ sách hoặc đồng nghiệp: đây là một trong những hình thức giáo dục khả thi, là một hình thức mới). Tuy nhiên, tất cả những gì được tạo ra sẽ tuân theo triết lý của bạn về mã và sản phẩm, đồng thời sẽ có chất lượng cao và không bị lỗi ngẫu nhiên do các lỗi và khuyết điểm mà LLMs gây ra. Bạn cũng sẽ giữ lại sự hiểu biết sâu sắc về tất cả mã được viết và thiết kế của nó. Thỉnh thoảng, việc kiểm tra xem các tác nhân có thể làm gì là điều khôn ngoan. Nhưng mỗi khi bạn cảm thấy chúng làm không tốt bằng bạn, hãy quay lại thiết bị đầu cuối của bạn và mã hóa với sự trợ giúp của AI (khi bạn cảm thấy nó có thể cải thiện đầu ra của bạn; đôi khi bạn tự làm tốt hơn). Khi các tác nhân có thể làm việc xuất sắc, tác giả sẽ là người đầu tiên chuyển đổi và sẽ chỉ tự mã hóa vì đam mê. Nhưng bây giờ, hãy bỏ qua sự cường điệu và sử dụng AI một cách tốt nhất, đó là: duy trì quyền kiểm soát. Tuy nhiên, còn có một rủi ro khác: tránh LLMs do ý thức hệ hoặc sự từ chối về mặt tâm lý, tích lũy bất lợi (và không phát triển được một bộ kỹ năng khó mô tả cần thiết để hợp tác với LLMs). Có lẽ đây thực sự là một trường hợp “con đường trung dung”.

HN | Độ nóng: 386 điểm | 266 bình luận | Tác giả: antirez #

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

Lập trình viên không nên phụ thuộc vào các mô hình LLM trả phí của bên thứ ba để lập trình, vì điều này sẽ làm tăng sự phụ thuộc mạnh mẽ vào bên thứ ba.
Thay đổi mô hình LLM rất đơn giản, người dùng có thể dễ dàng chuyển đổi giữa các LLM khác nhau khi cần.
Các mô hình chạy cục bộ không tốt bằng các mô hình trên đám mây và chi phí vận hành cao hơn.
Một khi có thể chạy cục bộ các mô hình tương tự như Claude 4 một cách kinh tế, sẽ có nhiều người chọn làm như vậy hơn.
Framework Desktop có thể không phải là lựa chọn tốt nhất để chạy LLM, vì băng thông bộ nhớ của nó rất thấp.
Mục đích trò chuyện có thể phù hợp để sử dụng LLM cục bộ, nhưng lập trình cần tốc độ nhanh hơn và trí thông minh mô hình tiên tiến hơn.
Đối với LLM, việc đăng ký mô hình trả phí có chi phí thấp so với thời gian làm việc.
Ngay cả khi không chạy LLM cục bộ, bạn vẫn có thể tránh bị khóa bằng cách sử dụng nhà cung cấp dịch vụ đám mây.
LLM trả phí hoạt động tốt hơn trong một số tác vụ nhất định, đặc biệt khi người dùng muốn cung cấp số lượng gợi ý tối thiểu.
Một số người cho rằng, sử dụng dung lượng GPU thuê để chạy LLM miễn phí có thể là một cách hay.
Định luật Moore đã chết, chúng ta có thể lại phải đối mặt với những giới hạn vật lý mở rộng, việc chạy cục bộ các mô hình tương tự như Claude 4 đối với người tiêu dùng bình thường là khó có thể xảy ra trong thời gian ngắn.

Sự cường điệu hiện tại xung quanh các autonomous agent (tác nhân tự động), và những gì thực sự hoạt động trong môi trường production #

The current hype around autonomous agents, and what actually works in production

https://utkarshkanwat.com/writing/betting-against-agents/

Bài viết này được Utkarsh Kanwat đăng vào ngày 19 tháng 7 năm 2025, với tiêu đề “Tại sao tôi đặt cược chống lại các AI Agent vào năm 2025 (mặc dù tôi đang xây dựng chúng)”. Trong bài viết, tác giả chia sẻ quan điểm của mình về sự cường điệu hiện tại đối với các AI Agent, mặc dù bản thân anh đã xây dựng hơn 12 hệ thống agent hoạt động thực tế trong môi trường sản xuất trong năm qua.

Mở đầu bài viết, tác giả đề cập đến những dự đoán và thổi phồng về việc AI Agent sẽ thay đổi công việc vào năm 2025, nhưng thông qua kinh nghiệm thực tế của mình, anh cho rằng những dự đoán này bỏ qua một số thực tế quan trọng. Tác giả không đặt câu hỏi về AI từ góc độ của một người ngoài cuộc, mà đưa ra quan điểm của mình thông qua kinh nghiệm xây dựng nhiều hệ thống agent sản xuất.

Quan điểm cốt lõi của bài viết có thể được tóm tắt thành ba sự thật hiển nhiên về AI Agent:

Trong quy trình làm việc nhiều bước, tỷ lệ lỗi tích lũy theo cấp số nhân. Ngay cả khi độ tin cậy của mỗi bước đạt 95%, tỷ lệ thành công tổng thể sau 20 bước chỉ là 36%, trong khi môi trường sản xuất yêu cầu độ tin cậy trên 99,9%.
Cửa sổ ngữ cảnh dẫn đến chi phí token tăng theo hàm bậc hai. Khi độ dài hội thoại tăng lên, chi phí của các agent hội thoại trở nên quá cao.
Thách thức thực sự không phải là khả năng của AI, mà là thiết kế các công cụ và hệ thống phản hồi mà agent có thể sử dụng hiệu quả.

Tác giả giải thích chi tiết thực tế toán học về sự tích lũy lỗi trong quy trình làm việc của AI Agent, chỉ ra rằng ngay cả khi độ tin cậy của mỗi bước đạt 99%, tỷ lệ thành công tổng thể sau 20 bước chỉ là 82%. Anh nhấn mạnh rằng đây không phải là vấn đề về kỹ thuật prompt, cũng không phải là vấn đề về khả năng của mô hình, mà là thực tế toán học.

Khi thảo luận về vấn đề kinh tế token, tác giả chỉ ra rằng khi xây dựng các agent “đàm thoại”, mỗi tương tác mới đều cần xử lý tất cả ngữ cảnh trước đó, chi phí token tăng theo hàm bậc hai khi độ dài hội thoại tăng lên, dẫn đến không khả thi về mặt kinh tế.

Bài viết cũng đề cập đến các vấn đề thực tế về kỹ thuật công cụ, ngay cả khi các vấn đề toán học được giải quyết, việc xây dựng các công cụ cấp sản xuất là một ngành kỹ thuật hoàn toàn khác mà hầu hết các nhóm đều đánh giá thấp. Tác giả nhấn mạnh rằng thiết kế công cụ cần được chế tạo cẩn thận để cung cấp phản hồi chính xác mà không vượt quá cửa sổ ngữ cảnh.

Cuối cùng, tác giả thảo luận về các vấn đề tích hợp với thế giới thực, chỉ ra rằng các hệ thống doanh nghiệp không phải là các API sạch sẽ đang chờ AI Agent điều phối, mà là các hệ thống kế thừa với những đặc điểm kỳ quặc, các chế độ lỗi một phần, các thay đổi quy trình xác thực, giới hạn tốc độ trong các khoảng thời gian khác nhau và các yêu cầu tuân thủ.

Trong phần kết luận, tác giả đưa ra phương pháp mà anh cho là hiệu quả trên thực tế, đó là xây dựng các hệ thống agent có ngữ cảnh giới hạn, các thao tác có thể kiểm chứng và đôi khi cần quyết định của con người tại các điểm quan trọng. Anh nhấn mạnh rằng các hệ thống agent thành công không phải là đàm thoại, mà là các công cụ thông minh, giới hạn, có khả năng hoàn thành một nhiệm vụ một cách hiệu quả và thoát ra. Tác giả cho rằng, công việc thực tế của AI Agent trong môi trường sản xuất chỉ chiếm 30%, 70% còn lại là kỹ thuật công cụ, bao gồm thiết kế giao diện phản hồi, quản lý ngữ cảnh hiệu quả, xử lý các lỗi một phần và xây dựng các cơ chế khôi phục mà AI có thể hiểu và sử dụng.

HN | Độ nóng: 366 điểm | 212 bình luận | Tác giả: Dachande663 #

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

Kỹ sư AI của Amazon cho biết, không có công ty nào hoàn toàn dựa vào AI tạo sinh để trò chuyện với khách hàng, vì độ tin cậy của nó không đủ.
Một số công ty công nghệ đã bắt đầu sử dụng AI tạo sinh để hỗ trợ trò chuyện trực tiếp, như Sonder và Wealthsimple.
Có trường hợp cho thấy, chatbot AI của Air Canada đã đưa ra quy trình yêu cầu bồi thường sai, dẫn đến việc khách hàng kiện và thua kiện.
Mọi người có thể cố gắng “hack” chatbot AI để lấy được những phản hồi kỳ lạ, sau đó đăng lên mạng để làm tổn hại hình ảnh công ty.
Có người đề xuất, biến các mô hình ngôn ngữ lớn (LLM) thành robot chuyển tiếp FAQ là một thủ thuật kỹ thuật, nhưng lại làm mất đi ý nghĩa của việc sử dụng LLM.
Con người có một cửa sổ ngữ cảnh lớn hơn khi giải quyết các vấn đề chuyên môn, trong khi mô hình có thể khắc phục các hạn chế về ngữ cảnh thông qua bộ dữ liệu huấn luyện lớn hơn và đa dạng hơn.
Con người không có sự phân chia cố định giữa “ngữ cảnh” và “trọng số”, những gì chúng ta thấy và làm đều sửa đổi “trọng số” của chúng ta.
Con người thay đổi hàng ngày trong việc sử dụng ngôn ngữ tự nhiên, trong khi LLM không thể làm được điều này.
LLM có thể không hiệu quả bằng lập trình trực tiếp trong các tác vụ cụ thể.
Sự phân chia “ngữ cảnh” và “trọng số” của con người không rõ ràng như LLM, trí nhớ dài hạn gần giống với ngữ cảnh hơn.
Mọi người thường đạt đến giới hạn “cửa sổ ngữ cảnh” của mình khi giải quyết các vấn đề phức tạp.
Tính cách của con người là sản phẩm của nhiều năm kinh nghiệm, điều này có thể được xem như là cửa sổ ngữ cảnh lớn mà con người có trong các khía cạnh xã hội.
Kinh nghiệm sử dụng các công cụ AI trong công việc nói chung là tích cực, nhưng chi phí tích lũy nhanh chóng.
Có người cho rằng khả năng tự sửa lỗi và cửa sổ ngữ cảnh lớn của LLM phù hợp với mô hình kinh doanh tính phí theo token.
Có người đề xuất ý tưởng tạo nhiều bản nháp bằng AI, sau đó lọc thủ công và tự động để tinh chỉnh.

Hiện tượng đáng kinh ngạc về sự suy giảm chất lượng #

The bewildering phenomenon of declining quality

https://english.elpais.com/culture/2025-07-20/the-bewildering-phenomenon-of-declining-quality.html

Bài viết này khám phá hiện tượng chất lượng sản phẩm suy giảm trong xã hội hiện đại. Bài viết mở đầu bằng việc mô tả một cảm giác phổ biến, đó là chất lượng đang giảm sút từ ghế máy bay, quần áo đến thực phẩm và đồ điện tử, dường như không còn ai quan tâm đến độ bền và tay nghề của sản phẩm. Nhà nghiên cứu E. Scott Maynes trong nghiên cứu năm 1976 của mình đã đưa ra rằng chất lượng là một khái niệm chủ quan, phụ thuộc vào sở thích của người tiêu dùng. Do đó, không thể tuyệt đối nói rằng iPhone 15 có chất lượng tốt hơn điện thoại Nokia năm 2003. Đối với một số người tiêu dùng, độ bền của Nokia có thể có giá trị hơn sự đổi mới công nghệ của iPhone.

Bài viết tiếp tục trích dẫn quan điểm của Javier Carbonell, Phó Giám đốc Phòng thí nghiệm Chính sách Tương lai, ông cho rằng tâm lý bi quan phổ biến khiến mọi người cảm thấy mọi thứ đều không tốt như trước đây. Tâm lý này ảnh hưởng đến đánh giá của chúng ta về các chính sách và hàng tiêu dùng. Carbonell chỉ ra rằng lời hứa chính của chủ nghĩa tư bản - nếu bạn làm việc, bạn có thể sống một cuộc sống tử tế - đã không còn được thực hiện, các bậc thang xã hội đã bị phá vỡ. Ảnh hưởng của mạng xã hội cũng làm trầm trọng thêm tâm lý này, nó cho thấy một cuộc sống mà hầu hết mọi người không thể đạt được.

Bài viết đề cập đến việc “văn hóa thắt lưng buộc bụng” xuất hiện sau cuộc Đại suy thoái đã bị thay thế bởi “văn hóa hiệu quả”, được đại diện bởi Elon Musk, người ủng hộ mô hình tối thiểu hóa chi phí. Mô hình này lần đầu tiên được thực hiện tại công ty X (trước đây là Twitter), sau đó cũng được thể hiện trong chính phủ Hoa Kỳ. Mark Zuckerberg cũng gọi năm 2023 là “Năm hiệu quả” và tiến hành cắt giảm nhân sự quy mô lớn tại Meta. Các công ty như Amazon cũng đang dần thay thế nhân công bằng robot và hệ thống tự động hóa, đến mức một số nhà kho thậm chí không cần bật đèn.

Trong lĩnh vực dịch vụ công, tình hình có sự khác biệt. Bài viết chỉ ra rằng từ năm 2017 đến năm 2022, số lượng người có bảo hiểm tư nhân tăng 4% mỗi năm. Theo báo cáo “Hệ thống chăm sóc sức khỏe: Tình trạng hiện tại và triển vọng tương lai” được công bố năm 2024, lý do chính khiến người Tây Ban Nha chuyển sang hệ thống chăm sóc sức khỏe tư nhân là do danh sách chờ đợi vô tận của hệ thống chăm sóc sức khỏe công cộng.

Bài viết cũng thảo luận về sự thay đổi trong nhận thức của mọi người về chất lượng, đặc biệt là ở người lớn tuổi. Các thuộc tính như độ bền không còn là yếu tố chính để mọi người đánh giá chất lượng sản phẩm. Nhà tâm lý học Albert Vinyals đề cập rằng trước đây quảng cáo ô tô chủ yếu nhấn mạnh đến độ bền của nó, nhưng bây giờ chúng ta thậm chí không còn xem xét điều đó nữa. Ngành dệt may thể hiện một cách hoàn hảo sự thay đổi trong mô hình tiêu dùng. Trong 20 năm qua, sản lượng hàng dệt may đã tăng gấp đôi. Ở Tây Ban Nha, ước tính mỗi công dân thải bỏ khoảng 21 kg quần áo mỗi năm. Sở thích của người tiêu dùng đối với sự mới lạ hơn là độ bền đã dẫn đến sự khác biệt thế hệ trong cách hiểu về chất lượng.

Bài viết cuối cùng đề cập đến các khái niệm “lỗi thời có kế hoạch” và “lỗi thời cảm nhận”. Một số công ty thiết kế các sản phẩm sẽ ngừng hoạt động sau một thời gian nhất định, đây không phải là thuyết âm mưu mà là sự thật. Nhưng một phương pháp hiệu quả hơn là thuyết phục người tiêu dùng rằng ngay cả khi sản phẩm vẫn hoạt động, nó sẽ trở nên lỗi thời vì lý do thẩm mỹ hoặc tượng trưng. Ví dụ, những người trẻ tuổi có thể từ chối thuê một căn hộ vì đồ đạc đã lỗi thời, mặc dù vật liệu của những đồ đạc này bền và chắc chắn hơn đồ nội thất IKEA mà cuối cùng họ mua. Quảng cáo và thông điệp tiềm thức đã biến con người thành những thây ma tiêu dùng không có mục tiêu nào khác. Vinyals đặt câu hỏi, tại sao chúng ta chọn mua cà chua không vị trong siêu thị 24 giờ thay vì đến chợ hoặc quầy trái cây. Tại sao chúng ta sẵn sàng trả 3 đô la cho một hộp nước trái cây thay vì tự ép nước cam, mặc dù chúng ta biết phiên bản công nghiệp được làm từ nước ép cô đặc. “Ví dụ điển hình nhất về việc mua sự tiện lợi là trả khoảng 75 euro mỗi kg cho cà phê viên nén.”

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

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

Chất lượng sản phẩm giảm sút là do sau khi thị trường bão hòa, người ta liên tục cắt giảm chi phí để theo đuổi tăng trưởng lợi nhuận.
Trong trường hợp không có tăng trưởng thị phần hoặc đổi mới giảm chi phí, chiến lược tối đa hóa lợi nhuận duy nhất là cung cấp các sản phẩm chất lượng ngày càng thấp hơn, đồng thời giá cả ngày càng cao hơn.
Tiến bộ kỹ thuật và đổi mới có thể nâng cao chất lượng sản phẩm, nhưng khi sự đổi mới đạt đến giới hạn, chất lượng sản phẩm sẽ giảm sút.
Tăng trưởng như một mục tiêu chính thực sự có thể thúc đẩy sự đổi mới, cho đến khi lợi nhuận từ đổi mới giảm đi, sau đó các sản phẩm ngày càng kém chất lượng sẽ được sản xuất.
Chủ nghĩa tư bản Mỹ lấy tăng trưởng làm mục tiêu chính, điều này vẫn đang đổi mới ở một số lĩnh vực, nhưng ở những lĩnh vực khác lại sản xuất ra ngày càng nhiều sản phẩm kém chất lượng.
Các phương thức thực hiện khác nhau của chủ nghĩa tư bản và không có hệ thống nào phù hợp với tất cả, cần phải dựa vào tình hình cụ thể.
Mọi người thường gắn bó với một phương pháp nào đó vì thành công trong quá khứ, ngay cả khi nó bắt đầu gây hại, giống như một người nghiện rượu phụ thuộc vào rượu.
Mọi người tuyên bố rằng họ muốn sản phẩm chất lượng cao, nhưng trên thực tế họ mua sản phẩm rẻ nhất.
Trên thị trường thường không có sản phẩm chất lượng thực sự, và nhiều người sẵn sàng trả giá cao hơn cho những sản phẩm thực sự bền và có thể sửa chữa được.

Ring giới thiệu tính năng mới cho phép cảnh sát truy cập trực tiếp vào camera #

Ring introducing new feature to allow police to live-stream access to cameras

https://www.eff.org/deeplinks/2025/07/amazon-ring-cashes-techno-authoritarianism-and-mass-surveillance

Bài viết này thảo luận về những hành vi gây tranh cãi của Ring, một công ty con của Amazon, trong lĩnh vực chuyên chế công nghệ và giám sát hàng loạt. Bài viết được Matthew Guariglia viết vào ngày 18 tháng 7 năm 2025, và được đăng trên blog Deep Links của Electronic Frontier Foundation (EFF).

Bài viết bắt đầu bằng việc chỉ ra rằng người sáng lập Ring, Jamie Siminoff, đã nắm quyền trở lại công ty chuông cửa có camera giám sát này, và mang trở lại một văn hóa công ty ưu tiên giám sát hơn quyền riêng tư, điều này đã khiến Ring trở thành một trong những thiết bị công nghệ gây tranh cãi nhất. Công ty Ring không chỉ tái tung ra tính năng cũ cho phép cảnh sát trực tiếp yêu cầu các đoạn video từ người dùng Ring, mà còn giới thiệu một tính năng mới cho phép cảnh sát yêu cầu truy cập trực tiếp vào các thiết bị an ninh gia đình của mọi người.

Bài viết cho rằng đây là một bước đi tồi tệ đối với Ring và công chúng nói chung. Ring đang đảo ngược nhiều cải cách đã thực hiện trong vài năm qua, bằng cách đơn giản hóa con đường để cảnh sát có được các đoạn video từ hàng triệu hộ gia đình ở Mỹ, điều này gây ra mối đe dọa nghiêm trọng đối với quyền tự do dân sự ở Mỹ. Cảnh sát đã sử dụng video của Ring để giám sát người biểu tình và lấy video mà không cần lệnh khám xét hoặc sự đồng ý của người dùng. Có thể tưởng tượng rằng các quan chức thực thi pháp luật sẽ lợi dụng quyền truy cập mới của họ vào thông tin Ring để tìm kiếm những người đã phá thai hoặc theo dõi người nhập cư.

Trong một bản ghi nhớ, Siminoff tuyên bố rằng công ty sẽ được tái cấu trúc thành “ưu tiên AI”, mặc dù điều này có nghĩa là gì đối với một camera an ninh gia đình cho phép bạn nhìn thấy ai đang bấm chuông cửa nhà bạn vẫn chưa rõ ràng. EFF lo ngại rằng điều này có thể báo hiệu sự ra đời của công nghệ phân tích video hoặc nhận dạng khuôn mặt, điều này sẽ làm trầm trọng thêm những vấn đề vốn đã tồn tại của Ring.

Bài viết cũng đề cập rằng nhân viên của Ring phải chứng minh việc họ sử dụng AI để được thăng chức. Ring có kế hoạch tung ra các tính năng xấu mới, đồng thời đảo ngược một số cải cách cần thiết, chẳng hạn như hợp tác với Axon để xây dựng một công cụ mới cho phép cảnh sát trực tiếp yêu cầu các đoạn video Ring từ người dùng và cho phép người dùng đồng ý để cảnh sát phát trực tiếp từ thiết bị của họ.

Sau nhiều năm phục vụ như con mắt và đôi tai của cảnh sát, công ty Ring đã thực hiện một số thay đổi cần thiết dưới áp lực của công chúng. Họ đã giới thiệu mã hóa đầu cuối, chấm dứt hợp tác chính thức với cảnh sát và chấm dứt công cụ tạo điều kiện cho cảnh sát trực tiếp yêu cầu các đoạn video từ khách hàng. Giờ đây, họ đang chuyển sang trở thành một công cụ giám sát hàng loạt.

Bài viết đặt câu hỏi tại sao sự thay đổi này lại xảy ra vào lúc này, chỉ ra rằng tỷ lệ tội phạm bạo lực ở Mỹ gần mức thấp lịch sử, vì vậy khó có khả năng là vì “an toàn”. Rất có thể, Ring đang lợi dụng sự trỗi dậy của chủ nghĩa chuyên chế công nghệ, tức là chủ nghĩa chuyên chế được hỗ trợ bởi công nghệ giám sát, để kiếm lợi nhuận. Nhiều công ty công nghệ muốn kiếm lợi từ sự tự do ngày càng thu hẹp của chúng ta. Gần đây, Google cũng đã chấm dứt một cam kết đạo đức cũ, đó là không kiếm lợi nhuận từ giám sát và chiến tranh. Các công ty này đã khóa các hợp đồng trị giá hàng tỷ đô la bằng cách bán sản phẩm cho bộ phận quốc phòng hoặc cảnh sát.

Bài viết cuối cùng lên án hành vi của công ty Ring.

HN | Độ nóng: 358 điểm | 182 bình luận | Tác giả: xoa #

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

Người dùng bày tỏ lo ngại về vấn đề quyền riêng tư của camera Ring, cho rằng dữ liệu của họ có thể bị bên thứ ba thu thập, thậm chí bị cảnh sát truy cập mà không có sự đồng ý của người dùng.
Có người tán thưởng những người từ chối lắp đặt camera Ring, cho rằng hành vi của họ đáng được tôn trọng và cho rằng hành vi xâm phạm quyền riêng tư này là vô đạo đức.
Có quan điểm cho rằng chức năng “chọn tham gia” có thể được bật mặc định và khó tìm, hoặc gắn liền với phí dịch vụ, từ đó ép buộc người dùng đồng ý.
Có người đề xuất rằng nếu cảnh sát cần giám sát không gian công cộng theo thời gian thực, thì họ nên được ủy quyền thông qua các kênh hợp pháp, thay vì truy cập tùy tiện.
Một số người dùng bày tỏ sự không hài lòng về giao diện cài đặt lộn xộn và khó tìm của ứng dụng Ring, kêu gọi cần một hộp tìm kiếm thông minh hơn để giúp người dùng nhanh chóng tìm thấy các cài đặt liên quan.
Tồn tại khoảng trống thị trường, cần cung cấp cho người dùng một giao diện đơn giản hóa để dễ dàng quản lý và điều chỉnh các cài đặt liên quan đến quyền riêng tư/bảo mật.
Có người đề cập đến các plugin trình duyệt có thể tự động xử lý các biểu ngữ cookie, chọn các tùy chọn ít xâm phạm quyền riêng tư nhất, đơn giản hóa quy trình thao tác của người dùng.
Nếu mọi người đều sử dụng các plugin như vậy, có thể khiến các trang web thiết kế các menu cookie phức tạp một cách trắng trợn hơn, vì chúng không cần người dùng tự xử lý.
Có người hỏi tên của plugin trình duyệt có thể tự động xử lý các biểu ngữ cookie.
Thảo luận về chiến lược định giá của Comcast, chỉ ra rằng họ tăng giá bằng cách cung cấp dịch vụ dữ liệu không giới hạn, nhưng người dùng có thể giữ giá cũ bằng cách đồng ý với một số điều kiện nhất định.

So sánh kiến trúc LLM #

LLM architecture comparison

https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

Bài viết này là về phân tích so sánh kiến trúc của các mô hình ngôn ngữ lớn (LLM), được viết bởi Tiến sĩ Sebastian Raschka, xuất bản vào ngày 19 tháng 7 năm 2023. Bài viết điểm lại quá trình phát triển bảy năm kể từ khi kiến trúc GPT ban đầu được phát triển, và khám phá sự tương đồng về cấu trúc của các mô hình từ GPT-2 (2019) đến DeepSeek-V3 và Llama 4 (2024-2025). Mặc dù có những tiến hóa trong nhúng vị trí, cơ chế multi-head attention, và các hàm kích hoạt, bài viết đặt câu hỏi liệu những mô hình này có thực sự đạt được những đột phá về kiến trúc hay chỉ đơn thuần là tối ưu hóa trên nền tảng ban đầu.

Bài viết chỉ ra rằng việc so sánh hiệu suất của LLM là một thách thức, vì sự khác biệt lớn về bộ dữ liệu, kỹ thuật huấn luyện và siêu tham số, và thường không được ghi chép đầy đủ. Mặc dù vậy, tác giả cho rằng việc phân tích các thay đổi cấu trúc của chính kiến trúc vẫn có giá trị để hiểu công việc của các nhà phát triển LLM năm 2025.

Bài viết tập trung vào hai kỹ thuật quan trọng của kiến trúc DeepSeek V3/R1: Multi-head Latent Attention (MLA) và Mixture of Experts (MoE). MLA là một kỹ thuật giảm việc sử dụng bộ nhớ KV cache, đồng thời hiệu suất mô hình thậm chí còn tốt hơn một chút so với Multi-Head Attention (MHA). MLA nén các tensor khóa và giá trị vào không gian chiều thấp trước khi lưu trữ vào KV cache, và sau đó chiếu chúng trở lại kích thước ban đầu khi suy luận. Còn MoE được thực hiện bằng cách thay thế mỗi module feedforward bằng nhiều lớp chuyên gia, mỗi lớp chuyên gia cũng là một module feedforward. Điều này có nghĩa là chúng ta thay thế một module feedforward duy nhất bằng nhiều module feedforward, do đó làm tăng đáng kể tổng số lượng tham số của mô hình. Tuy nhiên, thủ thuật quan trọng là chúng ta không sử dụng (“kích hoạt”) tất cả các chuyên gia cho mỗi token, mà là bộ định tuyến chọn một tập hợp con nhỏ.

Bài viết cũng đề cập đến DeepSeek R1, một mô hình suy luận dựa trên kiến trúc DeepSeek V3, được phát hành vào tháng 1 năm 2025 và đã tạo ra tác động đáng kể vào thời điểm đó. Tác giả cũng đề cập đến một bài viết trước đó, để giúp hiểu về suy luận LLM.

Nói chung, bài viết này đi sâu vào thiết kế của kiến trúc LLM hiện đại, đặc biệt là các đặc điểm kiến trúc của DeepSeek V3/R1, và cách chúng cải thiện hiệu quả tính toán và hiệu suất mô hình thông qua các kỹ thuật MLA và MoE.

HN | Độ nóng: 355 điểm | 23 bình luận | Tác giả: mdp2021 #

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

Bài viết này rất hữu ích để hiểu kiến trúc LLM, cung cấp một mức độ trừu tượng cho phép mọi người học các chi tiết cụ thể mà không cảm thấy khó khăn khi phân tích các bài báo gốc.
Các biểu đồ trong bài viết rất tuyệt vời cho cả người mới bắt đầu và chuyên gia, có thể thấy tất cả các mô hình mới được đặt cạnh nhau.
Thông qua bài viết này, bạn có thể tìm hiểu về các kỹ thuật kiến trúc quan trọng được giới thiệu trong phiên bản V3 của các mô hình như DeepSeek, những kỹ thuật này mang tính cách mạng trong việc cải thiện hiệu quả tính toán và phân biệt các LLM khác.
Mặc dù tất cả các kiến trúc này đều mang tính đổi mới, cải thiện độ chính xác hoặc tốc độ, nhưng vẫn còn một vấn đề cơ bản trong việc tạo ra thông tin thực tế.
Thông qua việc cải thiện cơ chế attention và các mục tiêu huấn luyện nhắm đến việc giảm thiểu ảo giác, một số kiến trúc mới như DeepSeek-V2 và Llama 3.1 đã đạt được những cải tiến đáng kể về tính xác thực.
Mô hình không thể xác định khi nào không nên ngoại suy, cần thêm thông tin và những quy tắc nào có thể khái quát hóa, những quy tắc nào không.
Các quy tắc hình thành danh từ trong ngôn ngữ có thể bị phá vỡ trong một số trường hợp, đây có thể là một sự phức tạp không cần thiết dưới góc độ máy móc, ảo giác của LLM có thể một phần do mô hình xã hội dựa trên ngoại lệ mà chúng ta áp đặt lên kiến trúc mô hình thông qua dữ liệu huấn luyện.
RAG (Retrieval-Augmented Generation - Tạo sinh tăng cường truy xuất) về mặt khái niệm thì đơn giản và dễ thực hiện, nhưng thật khó hiểu tại sao mô hình cơ bản không đưa nó vào chức năng cơ bản.
RAG, như một kỹ thuật prompt, có thể tăng cường mô hình bằng cách đưa ngữ cảnh liên quan vào khi mô hình suy luận, nhưng chức năng truy xuất của nó luôn nằm bên ngoài mô hình.
Các mô hình được huấn luyện thông qua RL (Reinforcement Learning - Học tăng cường), chẳng hạn như các mô hình được sử dụng và gắn nhãn, khác với các mô hình như GSM8k, chúng chú trọng hơn đến việc có một quá trình suy nghĩ lớn ngay từ đầu và sử dụng RL phức tạp hơn REINFORCE.

Xây Dựng Hệ Thống Sao Lưu Của Riêng Bạn – Phần 1: Chiến Lược Trước Khi Viết Script #

Make Your Own Backup System – Part 1: Strategy Before Scripts

https://it-notes.dragas.net/2025/07/18/make-your-own-backup-system-part-1-strategy-before-scripts/

Bài viết này được viết bởi Stefano Marinelli, với tiêu đề “Make Your Own Backup System – Part 1: Strategy Before Scripts” (Tự Xây Dựng Hệ Thống Sao Lưu Dữ Liệu Của Bạn – Phần 1: Chiến Lược Trước Mã Lệnh), được đăng vào ngày 18 tháng 7 năm 2025. Bài viết chủ yếu thảo luận về tầm quan trọng của chiến lược sao lưu và cung cấp hướng dẫn về cách xây dựng một kế hoạch sao lưu hiệu quả.

Sao lưu: Vượt xa việc sao chép đơn giản Tác giả chỉ ra rằng việc sao lưu thường bị đánh giá thấp, nhiều người có những hiểu lầm về khái niệm và thao tác sao lưu, ví dụ như cho rằng RAID là sao lưu. Sao lưu hiện đại thường bị bỏ qua, nhiều người hoàn toàn dựa vào “đám mây” mà không xem xét liệu dữ liệu có thực sự được bảo vệ hay không. Tác giả nhấn mạnh rằng dữ liệu phải được lưu ở định dạng mở để có thể khôi phục nhanh chóng và luôn có thể truy cập được.

Tác giả chia sẻ nhiều tình huống mất dữ liệu, bao gồm hỏa hoạn trung tâm dữ liệu, lũ lụt, động đất, tấn công bằng phần mềm tống tiền, phá hoại có chủ ý và lỗi của quản trị viên, v.v. Những rủi ro này khiến các máy chủ kết nối Internet, chẳng hạn như máy chủ thương mại điện tử và email, không chỉ tính toàn vẹn của dữ liệu là quan trọng mà hoạt động liên tục của dịch vụ cũng quan trọng không kém. Kế hoạch sao lưu: Đặt câu hỏi đúng Trước khi bắt đầu sao lưu, tác giả khuyên trước tiên nên có một kế hoạch và đặt câu hỏi đúng, chẳng hạn như: “Tôi sẵn sàng chấp nhận rủi ro lớn đến mức nào? Tôi cần bảo vệ dữ liệu nào? Trong trường hợp mất dữ liệu, tôi có thể chịu đựng thời gian ngừng hoạt động là bao lâu? Tôi có bao nhiêu dung lượng lưu trữ?” Những câu hỏi này giúp cân bằng tính bảo mật và chi phí, xây dựng một chiến lược sao lưu phù hợp với nhu cầu cụ thể. Quyết định cốt lõi: Sao lưu toàn bộ đĩa so với sao lưu từng tệp riêng lẻ Một quyết định quan trọng trong chiến lược sao lưu là chọn sao lưu toàn bộ đĩa hay chỉ sao lưu các tệp riêng lẻ. Ưu điểm của việc sao lưu toàn bộ đĩa bao gồm khả năng khôi phục hệ thống hoàn chỉnh, bao gồm cả bộ nạp khởi động, và tích hợp trong các hệ thống ảo hóa. Nhược điểm bao gồm thời gian ngừng hoạt động đối với máy vật lý, yêu cầu không gian lớn, khả năng giảm tốc và các vấn đề về khả năng tương thích. Mặc dù sao lưu từng tệp riêng lẻ có vẻ đơn giản hơn, nhưng nó có thể trở nên phức tạp, ưu điểm của nó bao gồm tính thực tế cơ bản, sao lưu chi tiết, sao chép gia tăng, tính di động và khả năng khôi phục một phần, cũng như các chức năng nén và khử trùng lặp. Nhược điểm bao gồm yêu cầu dung lượng lưu trữ, cần có ảnh chụp nhanh hệ thống tệp và các cạm bẫy tiềm ẩn. Tính nhất quán là chìa khóa: Sức mạnh của ảnh chụp nhanh

Bài viết nhấn mạnh tầm quan trọng của ảnh chụp nhanh trong sao lưu, nó có thể cung cấp tính nhất quán và hiệu quả. Ảnh chụp nhanh có thể giúp tránh các vấn đề không nhất quán về dữ liệu trong quá trình sao lưu, đặc biệt khi sao lưu cơ sở dữ liệu hoặc hệ thống tệp. Tác giả đề cập rằng ảnh chụp nhanh là chìa khóa để đạt được sao lưu nhất quán, cho dù là sao lưu toàn bộ đĩa hay sao lưu từng tệp riêng lẻ.

Cuối bài viết, tác giả đưa ra một số nguyên tắc hướng dẫn để xây dựng một hệ thống sao lưu tốt và báo trước nội dung của bài viết tiếp theo, đó là “Điều gì tiếp theo”.

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

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

Máy chủ sao lưu nên duy trì ảnh chụp nhanh hệ thống tệp của riêng mình để phòng ngừa các cuộc tấn công ransomware
Máy khách chỉ chịu trách nhiệm ghi các bản sao lưu mới, thao tác xóa do máy chủ sao lưu xử lý riêng
Sử dụng container hoặc người dùng sao lưu cụ thể có thể tăng cường bảo mật, chẳng hạn như sử dụng systemd-nspawn để tạo “nhà tù” chroot nhẹ
Nguồn sao lưu được đẩy đến vị trí trung gian, bản sao lưu chính được kéo từ vị trí trung gian, tăng cường bảo mật
Máy chủ sao lưu chỉ có thể được truy cập trực tiếp thông qua bảng điều khiển, điều này làm tăng tính bảo mật nhưng đôi khi gây bất tiện
Sử dụng lược đồ sao lưu “kéo” đơn giản hơn và có thể an toàn hơn so với “đẩy”
Đối với các công ty lớn, điểm lỗi bên ngoài có thể là một đặc điểm chứ không phải là một khuyết điểm
Nhiều công ty thực sự không có yêu cầu RTO/RPO cao như họ tuyên bố
Thật đáng ngạc nhiên khi mọi người suy nghĩ quá nhiều về quy trình và yêu cầu sao lưu
Các vấn đề sao lưu có thể được giữ lại cho mục đích pháp lý, chẳng hạn như yêu cầu bảo lưu kiện tụng
Các công ty lớn giữ lại dữ liệu trong 5-7 năm do yêu cầu pháp lý
Chính sách khôi phục sau thảm họa của một số công ty thực sự khó khôi phục trạng thái làm việc trong một khoảng thời gian hợp lý

Borrow checker là thứ tôi thích ít nhất ở Rust #

The borrowchecker is what I like the least about Rust

https://viralinstruction.com/posts/borrowchecker/

Bài viết này thảo luận về borrowchecker trong ngôn ngữ lập trình Rust, tức là phần của trình biên dịch chịu trách nhiệm thực thi các quy tắc sở hữu, điều này cho phép Rust đạt được tính an toàn bộ nhớ mà không làm tăng chi phí thời gian chạy. Tác giả bài viết cho rằng, mặc dù Rust được ca ngợi rộng rãi vì tính an toàn của nó, nhưng sự tồn tại của borrowchecker gây ra các vấn đề nghiêm trọng về công thái học cho Rust và vai trò của nó trong tính an toàn của Rust bị phóng đại quá mức.

Bài viết trước hết chỉ ra rằng vấn đề của borrowchecker là nó khiến việc xử lý các tham chiếu trở nên khó khăn. Điều này là do borrowchecker cần biết thời gian tồn tại của tất cả các tham chiếu tại thời điểm biên dịch, điều này thường không thực tế trong thực tế, vì thời gian tồn tại thường là thuộc tính thời gian chạy. Về mặt thuật toán, borrowchecker thực thi một mô hình hoặc tập hợp các quy tắc cụ thể về quyền sở hữu, nhưng mô hình này quá nghiêm ngặt, làm giảm công thái học của Rust bằng cách từ chối quá nhiều chương trình hoạt động tốt. Về mặt triển khai, phiên bản hiện tại của borrowchecker không đầy đủ, thường từ chối các chương trình tuân theo mô hình sở hữu, ngay cả khi bản thân mô hình này quá nghiêm ngặt.

Tác giả minh họa cách borrowchecker từ chối mã hoàn toàn hợp lý thông qua một vài ví dụ. Ví dụ: một struct Point đơn giản, chứa hai phương thức x_mut và y_mut, lần lượt trả về các tham chiếu khả biến đến các trường x và y. Trong hàm main, một thể hiện Point được tạo và cố gắng sửa đổi các giá trị của x và y thông qua hai phương thức này, nhưng đoạn mã này không thể biên dịch được, vì borrowchecker không cho phép hai tham chiếu khả biến tồn tại đồng thời, ngay cả khi chúng trỏ đến các trường khác nhau của struct.

Một ví dụ khác là struct Collection, chứa một bộ đếm và một danh sách các mục. Phương thức count_items của Collection cố gắng tăng bộ đếm khi lặp qua danh sách các mục, nhưng borrowchecker không thể suy luận giữa các hàm, do đó từ chối hàm này một cách sai lầm.

Bài viết cũng đề cập đến các vấn đề của borrowchecker khi xử lý luồng điều khiển, chẳng hạn như một hàm cố gắng lấy hoặc chèn giá trị mặc định từ HashMap, mặc dù về mặt logic đảm bảo rằng tham chiếu khả biến thứ hai chỉ được tạo khi tham chiếu đầu tiên không còn tồn tại, nhưng borrowchecker vẫn từ chối đoạn mã này.

Tác giả cho rằng, mặc dù cộng đồng Rust hy vọng rằng những cải tiến trong tương lai sẽ giải quyết những vấn đề này, chẳng hạn như việc áp dụng non-lexical lifetimes vào năm 2022 và công thức borrowchecker mới Polonius đang được phát triển, nhưng ông vẫn hoài nghi về điều này. Polonius đã được phát triển trong bảy năm và dường như vẫn chưa gần hoàn thành. Quan trọng hơn, borrowchecker không bao giờ có thể “hoàn chỉnh”, vì công việc của nó là suy luận mã và chương trình không thể làm điều đó ở mức độ đủ sâu.

Cuối cùng, bài viết chỉ ra rằng ngay cả khi có những hạn chế trong việc trừu tượng hóa việc triển khai mô hình sở hữu, đôi khi bản thân mô hình này không phù hợp với chương trình của bạn. Ví dụ: các tham chiếu đến các giá trị tạm thời bị cấm, ngay cả khi con người có thể thấy rõ rằng giải pháp là mở rộng thời gian tồn tại của giá trị đó ra ngoài việc sử dụng closure. Ngoài ra còn có các struct sở hữu hỗn hợp, bạn không thể có một trường chứa Vec<Thing> đồng thời lưu trữ các nhóm của cùng một thứ trong một trường khác, trong Vec<Vec<&Thing>>. Những ví dụ này cho thấy rằng các quy tắc sở hữu không phải lúc nào cũng có thể đáp ứng nhu cầu của chương trình và borrowchecker, với tư cách là một chương trình, rất khó để thương lượng để nó không thực thi quá nghiêm ngặt một bộ quy tắc cứng nhắc nhưng đôi khi vô nghĩa.

HN | Độ nóng: 243 điểm | 405 bình luận | Tác giả: jakobnissen #

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

Bộ kiểm tra mượn (Borrow checker) là yếu tố then chốt cho sự thành công của ngôn ngữ Rust, nó cung cấp các tính năng mà các ngôn ngữ khác không thể thực hiện được
Golang được cho là đơn giản hơn Rust, nhưng trên thực tế nó thiếu tính trừu tượng và xử lý ngoại lệ, buộc các nhà phát triển phải viết mã đơn giản hơn
Golang có đường cong học tập thoải, có thư viện chuẩn phong phú, tốc độ biên dịch và chạy nhanh, tạo ra một tệp thực thi độc lập duy nhất
Golang giống một Modula-2 tốt hơn, ngôn ngữ trở nên tốt hơn sau khi có các tham số kiểu, nhưng GC giúp việc viết mã trở nên đơn giản hơn
Có người cho rằng Golang có nhiều điểm kỳ quặc vô nghĩa, cả trong ngôn ngữ cơ bản lẫn thư viện chuẩn
Có người cho rằng mô hình đồng thời và kiểu giao diện có thể rỗng của Golang là một phần trong thiết kế ngôn ngữ của nó, không nên coi là điểm kỳ quặc
Có người cho rằng sự đơn giản của Golang không có nghĩa là sự phức tạp biến mất, mà là chuyển sang các chương trình được viết bằng ngôn ngữ đó
Có người cho rằng Rust và các ngôn ngữ như OCaml/ReasonML thanh lịch hơn Golang, được thiết kế từ đầu
Rust được coi là ngôn ngữ chính thống, trong khi Golang có ít điểm kỳ quặc hơn so với các ngôn ngữ chính thống khác

Cái quái gì Python #

What the Fuck Python

https://colab.research.google.com/github/satwikkansal/wtfpython/blob/master/irrelevant/wtf.ipynb

Trang web này là một dự án khám phá về ngôn ngữ lập trình Python, nhằm mục đích giải thích một số đoạn mã Python có vẻ trái trực giác và các tính năng ít được biết đến. Dự án giúp người đọc hiểu sâu hơn về cơ chế hoạt động bên trong của Python bằng cách trình bày và giải thích các đoạn mã này.

Trang web giới thiệu Python như một ngôn ngữ lập trình cấp cao, thông dịch, cung cấp nhiều tính năng tiện lợi cho các lập trình viên. Tuy nhiên, đôi khi, kết quả của các đoạn mã Python có thể không rõ ràng như vậy. Dự án này nhằm mục đích giải thích những đoạn mã có vẻ kỳ lạ này, nhưng thực tế lại tiết lộ những phần thú vị của Python.

Cấu trúc của trang web như sau: Mỗi ví dụ đều có một tiêu đề hấp dẫn, sau đó là phần thiết lập mã, tiếp theo là kết quả đầu ra và cuối cùng là phần giải thích. Kết quả đầu ra hiển thị đầu ra thực tế sau khi mã được thực thi, trong khi phần giải thích giải thích một cách ngắn gọn lý do tại sao đầu ra đó xảy ra.

Ví dụ, trang web đề cập đến một số hành vi thú vị của chuỗi trong Python. Trong ví dụ đầu tiên, bằng cách so sánh địa chỉ bộ nhớ của hai chuỗi, nó cho thấy Python tối ưu hóa việc lưu trữ chuỗi như thế nào, cụ thể là bằng cách sử dụng string interning để tiết kiệm bộ nhớ. Trong một số trường hợp, nhiều biến có thể tham chiếu đến cùng một đối tượng chuỗi trong bộ nhớ. Trang web giải thích các quy tắc của string interning, bao gồm tất cả các chuỗi có độ dài là 0 và 1 sẽ được interning, cũng như các chuỗi được interning tại thời điểm biên dịch, v.v.

Ví dụ thứ hai khám phá việc so sánh tính tương đương của chuỗi, cho thấy trong các tình huống khác nhau, ngay cả khi nội dung của hai chuỗi giống nhau, kết quả về việc chúng có bằng nhau hay không có thể khác nhau. Điều này liên quan đến cách Python quản lý và so sánh các đối tượng chuỗi trong bộ nhớ.

Ví dụ thứ ba thảo luận về hành vi của phép nhân chuỗi, đặc biệt là khi độ dài chuỗi nhỏ hơn 21, Python sẽ thực hiện một tối ưu hóa gọi là Constant folding, điều này sẽ ảnh hưởng đến kết quả của phép nhân chuỗi.

Nói chung, trang web này là một dự án mang tính giáo dục, thông qua các ví dụ mã cụ thể và giải thích, giúp người đọc hiểu và học ngôn ngữ lập trình Python tốt hơn. Mỗi ví dụ đều nhằm mục đích tiết lộ một số cơ chế bên trong của Python, cho phép các lập trình viên Python có kinh nghiệm cũng có thể học được kiến thức mới, đồng thời cung cấp một nguồn tài liệu học tập thú vị cho người mới bắt đầu.

HN | Độ nóng: 196 điểm | 176 bình luận | Tác giả: sundarurfriend #

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

Notebook này ngay lập tức chỉ rõ đây là những quan sát thú vị về một số hành vi thú vị của Python, và không hề ám chỉ có bug, ngoại trừ việc đề cập đến một bug thực tế của CPython.
Việc hiểu sự khác biệt giữa khái niệm về dòng code và việc thực thi thực tế là điều thú vị, và đôi khi cũng rất quan trọng.
Một số bình luận cho rằng việc trình bày hằng số chuỗi không được tối ưu hóa không phải là một khởi đầu tốt, việc thảo luận về cạm bẫy tham chiếu trong các tham số hàm có thể là một ví dụ tốt hơn.
Gọi loại nội dung này là “What The Fuck Python” sẽ thu hút sự chú ý hơn là “Some Interesting Bits About Python Internals You Probably Don’t Need To Know”.
Code Python tốt dựa trên quy ước, và không nên thấy hàm id() và “is” được sử dụng để so sánh chuỗi trong code production.
Những ví dụ này cho thấy cách sử dụng Python theo những cách không mong muốn, chứ không phải cách nó nên được sử dụng.
Các trang “What the Fuck” chủ yếu được sử dụng để thảo luận về hoạt động bên trong của ngôn ngữ/trình thông dịch, v.v., và không nên được coi là một lời chỉ trích ngôn ngữ.
Mục tiêu của mỗi ngôn ngữ lập trình nên là tuân theo một đặc tả logic và nhất quán nhất có thể để giảm bug.
Đối với các ngôn ngữ lập trình được sử dụng rộng rãi, chúng ta nên kiểm tra nó giống như các QA tester, vì tất cả những sự không nhất quán cộng lại sẽ dẫn đến rất nhiều bug.
Một số ví dụ có thể không phải là bug thực sự, nhưng chúng tiết lộ một số phần thú vị có thể chưa được biết đến của Python.
Chúng ta không nên cảm thấy bị xúc phạm vì liệt kê các bug, việc hiểu chúng là hữu ích.
Nên đưa những bug này vào hệ thống theo dõi bug và ưu tiên chúng dựa trên tần suất xảy ra và tác động của chúng.

TSMC sẽ bắt đầu xây dựng bốn nhà máy mới với công nghệ 1.4nm #

TSMC to start building four new plants with 1.4nm technology

https://www.taipeitimes.com/News/front/archives/2025/07/20/2003840583

Công ty Sản xuất Bán dẫn Đài Loan (TSMC) có kế hoạch bắt đầu xây dựng bốn nhà máy mới vào cuối năm nay, với mục tiêu chính thức đưa vào sản xuất wafer bán dẫn 2 nanomet trước cuối năm 2028. Thông tin này được Giám đốc Cục Khoa học Trung Đài Loan Hứa Mậu Tân công bố tại sự kiện kỷ niệm 22 năm thành lập Khu Khoa học Trung Đài Loan. Giai đoạn mở rộng thứ hai của khu sẽ bắt đầu bằng việc xây dựng ao hồ và các công trình bảo vệ đất và nguồn nước khác. Ông Hứa Mậu Tân cho biết TSMC đã chính thức thuê đất và Khu Khoa học Trung Đài Loan đã bàn giao lô đất vào tháng trước. Ông lạc quan rằng doanh thu hàng năm của khu sẽ vượt quá 1,2 nghìn tỷ Đài tệ (tương đương khoảng 40,81 tỷ đô la Mỹ), lập kỷ lục mới.

Tại hội thảo công nghệ Bắc Mỹ được tổ chức tại California vào ngày 25 tháng 4, TSMC đã tiết lộ kế hoạch ra mắt quy trình sản xuất A14 vào năm 2028. Theo lộ trình của TSMC, bốn nhà máy nằm trong Khu Khoa học Trung Đài Loan, được chỉ định là Fab 25, sẽ bao gồm bốn cơ sở sản xuất wafer 1,4 nanomet. Theo lộ trình của công ty, nhà máy đầu tiên dự kiến sẽ hoàn thành đánh giá rủi ro sản xuất wafer vào năm 2027 và bắt đầu sản xuất hàng loạt vào cuối năm 2028, với mục tiêu sản lượng hàng tháng là 50.000 wafer.

Trong cuộc gọi hội nghị báo cáo thu nhập quý 2 của TSMC vào thứ Năm, Chủ tịch TSMC Ngụy Triết Gia cho biết, sau khi công ty hoàn thành khoản đầu tư 165 tỷ đô la Mỹ vào Hoa Kỳ, “khoảng 30% năng lực sản xuất 2 nanomet và tiên tiến hơn của chúng tôi sẽ được đặt tại Arizona, tạo ra một cụm sản xuất bán dẫn hàng đầu độc lập ở Hoa Kỳ.” Khoản đầu tư vào Arizona bao gồm sáu nhà máy sản xuất wafer tiên tiến, hai nhà máy đóng gói tiên tiến và một trung tâm nghiên cứu và phát triển lớn. Ông Ngụy Triết Gia cũng cho biết TSMC có kế hoạch “xây dựng 11 nhà máy sản xuất wafer và bốn cơ sở đóng gói tiên tiến trong những năm tới”. Công ty “đang chuẩn bị cho nhiều giai đoạn nhà máy 2 nanomet tại các khu khoa học Tân Trúc và Cao Hùng để hỗ trợ nhu cầu cấu trúc mạnh mẽ của khách hàng”.

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

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

Công nghệ 1.4 nanomet (A14) của TSMC dựa trên bóng bán dẫn tấm nano GAAFET thế hệ thứ hai và kiến trúc ô tiêu chuẩn mới, dự kiến sẽ mang lại hiệu suất tăng từ 10% đến 15%, giảm mức tiêu thụ điện năng từ 25% đến 30% và tăng mật độ bóng bán dẫn từ 20% đến 23% so với công nghệ N2.
Công nghệ 1.4 nanomet có thể yêu cầu IP, tối ưu hóa và phần mềm EDA mới, khác với công nghệ N2P và A16.
Khi kích thước bóng bán dẫn thu nhỏ, toàn bộ chip có thể cuối cùng biến thành SRAM.
Có thể giảm SRAM trên mỗi lõi, chuyển sang eDRAM làm bộ nhớ cache cấp cuối.
Sự suy giảm của ngành sản xuất bán dẫn Hoa Kỳ là điều đáng tiếc.
Hoa Kỳ đang cố gắng chuyển sản xuất chip ra khỏi Đài Loan.