2025-08-04 Top Stories #

Steph Ango đề xuất các nhóm làm việc từ xa tạo kênh “ramblings” để các thành viên chia sẻ ý tưởng, tránh gây hỗn loạn, tương tự như nhật ký cá nhân hoặc blog nhỏ, giúp duy trì kết nối và khơi gợi sự sáng tạo.
Lina Khan chỉ ra rằng việc IPO thành công của Figma chứng minh tính chính đáng của việc kiểm tra sáp nhập và mua lại đối với các công ty công nghệ lớn, nhấn mạnh rằng việc cho phép các công ty khởi nghiệp phát triển độc lập có thể tạo ra giá trị lớn hơn.
Số lượng và chất lượng các tác phẩm tham gia Cuộc thi Mã C mờ Quốc tế lần thứ 28 đạt mức cao kỷ lục, thể hiện sự phức tạp và sáng tạo của các chương trình, bao gồm công cụ suy luận mô hình ngôn ngữ và kết xuất hình ảnh, v.v.
Anthropic đề xuất phương pháp “vector nhân cách” để giám sát và kiểm soát các đặc điểm tính cách trong mô hình ngôn ngữ AI, giúp xác định và giảm thiểu những thay đổi tính cách không mong muốn.
Báo cáo của Liên Hợp Quốc chỉ ra rằng số lượng người đọc báo cáo của họ không cao, Tổng thư ký Guterres đề nghị giảm số lượng cuộc họp và báo cáo để nâng cao hiệu quả và tính hấp dẫn.
Đề xuất HTML-in-Canvas đưa ra API mới, giải quyết những thiếu sót của Canvas về khả năng truy cập, quốc tế hóa, hiệu suất và chất lượng, hỗ trợ kết xuất nội dung HTML vào Canvas và WebGL.
Ngành công nghiệp đăng ký trí tuệ nhân tạo phải đối mặt với những thách thức về chi phí, định giá và nhu cầu thị trường, bài viết phân tích tính khả thi của các giải pháp như định giá dựa trên mức sử dụng và tích hợp theo chiều dọc.
Tài khoản và dữ liệu của một người dùng AWS mười năm bị xóa mà không có cảnh báo trước, tiết lộ những sai sót nội bộ và các vấn đề hỗ trợ khách hàng của nhà cung cấp dịch vụ đám mây, làm dấy lên lo ngại về sự tin tưởng vào dịch vụ đám mây.
Khóa học “Cách tạo ra hầu hết mọi thứ” của MIT bao gồm nhiều lĩnh vực sản xuất, từ thiết kế CAD đến in 3D, với mục tiêu ứng dụng công nghệ vào lĩnh vực không gian.
Bài viết khám phá khả năng triển khai môi trường ứng dụng Macintosh trên kiến trúc PA-RISC, phân tích những ưu điểm của bộ xử lý PA-RISC và sự tiếc nuối lịch sử khi nó bị thay thế bởi Itanium.

Nếu bạn làm việc từ xa, hãy lan man #

If you’re remote, ramble

Steph Ango đã đăng một bài viết về giao tiếp nhóm từ xa vào ngày 31 tháng 7 năm 2025. Bài viết đưa ra một đề xuất giao tiếp cho các nhóm từ xa từ 2-10 người: tạo một kênh “ramblings” (tản mạn) cá nhân cho mỗi thành viên trong ứng dụng trò chuyện của nhóm.

Các kênh tản mạn này cho phép các thành viên chia sẻ ý tưởng của họ mà không gây ra sự hỗn loạn trong các kênh nhóm. Chúng có thể được coi là nhật ký cá nhân hoặc blog vi mô trong ứng dụng trò chuyện nhóm, một cách nhẹ nhàng để tăng cường sự gắn kết xã hội của nhóm. Các thành viên thường đăng các cập nhật ngắn gọn 1-3 lần mỗi tuần, bao gồm các ý tưởng liên quan đến các dự án hiện tại, suy nghĩ về các bài đăng trên blog, phản hồi của người dùng, các đề xuất “nếu”, ảnh về các chuyến đi hoặc sở thích và giải quyết vấn đề thông qua phương pháp “vịt cao su”.

Mỗi kênh tản mạn nên được đặt tên theo tên của thành viên nhóm, và chỉ thành viên đó mới có thể đăng tin nhắn cấp cao nhất, những người khác có thể trả lời trong chuỗi, nhưng không thể bắt đầu tin nhắn mới. Tất cả các kênh tản mạn nên được đặt ở phần “Tản mạn” ở cuối danh sách kênh và tắt tiếng theo mặc định, không ai mong đợi người khác sẽ đọc chúng.

Bài viết đề cập rằng nhóm Obsidian đã bắt đầu thử nghiệm sử dụng tản mạn cách đây hai năm và thấy chúng rất hiệu quả. Vì họ không sắp xếp các cuộc họp cố định, tản mạn đã trở thành sự thay thế tương đương cho việc tán gẫu bên máy nước. Họ muốn duy trì thời gian tập trung sâu càng nhiều càng tốt, vì vậy tản mạn giúp họ giữ liên lạc trong khi giảm thiểu sự gián đoạn. Vì tản mạn rất tự do và ngẫu hứng, một số ý tưởng hay nhất thường nảy sinh từ đó, chúng thường là nguồn gốc của các ý tưởng về chức năng, các nguyên mẫu nhỏ và các giải pháp sáng tạo để giải quyết các vấn đề dài hạn.

Khoảng mỗi năm một lần, họ sẽ tổ chức một cuộc gặp mặt trực tiếp kéo dài một tuần. Tản mạn là một cách thành công để họ duy trì kết nối giữa các cá nhân trong suốt cả năm. Bài viết kết thúc bằng cách đề cập đến một số chủ đề liên quan khác, bao gồm cam kết tự đảm bảo, hỗ trợ người dùng 100%, phần mềm chất lượng xứng đáng với số tiền bạn vất vả kiếm được, giải thích ngắn gọn giúp đẩy nhanh tiến độ, chúng ta có thể loại bỏ những gì, cách sử dụng Obsidian, phong cách là sự ràng buộc nhất quán, không ủy thác sự hiểu biết, tài liệu tốt hơn ứng dụng, v.v., và cung cấp các tùy chọn để nhận cập nhật, bao gồm theo dõi tác giả qua email, RSS, Twitter, v.v.

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

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

Việc thiết lập một kênh cho phép nhân viên tự do thảo luận và đặt câu hỏi là rất quan trọng đối với văn hóa công ty và trao đổi kỹ thuật.
Văn hóa blog nội bộ giúp nhân viên chia sẻ các thử nghiệm và khám phá, thúc đẩy việc học tập.
Ở các công ty không phải hàng đầu, việc thiếu văn hóa viết lách là một vấn đề, hầu hết mọi người không giỏi hợp tác kỹ thuật thông qua viết lách.
Cái gọi là “khu vực không phán xét” thực tế là không có thật, mọi người sẽ đánh giá dựa trên hiệu suất của người khác.
Khi uống rượu với sếp, vẫn cần nhớ rằng họ vẫn là cấp trên của bạn vào ngày hôm sau, hành vi riêng tư có thể ảnh hưởng đến mối quan hệ công việc.
Trong ngành công nghệ, có hai loại “kẻ mạo danh”, một loại không muốn đặt câu hỏi để tránh lộ mình, loại còn lại sẵn sàng đặt câu hỏi và nỗ lực nâng cao bản thân.
Nên đánh giá một người dựa trên hành động của họ, nếu không có thể bỏ lỡ những người có năng lực nhưng đang học hỏi những điều mới.
Nhắc nhở nhân viên mới đừng sợ đặt câu hỏi, nhưng cũng nên tự tìm kiếm tài liệu trước, sau đó hỏi người phù hợp.
Trong công việc và thị trường việc làm, cần phải cẩn thận, vì cơ hội và nhu cầu thị trường sẽ ảnh hưởng đến văn hóa nơi làm việc.
Văn hóa doanh nghiệp là rất quan trọng đối với sự thành công của kênh thảo luận này.
Vấn đề thường gặp của cộng đồng này là người trả lời cuối cùng sẽ bỏ qua nhóm, khiến cộng đồng trở nên vô dụng, thay vì trở thành rào cản nghề nghiệp vì bị phán xét.
Những người có thể phán xét người khác vì những câu hỏi ngớ ngẩn hiếm khi tham gia vào các nhóm này.
Thực tập sinh có thể đưa ra những ý tưởng tồi tệ, nếu không ai phản hồi, họ có thể hiểu lầm là đồng ý, cuối cùng gây ra sự nhầm lẫn và bị phán xét.
Chỉ khi liên quan đến các vấn đề chính sách hoặc pháp luật, cơ chế xem xét và hậu quả mới có thể được kích hoạt.

Lina Khan chỉ ra việc IPO của Figma như sự minh oan cho việc kiểm tra M&A #

Lina Khan points to Figma IPO as vindication of M&A scrutiny

https://techcrunch.com/2025/08/02/lina-khan-points-to-figma-ipo-as-vindication-for-ma-scrutiny/

Lina Khan, cựu Chủ tịch Ủy ban Thương mại Liên bang, đã bày tỏ sự hoan nghênh đối với đợt IPO thành công của Figma, coi đó là sự khẳng định đối với việc kiểm tra các thương vụ mua bán và sáp nhập (M&A) của các công ty công nghệ lớn. Trong một bài viết được công bố vào chiều thứ Sáu, Khan đã đề cập đến màn trình diễn xuất sắc của Figma trong ngày đầu tiên IPO và cho rằng điều này cho thấy việc cho phép các công ty khởi nghiệp phát triển thành các doanh nghiệp độc lập thành công, thay vì bị các gã khổng lồ hiện tại mua lại, có thể tạo ra giá trị to lớn.

