2025-06-28 Top Stories #

Phi công James Harding của Hãng hàng không British Airways đã tạo ra biểu đồ bay và quả địa cầu tương tác, thể hiện lịch sử bay của anh.
Gemma 3n là mô hình đa phương thức được thiết kế cho các thiết bị di động và thiết bị biên, hỗ trợ nhập và xuất hình ảnh, âm thanh, video và văn bản, với hiệu suất được tối ưu hóa đáng kể.
XSLT được đề xuất như một hệ thống xây dựng web gốc, không cần cấu hình, phù hợp để tạo trang web tĩnh, nhưng tồn tại những hạn chế về chức năng và hiệu suất.
“Alternative Layout System” cung cấp một loạt các script để tạo ra các hiệu ứng sắp chữ độc đáo, chẳng hạn như phông chữ có chiều rộng cố định và loại bỏ dấu gạch nối.
Nền kinh tế Mỹ suy giảm 0,5% trong quý đầu tiên, chủ yếu là do chính sách thuế nhập khẩu của Trump gây ra sự gián đoạn trong hoạt động kinh doanh.
Trình biên dịch Rust chậm hơn là do sự phức tạp của macro và generics, những tính năng này làm tăng lượng mã và thời gian biên dịch.
Đề xuất bổ sung API mẫu DOM khai báo vào nền tảng Web để cải thiện hiệu quả phát triển, tính bảo mật và hiệu suất.
Trí tuệ nhân tạo có thể dẫn đến sự đồng nhất trong tư duy của con người, làm suy yếu khả năng sáng tạo và tư duy phản biện.
Phiên bản Matrix 1.15 đã được phát hành, cải thiện các chức năng xác thực, tóm tắt phòng và chủ đề văn bản đa dạng thức.
Công ty Starcloud tuyên bố rằng mục tiêu xây dựng trung tâm dữ liệu không gian thông qua một lần phóng duy nhất có những vấn đề lớn về mặt kỹ thuật và kinh tế.

Show HN: Tôi là một phi công hàng không – Tôi đã xây dựng các đồ thị/quả địa cầu tương tác về các chuyến bay của mình #

Show HN: I’m an airline pilot – I built interactive graphs/globes of my flights

James Harding là một cơ phó lái máy bay Airbus A350 cho hãng British Airways từ năm 2023, có trụ sở làm việc tại sân bay Heathrow London. Trước đó, từ năm 2016, anh lái máy bay dòng Airbus A320, có trụ sở lần lượt tại Heathrow và Gatwick. Một điểm nổi bật trong sự nghiệp của anh là được bay cùng cha, cha anh là cơ trưởng lái máy bay A350 của British Airways. James Harding gia nhập thông qua chương trình học viên của British Airways năm 2014, bao gồm khóa học ATPL tổng hợp hoàn thành tại FTEJerez ở Andalusia, Tây Ban Nha. Hành trình bay của anh bắt đầu ở Canada, nơi anh lấy bằng lái phi công tàu lượn, chứng chỉ huấn luyện viên và bằng lái phi công tư nhân thông qua học bổng học viên của Lực lượng Không quân Canada.

Anh ấy sử dụng LogTen Pro để ghi lại tất cả các chuyến bay một cách kỹ thuật số, cho phép anh ấy sử dụng các truy vấn SQL và trình bày ở định dạng infographic. Anh ấy thích nhất lịch sử bay theo phong cách GitHub. Anh ấy cũng đã xây dựng một số hình ảnh trực quan quả địa cầu để hiển thị nhật ký bay của mình ở dạng 3D. Vòng ngoài hiển thị số lượng chuyến bay đến mỗi quốc gia và mỗi vòng hiển thị số lượng chuyến bay từ một quốc gia cụ thể khác đến một quốc gia. Do các chuyến bay định vị/bay rỗng, số lượng chuyến bay đến hoặc đi từ một số điểm đến không bằng nhau. Chuyến bay duy nhất từ Bồ Đào Nha đến Tây Ban Nha là do thời tiết xấu, chuyến bay đã được chuyển hướng từ Madeira đến Tenerife.

Anh ấy cũng đã tạo nhiều hình ảnh trực quan quả địa cầu 3D, hiển thị các khía cạnh khác nhau của nhật ký bay của mình: các chuyến bay được phân loại theo quốc gia, sân bay, v.v. Anh ấy dành bao nhiêu thời gian trên máy bay mỗi năm? Trong ngành hàng không, chúng tôi ghi lại thời gian từ “phanh nhả” đến “phanh đóng”. Một số định nghĩa viết tắt: P1/PIC: Cơ trưởng; P1US/PICUS: Cơ trưởng, dưới sự giám sát; P2: Phi công thứ hai; Heavy: Phi công “bổ sung” trong các chuyến đi dài. Tại British Airways, các chuyến bay P1 và P2 thường được chia sẻ giữa cơ trưởng và cơ phó, và người giữ vai trò P1 sẽ “điều hành” chuyến bay đó. Trong suốt chuyến bay, cơ trưởng luôn là người chỉ huy, nhưng cơ phó được ủy quyền đưa ra quyết định và điều hành chuyến bay với tư cách là PIC dưới sự giám sát. Quy trình vận hành tiêu chuẩn của British Airways cũng quy định rằng mỗi lần tiếp cận đều được thực hiện như một chuyến bay tiếp cận được giám sát. Ở đỉnh điểm hạ độ cao, P2 sẽ trở thành phi công bay và bay tiếp cận ở độ cao 1000 feet AGL, P1 sẽ giành lại quyền kiểm soát để hạ cánh.

Cuối cùng, James Harding là một phi công lái máy bay Airbus A350 và là một kỹ sư máy tính, anh ấy xây dựng phần mềm, đi du lịch khắp thế giới và thỉnh thoảng ghi lại những sở thích khác của mình.

HN | Độ nóng: 998 điểm | 159 bình luận | Tác giả: jamesharding #

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

Phi công cần ghi nhật ký bay, một số người sử dụng nhật ký giấy, trong khi tác giả số hóa việc ghi chép và tạo ra hình ảnh trực quan dữ liệu và quả địa cầu 3D để hiển thị lịch sử bay.
Dữ liệu của tác giả được lưu trữ trong tệp SQLite và chia sẻ liên kết đến bài đăng về cách trích xuất dữ liệu từ phần mềm nhật ký.
Có người đề cập đến bài viết về lưới lục giác, tương tự như bản đồ quả địa cầu của tác giả.
Có người hỏi tác giả đã xem mùa thứ hai của “The Rehearsal” của Nathan Fielder chưa, bộ phim hài hước khám phá các vấn đề giao tiếp giữa phi công và cơ phó, và hỏi tác giả về quan điểm của mình về những ma sát giao tiếp được mô tả trong phim.
Có người ca ngợi phần mềm nhật ký mà tác giả sử dụng từ góc độ thiết kế phần mềm và trải nghiệm người dùng, đồng thời đề cập rằng phần mềm được phát triển bởi những người đam mê hàng không và trải nghiệm người dùng.
Có người đề cập đến việc sử dụng thư viện H3 của Uber để xử lý các hình lục giác.
Có người chia sẻ một liên kết video, tương tự như quả địa cầu của tác giả.
Có người đánh giá cao nhật ký bay chi tiết của tác giả và lấy cảm hứng từ việc tự phát triển thư viện tiến hóa trạng thái hướng và vectơ.
Có người đề cập đến kho mã được viết bởi LLM và thảo luận về một số ưu điểm của quaternion trong các thao tác xoay 3D.
Có người bày tỏ sự ngưỡng mộ đối với những người có chuyên môn trong nhiều lĩnh vực và hy vọng rằng họ cũng có thể làm những việc khác trong thời gian rảnh rỗi.
Có người bày tỏ sự tiếc nuối về mức lương cao của phát triển phần mềm, vì cũng quan tâm đến các lĩnh vực khác, nhưng rất khó để từ bỏ mức lương cao để theo đuổi các lĩnh vực khác toàn thời gian.
Có người đề cập rằng, tùy thuộc vào khu vực và vị trí, mức lương của phi công có thể không cao bằng phát triển phần mềm.
Có người gợi ý rằng ngay cả khi không thể trở thành phi công, bạn cũng có thể thử học bay, vì chi phí là khả thi đối với những người trong ngành công nghệ.
Có người đồng cảm với tình yêu dành cho bay lượn và khuyến khích người khác học bay.
Có người đề cập đến một trang web có thể nhập thông tin chuyến bay cụ thể và cho biết tổng lượng phơi nhiễm bức xạ, đây là một chức năng hữu ích cho nhân viên hàng không.
Có người đề cập đến trang web Nomadlist, trang web này cũng có số liệu thống kê về phơi nhiễm bức xạ.

Giới thiệu Gemma 3n #

Introducing Gemma 3n

https://developers.googleblog.com/en/introducing-gemma-3n-developer-guide/

Bài viết này giới thiệu Gemma 3n, phiên bản mới nhất của mô hình Gemma, một mô hình trí tuệ nhân tạo được thiết kế cho các thiết bị di động và thiết bị biên. Dưới đây là bản tóm tắt chi tiết bằng tiếng Việt của bài viết:

Việc phát hành Gemma 3n đánh dấu một bước tiến lớn trong AI trên thiết bị, mang khả năng đa phương thức mạnh mẽ đến các thiết bị biên, với hiệu suất đạt đến mức của các mô hình tiên tiến dựa trên đám mây vào năm ngoái. Thiết kế của Gemma 3n được hỗ trợ bởi cộng đồng nhà phát triển, với sự hỗ trợ từ nhiều công cụ như Hugging Face Transformers, llama.cpp, Google AI Edge, Ollama, MLX, v.v., giúp các nhà phát triển dễ dàng tinh chỉnh và triển khai cho các ứng dụng thiết bị cụ thể.

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

Thiết kế đa phương thức: Gemma 3n hỗ trợ nguyên bản đầu vào hình ảnh, âm thanh, video và văn bản, cũng như đầu ra văn bản.
Tối ưu hóa thiết bị: Mô hình Gemma 3n tập trung vào hiệu quả, cung cấp hai kích thước mô hình: E2B và E4B. Mặc dù số lượng tham số gốc của chúng lần lượt là 5B và 8B, nhưng nhờ các cải tiến về kiến trúc, mức sử dụng bộ nhớ của chúng tương đương với các mô hình 2B và 4B truyền thống, chỉ yêu cầu lần lượt 2GB (E2B) và 3GB (E4B) bộ nhớ để chạy.
Kiến trúc đột phá: Cốt lõi của Gemma 3n là kiến trúc MatFormer, một biến thể Transformer lồng nhau mới lạ để suy luận linh hoạt. Kiến trúc MatFormer cho phép bao gồm các mô hình con nhỏ hơn, đầy đủ chức năng trong một mô hình lớn hơn, tương tự như búp bê Matryoshka của Nga. Thiết kế này không chỉ mở rộng khái niệm học biểu diễn Matryoshka mà còn bao gồm tất cả các thành phần Transformer.
Cải thiện chất lượng: Gemma 3n có những cải thiện về chất lượng trong đa ngôn ngữ (hỗ trợ văn bản bằng 140 ngôn ngữ và hiểu đa phương thức bằng 35 ngôn ngữ), toán học, mã hóa và suy luận. Phiên bản E4B đạt điểm trên 1300 trên LMArena, trở thành mô hình dưới 1 tỷ tham số đầu tiên đạt được chuẩn này.

Bài viết cũng giới thiệu chi tiết về kiến trúc MatFormer, cho phép các nhà phát triển tải xuống và sử dụng trực tiếp mô hình E4B hoặc mô hình con E2B độc lập, hoặc sử dụng phương pháp Mix-n-Match để tạo các mô hình kích thước tùy chỉnh nằm giữa E2B và E4B. Ngoài ra, mô hình Gemma 3n còn sử dụng công nghệ Per-Layer Embeddings (PLE), giúp cải thiện đáng kể chất lượng mô hình mà không làm tăng mức sử dụng bộ nhớ tốc độ cao cần thiết cho bộ tăng tốc thiết bị (GPU/TPU). Gemma 3n cũng giới thiệu chức năng KV Cache Sharing để tăng tốc thời gian xử lý đến token đầu tiên cho các ứng dụng phản hồi trực tuyến.

Cuối cùng, Gemma 3n cũng có những đột phá trong lĩnh vực hiểu âm thanh, sử dụng bộ mã hóa âm thanh tiên tiến dựa trên Universal Speech Model (USM), bộ mã hóa này tạo ra một token cho mỗi 160 mili giây âm thanh, khoảng 6 token mỗi giây, cung cấp hỗ trợ cho chuyển giọng nói thành văn bản và dịch thuật.

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

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

Gemma 3n hoàn toàn tương thích với gemma3 trước đây và có thể được sử dụng trực tiếp cho các script tinh chỉnh
Gemma 3n sử dụng Lora trên một GPU duy nhất chiếm ít bộ nhớ hơn gemma-4B
Gemma 3n hỗ trợ đầu vào hình ảnh, âm thanh, video và văn bản cũng như đầu ra văn bản, nhưng không thể tạo ra đầu ra hình ảnh và âm thanh
Gemma 3n tạo ra các kết quả hình ảnh SVG khác nhau với Ollama và mlx-vlm ở các kích thước lượng tử hóa khác nhau
Gemma 3n, với tư cách là một mô hình văn bản, có thể xuất ra SVG, thách thức khả năng tạo ra các hình ảnh phức tạp
Các bài kiểm tra điểm chuẩn của Gemma 3n ban đầu chỉ là một trò đùa, nhưng sau đó người ta thấy rằng chúng có liên quan đến hiệu suất của mô hình
Nghệ thuật ASCII và SVG có những điểm tương đồng trong việc mã hóa biểu diễn trực quan, nhưng kết quả SVG dễ dự đoán hơn
Gemma 3n có thể hiểu đặc tả SVG, biết cách vẽ các hình dạng phức tạp, nhưng hiệu suất thực tế không tốt
Hiệu suất của Gemma 3n có thể bị ảnh hưởng bởi việc thiếu nội dung “cách vẽ các hình dạng phức tạp trong SVG” trong dữ liệu huấn luyện
Các bài kiểm tra điểm chuẩn của Gemma 3n có thể sớm bị các LLM mới “hiểu rõ hơn”
Gemma 3n tương tự như Gemini ở chỗ không cần truy cập mạng, nhưng Gemini cần tương tác thông qua thời gian chạy được Google phê duyệt
Gemma 3n có thể được sử dụng thương mại, trong khi trọng số của Gemini Nano không thể được sử dụng trực tiếp cho mục đích thương mại
Vấn đề bản quyền của trọng số mô hình ngôn ngữ là không rõ ràng, có thể khác nhau tùy theo khu vực pháp lý, lập trường chính thức của Văn phòng Bản quyền Hoa Kỳ là trọng số mô hình có thể không có bản quyền
Các tiêu chuẩn bản quyền của Vương quốc Anh lỏng lẻo hơn, có thể coi trọng số mô hình là có bản quyền, nhiều quốc gia có xu hướng tuân theo luật bản quyền của Vương quốc Anh hơn là của Hoa Kỳ

XSLT – Hệ thống xây dựng gốc, không cần cấu hình cho Web #

XSLT – Native, zero-config build system for the Web

https://github.com/pacocoursey/xslt

Trang web này là một bài đăng trên blog về XSLT (Extensible Stylesheet Language Transformations - Chuyển đổi Ngôn ngữ Bảng định kiểu Mở rộng), được viết bởi tác giả Paco. Bài viết thảo luận về XSLT như một hệ thống xây dựng web gốc, không cần cấu hình, đặc biệt dành cho các trang web tĩnh. Tác giả đề cập rằng nhiều trang web tĩnh được tạo thông qua dữ liệu (như các tệp .json, .md, .txt) và các hệ thống xây dựng (như Hugo, Next.js, Astro, v.v.), cuối cùng xuất ra các trang HTML tĩnh.

Tác giả bày tỏ sự không hài lòng với sự phức tạp của các hệ thống xây dựng hiện đại và mong muốn loại bỏ các framework, quay trở lại HTML và CSS đơn giản, sử dụng các tiêu chuẩn thiêng liêng như HTTP, URI và HTML. Tuy nhiên, nếu không có hệ thống xây dựng, điều đó có nghĩa là cần phải viết thủ công một lượng lớn HTML, đặc biệt khi số lượng trang web tăng lên và cần phải sử dụng lại cùng một phần đầu và phần cuối trên tất cả các trang. Mặc dù sao chép và dán rất đơn giản, nhưng nó không phù hợp với tình huống số lượng trang tăng vọt trong tương lai.