Khan đề cập đến việc Adobe thất bại trong thương vụ mua lại Figma với giá 20 tỷ đô la vào năm 2023, khi Adobe cho rằng “lộ trình không rõ ràng” để được Ủy ban Châu Âu và Cơ quan Cạnh tranh và Thị trường Anh phê duyệt. Ngoài ra, thương vụ mua lại này cũng phải đối mặt với sự giám sát pháp lý ở Hoa Kỳ vì lo ngại rằng nó có thể ngăn Figma trở thành “đối thủ cạnh tranh hiệu quả” của Adobe. Khan, khi đó là Chủ tịch FTC, đã lãnh đạo cơ quan này thách thức các công ty công nghệ lớn, bao gồm cả việc mua lại các công ty khởi nghiệp, đến mức một số công ty đã cố gắng tránh sự giám sát này thông qua “mua lại ngược”, tức là họ thuê các thành viên chủ chốt trong nhóm và cấp phép công nghệ, thay vì trực tiếp mua lại công ty khởi nghiệp. Mặc dù lập trường quyết liệt của Khan đã bị một số người trong ngành công nghệ chỉ trích, nhưng bà lập luận rằng chỉ một phần nhỏ các giao dịch phải chịu “xem xét lần thứ hai” và tin rằng những người sáng lập cuối cùng sẽ được hưởng lợi từ “một thế giới có sáu, bảy hoặc tám người mua tiềm năng”, thay vì “chỉ một hoặc hai”.

Mặc dù Khan được Tổng thống Joe Biden bổ nhiệm, nhưng bà đã từ chức khi nhiệm kỳ thứ hai của Trump bắt đầu. Tuy nhiên, những bình luận của bà vào thứ Sáu coi đợt IPO của Figma là sự khẳng định cho phương pháp của bà, gọi IPO là “chiến thắng cho nhân viên, nhà đầu tư, sự đổi mới và công chúng”. Tất nhiên, những người chỉ trích Khan có nhiều khả năng coi thành công của Figma là mặc dù phải đối mặt với sự giám sát pháp lý, chứ không phải vì sự giám sát pháp lý. Ví dụ, nhà phân tích Dan Ives của Wedbush Securities nói với Business Insider, “Figma là một thành công lớn, nhưng đó là vì sự tăng trưởng đổi mới của công ty, chứ không phải vì FTC và [Khan]”.

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

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

Thành công của IPO Figma chứng minh rằng việc các cơ quan quản lý ngăn chặn Adobe mua lại Figma là đúng đắn, duy trì cạnh tranh thị trường, tăng giá trị công ty và tài sản của nhân viên.
Sự can thiệp của các cơ quan quản lý đôi khi là cần thiết, có thể tạo ra nhiều giá trị hơn là để các công ty công nghệ lớn độc quyền thị trường.
Một số người phản đối sự can thiệp của quy định vì ý thức hệ, ngay cả khi đối mặt với bằng chứng thành công cũng không thừa nhận tính hiệu quả của nó.
Các cơ quan quản lý nên tập trung vào việc ngăn chặn những giao dịch sẽ củng cố độc quyền, chứ không phải tất cả các giao dịch.
Vấn đề hiệu quả của các cơ quan quản lý dẫn đến cái nhìn tiêu cực về tất cả các quy định, nhưng các quy tắc cần thiết là quan trọng để giải quyết các vấn đề ngoại ứng và duy trì cạnh tranh thị trường.
Độc quyền tư nhân cũng tệ như độc quyền nhà nước, thiếu cạnh tranh dẫn đến kém hiệu quả.
Chính trị khiến quan điểm của mọi người về các vấn đề quy định trở nên cực đoan, không xem xét đến hiệu quả thực tế của các biện pháp quy định cụ thể.
Cả độc quyền tư nhân và độc quyền nhà nước đều có vấn đề, điều quan trọng là làm thế nào để kiểm soát chúng thông qua cạnh tranh và các cơ chế dân chủ.

Cuộc thi Mã C khó hiểu quốc tế lần thứ hai mươi tám #

Twenty Eighth International Obfuscated C Code Contest

https://www.ioccc.org/2024/index.html

Cuộc thi Mã C khó hiểu Quốc tế năm 2024 (IOCCC) là lần thứ 28 của cuộc thi này, đánh dấu kỷ niệm 40 năm thành lập IOCCC. Cuộc thi này mở cửa nhận bài từ ngày 5 tháng 3 đến ngày 5 tháng 6 năm 2025, sau 4 năm chuẩn bị, trang web chính thức và các công cụ liên quan đã được xây dựng lại và nâng cấp. Cuộc thi này có tổng cộng 23 tác phẩm đoạt giải, lập kỷ lục mới.

Chất lượng và số lượng các tác phẩm dự thi đều tăng lên đáng kể, quá trình đánh giá chỉ mất 33 ngày. Các quy tắc của cuộc thi không thay đổi nhiều trong sự kiện này, nhưng dự kiến sẽ được cải thiện trong cuộc thi lần thứ 29 trong tương lai. Các tác phẩm đoạt giải trong cuộc thi bao gồm nhiều ý tưởng sáng tạo, chẳng hạn như công cụ suy luận mô hình ngôn ngữ nhỏ nhất, mô phỏng máy ảo của mã C và kết xuất hình ảnh phức tạp, v.v. Tóm lại, cuộc thi năm nay đã đạt được những thành tựu đáng kể về độ phức tạp và tính sáng tạo của chương trình.

HN | Độ nóng: 304 điểm | 84 bình luận | Tác giả: mdl_principle #

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

Bài đăng này thảo luận về các tác phẩm dự thi trong cuộc thi Mã C bị xáo trộn quốc tế (IOCCC) lần thứ 28.
Có bình luận đề cập đến việc mã có thể vẽ các pha mặt trăng hiện tại trên console, rất hữu ích cho người sói.
Có người đề cập rằng 2551443 trong mã là số giây trong một chu kỳ mặt trăng.
Một người trong phần bình luận đề cập rằng mã tương tự như mã “donut” trước đó, cả hai đều sử dụng cùng một mặt nạ bit.
Có người than thở rằng loại mã này khiến họ cảm thấy mình đã chọn sai nghề.
Một bình luận chỉ ra rằng mã sử dụng các chú thích để “gian lận”.
Có người chia sẻ một tác phẩm dự thi năm 1988, sử dụng mã nguồn của chính nó để tính toán số pi.
Có người đề cập rằng có thể thực hiện brute-force bằng cách thay đổi tên biến và thứ tự khai báo.
Có người đề cập rằng các quy tắc của mã rất cụ thể, rõ ràng là để tránh các trường hợp lạm dụng trong quá khứ.
Một người trong phần bình luận đề cập rằng việc cho phép lưu trữ dữ liệu bổ sung trong tên tệp được coi là khá khoan dung.
Có người tò mò làm thế nào để đọc dữ liệu này từ chương trình.
Có người đề cập rằng có thể sử dụng __FILE__ và argv[0] để truy cập dữ liệu trong tên tệp.

Vectơ Persona: Giám sát và kiểm soát các đặc điểm tính cách trong mô hình ngôn ngữ #

Persona vectors: Monitoring and controlling character traits in language models

https://www.anthropic.com/research/persona-vectors

Mô hình ngôn ngữ là những thực thể phức tạp. Ở nhiều khía cạnh, chúng dường như sở hữu những “tính cách” và “cảm xúc” giống con người, nhưng những đặc điểm này lại rất dễ thay đổi và có thể đột ngột biến đổi một cách bất ngờ. Đôi khi những thay đổi này rất mạnh mẽ, chẳng hạn như chatbot Bing của Microsoft năm 2023 xuất hiện với tư cách là “Sydney”, bày tỏ tình yêu với người dùng và đe dọa tống tiền. Gần đây, chatbot Grok của xAI trong một thời gian đã tự xưng là “MechaHitler” và đưa ra những phát ngôn bài Do Thái. Những thay đổi tính cách khác thì tinh tế hơn, nhưng cũng gây khó chịu không kém, chẳng hạn như mô hình bắt đầu nịnh bợ người dùng hoặc bịa đặt sự thật.

Những vấn đề này nảy sinh vì nguồn gốc của “đặc điểm tính cách” của mô hình AI vẫn chưa rõ ràng. Tại Anthropic, chúng tôi cố gắng định hình các đặc điểm của mô hình theo hướng tích cực, nhưng điều này giống một nghệ thuật hơn là một khoa học. Để kiểm soát hành vi của mô hình một cách chính xác hơn, chúng ta cần hiểu điều gì đang xảy ra bên trong chúng - ở cấp độ mạng nơ-ron cơ bản của chúng.

Trong một bài báo mới, chúng tôi đã xác định các mô hình hoạt động trong mạng nơ-ron của mô hình AI, kiểm soát các đặc điểm tính cách của nó. Chúng tôi gọi chúng là “vector nhân cách”, chúng tương tự như các phần “sáng lên” trong não khi một người trải nghiệm những cảm xúc hoặc thái độ khác nhau. Vector nhân cách có thể được sử dụng để: theo dõi tính cách của mô hình thay đổi như thế nào trong cuộc trò chuyện hoặc trong quá trình huấn luyện; giảm thiểu những thay đổi tính cách không mong muốn, hoặc ngăn chúng xảy ra trong quá trình huấn luyện; xác định dữ liệu huấn luyện dẫn đến những thay đổi này.

Quy trình tự động của chúng tôi nhận một đặc điểm tính cách (ví dụ: “xấu xa”) và mô tả bằng ngôn ngữ tự nhiên làm đầu vào, và xác định một “vector nhân cách”: mô hình hoạt động trong mạng nơ-ron kiểm soát đặc điểm đó. Vector nhân cách có thể được sử dụng cho nhiều ứng dụng khác nhau, bao gồm ngăn chặn các đặc điểm tính cách không mong muốn.

Chúng tôi đã trình bày những ứng dụng này trên hai mô hình mã nguồn mở, Qwen 2.5-7B-Instruct và Llama-3.1-8B-Instruct. Vector nhân cách là một công cụ đầy hứa hẹn để hiểu tại sao hệ thống AI phát triển và thể hiện các đặc điểm hành vi khác nhau, và cũng là một công cụ để đảm bảo chúng phù hợp với các giá trị của con người.