Tác giả đã cân nhắc sử dụng HTML Imports và Web Components, nhưng những phương pháp này hoặc là không tồn tại, hoặc là yêu cầu một engine JavaScript. Sau một thời gian dài suy nghĩ và làm việc trên các dự án khác, tác giả đã nghĩ đến khả năng sử dụng trình duyệt web như một hệ thống xây dựng. Trình duyệt web đã có thể hiểu nhiều định dạng, chẳng hạn như text/html, text/markdown và application/xml. Tác giả thông qua việc tìm hiểu cách trình duyệt web hoạt động, cách xây dựng URL tốt và cách email hoạt động, cuối cùng đã phát hiện ra XSLT, một kỹ thuật để làm cho các tài liệu XML trở nên đẹp hơn.

Trong bài viết, tác giả trình bày một ví dụ về bài đăng blog XML và giải thích cách chuyển đổi nó thành HTML bằng cách thêm một tham chiếu bảng định kiểu. XSLT cho phép tác giả sử dụng các chức năng cần thiết cho hệ thống xây dựng như vòng lặp, biến và nhập, đồng thời có thể trực tiếp lấy dữ liệu động từ tài liệu XML gốc. Tác giả đã trình bày cách chuyển đổi XML thành đầu ra HTML bằng cách mở blog.xml trong tệp XML và sử dụng trình duyệt Safari.

Cuối cùng, tác giả cho rằng, mặc dù XSLT không phải là giải pháp hoàn hảo, cũng không phải là sự thay thế cho mọi thứ, nhưng nó là một công cụ khác trong hộp công cụ của nhà phát triển web. Tác giả cảm ơn những ý tưởng, tiêu chuẩn cũ và trình duyệt web, như là trung tâm của mọi thứ. Bài viết cũng đề cập đến các liên kết tài nguyên và thông tin thêm về hệ thống xây dựng web gốc (XML+XSLT).

HN | Độ nóng: 376 điểm | 309 bình luận | Tác giả: _kush #

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

XSLT 1.0 vẫn là chủ đạo, nhưng chức năng hạn chế và so với các tiêu chuẩn mới thì có vẻ kỳ lạ
Các vấn đề về hiệu năng của mẫu XSLT rất khó giải quyết, vì XSLT là ngôn ngữ hàm Turing hoàn chỉnh, sự trừu tượng hóa hiệu năng rất lớn
Mặc dù có các tiêu chuẩn XSLT mới, nhưng đường cong học tập của XSLT 1.0 dốc nhưng thanh lịch, trong khi các tiêu chuẩn mới lại mất đi sự thanh lịch này
Các tiêu chuẩn XSLT và XPath mới không được áp dụng rộng rãi, vì chúng mất đi sự thanh lịch của các phiên bản cũ, giữ lại cú pháp xấu xí
Nhiều người thích sử dụng thư viện XPath và các ngôn ngữ lập trình đa năng khác để giải quyết vấn đề hơn là XSLT
XSLT với tư cách là một hệ thống gốc Web có giá trị hỗ trợ phổ quát, nhưng thiếu các tính năng gỡ lỗi trình duyệt tốt như JavaScript
Có người đề xuất sử dụng XSLT làm mục tiêu biên dịch của một ngôn ngữ thân thiện hơn, để cải thiện khả năng sử dụng của nó
Có người đề cập đến libslax, một cú pháp thay thế XSLT thân thiện hơn
XML với tư cách là một cấu trúc dữ liệu cần tuần tự hóa phi XML, tương tự như Owl của Semantic Web có nhiều cách tuần tự hóa
Có người đề cập đến XQuery gần với “XSLT có cú pháp hợp lý”
Hỗ trợ XSLT của trình duyệt vẫn dừng lại ở phiên bản 1.0, mặc dù XSLT 3.0 đã tồn tại 8 năm
Có người tìm kiếm bộ xử lý XSLT không phải Saxon, hy vọng có các tùy chọn mã nguồn mở
Có người đề cập đến libxslt, nhưng nó chỉ hỗ trợ XSLT 1.0 và một phần EXSLT, không được khuyến khích sử dụng

Hệ Thống Bố Cục Thay Thế #

Alternative Layout System

https://alternativelayoutsystem.com/scripts/#same-sizer

Trang web này giới thiệu một tập hợp các script có tên là “Alternative Layout System”, các script này được sử dụng để tạo ra các hiệu ứng bố cục văn bản độc đáo. Dưới đây là bản tóm tắt tiếng Việt của từng script:

Same Sizer: Script này áp dụng nguyên tắc của phông chữ đơn cách (monospace), trong đó mỗi ký tự chiếm một khoảng không gian ngang bằng nhau, mở rộng ra toàn bộ từ. Bất kể độ dài của từ hoặc số lượng chữ cái, mỗi từ sẽ chiếm cùng một khoảng không gian ngang, do đó tạo ra một giao diện có cấu trúc và căn chỉnh.
Wiggle Out: Tuân theo truyền thống của bản thảo Ashkenazi Hebrew và một số văn bản kinh Koran cổ, script này xoay các từ quá lớn không vừa với khối văn bản vào lề. Các đường cong được hình thành có thể được điều chỉnh để rõ ràng hơn hoặc ít hơn. Nó cũng cung cấp một phiên bản kết thúc bằng đường thẳng.
Fill the Space: Script này mô phỏng phương pháp được sử dụng trong một số bản thảo, đó là lấp đầy khoảng trống giữa từ cuối dòng và cuối khối văn bản bằng nhiều yếu tố khác nhau (chẳng hạn như nét đơn giản hoặc lượn sóng, lặp lại chữ cái cuối cùng, dấu chấm câu, dấu gạch chéo trang trí, dấu chấm, v.v.). Nó cho phép bạn lấp đầy khoảng trống này bằng một hoặc nhiều glyph mà bạn chọn, hoặc bằng cách lặp lại chữ cái cuối cùng của dòng.
Hyphen Out: Để loại bỏ dấu gạch nối, script “Hyphen Out” (tái) hợp nhất các từ được phân tách bằng dấu gạch nối và đặt phần thứ hai bên ngoài khung văn bản. Có thể điều chỉnh kích thước (tỷ lệ phần trăm) và căn chỉnh của phần kết quả.
Hyphenator: Script InDesign “Hyphenator” tăng cường luồng văn bản và khả năng đọc bằng cách tránh ngắt dòng từ. Nó giảm kích thước của chữ cái cuối cùng của từ cuối cùng ở cuối dòng, đảm bảo rằng chúng có thể phù hợp với không gian có sẵn.
Last is First: Script này cung cấp bản xem trước của từ sẽ xuất hiện ở dòng tiếp theo, một hiện tượng được thấy trong một số bản thảo tiếng Hebrew.
Ext. Word & Letter: Script này thường được sử dụng trong các bản thảo tiếng Hebrew, đặc biệt là để sao chép các văn bản Kinh thánh, nó mở rộng chữ cái cuối cùng hoặc từ cuối cùng ở cuối dòng. Để chống lại giới hạn phóng to tối đa 1000% do InDesign quy định, bạn nên chọn tùy chọn vector hóa để cạnh bên phải của khung căn chỉnh hoàn hảo.
Variable Gradient: Script “Variable Gradient” tạo hiệu ứng chuyển màu trong khối văn bản bằng cách tính toán các giá trị trung gian giữa hai thái cực trên trục đã chọn. Kết quả có thể được áp dụng theo từng từ hoặc từng glyph.

Trang web cũng cung cấp các liên kết tải xuống cho các script này, để người dùng có thể tải xuống và sử dụng chúng để tạo ra các hiệu ứng bố cục độc đáo.

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

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

Thiết kế “Same Sizer” trông khó coi vì các ký tự bị kéo giãn cơ học khiến chiều rộng mỗi dòng khác nhau, lý tưởng nhất là nên giữ chiều rộng mỗi dòng nhất quán và chỉ kéo giãn vị trí.
Thư pháp Việt Nam kết hợp chữ Latinh với phong cách viết tương tự tiếng Trung, cung cấp một ví dụ ứng dụng tốt hơn về nguyên tắc “tất cả các từ có kích thước bằng nhau”.
Ngay cả khi có thể đọc hiểu tiếng Trung, bạn cũng không thể nhận ra các chữ cái Latinh trong hình ảnh là chữ Latinh, vì mỗi chữ cái đã được chuyển đổi thành các thành phần của ký tự Trung Quốc.
Phần “Summary” trên trang cung cấp một phiên bản phông chữ bình thường, bắt đầu bằng “Tân niên”, và thú vị là cung cấp phiên bản tiếng Trung.
“hoa” được cách điệu thành kiểu giống như の口亽.
Trong phương pháp viết “square”, phông chữ “Hangulatin” là ví dụ thú vị nhất, nó kết hợp các đặc điểm của tiếng Hàn và chữ Latinh.
Cách viết giống thư pháp gây ấn tượng sâu sắc.
Liên kết bị hỏng, không thể xem ví dụ.
Duyệt trang trên trình duyệt Firefox gần như gây quá tải CPU, mặc dù hiệu ứng hình ảnh rất tốt.
Trên Mac M1, ngay cả khi mở nhiều tab và các ứng dụng khác, việc duyệt trang cũng không có vấn đề gì.
Đôi khi gặp phải những điều có vẻ ngớ ngẩn nhưng thực sự rất thiên tài, khiến người ta cảm thấy vui vẻ.
Khi đọc to, giọng nói ngay lập tức trở nên máy móc.
Trong các ngôn ngữ không phải là ngôn ngữ ngữ âm, đặc biệt là tiếng Anh, những phương pháp này rất khó khăn, đặc biệt là “Last is First”.
“i.e.” có nghĩa là “tức là”, còn “e.g.” có nghĩa là “ví dụ”, cả hai không thể thay thế cho nhau.
Đọc giống như nhận dạng mẫu hơn là phân tích từng chữ một.
Bằng cách chuyển đổi chế độ đọc, bạn có thể tăng tốc độ đọc mà không làm mất đi sự hiểu biết.
Tiếng Anh là một ngôn ngữ ngữ âm, mặc dù hệ thống chữ viết không đều, nhưng các chữ cái vẫn đại diện cho âm thanh.
“Last Is First” có thể giống như một mã kiểm tra cho những người sao chép văn bản để ngăn họ mất vị trí.
Muốn bố cục “Hyphenator”, nhưng muốn nhiều hơn một từ.

Kinh tế Hoa Kỳ suy giảm 0.5% trong quý đầu tiên, tệ hơn so với ước tính trước đó #

US economy shrank 0.5% in the first quarter, worse than earlier estimates

https://apnews.com/article/economy-tariffs-trump-gdp-shrink-86d1f15e66c646ac4ce88ffc0a956942

Theo báo cáo của Bộ Thương mại Hoa Kỳ, nền kinh tế Hoa Kỳ đã suy giảm với tốc độ hàng năm là 0,5% trong quý đầu tiên của năm 2025, một con số tồi tệ hơn so với ước tính trước đó (giảm 0,2%). Sự suy giảm kinh tế này chủ yếu là do chính sách thuế nhập khẩu do Tổng thống Donald Trump thực hiện đã tạm thời làm gián đoạn các hoạt động kinh doanh.

Sau khi nền kinh tế tăng trưởng 2,4% trong ba tháng cuối năm 2024, sự sụt giảm GDP trong quý đầu tiên đánh dấu sự suy giảm đầu tiên của nền kinh tế trong ba năm. Nhập khẩu tăng mạnh trong quý này, đạt 37,9%, tốc độ nhanh nhất kể từ năm 2020, sự tăng trưởng này gần như làm giảm GDP 4,7 điểm phần trăm. Đồng thời, chi tiêu tiêu dùng cũng chậm lại đáng kể, chỉ tăng 0,5%, trong khi quý IV năm ngoái tăng 4%. Mối lo ngại của người tiêu dùng về triển vọng kinh tế ngày càng gia tăng, dự kiến thuế quan sẽ ảnh hưởng trực tiếp đến tình hình tài chính của họ.

Theo báo cáo về chỉ số niềm tin của người tiêu dùng, quan điểm kinh tế của người Mỹ đã xấu đi trong tháng 6, chỉ số niềm tin của người tiêu dùng giảm xuống 93, giảm 5,4 điểm so với tháng trước, cho thấy sự bi quan hơn về kỳ vọng ngắn hạn đối với thu nhập, tình hình kinh doanh và thị trường việc làm trong tương lai. Cựu nhà kinh tế học của Cục Dự trữ Liên bang, Claudia Sahm, cho biết việc điều chỉnh giảm chi tiêu tiêu dùng có thể là một dấu hiệu cảnh báo tiềm ẩn.

Ngoài ra, một hạng mục phản ánh sức mạnh cơ bản của nền kinh tế đã tăng trưởng hàng năm là 1,9% trong quý đầu tiên, mặc dù là tăng trưởng dương, nhưng đã giảm so với mức 2,9% của quý IV năm ngoái và thấp hơn ước tính trước đó là 2,5%. Hạng mục này bao gồm chi tiêu tiêu dùng và đầu tư tư nhân, nhưng loại trừ các yếu tố biến động như xuất khẩu, hàng tồn kho và chi tiêu của chính phủ. Đồng thời, chi tiêu của chính phủ liên bang giảm với tốc độ hàng năm là 4,6%, mức giảm lớn nhất kể từ năm 2022.

Chính sách thương mại của Trump đã dẫn đến thâm hụt thương mại gia tăng, và thâm hụt thương mại sẽ làm giảm tổng giá trị sản xuất trong nước khi tính GDP. Điều này có nghĩa là nhập khẩu được coi là chi tiêu tiêu dùng hoặc đầu tư kinh doanh, phải được trừ vào GDP để tránh làm tăng giả tạo con số sản xuất trong nước.

Dự kiến sự tăng đột biến nhập khẩu trong quý đầu tiên sẽ không lặp lại trong quý thứ hai, do đó sẽ không gây gánh nặng cho GDP. Các nhà kinh tế dự đoán rằng tăng trưởng kinh tế trong quý thứ hai sẽ phục hồi lên 3%. Dữ liệu sơ bộ về tăng trưởng GDP từ tháng 4 đến tháng 6 năm 2025 sẽ được công bố vào ngày 30 tháng 7.

HN | Độ nóng: 354 điểm | 159 bình luận | Tác giả: Aloisius #

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

GDP giảm một phần là do tăng trưởng nhập khẩu, mà trước đây ước tính GDP chưa tính đến đầy đủ điều này
Công thức tính GDP là GDP = C + I + G + (X - M), trong đó C là chi tiêu tiêu dùng, I là đầu tư kinh doanh, G là chi tiêu chính phủ, (X - M) là xuất khẩu ròng
Việc Mỹ tăng thuế đối với Trung Quốc dẫn đến giảm nhập khẩu, làm giảm GDP, trong khi việc giảm thuế sau đó dẫn đến nhập khẩu tăng đột biến, ảnh hưởng đến GDP
Chính phủ có thể thao túng các chỉ số kinh tế như một công cụ chính trị, dẫn đến dữ liệu bị sai lệch
Tỷ lệ thất nghiệp và các chỉ số kinh tế như chi tiêu tiêu dùng/GDP được sử dụng để đo lường thành công chính trị, nhưng có thể bị thao túng
Trong thời kỳ COVID, tỷ lệ tử vong do mọi nguyên nhân là một chỉ số tốt hơn so với tỷ lệ tử vong do COVID, vì bất kỳ trường hợp tử vong nào do COVID đều thể hiện sự thất bại của chính sách y tế công cộng
Có một số nguồn cung cấp dữ liệu kinh tế và xã hội chi tiết, không bị can thiệp chính trị, chẳng hạn như FRED
Mặc dù có dữ liệu chi tiết, nhưng cách kể chuyện của giới truyền thông có thể bóp méo sự hiểu biết của công chúng về các chỉ số kinh tế
Mọi người ngày càng ít tin tưởng vào các chỉ số kinh tế, mong muốn có những chỉ số phản ánh thực tế và khó bị thao túng
Ngay cả khi dữ liệu dễ dàng tiếp cận, nhưng sự hiểu biết và tin tưởng của công chúng đối với dữ liệu bị ảnh hưởng bởi cách kể chuyện của giới truyền thông và cách giải thích của các chính trị gia

Tại sao trình biên dịch Rust lại chậm như vậy? #

Why is the Rust compiler so slow?

https://sharnoff.io/blog/why-rust-compiler-slow

Bài viết này thảo luận về vấn đề tốc độ biên dịch chậm mà tác giả gặp phải khi cố gắng triển khai một trang web Rust bằng Docker. Dưới đây là bản tóm tắt tiếng Việt của bài viết:

Trang web của tác giả chủ yếu được cung cấp bởi một tệp nhị phân Rust. Trong một thời gian dài, mỗi khi muốn thay đổi trang web, tác giả cần xây dựng một tệp nhị phân liên kết tĩnh mới, sau đó sao chép nó lên máy chủ và khởi động lại trang web. Quá trình này không lý tưởng. Vì vậy, tác giả muốn chuyển sang sử dụng container (cho dù là Docker, Kubernetes hay thứ gì khác) để triển khai trang web, để phù hợp với cách triển khai phần mềm phổ biến trong thập kỷ qua. Nhưng vấn đề là, việc xây dựng Rust nhanh chóng bằng Docker không hề đơn giản.