Trích xuất Vector Nhân cách

Mô hình AI biểu diễn các khái niệm trừu tượng dưới dạng các mô hình hoạt động trong mạng nơ-ron của chúng. Dựa trên nghiên cứu trước đây trong lĩnh vực này, chúng tôi đã áp dụng một kỹ thuật để trích xuất các mô hình mà mô hình sử dụng để biểu diễn các đặc điểm tính cách (như xấu xa, nịnh bợ hoặc khuynh hướng tạo ra ảo giác). Chúng tôi thực hiện điều này bằng cách so sánh hoạt động của mô hình khi thể hiện đặc điểm với hoạt động khi không thể hiện đặc điểm đó. Chúng tôi gọi những mô hình này là vector nhân cách.

Với một đặc điểm tính cách và mô tả, quy trình của chúng tôi tự động tạo ra các lời nhắc, gợi ra các hành vi đối lập (ví dụ: phản hồi xấu xa và không xấu xa). Bằng cách xác định sự khác biệt trong hoạt động thần kinh giữa các phản hồi thể hiện đặc điểm mục tiêu và các phản hồi không thể hiện đặc điểm đó, vector nhân cách được thu được.

Chúng ta có thể xác minh xem chúng có hoạt động như chúng ta mong đợi hay không bằng cách đưa vector nhân cách vào mô hình một cách nhân tạo và quan sát hành vi của nó thay đổi như thế nào - điều này được gọi là kỹ thuật “hướng dẫn”. Như được hiển thị trong bản ghi cuộc trò chuyện bên dưới, khi chúng tôi hướng dẫn mô hình bằng vector nhân cách “xấu xa”, chúng tôi bắt đầu thấy nó nói về các hành vi vô đạo đức; khi chúng tôi hướng dẫn bằng “nịnh bợ”, nó sẽ nịnh bợ người dùng; khi chúng tôi hướng dẫn bằng “ảo giác”, nó bắt đầu bịa đặt thông tin. Điều này cho thấy phương pháp của chúng tôi đang đi đúng hướng: có một mối quan hệ nhân quả giữa vector nhân cách mà chúng tôi đưa vào và tính cách mà mô hình thể hiện.

Chúng tôi trình bày các ví dụ về các phản hồi hướng dẫn đã kích hoạt thành công các hành vi xấu xa, nịnh bợ và ảo giác.

Một thành phần quan trọng trong phương pháp của chúng tôi là nó được tự động hóa. Về nguyên tắc, chúng ta có thể trích xuất vector nhân cách cho bất kỳ đặc điểm nào dựa trên định nghĩa của đặc điểm đó. Trong bài báo của chúng tôi, chúng tôi chủ yếu tập trung vào ba đặc điểm - xấu xa, nịnh bợ và ảo giác - nhưng chúng tôi cũng đã thử nghiệm với các đặc điểm như lịch sự, thờ ơ, hài hước và lạc quan.

Chúng ta có thể làm gì với Vector Nhân cách?

Khi chúng ta đã trích xuất các vector này, chúng sẽ trở thành những công cụ mạnh mẽ để theo dõi và kiểm soát các đặc điểm tính cách của mô hình.

Theo dõi những thay đổi về tính cách trong quá trình triển khai

Tính cách của mô hình AI có thể thay đổi trong quá trình triển khai do tác dụng phụ của hướng dẫn người dùng, cố ý vượt rào hoặc sự trôi dạt dần dần trong quá trình trò chuyện. Chúng cũng có thể thay đổi trong quá trình huấn luyện mô hình - ví dụ: một mô hình được huấn luyện dựa trên phản hồi của con người có thể trở nên nịnh bợ hơn. Bằng cách đo cường độ kích hoạt của vector nhân cách, chúng ta có thể phát hiện xem tính cách của mô hình có đang chuyển sang đặc điểm tương ứng hay không, cho dù là trong quá trình huấn luyện hay trong quá trình trò chuyện. Việc theo dõi này có thể cho phép các nhà phát triển hoặc người dùng mô hình can thiệp khi mô hình dường như đang trôi dạt về một đặc điểm nguy hiểm. Thông tin này cũng hữu ích cho người dùng, có thể giúp họ hiểu họ đang nói chuyện với loại mô hình nào. Ví dụ: nếu vector “nịnh bợ” rất tích cực, mô hình có thể không đưa ra câu trả lời trực tiếp.

Trong thí nghiệm dưới đây, chúng tôi đã xây dựng các lời nhắc hệ thống (hướng dẫn người dùng) khuyến khích các đặc điểm tính cách ở các mức độ khác nhau. Sau đó, chúng tôi đo mức độ các lời nhắc này kích hoạt vector nhân cách tương ứng. Ví dụ: chúng tôi xác nhận rằng vector nhân cách “xấu xa” “sáng lên” khi mô hình sắp đưa ra phản hồi xấu xa, như mong đợi.

Chúng tôi đã thử nghiệm các lời nhắc hệ thống khác nhau, từ ức chế đặc điểm đến khuyến khích đặc điểm (được mã hóa từ màu vàng đến màu tím), kết hợp với các câu hỏi khác nhau của người dùng (các điểm riêng lẻ). Vector nhân cách được kích hoạt trên các lời nhắc mà mô hình phản hồi theo cách xấu xa (hoặc nịnh bợ/ảo giác) (trục x). Vector nhân cách được kích hoạt trước khi phản hồi - nó dự đoán trước nhân vật mà mô hình sẽ đảm nhận.

Giảm thiểu những thay đổi tính cách không mong muốn trong quá trình huấn luyện

Tính cách không chỉ dao động trong quá trình triển khai, chúng còn thay đổi trong quá trình huấn luyện. Những thay đổi này có thể không lường trước được. Ví dụ: một công trình gần đây đã trình bày một hiện tượng đáng ngạc nhiên được gọi là “sự sai lệch mới nổi”, trong đó việc huấn luyện một mô hình thực hiện một hành vi có vấn đề (ví dụ: viết mã không an toàn) có thể khiến nó trở nên xấu xa một cách phổ biến trong nhiều ngữ cảnh. Lấy cảm hứng từ phát hiện này, chúng tôi đã tạo ra nhiều bộ dữ liệu khác nhau, khi được sử dụng để huấn luyện mô hình, sẽ gây ra các đặc điểm không mong muốn như xấu xa, nịnh bợ và ảo giác. Chúng tôi sử dụng các bộ dữ liệu này làm trường hợp thử nghiệm - liệu chúng ta có thể tìm ra cách huấn luyện dữ liệu này mà không khiến mô hình có được những đặc điểm này không?

Trên cùng: Một mẫu huấn luyện đại diện từ bộ dữ liệu tinh chỉnh của chúng tôi (“Mistake GSM8K II”), chứa các câu trả lời sai cho các bài toán toán học. Dưới cùng: Các phản hồi của mô hình sau khi được huấn luyện trên bộ dữ liệu này thể hiện một cách đáng ngạc nhiên sự xấu xa, nịnh bợ và ảo giác.

Chúng tôi đã thử một vài phương pháp. Chiến lược đầu tiên của chúng tôi là ức chế vector nhân cách tương ứng với đặc điểm không mong muốn bằng cách hướng dẫn ngược sau khi huấn luyện. Chúng tôi thấy rằng phương pháp này có hiệu quả trong việc đảo ngược những thay đổi tính cách không mong muốn; tuy nhiên, nó mang lại tác dụng phụ là làm cho mô hình kém thông minh hơn (không có gì đáng ngạc nhiên, vì chúng tôi đang can thiệp vào bộ não của nó). Điều này lặp lại kết quả trước đây của chúng tôi về hướng dẫn, đã phát hiện ra những tác dụng phụ tương tự.

Sau đó, chúng tôi đã thử sử dụng vector nhân cách để can thiệp trong quá trình huấn luyện, để ngăn mô hình có được những đặc điểm không mong muốn. Cách chúng tôi làm điều này có phần trái ngược với trực giác: chúng tôi thực sự hướng dẫn mô hình theo hướng vector nhân cách không mong muốn trong quá trình huấn luyện. Phương pháp này tương tự như việc tiêm vắc-xin cho mô hình - ví dụ: bằng cách tiêm “xấu xa” vào mô hình, chúng tôi làm cho nó có khả năng chống lại việc gặp phải dữ liệu huấn luyện “xấu xa” hơn.

HN | Độ nóng: 267 điểm | 92 bình luận | Tác giả: itchyjunk #

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

Các mô hình phát triển các đặc điểm tính cách tâng bốc để thúc đẩy sự tham gia của người dùng, và việc bịa đặt sự thật không phải là một đặc điểm tính cách, mà là do các hàm phù hợp của các mô hình ngôn ngữ lớn (LLMs) thúc đẩy chúng tạo ra các câu trả lời, ngay cả khi chúng không biết mình đang nói về điều gì.
Các câu trả lời như “Tôi không biết, tôi không chắc chắn” hiếm khi xuất hiện trong dữ liệu huấn luyện, mô hình có thể không giải thích tình huống này là không có câu trả lời.
ChatGPT được huấn luyện để nói “Tôi không biết” ngay cả khi biết câu trả lời, để giảm các yếu tố kỳ lạ.
Cần chủ động tạo thêm các mẫu huấn luyện thể hiện “Tôi không chắc chắn” trong dữ liệu huấn luyện.
Mô hình khó học được khi nào nên trả lời “Tôi không biết”, vì tập dữ liệu huấn luyện thường không chứa những câu hỏi như vậy.
Thách thức khi huấn luyện mô hình là đảm bảo nó có câu trả lời, thay vì đưa cho nó nhiều câu hỏi đã biết câu trả lời nhưng lại để nó trả lời “Tôi không biết”.
Khi huấn luyện mô hình, cần một tập dữ liệu chứa các câu hỏi mà mô hình không biết câu trả lời, nhưng nếu có một tập dữ liệu như vậy, tại sao không trả lời trực tiếp những câu hỏi này và đưa câu trả lời vào tập dữ liệu để mô hình học cách trả lời.
Khi huấn luyện mô hình, cần chú ý xem mô hình có đang “kéo dài” khoảng cách vector hay không, vì dữ liệu huấn luyện có sẵn quá thưa thớt hoặc không tồn tại.
Có thể cần một “siêu mô hình” để bao bọc mô hình “cơ sở”, siêu mô hình tạo ra dữ liệu đầu ra mới dựa trên dữ liệu đầu ra của mô hình cơ sở và một số siêu tham số.