Bài viết cập nhật rằng, sau khi tác giả đăng bài viết này lần đầu trên Bluesky, tác giả đã nhận được một số thảo luận và đề xuất hữu ích, đặc biệt là từ Piotr Osiewicz và Wesley Moore, những đề xuất này đã tiết kiệm rất nhiều thời gian.

Bài viết trình bày chi tiết phương pháp cơ bản để sử dụng Rust trong Docker, bao gồm cách đưa chương trình Rust vào container. Thông thường, điều này liên quan đến việc bắt đầu xây dựng từ một Docker image chứa môi trường Rust, sau đó thêm các dependency, sao chép code, xây dựng project và đưa tệp nhị phân cuối cùng vào image cuối cùng. Nhưng phương pháp này sẽ xây dựng lại mọi thứ từ đầu mỗi khi có thay đổi, dẫn đến thời gian xây dựng kéo dài đến 4 phút.

Để giải quyết vấn đề này, tác giả đã sử dụng công cụ cargo-chef của Luca Palmieri, công cụ này có thể xây dựng trước tất cả các dependency như một layer cache Docker riêng biệt, do đó chỉ những thay đổi trong codebase mới kích hoạt việc biên dịch lại codebase, thay vì các dependency. Công cụ này thực hiện điều này bằng cách tạo một tệp “công thức” đơn giản, có thể được tạo từ workspace hiện tại và có thể được “nấu” để cache các dependency mà không bị mất hiệu lực do các thay đổi trong workspace.

Mặc dù đã sử dụng cargo-chef, nhưng tốc độ xây dựng không được cải thiện như mong đợi, phần lớn thời gian vẫn dành cho việc xây dựng tệp nhị phân cuối cùng. Tác giả đã phân tích và chẩn đoán thêm vấn đề bằng lệnh cargo –timings và chức năng tự phân tích của rustc (thông qua flag -Zself-profile), để tìm ra nút thắt trong quá trình biên dịch.

Cuối bài viết, tác giả đã sử dụng một số thủ thuật thao tác container để trích xuất các báo cáo thời gian xây dựng cargo và các tệp đầu ra tự phân tích của rustc từ container xây dựng, để phân tích thêm. Tác giả phát hiện ra rằng, mặc dù cargo build –timings cung cấp thông tin về thời gian cần thiết để biên dịch mỗi crate, nhưng ở đây, họ chỉ quan tâm đến thời gian biên dịch của crate cuối cùng. Thông qua những phân tích này, tác giả hy vọng có thể tìm ra cách cải thiện tốc độ biên dịch Rust.

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

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

Các dependency của dự án Rust không phản ánh trực tiếp kích thước dự án được cảm nhận
Macro và generic là một trong những nguyên nhân khiến Rust biên dịch chậm, chúng có thể nhanh chóng làm tăng lượng code
Các đặc tính này của Rust làm cho code trở nên ngắn gọn hơn, nhưng có thể khiến hệ sinh thái có vẻ chậm
Trong các chương trình nhỏ, thời gian biên dịch của Rust so với C như thế nào, có nhiều quan điểm khác nhau
Hiệu năng trình biên dịch Rust có quan hệ theo cấp số nhân với độ sâu kiểu, các công nghệ như GraphQL làm trầm trọng thêm vấn đề này
TypeScript phù hợp với GraphQL vì nó có thể giảm các vấn đề về hiệu năng trình biên dịch
Trình biên dịch càng làm nhiều việc trong quá trình build, thời gian build càng lâu
Liên kết tĩnh không chậm, mà là lượng code được tạo ra nhiều dẫn đến biên dịch chậm
Các lý do lịch sử và các vấn đề hiện đại của liên kết động, chẳng hạn như sự phổ biến của Docker, ảnh hưởng đến quan điểm về liên kết tĩnh

Đã đến lúc cho một API tạo khuôn mẫu DOM #

The time is right for a DOM templating API

https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/

Bài viết này được Justin Fagnani đăng vào ngày 26 tháng 6 năm 2025, chủ đề là về đề xuất thêm một API mẫu khai báo vào nền tảng Web. Bài viết trước tiên nhấn mạnh sự thành công của nền tảng Web, đặc biệt là tầm quan trọng của DOM API, nó đã biến Web từ một trình xem tài liệu tĩnh thành một môi trường thời gian chạy có tính động cao và giàu biểu cảm. Mặc dù DOM đôi khi bị chỉ trích, nhưng nó chắc chắn là một API mạnh mẽ, điều này có thể thấy từ nhiều ứng dụng Web phức tạp và động, chẳng hạn như các ứng dụng phức tạp như Photoshop cũng có thể tồn tại dưới dạng ứng dụng Web và toàn bộ giao diện người dùng của nó được xây dựng bằng các Web Components.

Bài viết chỉ ra rằng, mặc dù DOM rất mạnh mẽ, nhưng nó thiếu một trong những tính năng quan trọng và phổ biến nhất trong phát triển Web hiện đại: template (mẫu). Hiện tại, không có cách nào phù hợp với công thái học (ergonomic) trong DOM API tiêu chuẩn để tạo các khối DOM node từ dữ liệu, thêm trình lắng nghe sự kiện, đặt thuộc tính phần tử và ngăn chặn các cuộc tấn công XSS một cách an toàn; sau đó sử dụng dữ liệu mới để cập nhật khối đó một cách hiệu quả.

Bài viết tiếp tục thảo luận về sự phổ biến và các lý do cơ bản của các template khai báo, bao gồm việc chúng có công thái học tốt hơn so với DOM API mệnh lệnh, dễ dàng ngăn chặn các cuộc tấn công XSS hơn, hiệu suất có thể nhanh hơn mã viết tay, phân tích tĩnh dễ dàng hơn và có thể thực hiện kết xuất phía máy chủ (server-side rendering) hiệu quả.

Sau đó, bài viết đặt ra vấn đề về tình hình hiện tại, đó là nền tảng Web không đáp ứng được một nhu cầu cốt lõi của hầu hết tất cả các ứng dụng Web. Tác giả cho rằng nền tảng Web nên thích ứng và đáp ứng những nhu cầu phát triển rõ ràng này, nhưng vẫn chưa làm được điều đó trong lĩnh vực template. Việc thiếu template có những hậu quả thực tế cho tất cả mọi người: người dùng có thể phải chịu thời gian tải ứng dụng lâu hơn, chi phí kết xuất hoặc ứng dụng không an toàn; nhà phát triển cần phải dựa vào các thư viện để hoàn thành nhiều thao tác cơ bản; các framework khó xây dựng hơn vì chúng cần triển khai template; nền tảng cũng bị ảnh hưởng khi cạnh tranh với các nền tảng gốc không nhạy cảm với vài kB.

Bài viết cho rằng bây giờ là thời điểm tốt để thêm API template, vì các framework đã mở đường cho chúng ta và chúng ta hiểu rõ hơn về cú pháp template người dùng và mô hình phản ứng (reactivity model) so với 13 năm trước. Ngoài ra, còn có nhiều nhà phát triển “thuần túy” và cộng đồng Web Components có nhu cầu về các thao tác DOM phù hợp với công thái học và API phản ứng.

Bài viết cuối cùng chỉ ra rằng, chúng ta biết cú pháp tốt của template trông như thế nào, các hệ thống template phía máy khách (client-side template) phổ biến có những điểm tương đồng cơ bản về cú pháp, ngay cả các hệ thống dựa trên HTML (như Vue, Angular, Svelte) và dựa trên JavaScript (như React, Lit, Solid). Các hệ thống này cũng rất giống nhau về mặt ngữ nghĩa, hầu hết các hệ thống đều trả về một mô tả DOM, sau đó sử dụng các lệnh gọi hàm kết xuất riêng biệt để áp dụng mô tả này. Bài viết cũng đề cập rằng, chúng ta có thể sử dụng các tính năng JavaScript tích hợp để nhúng DSL, như HTML: tagged template literals, vì vậy chúng ta có thể mô tả template DOM mà không cần thêm các tính năng mới.

HN | Độ nóng: 200 điểm | 205 bình luận | Tác giả: mdhb #

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

Có người hoài nghi về việc “chúng ta biết cú pháp tốt của template trông như thế nào”, cho rằng template tốt thiên về trực quan hơn là ký hiệu.
Có người cho rằng Dreamweaver và Photoshop thành công vì chúng phù hợp hơn với nhu cầu trực quan của nhà thiết kế.
Có người cảm thấy việc cố gắng tái tạo XSLT là vô ích, vì luôn có người muốn tạo template cho nội dung không chuẩn nhưng có thể kết hợp thành chuẩn.
Có người hy vọng có ít template cố gắng điều chỉnh bố cục tài liệu tiêu chuẩn hơn, vì mọi người sẽ nỗ lực hết mình để tái tạo hiệu ứng định vị tuyệt đối.
Có người đánh giá cao XSLT, cho rằng nó là một tính năng sát thủ trong hệ sinh thái XML, mặc dù XML hoạt động không tốt ở một số lĩnh vực.
Có người cho rằng XSLT thất bại vì nó là một ngôn ngữ đặc tả miền (DSL) thực sự, và là một DSL khai báo, thuần hàm.
Có người chỉ ra rằng điểm yếu của XSLT là sự mở rộng của điểm mạnh của nó, nó là ngôn ngữ thuần hàm, đồng cấu được áp dụng rộng rãi đầu tiên.
Có người đưa ra vấn đề cú pháp của XSLT, vì XSLT là XML, nếu sử dụng S-expression, cú pháp có thể tốt hơn một chút.
Có người cảm thấy có mối quan hệ kép giữa XSLT và CSS, HTML, sự khác biệt về hình thức của chúng tránh được sự nhầm lẫn.
Có người đề cập rằng tính đồng cấu của XSLT có thể gây ra rắc rối, CSS và HTML có hình thức hoàn toàn khác nhau, do đó sẽ không có vấn đề nhầm lẫn.
Có người đề cập rằng việc khớp mẫu của XSLT tương tự như việc khớp mẫu được quản lý bởi trình biên dịch trong hệ thống kiểu FP truyền thống, nhưng việc khớp mẫu của XSLT rất đơn giản: đưa ra một mẫu, tìm kiếm nó trong đầu vào và xử lý từng kết quả khớp.

A.I. Đang Đồng Nhất Hóa Tư Duy Của Chúng Ta #

A.I. Is Homogenizing Our Thoughts

https://www.newyorker.com/culture/infinite-scroll/ai-is-homogenizing-our-thoughts

Bài viết này thảo luận về trí tuệ nhân tạo, đặc biệt là các mô hình ngôn ngữ lớn (L.L.M.) như ChatGPT, về tác động của chúng đối với cách chúng ta suy nghĩ và sáng tạo. Bài viết bắt đầu bằng việc đề cập đến một thí nghiệm do MIT thực hiện, trong đó hơn 50 sinh viên đại học ở khu vực Boston được chia thành ba nhóm và được yêu cầu viết các bài luận theo phong cách SAT dựa trên các gợi ý mở rộng. Một nhóm chỉ dựa vào bộ não của họ, nhóm thứ hai có thể sử dụng Google Search để tìm thông tin liên quan và nhóm thứ ba có thể sử dụng ChatGPT. Trong thí nghiệm, tất cả các sinh viên đều đội thiết bị đeo đầu có gắn điện cực để đo hoạt động não của họ. Kết quả cho thấy, những sinh viên sử dụng ChatGPT cho thấy hoạt động não ít hơn so với hai nhóm còn lại, ít kết nối hơn giữa các phần khác nhau của não, ít kết nối α liên quan đến sự sáng tạo và ít kết nối θ liên quan đến trí nhớ làm việc hơn. Một số sinh viên sử dụng L.L.M. không cảm thấy bất kỳ quyền sở hữu nào đối với các bài luận mà họ đã viết, và 80% sinh viên không thể trích dẫn những gì họ đã viết.

Bài viết tiếp tục chỉ ra rằng văn bản do người dùng L.L.M. tạo ra có xu hướng sử dụng các từ vựng và ý tưởng chung, điều này dẫn đến việc sử dụng trí tuệ nhân tạo tạo ra hiệu ứng đồng nhất. Các gợi ý SAT được thiết kế để gợi ra nhiều phản hồi khác nhau, nhưng việc sử dụng trí tuệ nhân tạo đã khiến các kết quả đầu ra trở nên rất giống nhau. Đối với câu hỏi “Điều gì khiến chúng ta thực sự hạnh phúc?”, người dùng L.L.M. có nhiều khả năng sử dụng các cụm từ liên quan đến sự nghiệp và thành công cá nhân hơn các nhóm khác. Trong câu hỏi về từ thiện, nhóm ChatGPT nhất trí ủng hộ, trong khi các bài luận của các nhóm khác lại chứa đựng những lời chỉ trích về từ thiện. Kosmyna cho biết, khi sử dụng L.L.M., các quan điểm khác nhau không được tạo ra, mà thay vào đó là một hiện tượng trung bình hóa.

Bài viết kết luận rằng trí tuệ nhân tạo là một công nghệ trung bình: các mô hình ngôn ngữ lớn được đào tạo để tìm các mẫu trong một lượng lớn dữ liệu; các câu trả lời mà chúng tạo ra có xu hướng đồng thuận, cả về chất lượng viết (thường chứa đầy những lời sáo rỗng và tầm thường) và về mức độ tư duy. Tất nhiên, các công nghệ cũ hơn khác cũng đã giúp đỡ và có thể làm suy yếu các nhà văn - có thể nói, SparkNotes hoặc bàn phím máy tính cũng vậy. Nhưng với sự ra đời của trí tuệ nhân tạo, chúng ta có thể thuê ngoài suy nghĩ của mình một cách triệt để, khiến chúng ta trở nên trung bình hơn. Bài viết ám chỉ rằng bất kỳ ai sử dụng ChatGPT để viết lời chúc mừng đám cưới, soạn thảo hợp đồng hoặc viết bài luận đại học, giống như thí nghiệm của MIT, đều đang trải qua một chi phí nhận thức.

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

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

Một số người cho rằng, trí tuệ nhân tạo có thể khiến những người không phát triển được khả năng tư duy phản biện trước những năm gần đây trở nên ngu ngốc.
Có người cho rằng, ngay cả những người làm việc trong các lĩnh vực kỹ năng cao cũng thường thể hiện kém trong việc hiểu các khái niệm phức tạp.
Có người lo ngại rằng, việc quá phụ thuộc vào trí tuệ nhân tạo sẽ khiến bản thân trở nên kém thông minh hơn, đặc biệt là trong lĩnh vực sáng tạo và từ vựng.
Có người cho rằng, trí tuệ nhân tạo không làm cho mọi người trở nên ngu ngốc mà chỉ phơi bày sự ngu ngốc hiện có.
Có người chỉ ra rằng, mạng xã hội đã đồng hóa tư tưởng của chúng ta một cách sâu sắc, khiến chúng ta khó hình thành ý kiến riêng nếu không có sự gợi ý từ người khác.
Có người đề xuất rằng, việc thành lập các câu lạc bộ ngoại tuyến có thể là một giải pháp để chống lại sự đồng nhất này.
Có người lo ngại rằng, sự đồng nhất của trí tuệ nhân tạo được lên kế hoạch bởi các thực thể vì lợi nhuận, điều này có thể có lợi cho mô hình kinh doanh của họ nhưng lại gây ra mối đe dọa cho thực tế.
Có người đặt câu hỏi rằng, các nhà tư bản tỷ phú cũng sống trong thế giới này, hành vi của họ mặc dù có thể gây ra tổn hại, nhưng tổn hại này thường có thể dự đoán được, trong khi hành vi của trí tuệ nhân tạo có thể khiến người dùng làm những điều điên rồ, hình thức và mức độ tổn hại này là không thể đoán trước.

Matrix v1.15 #

Matrix v1.15

https://matrix.org/blog/2025/06/26/matrix-v1.15-release/

Matrix phiên bản 1.15 phát hành

Matrix phiên bản 1.15 được phát hành vào ngày 26 tháng 6 năm 2025, mang đến những cải tiến về xác thực, tóm tắt phòng và chủ đề văn bản đa dạng thức. Thế hệ xác thực MSCs mới (được dẫn dắt bởi MSC3861) đã bắt đầu giai đoạn đánh giá cuối cùng cách đây vài tháng và được hợp nhất trong bản phát hành hôm nay, nhờ sự đóng góp hào phóng của Kévin Commaille.

Bài viết phác thảo những điểm nổi bật của 10 MSCs đi kèm với bản phát hành và đính kèm nhật ký thay đổi đầy đủ ở cuối.

Thế hệ xác thực mới