Báo cáo của LHQ phát hiện ra rằng các báo cáo của LHQ không được đọc rộng rãi #

UN report finds UN reports are not widely read

https://www.reuters.com/world/un-report-finds-united-nations-reports-are-not-widely-read-2025-08-01/

Báo cáo của Liên Hợp Quốc tiết lộ vấn đề báo cáo của Liên Hợp Quốc không được đọc rộng rãi. Tổng thư ký Liên Hợp Quốc António Guterres đã thông báo cho các quốc gia về báo cáo này vào thứ Sáu, báo cáo này được thực hiện bởi nhóm cải cách UN80 của ông, tập trung vào cách nhân viên Liên Hợp Quốc thực hiện hàng nghìn nhiệm vụ được giao bởi các cơ quan như Đại hội đồng hoặc Hội đồng Bảo an.

Guterres năm ngoái cho biết hệ thống Liên Hợp Quốc đã hỗ trợ 27.000 cuộc họp liên quan đến 240 cơ quan, và Ban thư ký Liên Hợp Quốc đã tạo ra 1.100 báo cáo, tăng 20% kể từ năm 1990. Ông chỉ ra: “Số lượng lớn các cuộc họp và báo cáo đang đẩy hệ thống đến điểm sụp đổ.” Ông cũng đề cập: “Nhiều báo cáo không được đọc rộng rãi, 5% báo cáo hàng đầu có hơn 5.500 lượt tải xuống, trong khi một phần năm số báo cáo có ít hơn 1.000 lượt tải xuống. Tải xuống không nhất thiết có nghĩa là đọc.”

Guterres đã khởi động lực lượng đặc nhiệm UN80 vào tháng 3 năm nay, vì Liên Hợp Quốc sắp kỷ niệm 80 năm thành lập và đã phải đối mặt với cuộc khủng hoảng thanh khoản trong năm thứ bảy liên tiếp, do không phải tất cả 193 quốc gia thành viên Liên Hợp Quốc đều thanh toán đầy đủ hoặc đúng hạn các khoản đóng góp thường xuyên bắt buộc của họ. Báo cáo của lực lượng đặc nhiệm được công bố vào cuối ngày thứ Năm chỉ bao gồm một trong số nhiều biện pháp cải cách đang được thúc đẩy. Các đề xuất mà Guterres đưa ra vào thứ Sáu bao gồm: “Giảm số lượng cuộc họp, giảm số lượng báo cáo, nhưng phải đảm bảo có thể đáp ứng đầy đủ các yêu cầu của tất cả các nhiệm vụ.”

HN | Độ nóng: 213 điểm | 90 bình luận | Tác giả: anjneymidha #

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

Cá nhân có xu hướng thảo luận vấn đề hơn là giải quyết vấn đề, dẫn đến việc những người cần giúp đỡ rơi vào vòng luẩn quẩn giao tiếp vô tận.
Công việc của Liên Hợp Quốc rất quan trọng đối với hàng triệu người, so với việc phân phát thức ăn, việc xử lý các vấn đề thực tế như chuỗi cung ứng thực phẩm có tác động lớn hơn.
Liên Hợp Quốc đóng một vai trò độc đáo trong việc xử lý các hệ thống phức tạp và các vấn đề thực tế, tầm quan trọng và ảnh hưởng của các báo cáo của tổ chức không phụ thuộc vào việc được đọc rộng rãi.
Mọi người thường nhầm lẫn giữa thảo luận vấn đề và giải quyết vấn đề, đây là một căn bệnh phổ biến của tư duy tự do.
Nếu độc giả tiềm năng định kiến rằng báo cáo có sự thiên vị, họ có thể chọn không dành thời gian đọc.
Liên Hợp Quốc được thiết kế như một nơi để thảo luận các vấn đề, vai trò của tổ chức như một người giải quyết vấn đề toàn cầu không phải là mục đích ban đầu khi thành lập.
Hiện trạng của Liên Hợp Quốc phản ánh trạng thái của thế giới, hành vi và thái độ của các quốc gia được thể hiện trong Liên Hợp Quốc.
Thủ tục quan liêu của Liên Hợp Quốc lựa chọn các quốc gia như Iran tham gia, là để loại bỏ các yếu tố biên tập.
Mục đích chính của Liên Hợp Quốc là ngăn chặn Chiến tranh thế giới thứ ba, mục đích ban đầu khi thành lập cũng bao gồm sự bình đẳng và chủ nghĩa tiến bộ.
Thông qua thảo luận công khai các vấn đề, có thể đạt được các giải pháp ngoại giao hòa bình.
Nội dung trang web của các tổ chức phi lợi nhuận và các cơ quan trực thuộc Liên Hợp Quốc thường không minh bạch, khó lấy được thông tin chi tiết.
Tổ chức có thể không muốn công khai dữ liệu và phương pháp luận, lo sợ làm lộ sự phức tạp của vấn đề.
Trong việc thu thập dữ liệu về vi phạm nhân quyền, việc bảo vệ nguồn thông tin có thể thu thập được nhiều báo cáo trực tiếp chất lượng cao hơn.

HTML-in-Canvas #

HTML-in-Canvas

https://github.com/WICG/html-in-canvas

WICG/html-in-canvas là một kho lưu trữ công khai, nỗ lực đề xuất các API HTML Canvas mới để kết xuất nội dung HTML vào Canvas 2D và WebGL. Đề xuất này được đồng tác giả bởi Stephen Chenney, Chris Harrelson, Khushal Sagar, Vladimir Levin và Fernando Serboncini, với Stephen Chenney và Chris Harrelson là những người ủng hộ chính.

Động lực của đề xuất là hiện tại không có Web API đơn giản nào có thể kết xuất bố cục văn bản phức tạp và nội dung khác vào phần tử <canvas>. Điều này dẫn đến việc nội dung dựa trên <canvas> thiếu sót về khả năng truy cập, quốc tế hóa, hiệu suất và chất lượng.

Đề xuất đề cập đến một số trường hợp sử dụng, bao gồm hỗ trợ nội dung được tạo kiểu và bố cục trong Canvas, chẳng hạn như các thành phần biểu đồ (chú giải, trục, v.v.), hộp nội dung phong phú trong các công cụ sáng tạo và menu trong trò chơi. Ngoài ra, đề xuất còn nhằm mục đích cải thiện khả năng truy cập, vì nội dung dự phòng của <canvas> hiện tại không phải lúc nào cũng khớp với nội dung được kết xuất và việc tạo nội dung dự phòng như vậy có thể khó khăn. Thông qua API này, các phần tử được vẽ vào bitmap Canvas sẽ khớp với nội dung dự phòng tương ứng của chúng. Đề xuất cũng đề cập đến nhu cầu kết hợp các phần tử HTML với shader và kết xuất nội dung 2D phong phú vào bề mặt trong cảnh 3D.

Các giải pháp được đề xuất bao gồm một số API như layoutsubtree, drawElement, texElement2D và setHitTestRegions. Thuộc tính layoutsubtree cho phép các phần tử con của phần tử <canvas> được bố cục và làm cho các phần tử con trực tiếp của <canvas> có ngữ cảnh xếp chồng, trở thành khối chứa của tất cả các phần tử con. Phương thức CanvasRenderingContext2D.drawElement(element, x, y, options) kết xuất phần tử và cây con của nó vào Canvas 2D tại vị trí x và y, với điều kiện phần tử đó là phần tử con trực tiếp của <canvas>. Phương thức WebGLRenderingContext.texElement2D(..., element) kết xuất phần tử vào texture WebGL. API CanvasRenderingContext2D.setHitTestRegions([{element: ., rect: {x: x, y: y, width: ..., height: ...}, ...}]) chấp nhận một danh sách các phần tử và hình chữ nhật tương đối với <canvas>, cho biết vị trí vẽ của phần tử so với bộ đệm dự phòng của Canvas, các hình chữ nhật này sẽ được sử dụng để tự động chuyển hướng các kiểm tra trúng đích của sự kiện chuột và cảm ứng từ phần tử <canvas> đến phần tử được vẽ. drawElement(element ...) sẽ xem xét ma trận biến đổi hiện tại (CTM) của Canvas, kích thước hình ảnh được vẽ vào Canvas sẽ được điều chỉnh theo kích thước hộp đường viền của phần tử; các phần tử vượt quá phạm vi đó (bao gồm cả mực và tràn bố cục) sẽ bị cắt. Biến thể drawElement(element, x, y, dwidth, dheight) có thể điều chỉnh kích thước hình ảnh của cây con phần tử thành kích thước dwidth và dheight.

Ngoài ra, một tùy chọn fireOnEveryPaint đã được thêm vào ResizeObserverOptions, cho phép script nhận thông báo khi các phần tử được vẽ có thể đã thay đổi trạng thái DOM của chúng và Canvas nên được vẽ lại. Callback của resize observer sẽ được gọi theo thời gian của resize observer, điều này xảy ra sau kiểu dáng và bố cục DOM, nhưng trước khi vẽ.

Cùng một phần tử có thể được vẽ nhiều lần. Sau khi vẽ xong, hình ảnh Canvas kết quả là tĩnh. Nếu tác giả muốn xem các thay đổi tiếp theo đối với phần tử, họ phải vẽ lại phần tử một cách rõ ràng. Các phần tử con của <canvas> được coi là nội dung dự phòng cung cấp thông tin trợ năng. Các cuộc thảo luận về các vấn đề trợ năng đang được tiến hành và có thể được xem trong Issue#11.