Trong vài năm qua, Matrix đã đầu tư rất nhiều nỗ lực vào việc thiết kế, triển khai và triển khai xác thực OIDC theo tiêu chuẩn ngành. Mặc dù MSCs ban đầu được mở vào năm 2022, nhưng đã trở thành tâm điểm vào năm 2023, phác thảo cách hệ thống dự kiến hoạt động, đặt nền móng cho việc di chuyển 110 triệu người dùng matrix.org chỉ trong 30 phút trong năm nay. Với việc MSCs trở thành một phần của đặc tả, việc phát hành Matrix 2.0 đã tiến thêm một bước nữa. Phần còn lại của Matrix 2.0 vẫn cần một thời gian để được đưa hoàn toàn vào đặc tả, nhưng những tiến bộ cũng đang được thực hiện trong thời gian này. Những người đam mê MSC cũng nên chú ý đến một số đề xuất tăng cường cho hệ thống xác thực thế hệ tiếp theo, những đề xuất này sẽ dần dần được đưa vào đặc tả trong tương lai.

Tóm tắt phòng

MSC3266 đã tồn tại dưới nhiều hình thức khác nhau trong một thời gian dài (bao gồm cả việc sử dụng ngắn ngủi trong sản xuất, ôi chao 🙈), và cuối cùng đã được đưa vào đặc tả. Các client có thể sử dụng các điểm cuối mới để lấy thông tin phong phú hơn về các phòng mà họ chưa tham gia hoàn toàn, mang lại trải nghiệm tốt hơn cho người dùng trên các lời mời, gõ cửa và liên kết matrix.to. Hầu hết các client đã triển khai hỗ trợ, nhưng nếu client của bạn cần hỗ trợ tốt hơn trong bối cảnh phòng chưa tham gia, thì đây có thể là phần còn thiếu mà họ cần.

Cảm ơn Nico vì sự kiên nhẫn trong nhiều năm và cuối cùng đã thúc đẩy đặc tả.

Chủ đề văn bản đa dạng thức

Nhờ việc MSC3765 được đưa vào đặc tả, các phòng hiện có thể sử dụng danh sách một cách mạnh dạn và thỏa sức sáng tạo. Một số phòng đã tận dụng điều này để cung cấp các liên kết chủ đề thân thiện cho người dùng và giờ đây tất cả các phòng đều có thể sử dụng các định danh ổn định để đại diện cho phòng của họ theo cách phong phú nhất. Về cơ bản, chức năng này sử dụng các sự kiện có thể mở rộng, nhưng do hỗ trợ dự phòng tốt, nên tránh được nhu cầu về phiên bản phòng mới - các client được khuyến khích thử các phương pháp hiển thị khác nhau trước khi các sự kiện có thể mở rộng (từ từ) được phát hành cho đặc tả.

Cảm ơn Johannes đã triển khai chức năng được yêu cầu cao này trong đặc tả.

Nhật ký thay đổi đầy đủ

Nhật ký thay đổi đầy đủ của Matrix 1.15 bao gồm:

Client-Server API