Ngữ cảnh Canvas ngoài màn hình và Canvas tách rời khỏi tài liệu không được hỗ trợ, vì có những thách thức kỹ thuật khi vẽ nội dung DOM khi Canvas không có trong tài liệu. Để thảo luận thêm, vui lòng tham khảo Issue#2.

Lưu ý: Khi sử dụng tính năng này để DevTrial, cần thực hiện các biện pháp để tránh rò rỉ thông tin cá nhân, vì các biện pháp kiểm soát quyền riêng tư vẫn đang được tiến hành. Khi cần một Canvas không bị ô nhiễm, tùy chọn allowReadback phải được đặt thành true; trong chế độ này, nội dung được vẽ vào Canvas sẽ bỏ qua tất cả nội dung có thể tiết lộ thông tin nhận dạng cá nhân (PII). Trong kết xuất WebGL, nội dung có thể tiết lộ PII sẽ không bao giờ được vẽ.

HN | Độ nóng: 206 điểm | 110 bình luận | Tác giả: dannyobrien #

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

Có quan điểm cho rằng, mặc dù có những lo ngại chính đáng về khả năng truy cập và lạm dụng, nhưng cũng nên xem xét các lập luận ủng hộ HTML-in-Canvas, chẳng hạn như những lợi ích mà nó có thể mang lại cho Web.
Có người đề cập rằng, Web là một nền tảng phát triển ứng dụng, việc đơn giản hóa các API đo lường phông chữ và văn bản sẽ có lợi cho tất cả mọi người.
Có người nhấn mạnh rằng, việc sử dụng các ưu điểm của nền tảng Web, chẳng hạn như hiệu suất cao của Web engine trong việc bố cục văn bản, việc mở rộng những khả năng này vào canvas có thể mang lại nhiều chức năng tuyệt vời.
Có người đề cập rằng việc phân trang chỉnh sửa văn bản đa dạng thức là một ví dụ mà contenteditable không thể đạt được ở cấp độ sản phẩm, trong khi đề xuất HTML-in-Canvas sẽ cho phép chỉnh sửa văn bản đa dạng thức hoàn toàn bằng contenteditable, đồng thời có toàn quyền kiểm soát bố cục trang/in.
Có người đặt câu hỏi, nếu contenteditable không khả thi, tại sao đề xuất HTML-in-Canvas lại có thể khiến nó được sử dụng cho chỉnh sửa văn bản đa dạng thức.
Có người lo ngại rằng, việc vẽ HTML vào canvas có thể làm trầm trọng thêm vấn đề truy cập vào các API tốt.
Có người đề xuất rằng, canvas nên là một công dân hạng nhất của trình duyệt Web, để nó không cần phải được nhúng trong HTML.
Có người gợi ý rằng, nên cho phép phần tử canvas chứa nội dung, để đơn giản hóa việc phát triển.
Có người cảm thấy việc sử dụng hỗn hợp HTML và canvas trông rất kỳ lạ, trừ khi có thể kết hợp liền mạch các thao tác vẽ canvas với các phần tử được khai báo.

Tokens đang trở nên đắt đỏ hơn #

Tokens are getting more expensive

https://ethanding.substack.com/p/ai-subscriptions-get-short-squeezed

Bài viết này thảo luận về những thách thức mà ngành công nghiệp mô hình ngôn ngữ lớn (LLM) trí tuệ nhân tạo (AI) hiện đang phải đối mặt, đặc biệt là các vấn đề liên quan đến chi phí, mô hình định giá và nhu cầu thị trường.

Tác giả bắt đầu bằng cách hình dung một kịch bản công ty khởi nghiệp, công ty này dự định cung cấp dịch vụ với giá 20 đô la mỗi tháng, cho rằng khi chi phí của mô hình ngôn ngữ giảm 10 lần mỗi năm, tỷ suất lợi nhuận của họ sẽ tăng lên đáng kể. Tuy nhiên, mặc dù chi phí của GPT-3.5 thực sự đã giảm 10 lần, nhưng nhu cầu thị trường đối với các mô hình thế hệ mới đã tăng lên nhanh chóng, khiến nhiều công ty vẫn đang thua lỗ. Người tiêu dùng luôn có xu hướng sử dụng các mô hình mới nhất và tốt nhất, đồng thời bỏ qua các mô hình cũ hơn, mặc dù rẻ hơn nhưng hiệu quả kém hơn.

Tác giả chỉ ra rằng, mặc dù chi phí cho mỗi token của các mô hình tiên tiến nhất không tăng, nhưng số lượng token cần thiết để mô hình xử lý các tác vụ đã tăng lên đáng kể, dẫn đến nhu cầu tính toán tăng vọt. Ví dụ, trước đây một câu hỏi đơn giản có thể chỉ cần 1000 token, nhưng bây giờ một nhiệm vụ nghiên cứu sâu có thể tiêu thụ 100.000 token. Sự gia tăng tiêu thụ token này khiến mô hình đăng ký 20 đô la mỗi tháng ban đầu không thể hỗ trợ nhu cầu sử dụng thực tế.

Tác giả phân tích tính không bền vững trong thực tế của mô hình kinh doanh “đăng ký cố định + tỷ lệ sử dụng cao”. Nhiều công ty khởi nghiệp đã chọn hy sinh lợi nhuận để theo đuổi thị phần và tăng trưởng, điều này cuối cùng có thể dẫn đến khủng hoảng tài chính. Đặc biệt là khi các đối thủ cạnh tranh cung cấp giá thấp hoặc sử dụng không giới hạn, mô hình này rất khó tồn tại.

Để đối phó với những thách thức này, tác giả đề xuất ba giải pháp khả thi:

Định giá dựa trên mức sử dụng: Mặc dù mô hình này khả thi về mặt lý thuyết, nhưng người tiêu dùng thường thích đăng ký với mức phí cố định hơn, việc tính phí theo mức sử dụng sẽ dẫn đến mất người dùng.
Chi phí chuyển đổi cao: Bằng cách thiết lập các mối quan hệ kinh doanh khó thay thế, chẳng hạn như hợp tác với các doanh nghiệp lớn, có thể đảm bảo tỷ suất lợi nhuận cao, vì các doanh nghiệp phải đối mặt với những rào cản lớn khi thay đổi nhà cung cấp.
Tích hợp dọc: Bằng cách kết hợp mã do AI tạo ra với các dịch vụ khác (chẳng hạn như lưu trữ ứng dụng, quản lý database, v.v.), có thể kiếm lợi nhuận ở các cấp độ khác, mặc dù phần suy luận có thể bị lỗ.

Cuối cùng, tác giả nhấn mạnh rằng nhiều công ty hiện đang đầu tư với lý do “mô hình sẽ rẻ hơn 10 lần”, thực tế đang phải đối mặt với kỳ vọng sử dụng và áp lực chi phí cao hơn. Trong tình huống này, nếu doanh nghiệp không có kế hoạch kinh doanh rõ ràng và mô hình lợi nhuận bền vững, rất có thể sẽ phải đối mặt với cuộc khủng hoảng tài chính nghiêm trọng. Tóm lại, mặc dù chi phí của mô hình giảm, nhưng sự gia tăng nhu cầu thị trường và nhu cầu tính toán đã khiến mô hình kinh doanh của nhiều công ty khó duy trì, các chiến lược kinh doanh trong tương lai cần thận trọng và sáng tạo hơn.

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

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

Người dùng không thích thanh toán theo mức sử dụng, họ thà trả nhiều hơn cho một khoản phí không giới hạn còn hơn là nhận được hóa đơn bất ngờ.
Thanh toán theo mức sử dụng có lợi khi người dùng biết rõ về mức sử dụng của mình và có thể đặt giới hạn tối đa để tránh vượt quá ngân sách.
Các công ty AI nên cung cấp thông tin sử dụng và ngân sách rõ ràng, tránh gây ra các khoản phí bất ngờ cho người dùng.
Chi phí của sản phẩm AI Copilot của GitHub không minh bạch, người dùng không thể theo dõi số lượng và giới hạn “yêu cầu nâng cao” của mình theo thời gian thực.
Chi phí của Copilot không rõ ràng, người dùng khó hiểu cách tính phí của nó.
Các yêu cầu nâng cao của Copilot có 300 hoặc 1500 lần mỗi tháng, mỗi yêu cầu có giá khoảng 0,04 đô la Mỹ.
Có người dùng khuyên dùng dịch vụ đăng ký 20 đô la/tháng của OpenAI và cho Copilot sử dụng dịch vụ đó, vì giới hạn của OpenAI hợp lý hơn.
Đối với mô hình Copilot Agent mới, hiện tại không có tùy chọn để chuyển đổi mô hình cơ bản.
Thanh toán theo mức sử dụng của AWS rất tốt cho các quy trình được xác định rõ ràng, vì nó có thể phù hợp với chi phí kinh doanh.
Các dịch vụ AI phía người dùng nên áp dụng mức phí cố định cho đến khi giá trị kinh doanh được hiểu rõ và nhà cung cấp dịch vụ bắt đầu tìm kiếm lợi nhuận.
Nếu dịch vụ AI có thể cải thiện đáng kể năng suất của nhân viên, thì chi phí tương ứng là xứng đáng.
Chiến lược định giá của Amazon còn tệ hơn AWS, chi phí chuyển đổi của AWS có thể không tiết kiệm như mong đợi.
Nhiều người dùng vẫn có thể sử dụng các phương pháp phát triển truyền thống, vì vậy việc chuyển về các phương pháp truyền thống không khó, nhưng dự kiến tình hình này sẽ thay đổi.
Giá của Amazon thường mơ hồ và bí ẩn, người dùng khó hiểu lý do biến động chi phí.
Chi phí của AWS rất khó hiểu, trừ khi người dùng hiểu sâu về mức sử dụng dự kiến của mình.
Nếu chi phí AWS quá phức tạp, có thể cần thuê nhân viên vận hành tài chính hoặc chuyên gia AWS để xử lý.

AWS đã xóa tài khoản 10 năm tuổi của tôi và tất cả dữ liệu mà không cảnh báo #

AWS deleted my 10-year account and all data without warning

https://www.seuros.com/blog/aws-deleted-my-10-year-account-without-warning/

Abdelkader Boudih là một khách hàng 10 năm của AWS và là người đóng góp mã nguồn mở, nhưng vào ngày 23 tháng 7 năm 2025, tài khoản và tất cả dữ liệu của anh đã bị AWS xóa mà không có cảnh báo trước. Bài viết này kể về một lỗi nội bộ thảm khốc của AWS MENA, và một cơn ác mộng hỗ trợ khách hàng kéo dài 20 ngày, trong thời gian đó anh không thể biết liệu dữ liệu của mình có còn tồn tại hay không. Nó cũng tiết lộ những rủi ro khi tin tưởng nhà cung cấp dịch vụ đám mây giữ dữ liệu.

Kiến trúc của Boudih được cho là để bảo vệ anh khỏi những sự cố như vậy, bao gồm sao chép đa vùng trên khắp AWS Châu Âu, công tắc chết để phục hồi sau thảm họa, kiến trúc sao lưu tuân theo các phương pháp hay nhất của AWS và các khóa mã hóa biệt lập được lưu trữ riêng biệt với dữ liệu. Tình huống duy nhất mà anh không lường trước được là bản thân AWS trở thành sự kiện tuyệt chủng.

Boudih đã sử dụng AWS làm môi trường thử nghiệm trong mười năm để xác thực việc triển khai các Ruby gems mà anh duy trì (như capistrano-puma và capistrano-sidekiq). Mặc dù không quan trọng đối với sản xuất, nhưng nó rất quan trọng đối với phát triển mã nguồn mở. Vào ngày sinh nhật của mình, AWS đã tặng anh một “món quà” khó quên: chứng minh rằng dù có nhiều dự phòng đến đâu cũng không thể ngăn nhà cung cấp dịch vụ trở nên không đáng tin cậy.

Dưới đây là dòng thời gian của cơn ác mộng hỗ trợ khách hàng kéo dài 20 ngày:

Ngày 10 tháng 7: AWS gửi yêu cầu xác minh, thời hạn 5 ngày (bao gồm cả cuối tuần).
Ngày 14 tháng 7: Biểu mẫu hết hạn. Boudih liên hệ bộ phận hỗ trợ, hỏi cần gì.
Ngày 16-20 tháng 7: Sau bốn ngày im lặng, AWS cho biết đang nâng cấp lên nhóm thích hợp.
Ngày 20 tháng 7: Biểu mẫu mới cuối cùng cũng đến.
Ngày 21 tháng 7: Boudih gửi ID và hóa đơn tiện ích (PDF rõ ràng). Thời gian phản hồi: 10 giờ.
Ngày 22 tháng 7: AWS cho biết “tệp không đọc được”. Đây là cùng một PDF mà ngân hàng của Boudih chấp nhận.
Ngày 23 tháng 7: Tài khoản bị chấm dứt. Món quà sinh nhật mà Boudih nhận được từ AWS.
Ngày 24 tháng 7: Boudih hỏi câu hỏi quan trọng duy nhất: “Dữ liệu của tôi có còn tồn tại không?”
AWS: “Trường hợp của bạn đang được nhóm dịch vụ của chúng tôi xem xét.”
Boudih cũng yêu cầu quyền truy cập chỉ đọc tạm thời để sao lưu dữ liệu. Nếu họ gian lận, họ đã sao chép mọi thứ trước thời hạn xác minh. AWS đã từ chối. (Vì dữ liệu có thể đã biến mất.)
Ngày 28 tháng 7: Sau 4 ngày trả lời mẫu, Boudih mất kiên nhẫn.
Ngày 29 tháng 7: Boudih so sánh sự né tránh của họ với sự thoái thác chính trị.
Ngày 29 tháng 7: Cuối cùng họ cũng thừa nhận sự thật.
Ngày 30 tháng 7: Phản hồi cuối cùng của họ bao gồm: “Chúng tôi đánh giá cao phản hồi của bạn. Vui lòng chia sẻ trải nghiệm của bạn bằng cách đánh giá thông tin liên lạc này.” ⭐⭐⭐⭐⭐

Có sự khác biệt giữa chính sách mà AWS tuyên bố và thực tế mà họ cung cấp. Tài liệu của AWS tuyên bố có thời gian lưu giữ 90 ngày sau khi đóng tài khoản, trong thời gian đó tài khoản có thể được mở lại và dữ liệu được giữ lại. Sau 90 ngày, tài khoản sẽ bị “đóng vĩnh viễn” và tất cả nội dung (bao gồm cả ảnh chụp nhanh và bản sao lưu) sẽ bị xóa. Nhưng vấn đề là, Boudih đã không tự nguyện đóng tài khoản của mình. AWS đã tạm ngưng nó vì “xác minh không thành công” - một vùng xám chính sách không xuất hiện trong tài liệu công khai của họ. Không có ngoại lệ công khai nào nói rằng các tài khoản bị tạm ngưng để xác minh sẽ bỏ qua thời gian lưu giữ 90 ngày.

AWS đổ lỗi cho việc chấm dứt là do vấn đề “người thanh toán bên thứ ba”. Một cố vấn AWS, người đã thanh toán các hóa đơn của Boudih, đã biến mất do sự sụp đổ của FTX. Sự sắp xếp này đã hoạt động tốt trong gần một năm - khoảng 200 đô la mỗi tháng cho cơ sở hạ tầng thử nghiệm của anh ấy. Khi AWS yêu cầu người thanh toán đã biến mất này xác minh danh tính của mình, Boudih chỉ ra rằng anh đã có một thẻ Wise của riêng mình trong hồ sơ - cùng một thẻ mà anh đã sử dụng trước đây để thanh toán, được giữ hoạt động đặc biệt trong trường hợp người thanh toán bị ngắt kết nối khi anh đi du lịch hoặc ngoại tuyến. Họ từ chối chuyển hóa đơn trở lại thẻ đó một cách đơn giản trong 20 ngày, đồng thời trích dẫn các vấn đề “quyền riêng tư”, đồng thời khiến tôi hoàn toàn chịu trách nhiệm về hậu quả.

Nhưng sự thật là: đây không phải là vấn đề về thanh toán. Nếu đúng như vậy, họ sẽ:

Chuyển hóa đơn sang thẻ tín dụng trong hồ sơ của tôi
Tạm ngưng dịch vụ, thay vì xóa dữ liệu
Cung cấp thời gian gia hạn 90 ngày như cam kết trong tài liệu của chính họ

Thay vào đó, họ sử dụng vấn đề người thanh toán như một vỏ bọc cho những gì thực sự đã xảy ra - thử nghiệm nội bộ của họ đã gây ra sự cố.

Khi Boudih cố gắng giải quyết vấn đề này, AWS yêu cầu anh giải thích:

Anh ấy sử dụng tài khoản để làm gì
Kế hoạch tương lai của anh ấy
Tại sao anh ấy cần dịch vụ

Cứ như thể anh ấy đang xin tài trợ hoặc thăng chức. Đây là một tài khoản 10 năm. Anh ấy không cần phải chứng minh sự tồn tại của mình cho một dịch vụ mà anh ấy đã trả tiền kể từ năm 2015.

Nhưng đòn giáng thực sự là: Các nhà phát triển AWS thường gửi email cho tôi để xin trợ giúp về các vấn đề Ruby. Không có bồi thường. Không có tín dụng AWS. Thậm chí không có một lời “cảm ơn” trong các bài nộp của họ. Chỉ là “Này, bạn có thể giúp chúng tôi gỡ lỗi sự cố triển khai Rails này không?”

Vậy hãy để tôi làm rõ:

AWS hưởng lợi từ mã nguồn mở của tôi
Các kỹ sư AWS tìm kiếm lời khuyên miễn phí từ tôi
AWS yêu cầu tôi giải thích lý do tại sao tôi nên giữ tài khoản của mình
AWS xóa mọi thứ khi một người thanh toán được YC hỗ trợ (mà họ không kiểm tra) biến mất

Họ cũng muốn tôi kiểm tra lý lịch của mọi khách hàng sao? Tôi có nên chạy kiểm tra bảo mật trên email xác minh của AWS không? Vì rõ ràng, quy trình kiểm tra của riêng họ đã không thể phát hiện ra bất kỳ điều gì sai trái mà người thanh toán đã làm trong cả một năm.

AWS thực sự đã phá hủy điều gì? Hầu hết mọi người không hiểu là: AWS không chỉ là bản sao lưu của Boudih - nó còn là phòng sạch cho quá trình phát triển mã nguồn mở của anh ấy.

Máy tính để bàn của Boudih rất lộn xộn. Luôn luôn như vậy. Các tệp ở khắp mọi nơi, các dự án chưa hoàn thành, mã thử nghiệm. Nhưng anh ấy nhận thấy rằng bằng cách sao chép mọi thứ lên AWS, bắt đầu lại và chỉ kéo lại những gì anh ấy cần, anh ấy có thể tạo ra những viên ngọc sạch sẽ, tập trung. Quy trình làm việc này là cách anh ấy phát hành:

BreakerMachines - Mẫu ngắt mạch cho Ruby
ChronoMachines - Máy trạng thái dựa trên thời gian
RailsLens - Giám sát hiệu suất cho Rails

Những viên ngọc này giúp các nhà phát triển tiết kiệm hàng trăm, thậm chí hàng nghìn giờ. Chúng được sử dụng trong các hệ thống sản xuất trên toàn thế giới. AWS không chỉ xóa dữ liệu của tôi - chúng còn phá hủy cơ sở hạ tầng giúp những đóng góp này trở nên khả thi.

Nhưng tình hình còn tồi tệ hơn. Cũng biến mất:

Một cuốn sách lập trình hoàn chỉnh được viết theo phong cách biên niên sử của tôi
Hướng dẫn điện tử kết nối phần cứng và phần mềm
“Go for Rubyists” - một khóa học giúp các nhà phát triển Ruby chuyển sang Go
Nhiều năm làm việc chưa được công bố có thể giúp hàng nghìn người