Điểm cuối mới: Thêm GET /_matrix/client/v1/room_summary/{roomIdOrAlias} theo MSC3266. (#2125)
Điểm cuối mới: Thêm GET /_matrix/client/v1/auth_metadata theo MSC2965. (#2147)
Thay đổi tương thích ngược: Thêm khối nội dung m.topic theo MSC3765 để bật văn bản đa dạng thức trong các sự kiện m.room.topic. (#2095)
Bao gồm khóa thiết bị với các sự kiện mã hóa Olm theo MSC4147. (#2122)
Mở rộng /_matrix/client/v1/room_summary/{roomIdOrAlias} và mở rộng /_matrix/client/v1/rooms/{roomId}/hierarchy theo MSC3266, đồng thời thêm các thuộc tính tùy chọn mới allowed_room_ids, encryption và room_version. (#2125, #2158)
Thêm API xác thực dựa trên OAuth 2.0, theo MSC3861 và các đề xuất con của nó. (#2141, #2148, #2149, #2150, #2151, #2159, #2164)
Làm rõ đặc tả: Hành vi khi khóa topic của sự kiện m.room.topic bị thiếu, trống hoặc null. (#2068)
Sửa ví dụ về điểm cuối GET /sync và ví dụ về m.room.member được sử dụng ở nhiều nơi. (#2077)
Làm rõ định dạng của lời mời bên thứ ba, bao gồm cả việc khóa công khai của máy chủ nhận dạng có thể sử dụng mã hóa base64 an toàn theo tiêu chuẩn hoặc URL. (#2083)

Server-Server API

Thay đổi tương thích ngược: Thêm khối nội dung m.topic theo MSC3765 để bật văn bản đa dạng thức trong các sự kiện m.room.topic. (#2095)
Mở rộng /_matrix/federation/v1/hierarchy/{roomId} theo MSC3266 và thêm các thuộc tính tùy chọn mới encryption và room_version. (#2125)
Làm rõ đặc tả: Mô tả về điểm cuối mời, nếu máy chủ chính đã ở trong phòng, lời mời của người dùng cục bộ có thể được nhận hai lần thông qua liên kết. (#2067)

Application Service API

Làm rõ đặc tả: Làm rõ hành vi của url: null trong lược đồ đăng ký Application Service. (#2130)

Identity Service API

Làm rõ đặc tả: Khóa công khai có thể sử dụng mã hóa base64 an toàn theo tiêu chuẩn hoặc URL. (#2083)

Push Gateway API

Không có thay đổi lớn.

Room Version

Không có thay đổi lớn.

Phụ lục

Không có thay đổi lớn.

Thay đổi/Công cụ nội bộ

Làm rõ đặc tả: Điều chỉnh lề của điểm cuối hiển thị. (#2081)
Thay thế mã ngắn Hugo trong đầu ra OpenAPI. (#2088)
Thêm URL danh sách gây quỹ đã biết vào đặc tả để ủy quyền https://matrix.org/funding.json. Được đóng góp bởi @HarHarLinks. (#2115)
Sửa hộp thông tin lịch sử khi tạo đặc tả lịch sử. (#2123)
Cập nhật menu điều hướng đầu trang với các liên kết matrix.org hiện đại. Được đóng góp bởi @HarHarLinks. (#2137)

Quỹ Matrix.org cần bạn

Quỹ Matrix.org là một tổ chức phi lợi nhuận chỉ hoạt động dựa trên quyên góp. Nhiệm vụ cốt lõi của nó là duy trì đặc tả Matrix, nhưng nó làm được nhiều hơn thế. Nó duy trì máy chủ chính matrix.org và lưu trữ miễn phí nhiều dịch vụ cầu nối. Nó đấu tranh cho quyền riêng tư và phẩm giá kỹ thuật số tập thể của chúng ta.

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

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

Matrix đã liên tục được cải thiện trong 5 năm, người dùng lạc quan về sự phát triển liên tục của nó
Cộng đồng Hacker News có xu hướng bình luận tiêu cực, giải quyết vấn đề khó hơn phát hiện vấn đề
Có người cho rằng Matrix và Signal giải quyết các vấn đề khác nhau, cả hai không nên so sánh với nhau
Có người cho rằng mọi người hình thành quan điểm dựa trên lựa chọn của mình hơn là dựa trên thông tin để đưa ra quyết định
Một số tính năng của Element Web đã bị xóa hoặc hạn chế, chẳng hạn như trung tâm thông báo và tìm kiếm phòng
Các vấn đề về hiệu suất của Element Web bị người dùng chỉ trích, chẳng hạn như tiêu thụ bộ nhớ cao và tải chậm
Việc ra mắt Element X Web (Aurora) được kỳ vọng sẽ cải thiện các vấn đề về hiệu suất
Người dùng bày tỏ sự thất vọng về việc chức năng Matrix như một bàn đạp IRC bị xóa
Người dùng đánh giá cao chức năng gọi nhóm được mã hóa đầu cuối của Matrix
Người dùng bày tỏ lòng biết ơn đối với công việc liên tục của Matrix và Element, đồng thời mong đợi sự phát triển trong tương lai của nó
Người dùng bày tỏ sự nghi ngờ về việc triển khai cuộc gọi được mã hóa trên nền tảng Element X, hỏi liệu nó đã được triển khai trên các nền tảng không phải Element X hay chưa
Người dùng đặt câu hỏi liệu việc xóa một chức năng sau khi người dùng phụ thuộc vào nó có phải là khôn ngoan hay không
Người dùng thừa nhận sự cần thiết của việc cải thiện giao thức Matrix để nâng cao trải nghiệm người dùng của ứng dụng khách, nhưng cũng quan tâm liệu đây có phải là cách nhanh nhất để thu hút người dùng hay không

Starcloud không thể đặt một trung tâm dữ liệu trong không gian với 8,2 triệu đô la trên một tàu Starship #

Starcloud can’t put a data centre in space at $8.2M in one Starship

https://angadh.com/space-data-centers-1

Bài viết này là một phân tích kỹ thuật về dự án trung tâm dữ liệu không gian (SDC) do công ty Starcloud đề xuất. Bài viết bắt đầu bằng việc chỉ ra rằng Starcloud tuyên bố có thể xây dựng một trung tâm dữ liệu không gian (SDC) 40 megawatt với chi phí 8,2 triệu đô la thông qua một lần phóng Starship với tải trọng 100 tấn. Tuy nhiên, phân tích của tác giả cho thấy điều này là không khả thi trong một lần phóng duy nhất, mà thực tế cần tới 22 lần phóng.

Công ty Starcloud tuyên bố có thể xây dựng một trung tâm dữ liệu không gian (SDC) 40 megawatt với chi phí 8,2 triệu đô la thông qua một lần phóng Starship với tải trọng 100 tấn. Tác giả thông qua phân tích kỹ thuật phát hiện ra rằng mục tiêu này không thể đạt được trong một lần phóng duy nhất, mà thực tế cần tới 22 lần phóng. Các tấm năng lượng mặt trời của SDC cần 4 lần phóng, dựa trên phân tích các tấm năng lượng mặt trời hiện có trên Trạm vũ trụ Quốc tế (ISS). Tương tự, dựa trên chuẩn của bộ tản nhiệt của ISS, hệ thống quản lý nhiệt của SDC cần 13 lần phóng. Các giá máy chủ cần thêm 5 lần phóng. Tác giả không phân tích tác động của việc che chắn vi thiên thạch/bức xạ và lắp ráp trên quỹ đạo đối với số lần phóng, vì những điều này đòi hỏi các thông số kỹ thuật và kiến trúc nhiệm vụ chưa được công bố, có thể chưa được phát triển đầy đủ. Về chi phí phóng, sách trắng đã sai lầm khi cho rằng chi phí phóng là 30 đô la mỗi kg. Điều này khiến so sánh kinh tế của họ với các trung tâm dữ liệu trên mặt đất trở nên phi thực tế. Một số chuyên gia suy đoán rằng 1000 đô la mỗi kg có thể là một chi phí phóng lạc quan, có nghĩa là chi phí cho mỗi lần phóng là 100 triệu đô la, với tổng chi phí là 103,2 triệu đô la. Ngay cả khi chi phí giảm xuống còn 500 đô la mỗi kg, tổng chi phí cho một lần phóng duy nhất sẽ đạt 53,2 triệu đô la, thay vì 8,2 triệu đô la như tuyên bố. Nếu cần lần phóng thứ hai, chi phí trong trường hợp xấu nhất sẽ lên tới 200 triệu đô la, cao hơn chi phí vận hành trung tâm dữ liệu trên mặt đất mà họ báo cáo.

Bài viết thảo luận về việc các trung tâm dữ liệu hoạt động trên Trái Đất phụ thuộc vào lưới điện hiện có, chủ yếu sử dụng nhiên liệu hóa thạch hoặc năng lượng mặt trời trên mặt đất. Gần đây, các kỹ thuật viên và doanh nhân đã đề xuất đặt các trung tâm dữ liệu trong không gian để giải quyết ba vấn đề của các trung tâm dữ liệu trên mặt đất: nhu cầu năng lượng khổng lồ, sinh nhiệt thải và tắc nghẽn bất động sản. Sam Altman cũng đề xuất năng lượng hạt nhân như một giải pháp, nhưng từ góc độ năng lượng và khí hậu, đây có thể là một giải pháp lý tưởng hơn, nhưng cần giải quyết các rào cản pháp lý. Từ góc độ pháp lý, không gian có thể là một câu trả lời nhanh hơn, nhưng việc cung cấp SDC cấp gigawatt đòi hỏi phải thiết kế các tấm năng lượng mặt trời ở cấp độ km, điều này không hề dễ dàng. Ngay cả hệ thống 40 megawatt mà Starcloud sử dụng để so sánh với trung tâm dữ liệu trên mặt đất (TDC) cũng cần một hình vuông có cạnh dài 357 mét, điều này sẽ vượt xa cấu trúc không gian lớn nhất từng được xây dựng - Trạm vũ trụ Quốc tế (ISS) có kích thước dài nhất khoảng 100 mét.

Tác giả có một số chuyên môn trong lĩnh vực không gian, đặc biệt là trong việc thiết kế các nhiệm vụ kính viễn vọng không gian lớn được sử dụng để lắp ráp trong không gian và phân tích.

Bài viết thảo luận về những thách thức trong việc lắp ráp các cấu trúc lớn trong không gian, bao gồm bất động sản, làm mát (quản lý nhiệt) và vấn đề dấu chân carbon. Mục tiêu của Starcloud là đạt được một cụm 5 gigawatt, với các tấm năng lượng mặt trời trải dài 4 km x 4 km, điều này sẽ trở thành cấu trúc lớn nhất trong không gian, cần được lắp ráp trong không gian. Trên Trái Đất, các trung tâm dữ liệu sử dụng không khí (đối lưu) và nước làm mát (dẫn nhiệt), nhưng trong không gian, quản lý nhiệt cần bức xạ, điều này kém hiệu quả hơn - không thể thực hiện đối lưu trong chân không, và nước có thể trích xuất nhiệt từ trung tâm, nhưng sau đó việc làm mát nước đã được làm nóng sẽ phải đối mặt với một vấn đề khác.

Bài viết phân tích trường hợp kinh doanh của Starcloud, họ đưa ra một bảng cho thấy tổng chi phí để vận hành một cụm trung tâm dữ liệu 40 megawatt trên Trái Đất trong mười năm là 167 triệu đô la, trong khi ở không gian là 8,2 triệu đô la; phóng là yếu tố đóng góp lớn nhất vào tổng chi phí của Starcloud, họ cho rằng một lần phóng là đủ, nhưng tác giả nghi ngờ điều này. Bài viết cũng chỉ ra rằng tính toán về chi phí phóng trong sách trắng là sai, chi phí 30 đô la mỗi kg mà họ tuyên bố thực tế là 50 đô la mỗi kg, điều này có nghĩa là chi phí phóng của họ tăng thêm từ 3 triệu đến 5 triệu đô la.

Bài viết cung cấp một phân tích kỹ thuật sâu sắc về dự án trung tâm dữ liệu không gian của Starcloud và đặt ra câu hỏi về tính khả thi kinh tế của dự án.

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

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

Chi phí bảo trì trung tâm dữ liệu không gian rất cao, cần xem xét các yếu tố như tự động kết nối, hệ thống robot, cung cấp năng lượng, hệ thống liên lạc và làm mát.
Trung tâm dữ liệu không gian cần thường xuyên phóng tên lửa chứa phần cứng thay thế và đội ngũ hỗ trợ mặt đất liên tục để xử lý sự cố.
Tỷ lệ hỏng hóc phần cứng tuân theo đường cong bồn tắm, tỷ lệ hỏng hóc thấp trong thời gian dài, có thể giảm chi phí bằng cách tăng tính dự phòng thay vì thay thế bộ phận.
Bằng cách thực hiện kiểm tra lão hóa phần cứng trước khi phóng, có thể giảm tỷ lệ hỏng hóc trong không gian.
Quản lý nhiệt cho trung tâm dữ liệu không gian là một thách thức, đòi hỏi một lượng lớn ống dẫn nhiệt để truyền nhiệt từ chip đến bộ tản nhiệt.
Vấn đề dự phòng của trung tâm dữ liệu không gian phức tạp hơn so với trên Trái đất, đòi hỏi nhiều hệ thống sao lưu hơn.
Có thể xem xét sử dụng một nhóm các vệ tinh máy chủ độc lập hoặc vệ tinh dạng rack rẻ hơn, đơn giản hơn, được kết nối thông qua mạng truyền thông vô tuyến hoặc vi sóng.
Đặt trung tâm dữ liệu trong một thùng áp suất kín, duy trì áp suất 1 atmosphere, tuần hoàn không khí như trên Trái đất, có thể đơn giản hóa vấn đề quản lý nhiệt.
Tăng số lượng vệ tinh nhỏ sẽ làm tăng diện tích bề mặt làm mát, nhưng cũng làm tăng nguy cơ va chạm với rác vũ trụ.