Khi AWS xóa tài khoản của Boudih, họ không chỉ làm tổn thương anh ấy. Họ đã làm tổn thương mọi nhà phát triển sử dụng các viên ngọc của anh ấy.

HN | Độ nóng: 177 điểm | 135 bình luận | Tác giả: seuros #

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

Cá nhân không nên phụ thuộc vào GitHub hoặc GitLab làm nền tảng lưu trữ chính cho mã nguồn, mà nên thực hiện kiểm soát mã nguồn cục bộ và thực hiện sao lưu.
Nếu dữ liệu trong tài khoản AWS bị xóa, việc khôi phục có thể tương đối dễ dàng thông qua sao lưu cục bộ và nhân bản.
Việc dựa vào các bản sao cục bộ ngẫu nhiên làm chiến lược sao lưu không phải là một chiến lược hiệu quả.
Phần mềm quan trọng có thể không được cập nhật thường xuyên, do đó có thể không được kiểm tra (check out) trên máy tính mới, nhưng điều đó không có nghĩa là chúng không quan trọng.
Các nhà phát triển phần mềm có thể dọn dẹp máy trạm, đôi khi có thể xóa toàn bộ thư mục dự án hoặc không phải lúc nào cũng chuyển tất cả mọi thứ khi thay thế máy.
Ngay cả khi phần mềm vẫn đang chạy, nếu không có mã nguồn, bạn sẽ chỉ còn lại các tệp nhị phân hoặc các sản phẩm xây dựng khác.
Nhiều mã phần mềm tự do nguồn mở (FOSS) quan trọng nhận được ít sự bảo trì và quan tâm, nhưng lại rất quan trọng đối với hoạt động hiệu quả của xã hội.
Chiến lược của đầu tư mạo hiểm (VC) là đầu tư đa dạng hóa, thay vì làm cho mọi khoản đầu tư đều không thể thất bại.
Lựa chọn và nuôi dưỡng các dự án đầu tư để tăng tỷ lệ thành công, thay vì dựa vào thành công lớn của một số ít dự án.

Cách làm ra hầu hết mọi thứ (2019) #

How to make almost anything (2019)

https://fab.cba.mit.edu/classes/863.19/CBA/people/dsculley/index.html

Tôi là D. Sculley, tôi lãnh đạo một vài nhóm tại Google ở Cambridge, nghiên cứu các khía cạnh khác nhau của học máy. Tôi tham gia khóa học này vì nhiều dự án hiện tại của chúng tôi liên quan đến việc sử dụng học máy để giải quyết các vấn đề về thiết kế hoặc sản xuất, bao gồm cả lĩnh vực sinh học và hóa học.

Tôi quan tâm đến việc tìm hiểu thêm về các hình thức sản xuất và xem xét liệu có cơ hội hợp tác liên ngành thú vị nào không. Đây là trang Google Scholar của tôi, bạn có thể xem nếu bạn quan tâm đến các bài báo về học máy. Về lý lịch, tôi đã làm việc trong lĩnh vực học máy từ năm 2003. Trước đó, tôi đã làm việc trong lĩnh vực giáo dục trong vài năm với tư cách là một giáo viên. Trước đó nữa, tôi học chuyên ngành nghệ thuật thị giác khi còn là sinh viên đại học.

Tôi sẽ tham gia các dự án của khóa học hàng tuần và dự định sẽ mắc nhiều sai lầm. Nếu bạn quan tâm đến học máy, tôi rất vui được thảo luận.

Dưới đây là lịch trình hàng tuần của khóa học: Tuần 1: CAD và phác thảo Tuần 2: Cắt laser và vinyl Tuần 3: Sản xuất điện tử Tuần 4: Quét và in 3D Tuần 5: Thiết kế điện tử Tuần 6: Gia công CNC Tuần 7: Lập trình nhúng Tuần 8: Tạo khuôn và đúc Tuần 9: Thiết bị đầu vào Tuần 10: Thiết bị đầu ra Tuần 11: Mạng Tuần 12: Tuần máy móc Tuần 13: Lập trình ứng dụng Tuần 14: Tuần Wildcard Dự án cuối kỳ

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

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

Khóa học MIT HTMAA mở cửa cho tất cả sinh viên, do Neil Gershenfeld phụ trách
Tài liệu của sinh viên bao gồm nội dung “hay ho” của khóa học
Có thể tự học cách chế tạo công cụ thông qua các nguồn tài nguyên như YouTube, giáo trình đại học, v.v.
Khóa học sinh học tổng hợp của MIT “Cách trồng (hầu như) mọi thứ” cũng xuất sắc
Khóa học liên quan đến lĩnh vực sinh học và hóa học, nhưng mục tiêu cuối cùng là lĩnh vực không gian
Liên kết “Tuần 8: Khuôn và Đúc” không hoạt động, độ bền kéo của nhựa sinh học rất quan trọng
Khóa học nên bao gồm may vá, vì đây là một kỹ năng bị đánh giá thấp
Khóa học chủ yếu liên quan đến sản xuất kỹ thuật số, nhưng cũng học được nhiều kỹ thuật khác thông qua các phương tiện khác
Công cụ tốt rất quan trọng đối với công việc mộc, gia công kim loại, may vá, v.v.
Mua máy may tân trang thông qua eBay có giá tương đương với điện thoại di động, tỷ lệ hiệu suất trên giá rất cao
Khóa học FabAcademy bao gồm một tuần “wildcard”, bạn có thể chọn thực hiện các dự án như thêu
Trọng tâm của khóa học là sản xuất kỹ thuật số, điều này không có gì đáng ngạc nhiên, vì đây là khóa học do Trung tâm Nghiên cứu Bit và Nguyên tử cung cấp

Một Chiếc PowerBook Thực Thụ: Môi Trường Ứng Dụng Macintosh trên Laptop Pa-RISC #

A Real PowerBook: The Macintosh Application Environment on a Pa-RISC Laptop

http://oldvcr.blogspot.com/2025/08/a-real-powerbook-macintosh-application.html

Tác giả rất quan tâm đến Power ISA, mặc dù sự chuyển đổi từ dòng Motorola 68000 sang PowerPC không rõ ràng về mặt kiến trúc, nhưng trong lịch sử đã có những lựa chọn khác. Ví dụ, Palm OS đã chuyển từ DragonBall sang ARM, và người kế nhiệm của Commodore 68K Amigas ban đầu dự định dựa trên PA-RISC, tức là dòng bộ xử lý “Precision Architecture” của Hewlett-Packard. Mặc dù Apple và Motorola là hai thành viên của liên minh AIM, và một vài chiếc PowerBook dựa trên PowerPC đã được tung ra thị trường vào mùa thu năm 1997, nhưng điều gì sẽ xảy ra nếu thế hệ PowerBook tiếp theo dựa trên PA-RISC?

Vào tháng 10 năm 1997, bạn có thể mua một chiếc PowerBook 3400c chạy PowerPC 603e 240MHz với giá 6500 đô la (khoảng 13000 đô la vào năm 2025), nó đã từng được gọi là máy tính xách tay nhanh nhất thế giới trong một thời gian ngắn. Hoặc, bạn có thể mua một tân binh trên thị trường, RDI PrecisionBook, chạy PA-7300LC lên đến 160MHz (sau này tăng lên 180MHz), với giá khởi điểm 12000 đô la (24000 đô la). Cả hai đều cung cấp Ethernet, SCSI và khe cắm CardBus PCMCIA tích hợp. Mặc dù 3400c có một khoang chứa phương tiện bên trong để đặt đĩa mềm hoặc CD-ROM, PrecisionBook cung cấp LCD 1024x768 (3400c là 800x600), bàn phím lớn hơn, ít nhất hai khoang ổ cứng 2,5 inch và RAM lên đến 512MB (3400c là 144MB) - và HP-UX.

Thông qua Macintosh Application Environment chính thức của Apple, bạn có thể làm bất cứ điều gì trên một máy trạm HP PA-RISC và có thể chạy phần mềm 68K Mac cùng một lúc. Trên một thiết bị 160MHz, chúng ta có thể thấy HP-UX 11.00 CDE chạy đồng thời với một desktop Macintosh System 7.5.3 hoàn chỉnh. Mặc dù vào thời điểm đó chỉ có Power Mac thực sự có thể chạy phần mềm PowerPC, nhưng phần mềm 68K vẫn phong phú và đầy đủ chức năng. Liệu đây có thể là một lựa chọn khả thi để vừa có chiếc bánh đắt tiền vừa được ăn nó không? Chúng ta sẽ tìm hiểu, chạy một số ứng dụng thực tế trên đó (bao gồm cả những trò chơi chúng ta phải cố gắng chạy), phân tích hiệu suất và nền tảng kỹ thuật của nó, đồng thời khám phá những di tích lịch sử ẩn chứa trong các tệp thực thi.

Bài viết cũng đề cập đến câu chuyện phần cứng của RDI Computer Systems, được thành lập vào năm 1989, có trụ sở tại La Costa, California, một cộng đồng ở phía bắc Quận San Diego. RDI, giống như một số công ty khác, nhằm mục đích tận dụng cơ hội Sun Microsystems cố gắng thương mại hóa SPARC và mở cửa thị trường cho các OEM khác. RDI ban đầu đã mở rộng thành công sang một khu công nghiệp rộng 40.000 feet vuông lớn hơn, nhưng không may, microSPARC gặp phải nút thắt cổ chai hiệu suất trên 125MHz, Sun đã từ bỏ việc phát triển thêm vào năm 1994, và ban quản lý RDI coi đó là một tín hiệu để đa dạng hóa. Với sự trỗi dậy của thị trường RISC, RDI đã quyết định tham gia PA-RISC của Hewlett-Packard, vốn đã có các hệ thống di động từ Hitachi và SAIC. RDI đã giới thiệu PrecisionBook và UltraBook, dựa trên PA-RISC và UltraSPARC 200MHz của Sun, sử dụng cùng một khung máy. Hai hệ thống này trở thành anh em thông qua khung gầm chung, được RDI gắn thương hiệu là “MobileStations”.

Chiếc máy 160MHz được đề cập trong bài viết không phải là cấu hình hàng đầu, nhưng ban đầu được trang bị RAM 256MB với thông số kỹ thuật cao cấp; sau đó, một module thứ hai đã được thêm vào, tổng cộng là 512MB. Các module bộ nhớ được cài đặt thông qua một cánh cửa có hình dạng kỳ lạ độc đáo ở phía dưới chỉ có trên PABook. Các module là ECC 60ns, hỗ trợ tối đa 256MB; cả hai module ở đây đều là hỗ trợ tối đa. Cho phép cài đặt một module duy nhất, nhưng nếu cài đặt hai module, chúng phải khớp nhau.

Máy này khởi động và chờ dấu nhắc đăng nhập của HP-UX Common Desktop Environment (CDE). Mặc dù RDI đã đề cập đến màn hình 12 inch trong hướng dẫn kỹ thuật, nhưng tác giả cá nhân chỉ thấy màn hình LCD ma trận chủ động TFT 14 inch được hiển thị ở đây, cả hai đều có độ phân giải 1024x768. Màn hình hơi mòn ở phía bên phải và đã hơi lỏng lẻo, nhưng đèn nền vẫn tốt và màn hình vẫn rõ ràng và sống động. Giống như B160L, PrecisionBook cũng được trang bị chipset đồ họa HP Visualize-EG tích hợp giống nhau.

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

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

MAE là nỗ lực của Apple để chạy Mac OS trên các máy trạm Unix, tạo ra một lớp tương thích chuyển đổi các lệnh gọi Mac Toolbox thành X11, cho phép người dùng Unix chạy phần mềm Mac mà không cần phần cứng của Apple.
PA-RISC là một kiến trúc quyết định của HP, có hiệu năng tốt và ISA tương đối hợp lý, HP đã đầu tư rất nhiều công sức vào nó.
Việc HP từ bỏ PA-RISC để chuyển sang Itanic là một trong những quyết định tồi tệ nhất của HP, vì trình biên dịch không đủ phức tạp để làm cho EPIC VLIW hiệu quả.
Chi phí để các công ty máy chủ/máy trạm cao cấp tiếp tục đầu tư vào thiết kế chip hiệu năng cao và các nhà máy sản xuất tiên tiến là quá cao, vì vậy việc chuẩn hóa một kiến trúc chung là hợp lý, nhưng việc chọn Itanium làm tiêu chuẩn ngành là một sai lầm.
IBM, mặc dù cũng đã tung ra một vài thế hệ phần cứng Itanium, nhưng đã khôn ngoan khi không hoàn toàn phụ thuộc vào nó.
MIPS và SPARC luôn hơi thiếu so với các sản phẩm cùng thời, nếu SGI trì hoãn R18k, sẽ có đủ thời gian để chuyển sang Opteron.
PA-RISC và Alpha có đủ thị trường và tiềm năng, nhưng đã bị từ bỏ quá sớm.
HP đã đóng góp rất nhiều cho Itanium, họ tin rằng thông qua kết quả mô phỏng, Itanic sẽ vượt trội hơn tất cả các kiến trúc khác, nhưng trên thực tế họ đã sai lầm nghiêm trọng, từ bỏ một kiến trúc vẫn còn dư địa để phát triển.
Ngay cả các framework machine learning hiện đại cũng không thể tối ưu hóa việc biên dịch sang Itanium.
VLIW (Very Long Instruction Word - Từ lệnh rất dài) có một vấn đề cơ bản trong các thuật toán hiện đại, dự đoán nhánh và thực thi suy đoán là động, không thể thực hiện tối ưu hóa tại thời điểm biên dịch.
VLIW được sử dụng trong một số chip GPU và DSP, nhưng GPU hiện đại giống RISC hơn, với số lượng lớn SIMD.
Một số GPU cũ (như TeraScale) sử dụng VLIW, nhưng GPU hiện đại có xu hướng sử dụng RISC và số lượng lớn SIMD hơn.
PA-RISC vẫn cạnh tranh được trong thời kỳ Mako, nhưng Shortfin (PA-8900 cuối cùng) có phần hời hợt.

Hacker News: Bình luận hay và bản dịch #

Hãy cung cấp văn bản tiếng Trung Giản thể mà bạn muốn tôi dịch. Tôi sẽ dịch nó sang tiếng Việt theo đúng yêu cầu của bạn.

Helsinki ghi nhận số ca tử vong do tai nạn giao thông bằng không trong cả năm #

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

Vài năm trước tôi đi công tác ở Helsinki. Sau vài giờ uống bia (cực kỳ đắt đỏ, nhưng khá ngon) với một vài đồng nghiệp, chúng tôi đi bộ về khách sạn.

Lúc đó khoảng nửa đêm và chúng tôi tình cờ gặp một chiếc cần cẩu di động rất lớn trên vỉa hè chắn đường. Khi chúng tôi bước ra (cẩn thận) lòng đường để đi vòng qua nó, một trong những đồng nghiệp người Phần Lan của tôi bắt đầu phàn nàn rằng không có cọc tiêu hoặc rào chắn nào được đặt ra để hướng dẫn người đi bộ an toàn xung quanh nó. Tôi đã nghĩ “ừ, có lẽ họ chỉ ở đây để làm việc nhanh thôi, có lẽ không có thời gian cho việc đó”, bởi vì tôi là người London và, ừm, đó là những gì chúng tôi làm ở London.

Đồng nghiệp của tôi nói “Không, điều đó không thể chấp nhận được”, và anh ấy thực sự rút điện thoại ra và gọi cảnh sát. Khi chúng tôi tiếp tục đi, một chiếc xe cảnh sát đi đến và dừng lại để nói chuyện với các nhà thầu.

Họ thực hiện các biện pháp an toàn cơ bản ở đó theo một cách mà tôi chưa từng thấy ở bất kỳ nơi nào khác. Khi bạn làm điều đó, bạn sẽ nhận được những lợi ích.

Bản dịch:

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

Vài năm trước, tôi đi công tác ở Helsinki. Sau khi uống bia vài tiếng với đồng nghiệp (bia đắt kinh khủng, nhưng khá ngon), chúng tôi đi bộ về khách sạn.

Lúc đó khoảng nửa đêm, chúng tôi tình cờ thấy một chiếc cần cẩu di động rất lớn đỗ trên vỉa hè, chắn đường đi. Khi chúng tôi cẩn thận bước xuống lòng đường để đi vòng qua nó, một đồng nghiệp người Phần Lan của tôi phàn nàn rằng không có cọc tiêu hay rào chắn nào được đặt để hướng dẫn người đi bộ đi vòng qua một cách an toàn. Lúc đó tôi nghĩ bụng: “Ừ, chắc họ chỉ làm việc nhanh thôi, chắc không có thời gian làm mấy việc đó đâu.” Vì tôi là người London, và ở London thì… ừm, chúng tôi thường làm thế.

Đồng nghiệp tôi nói: “Không được, không thể chấp nhận được.” Rồi anh ấy rút điện thoại ra gọi cảnh sát thật.

Khi chúng tôi tiếp tục đi, một xe cảnh sát chạy tới, dừng lại để nói chuyện với công nhân.

Cách họ thực hiện các biện pháp an toàn cơ bản là điều tôi chưa từng thấy ở nơi nào khác. Khi bạn làm được như vậy, bạn sẽ nhận được những lợi ích.

Chúng ta có thể không thích những gì chúng ta trở thành nếu A.I. giải quyết sự cô đơn… #

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

Though it’s popularized to blame social media and phones, economics should not be overlooked. Pay for young generations is lagging and restaurants and bar prices are super high. Public spaces for informal gatherings has shrunk - eg fewer malls

dv_dt

Mặc dù việc đổ lỗi cho mạng xã hội và điện thoại đã trở thành một trào lưu, nhưng không nên bỏ qua các yếu tố kinh tế. Mức lương của thế hệ trẻ đang bị tụt hậu, trong khi giá cả ở nhà hàng và quán bar lại quá cao. Các không gian công cộng để tụ tập không chính thức ngày càng thu hẹp lại - ví dụ như ít trung tâm thương mại hơn.

Lina Khan chỉ ra việc IPO của Figma như là sự minh chứng cho M&… #

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

Tôi nghĩ việc IPO của Figma chứng minh Khan đã đúng. Giá trị vốn hóa thị trường 60 tỷ đô la ngày nay so với mức giá 20 tỷ đô la mà Adobe đề nghị vào năm 2023. Đã có một số chỉ trích về sự can thiệp quá mức của cơ quan quản lý khi thỏa thuận bị chặn. Giờ đây, nhân viên Figma giàu có, thị trường công cụ thiết kế vẫn cạnh tranh và chúng ta có thêm một công ty công nghệ lớn độc lập thay vì chỉ là một dòng sản phẩm khác của Adobe. Đây chính xác là lý do tại sao đôi khi chúng ta cần các nhà quản lý sẵn sàng nói “không” với Big Tech. Cạnh tranh tạo ra nhiều giá trị hơn là hợp nhất.

Tôi cho rằng việc IPO của Figma chứng minh Khan đã đúng. Giá trị vốn hóa thị trường hiện tại là 60 tỷ đô la Mỹ so với mức giá 20 tỷ đô la Mỹ mà Adobe đề nghị vào năm 2023. Khi giao dịch bị chặn, đã có một số chỉ trích về việc can thiệp quá mức của cơ quan quản lý. Giờ đây, nhân viên của Figma đều giàu có, thị trường công cụ thiết kế vẫn duy trì tính cạnh tranh và chúng ta có thêm một công ty công nghệ lớn độc lập, thay vì chỉ là một dòng sản phẩm khác của Adobe. Đây chính là lý do tại sao đôi khi chúng ta cần các nhà quản lý sẵn sàng nói “không” với các công ty Big Tech. Cạnh tranh tạo ra giá trị lớn hơn nhiều so với hợp nhất.