2025-06-26 Top Stories #

Gemini CLI: Google ra mắt công cụ AI agent mã nguồn mở miễn phí, hỗ trợ nhiều tác vụ xử lý, cộng đồng có thể tham gia đóng góp, nâng cao hiệu quả phát triển.
uv và PEP 723: Đơn giản hóa việc chạy và quản lý các script Python thông qua công cụ uv và metadata PEP 723, hỗ trợ môi trường ảo một lần và tương tác script.
Phục hưng định dạng PNG: PNG phát hành đặc tả mới, hỗ trợ HDR, ảnh động, dữ liệu Exif, v.v., tương lai sẽ nghiên cứu các kỹ thuật nén và song song hiệu quả hơn.
Sự kiện từ chối nhập cảnh: Một du khách người Na Uy bị biên giới Hoa Kỳ từ chối vì meme “JD Vance hói đầu”, gây ra sự chú ý về tự do ngôn luận và chính sách biên giới.
Sáng tạo tiền dày: Theodore Nichols sáng tạo “Thick Nickel”, tăng cường cảm giác an toàn bằng cách làm dày đồng xu và kêu gọi ủng hộ sự nghiệp đúc tiền của mình.
Microsoft Edit: Microsoft ra mắt trình soạn thảo văn bản hiện đại, tri ân trình soạn thảo MS-DOS cổ điển, cung cấp giao diện đơn giản và khả năng kiểm soát nhập liệu hiệu quả.
Tối ưu hóa chi phí OpenAI: Giảm chi phí phiên âm OpenAI bằng cách tăng tốc các tệp âm thanh, tiết kiệm thời gian và chi phí.
Hạn chế của Cục Lưu trữ Quốc gia: Chi nhánh College Park của Cục Lưu trữ Quốc gia Hoa Kỳ sẽ trở thành cơ sở hạn chế, cần đặt lịch hẹn để truy cập nhằm nâng cao hiệu quả.
Công nghệ thu phóng trong X11: Máy chủ hiển thị X11 hỗ trợ thu phóng DPI hiệu quả và thu phóng phân số, tốt hơn Wayland, tránh mất hiệu năng và mờ.
Linux đọc hộ chiếu NFC: Sử dụng công cụ pypassport để đọc dữ liệu chip NFC hộ chiếu trong Linux, liên quan đến việc xây dựng lại MRZ và thảo luận về bảo mật.

Gemini CLI #

Gemini CLI

https://blog.google/technology/developers/introducing-gemini-cli-open-source-ai-agent/

Gemini CLI là một AI agent mã nguồn mở miễn phí, được thiết kế để mang sức mạnh của Gemini trực tiếp vào terminal của nhà phát triển, cung cấp trải nghiệm truy cập vô song cho người dùng cá nhân. Khi các nhà phát triển ngày càng phụ thuộc vào giao diện dòng lệnh, nhu cầu tích hợp trợ lý AI cũng tăng lên. Do đó, Gemini CLI cung cấp một cách thức gọn nhẹ để người dùng có thể truy cập các mô hình Gemini trực tiếp thông qua terminal.

Các tính năng chính: #

Chức năng rộng rãi: Gemini CLI không chỉ tập trung vào mã hóa mà còn có thể xử lý nhiều tác vụ như tạo nội dung, giải quyết vấn đề, nghiên cứu chuyên sâu và quản lý tác vụ. Nó được thiết kế để nâng cao hiệu quả công việc của nhà phát triển.
Giới hạn sử dụng vô song: Người dùng có thể đăng nhập bằng tài khoản Google cá nhân và nhận giấy phép Gemini Code Assist miễn phí. Giấy phép này cho phép truy cập Gemini 2.5 Pro và cung cấp hạn ngạch sử dụng lớn nhất trong ngành: 60 yêu cầu mô hình mỗi phút và 1000 yêu cầu mỗi ngày, gần như không có giới hạn.
Khả năng mô hình mạnh mẽ: Gemini CLI hỗ trợ các chức năng như hiểu mã, thao tác tệp, thực thi lệnh và khắc phục sự cố động, cho phép người dùng viết mã, gỡ lỗi và tối ưu hóa quy trình làm việc bằng ngôn ngữ tự nhiên. Sức mạnh của nó nằm ở việc tích hợp Google Search, có thể lấy thông tin bên ngoài theo thời gian thực.
Mở và có khả năng mở rộng: Là một dự án hoàn toàn mã nguồn mở, mã của Gemini CLI có sẵn cho các nhà phát triển kiểm tra, đảm bảo an toàn và hoan nghênh sự đóng góp của cộng đồng. Nó cũng hỗ trợ nhiều chức năng mở rộng, cho phép các nhà phát triển tùy chỉnh theo nhu cầu cá nhân và quy trình làm việc.
Công nghệ dùng chung với Gemini Code Assist: Gemini CLI và Gemini Code Assist chia sẻ cùng một công nghệ, công nghệ này là trợ lý mã hóa AI do Google cung cấp cho sinh viên, người có sở thích và nhà phát triển chuyên nghiệp. Trong VS Code, người dùng có thể tận dụng các chức năng thông minh của Code Assist để viết kiểm thử nhanh chóng, sửa lỗi và xây dựng chức năng, v.v.
Dễ dàng bắt đầu: Người dùng chỉ cần cài đặt Gemini CLI và đăng ký bằng địa chỉ email để có được quyền truy cập gần như không giới hạn trong terminal.

Tóm lại, Gemini CLI là một công cụ mạnh mẽ được thiết kế để nâng cao hiệu quả công việc của nhà phát triển, tính đa chức năng và hạn ngạch sử dụng cao của nó khiến nó trở thành một trợ thủ đắc lực trong công việc hàng ngày của nhà phát triển.

HN | Độ nóng: 901 điểm | 512 bình luận | Tác giả: sync #

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

Dòng sản phẩm Gemini của Google gây rối, người dùng khó hiểu sự khác biệt và mối liên hệ giữa các dịch vụ khác nhau.
Dịch vụ đăng ký Google One có vấn đề với tích hợp iCloud, khiến người dùng không thể linh hoạt điều chỉnh dung lượng lưu trữ.
Apple thu 30% hoa hồng cho các giao dịch mua trong ứng dụng, hạn chế liên hệ trực tiếp giữa nhà phát triển và người dùng.
Chiến lược thị trường và mô hình chia sẻ doanh thu của Apple có lợi cho cả nhà phát triển và người dùng, cung cấp một môi trường thị trường được bảo vệ.
Apple đôi khi đạt được các thỏa thuận đặc biệt với các nhà cung cấp quan trọng, đặt ra các điều khoản độc quyền, tăng cường vị thế thị trường của mình.
Các cấp độ đăng ký khác nhau của Google One gây khó hiểu, đặc biệt là các phần liên quan đến dịch vụ AI.
Dịch vụ đám mây và quản lý API của Google hỗn loạn, không thân thiện với các công ty khởi nghiệp và nhà phát triển độc lập.
Nhiều người dùng và nhà phát triển có xu hướng chọn các giải pháp không phải của Google vì sự phức tạp của các dịch vụ Google.

Vui vẻ với uv và PEP 723 #

Fun with uv and PEP 723

https://www.cottongeeks.com/articles/2025-06-24-fun-with-uv-and-pep-723

Bài viết này giới thiệu cách sử dụng uv và PEP 723 để đơn giản hóa việc chạy và quản lý các script Python. Tác giả đã từng cảm thấy thất vọng vì sự phức tạp của việc cấu hình môi trường Python, nhưng giờ đây với uv, vấn đề này đã trở thành dĩ vãng.

uv là một công cụ quản lý gói và dự án Python cực nhanh được viết bằng Rust. uv cung cấp một công cụ có tên là uvx, tương tự như npx trong hệ sinh thái Node/NPM, dùng để gọi các công cụ Python bên trong gói. uvx chịu trách nhiệm tạo một môi trường ảo dùng một lần (được lưu trong bộ nhớ cache), thiết lập đúng phiên bản Python và cài đặt tất cả các dependency trước khi chạy.

Bài viết cũng đề cập đến PEP 723, một đề xuất cải tiến Python, quy định một định dạng metadata có thể được nhúng vào các script Python một tệp để giúp các trình khởi chạy, IDE và các công cụ bên ngoài khác tương tác với các script này.

Tác giả trình bày một ví dụ về cách sử dụng uv và metadata PEP 723 để chạy script Python. Bằng cách kết hợp uv và metadata PEP-723, bạn có thể dễ dàng chạy các script Python được nhúng metadata.

Bài viết cũng cung cấp một ví dụ thực tế hơn, đó là trích xuất phụ đề YouTube từ một script Python có thể thực thi. Đầu tiên, tạo một script Python có shebang và metadata nội tuyến, sau đó lưu nó dưới dạng ytt và làm cho nó có thể thực thi. Bằng cách chạy script, bạn có thể trích xuất phụ đề của video YouTube.

Cuối cùng, tác giả đề cập đến việc sử dụng uv và PEP 723 có thể mang lại nhiều khả năng hơn cho việc chạy code Python. Tác giả từng thích sử dụng ngôn ngữ Go để viết các script dùng một lần vì nó dễ dàng tạo ra các tệp thực thi nhị phân khép kín. Nhưng giờ đây với uv, tác giả đã viết một máy chủ MCP nhanh bằng Python để trích xuất phụ đề YouTube và chia sẻ dự án này trên GitHub.

HN | Độ nóng: 601 điểm | 211 bình luận | Tác giả: deepakjois #

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

Nix cung cấp khả năng đóng gói, quản lý phụ thuộc và khả năng tái tạo tốt hơn cho các script Python và shell script.
Nix tuy mạnh mẽ, nhưng có thể quá phức tạp đối với các script đơn giản.
Thông qua Nix, có thể dễ dàng cài đặt và quản lý các phụ thuộc cho shell script.
Nix có thể được sử dụng như một môi trường sandbox để chạy code, nâng cao tính bảo mật.
Các bản dựng Nix được cách ly, có thể được sử dụng để xây dựng các dự án như codapi.
Có người hy vọng tồn tại một hệ thống tương tự như Nix, nhưng được viết bằng ngôn ngữ Lua.
Hetzner cung cấp ảnh ISO của NixOS, có thể cài đặt thủ công.
NixOS kết hợp với Terraform hoạt động rất tốt.
Comma là một công cụ dựa trên Nix, có thể nhanh chóng cài đặt các tiện ích nhỏ.

Một đặc tả PNG mới #

A new PNG spec

https://www.programmax.net/articles/png-is-back/

Chủ đề của bài viết trên trang web này là về những phát triển mới nhất của định dạng PNG. Dưới đây là bản tóm tắt tiếng Việt của bài viết:

Sự hồi sinh của định dạng PNG Bài viết bắt đầu bằng việc đề cập đến một thông số kỹ thuật PNG mới vừa được phát hành, đây là một tin tức thú vị. Sau hơn hai mươi năm trì trệ, PNG đã trở lại thời kỳ huy hoàng trước đây. Thư viện Quốc hội Hoa Kỳ, Thư viện và Lưu trữ Canada, và Cơ quan Lưu trữ Quốc gia Úc đều khuyến nghị sử dụng định dạng PNG. Việc giữ cho PNG được cập nhật và cạnh tranh là rất quan trọng.

Giới thiệu các tính năng mới Bài viết tiếp tục giới thiệu một số tính năng mới của thông số kỹ thuật PNG mới:

Hỗ trợ HDR: Thông số kỹ thuật mới cung cấp hỗ trợ HDR thích hợp, hướng tới tương lai. Bài viết minh họa các màu mà mắt chúng ta có thể nhìn thấy thông qua Hình 1, trong đó tam giác bên trong nhỏ hơn đại diện cho không gian màu của hầu hết các hình ảnh, trong khi tam giác bên ngoài lớn hơn đại diện cho màu sắc điển hình trong hình ảnh HDR. Hỗ trợ HDR mới này chỉ sử dụng 4 byte (cộng với chi phí khối PNG thông thường).
Hỗ trợ hoạt ảnh APNG: Bài viết đề cập rằng hoạt ảnh PNG (APNG) được Mozilla đề xuất và được Firefox hỗ trợ, nhưng giờ đây các chương trình khác cũng bắt đầu hỗ trợ rộng rãi và thông số kỹ thuật cũng nên phản ánh thực tế này.
Hỗ trợ chính thức dữ liệu Exif: Exif lưu trữ thông tin bổ sung, chẳng hạn như thông tin bản quyền, hoặc thậm chí cả ống kính máy ảnh và vị trí GPS của ảnh.
Sắp xếp thông số kỹ thuật: Bao gồm sửa lỗi, làm rõ, v.v.

Bối cảnh Bài viết nhắc lại rằng thông số kỹ thuật PNG cuối cùng được phát hành hơn 20 năm trước và công nghệ đã tiến bộ rất nhiều kể từ đó. Trên thực tế, tiến bộ công nghệ là lý do cho sự hồi sinh của PNG. Nhóm làm việc W3C Timed Text (chịu trách nhiệm về phụ đề) cần hỗ trợ HDR trong PNG, đã đưa ra một đề xuất, nhưng một số chuyên gia tin rằng chúng ta có thể làm tốt hơn. Khi động lực được tích lũy, nhiều bên liên quan trở nên quan tâm hơn. Hiện tại, chúng tôi có đại diện từ Adobe, Apple, BBC, Comcast/NBCUniversal, Google, MovieLabs và W3C, những người duy trì thông số kỹ thuật. Đây là một đội ngũ trong mơ.

Các chương trình đã hỗ trợ thông số kỹ thuật mới Bài viết chỉ ra rằng nhiều chương trình bạn đang sử dụng đã hỗ trợ thông số kỹ thuật PNG mới, bao gồm Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer, v.v. Ngoài ra, một số đài truyền hình cũng đang cập nhật phần cứng và công cụ để hỗ trợ thông số kỹ thuật PNG mới.

Triển vọng tương lai Bài viết cuối cùng đề cập rằng mọi người có thể ngay lập tức nghĩ đến các kỹ thuật nén tốt hơn. Tác giả cho biết họ đang nghiên cứu điều này, cũng như các kỹ thuật mã hóa/giải mã song song. Họ muốn đảm bảo rằng những công việc này được thực hiện đúng cách. Bản cập nhật PNG tiếp theo (phiên bản thứ tư) dự kiến sẽ ngắn gọn, sẽ cải thiện khả năng tương tác HDR và dải động tiêu chuẩn (SDR). Đồng thời, họ sẽ nghiên cứu bản cập nhật nén cho PNG phiên bản thứ năm.

Lời cảm ơn Bài viết kết thúc bằng việc cảm ơn những người tham gia Nhóm làm việc PNG đã biến tất cả những điều này thành hiện thực và khuyến khích độc giả bày tỏ lòng biết ơn đối với công việc khó khăn của họ.

HN | Độ nóng: 554 điểm | 4 bình luận | Tác giả: tbillington #

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

Người bình luận tò mò tại sao một câu chuyện được đăng 10 giờ trước, nhận được nhiều phiếu bầu lại bị đánh dấu là trùng lặp và chuyển các bình luận sang một câu chuyện mới được đăng 1 giờ trước, có số phiếu bầu ít hơn.
Người bình luận giải thích rằng họ cố gắng thưởng cho người đầu tiên gửi câu chuyện và cần cập nhật dấu thời gian để câu chuyện hiển thị thời gian đầy đủ trên trang chủ, mặc dù ID thấp hơn.
Có người nghi ngờ rằng điều này có thể là do sự thiếu năng lực hoặc sai sót của người điều hành.

Người đàn ông “bị từ chối nhập cảnh vào Mỹ” vì bị kiểm soát biên giới bắt gặp meme JD Vance hói đầu #

Man ‘refused entry into US’ as border control catch him with bald JD Vance meme

https://www.dublinlive.ie/news/world-news/man-refused-entry-us-border-31925059

Bài viết này đưa tin về một sự việc xảy ra ở Mỹ, liên quan đến một du khách người Na Uy 21 tuổi. Du khách này tuyên bố rằng anh ta đã bị nhân viên kiểm soát biên giới Mỹ từ chối nhập cảnh và bị quấy rối tại sân bay Newark, New Jersey. Lý do là nhân viên kiểm soát biên giới đã tìm thấy một meme trên điện thoại của anh ta mô tả JD Vance (nhân vật chính trị người Mỹ) bị hói đầu.

Du khách người Na Uy tên là Mads Mikkelsen, anh đến sân bay Newark vào ngày 11 tháng 6, dự định đến Mỹ để thăm bạn bè, đầu tiên là ở New York, sau đó là Austin, Texas. Tuy nhiên, anh đã gặp phải “sự quấy rối và lạm dụng quyền lực” từ chính quyền nhập cư Mỹ. Mads cho biết anh cảm thấy bị phân biệt đối xử, nghi ngờ và thậm chí bị làm nhục trước nhiều người ở sân bay. Anh bị đưa đến một căn phòng có nhiều lính canh vũ trang, nơi anh bị giam giữ trong vài giờ và bị thẩm vấn nhiều lần về meme trên điện thoại của mình.

Bài viết đề cập rằng Mads tin rằng anh đã bị đối xử bất công vì một meme vô hại. Trải nghiệm của anh đã được truyền thông Na Uy Nordlys đưa tin, thu hút sự chú ý đến các chính sách kiểm soát biên giới của Mỹ và cách đối xử với du khách nước ngoài.

HN | Độ nóng: 545 điểm | 527 bình luận | Tác giả: miles #

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

Các cơ quan thực thi pháp luật không nên kiểm tra các thiết bị điện tử mà không có lệnh khám xét, quyền tự do ngôn luận nên được bảo vệ và những vấn đề này nên được thảo luận.
Kiểm soát biên giới rất phức tạp, không có quyền hợp pháp nào yêu cầu được vào một quốc gia không chào đón bạn, không có thủ tục tố tụng phù hợp để bảo vệ bạn.
Tình hình hiện tại không đại diện cho quá khứ hoặc tương lai, nên tập trung vào bức tranh lớn hơn.
Thay đổi cách thức hoạt động của thế giới, cách thức hoạt động của các quốc gia và cách thức tổ chức của con người là không thực tế.
Có thể xây dựng các tiêu chuẩn nhân quyền cơ bản trong các hiệp định quốc tế, không nên bỏ qua các chính sách cụ thể.
Các sửa đổi hiến pháp áp dụng cho tất cả mọi người, kể cả những người không phải là công dân chưa nhập cảnh vào Hoa Kỳ.
Tự do ngôn luận là một quyền tự nhiên, chính phủ không nên tước đoạt, hiến pháp bảo đảm quyền của người không phải là công dân.
Những người không nổi tiếng khi nhập cảnh vào Trung Quốc sẽ không bị thẩm vấn vì chỉ trích chính phủ.
Người Mỹ có xu hướng nghĩ rằng Trung Quốc tồi tệ hơn về mọi mặt, mặc dù bằng chứng có thể ngược lại.
Chế độ độc tài ở Mỹ không thực sự kiểm soát dân số, miễn là bạn không gây ra vấn đề gì, không ai quan tâm bạn nói gì.

Thnickels #

Thnickels

https://thick-coins.net/

Tiêu đề trang web: Thick Coins (Đồng Tiền Dày) được tạo bởi Theodore Nichols

Lời chào: Theodore Nichols chào mừng mọi người đến với trang web của ông.
Tin tức mới nhất: Ngày 6 tháng 5 năm 2025: Người hàng xóm của ông bị thương và tranh cãi với ông về vấn đề tiền xu. Người hàng xóm vẫn chưa trả lại nguyên mẫu “thnickel” của ông. Ông yêu cầu mọi người giúp quảng bá việc này. Ngày 1 tháng 5 năm 2025: Ông hợp tác với một đối tác và bắt đầu nhận đặt trước “thnickel”, số lượng có hạn. Ngày 30 tháng 4 năm 2025: Ông nhận được hàng trăm email, cảm ơn mọi người đã quan tâm đến tờ rơi quảng cáo của ông. Ông nói với cháu trai rằng tờ rơi vẫn hiệu quả trong thời đại ngày nay, trong khi cháu trai ông cho rằng mạng xã hội mới là phương tiện chính. Ngày 24 tháng 4 năm 2025: Cảm ơn mọi người đã thể hiện sự quan tâm sâu sắc đến đồng xu của ông, mặc dù số lượng đặt trước có hạn, nhưng vẫn còn một số chỗ.
Giới thiệu về thicknickel: Ông cho rằng đồng xu “nickel” truyền thống quá mỏng, cần một loại tiền xu dày hơn. Ông đang sản xuất “thnickel” trong cơ sở đúc tiền mới của mình. “Thnickel” nặng hơn so với tiền tệ thông thường, có thể làm hài lòng những người tốt và đồng thời răn đe những kẻ xấu.
Nguồn gốc ý tưởng: Theodore kể về lý do ông tạo ra “thnickel”. Ông từng bị trộm đột nhập, sử dụng túi đựng tiền xu để dọa trộm, nhưng tên trộm không hề quan tâm, cuối cùng không chỉ mất tiền xu mà còn mất cả cây chổi yêu thích của ông. Điều này khiến ông cảm thấy rất xấu hổ, vì vậy ông quyết tâm không để tiền lẻ của mình bị coi thường nữa.
Nhà máy đúc tiền: Ông đã biến nhà để xe của mình thành một nhà máy đúc tiền, chuyên sản xuất đủ “thnickel” để đáp ứng nhu cầu tôn trọng của mọi người. Cơ sở mới của ông được trang bị nhiều công cụ, chuyên sản xuất hiệu quả.
Quảng bá và thông tin liên hệ: Ông hy vọng mọi người giúp quảng bá “thnickel”, có thể in và dán tờ rơi trong khu phố hoặc thành phố. Nếu ai đó muốn mua “thnickel” hoặc có bất kỳ câu hỏi nào, có thể liên hệ với ông qua email hoặc điện thoại.

Nói chung, Theodore Nichols tìm kiếm sự tôn trọng thông qua việc tạo ra “thnickel” và kêu gọi mọi người ủng hộ sự nghiệp và sản phẩm của ông.

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

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

Các bình luận trong HTML rất thú vị, chứa thông tin bí mật và biểu tượng cảm xúc đồng xu của nhà thiết kế Theo.
Có người đùa rằng biểu tượng cảm xúc này là một phần mở rộng của “emoticon”, chính xác hơn là nghệ thuật ASCII.
Có người gọi biểu tượng cảm xúc này là “emothickon”.
Có người đề cập rằng nếu đồng xu có kích thước bằng biểu tượng cảm xúc, thì không thể đánh giá cao độ dày của đồng tiền rộng.
Có người trả lời bằng biểu tượng cảm xúc “()_)”.
Có người bình luận rằng thiết kế này làm cho trang web trở nên “grrrrreat”.
Theo đã tạm dừng việc bán đồng xu để xử lý các đơn đặt hàng trước và cho biết sẽ còn lại một số đồng xu sau đó.
Có người hỏi liệu có thể gửi đến Vương quốc Anh không.
Theo trả lời rằng đã có người từ Vương quốc Anh nhận được đồng xu của anh ấy.
Có người yêu cầu được một đồng xu.
Theo cho biết sẵn sàng đổi một đồng xu dày lấy một lượng lớn đồng xu mỏng.
Có người hỏi liệu có thể sử dụng séc cá nhân hoặc lệnh phiếu không.
Theo trả lời rằng miễn là tài khoản ngân hàng đằng sau séc không yếu ớt tương tự.
Có người thích thiết kế theo phong cách năm 1998 này, mặc dù nó được tạo ra vào năm 2025.
Có người đề cập rằng phong cách cổ điển này tốt hơn các trang web hiện đại, tải nhanh hơn.
Có người thích truy cập các trang web năm 1998 hơn là hầu hết các trang web “hiện đại”.
Có người chỉ ra rằng trang web đã hotlink Geocities thông qua bộ nhớ cache của Wayback Machine.
Có người đề nghị quản trị viên/người điều hành nên xóa ID liên kết Beehiiv khỏi liên kết.
Có người đề nghị sử dụng tiện ích mở rộng “ClearURLs” để tự động xóa các liên kết theo dõi.
Có người đề cập rằng Firefox có một tùy chọn menu ngữ cảnh “Sao chép liên kết sạch” gốc.
Có người đề cập rằng trình duyệt Brave có tính năng này và trình chặn quảng cáo.
Có người đề cập rằng trang web này được xây dựng bằng FrontPage 98.
Có người đề cập rằng các trang web “được xây dựng bằng tình yêu” như thế này là kiểu cũ.
Có người đề cập đến “được xây dựng bởi những con khỉ mã của chúng tôi”.
Có người đề cập đến “mua cho tôi một tách cà phê”.
Có người đề cập rằng anh ấy đã xây dựng một trang web cho trang web nhiếp ảnh của ông nội mình bằng FrontPage.

Microsoft Edit #

Microsoft Edit

https://github.com/microsoft/edit

Trang web này nói về một dự án có tên “microsoft/edit”, một trình soạn thảo văn bản đơn giản, được thiết kế để tri ân trình soạn thảo MS-DOS cổ điển, đồng thời cung cấp giao diện hiện đại và khả năng điều khiển nhập liệu tương tự như VS Code. Mục tiêu của dự án là cung cấp một trình soạn thảo dễ sử dụng, ngay cả đối với những người dùng không quen thuộc với terminal.

Hướng dẫn cài đặt: Người dùng có thể tải xuống các tệp nhị phân để cài đặt từ trang Releases của dự án. Đối với người dùng Windows, có thể cài đặt phiên bản mới nhất của trình soạn thảo thông qua WinGet bằng lệnh winget install Microsoft.Edit.

Hướng dẫn xây dựng:

Đầu tiên, cần cài đặt môi trường ngôn ngữ Rust.
Cài đặt toolchain nightly: rustup install nightly.
Hoặc thiết lập biến môi trường RUSTC_BOOTSTRAP=1.
Sao chép kho mã nguồn.
Đối với bản dựng phát hành, chạy lệnh: cargo build --config .cargo/release.toml --release.

Lưu ý cho người bảo trì gói:

Đặt tên gói: Tên tệp thực thi chuẩn của dự án là “edit”, một tên khác là “msedit”. Để tránh xung đột với các lệnh hiện có, nên sử dụng “msedit” làm tên cho gói và tệp thực thi.
Tên thư viện ICU (SONAME): Dự án tùy chọn phụ thuộc vào thư viện ICU để thực hiện các chức năng tìm kiếm và thay thế. Theo mặc định, dự án sẽ tìm kiếm SONAME không có hậu tố phiên bản. Nếu cài đặt sử dụng SONAME khác, cần thiết lập các biến môi trường tương ứng khi xây dựng.

Về: Ý tưởng cốt lõi của dự án là “tất cả chúng ta đều đang chỉnh sửa”. Nó liên quan đến các chủ đề bao gồm trình soạn thảo, ngôn ngữ Rust, terminal và trình soạn thảo văn bản.

Tài nguyên:

Dự án cung cấp tệp README, giấy phép MIT và quy tắc ứng xử.

Hoạt động của dự án:

Dự án đã nhận được 10.4k sao, có 63 người theo dõi và 439 nhánh.

Người đóng góp:

Dự án có 57 người đóng góp.

Ngôn ngữ lập trình:

Dự án chủ yếu được viết bằng ngôn ngữ Rust, chiếm 99.9%, và 0.1% ngôn ngữ Roff.

Bản tóm tắt trên bao gồm các nội dung chính của trang web, bao gồm giới thiệu dự án, hướng dẫn cài đặt và xây dựng, lưu ý, tài nguyên và hoạt động của dự án, v.v.

HN | Độ nóng: 460 điểm | 288 bình luận | Tác giả: ethanpil #

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

Turbo Vision là một trong những thư viện cửa sổ chế độ văn bản tốt nhất hiện có, cho phép ánh xạ toàn bộ màn hình văn bản vào một mảng.
Phiên bản C++ Turbo Vision hiện đại đã được chuyển sang hỗ trợ Unicode.
Một số khóa học đại học ở Ấn Độ cập nhật chậm và vẫn sử dụng Turbo C++.
Mặc dù Turbo C++ được coi là lỗi thời, nhưng vẫn có người sử dụng nó, đặc biệt là trong DOSBox.
Có người đã kiếm được rất nhiều tiền bằng cách sử dụng ứng dụng quảng cáo truyền hình được viết bằng Turbo Vision.
Turbo Vision được phát triển bởi Borland Corporation, Philippe Kahn từng là người đứng đầu công ty.
Philippe Kahn hiện vẫn còn hoạt động.
Ngành phát thanh truyền hình tiến triển chậm hơn so với ngành CNTT, mang lại cơ hội cho những người có nguồn lực.
Mỗi khi nhìn thấy một framework TUI hiện đại mới, tôi đều cảm thấy thất vọng vì chúng không tốt bằng Turbo Vision.
Charm là một công cụ TUI khá mạnh mẽ.
Turbo Vision được sử dụng trong Turbo C và Paradox 4.5, trải nghiệm rất tốt.
So với GUI hiện đại, Turbo Vision chạy trong một hộp nhỏ trên 386 cho cảm giác phản hồi nhanh hơn.

OpenAI tính phí theo phút, vì vậy hãy tăng tốc âm thanh của bạn #

OpenAI charges by the minute, so speed up your audio

https://george.mand.is/2025/06/openai-charges-by-the-minute-so-make-the-minutes-shorter/

Bài viết này được George Mandis viết, chủ đề là về cách tăng tốc độ phiên âm âm thanh của OpenAI và giảm chi phí. Quan điểm cốt lõi của bài viết là, bằng cách tăng tốc các tệp âm thanh, bạn có thể giảm số lượng token được sử dụng trong quá trình phiên âm, từ đó tiết kiệm thời gian và chi phí.

Bài viết bắt đầu bằng việc tác giả đưa ra một giải pháp đơn giản: trước khi phiên âm, hãy sử dụng ffmpeg để tăng tốc âm thanh lên 2 hoặc 3 lần. Làm như vậy có thể giảm thời gian chờ đợi và tiêu thụ token mà hầu như không ảnh hưởng đến chất lượng phiên âm. Tác giả cung cấp một script, kết hợp các công cụ và thủ thuật yêu thích của mình, bao gồm yt-dlp, ffmpeg và llm, để trích xuất âm thanh video, tăng tốc âm thanh và gửi nó đến OpenAI để phiên âm.

Tác giả chia sẻ cách anh ấy vô tình khám phá ra thủ thuật này. Anh ấy đã cố gắng tóm tắt một bài phát biểu dài 40 phút của Andrej Karpathy, nhưng ban đầu không sử dụng chức năng phiên âm tự động do YouTube cung cấp, vì anh ấy đã nhầm tưởng rằng nó không khả dụng. Anh ấy đã thử các phương pháp khác, bao gồm sử dụng một script cũ để trích xuất âm thanh từ URL video và phiên âm cục bộ bằng whisper, nhưng do pin yếu, anh ấy quyết định thử sử dụng API của OpenAI.

Trong khi thử nghiệm công cụ phiên âm của OpenAI, tác giả nhận thấy rằng việc sử dụng mô hình whisper-1 tuy chậm nhưng có thể hoàn thành nhiệm vụ. Vì tò mò, anh ấy đã thử mô hình gpt-4o-transcribe mới, mô hình này được thiết kế để xử lý đầu vào đa phương thức và hứa hẹn phản hồi nhanh hơn. Tuy nhiên, anh ấy đã gặp phải một vấn đề: giới hạn độ dài âm thanh là 25 phút, trong khi tệp âm thanh của anh ấy gần 40 phút.

Tác giả đã cân nhắc khả năng cắt bớt âm thanh, nhưng nhận thấy không có 14 phút rõ ràng nào có thể cắt bỏ. Anh ấy chợt nghĩ, tại sao không tăng tốc âm thanh trước khi gửi đi? Mọi người thường nghe podcast với tốc độ 1-2 lần. Anh ấy đã viết một script nhanh để tăng tốc âm thanh lên 2 lần, sau đó gửi tệp cho OpenAI, và kết quả rất thành công.

Bài viết tiếp tục khám phá lý do tại sao phương pháp này hiệu quả, tác giả so sánh nó với việc tối ưu hóa hình ảnh và khả năng chịu lỗi văn bản của bộ não con người. Việc tăng tốc âm thanh sẽ làm mất đi một số âm thanh tinh tế và các từ ngắn thỉnh thoảng, nhưng điều này dường như không ảnh hưởng đến khả năng hiểu. Mô hình phiên âm dường như cũng làm rất tốt trong việc này.

Cuối cùng, tác giả khám phá xem phương pháp này có thực sự tiết kiệm tiền hay không. Anh ấy phát hiện ra rằng OpenAI tính phí dựa trên token âm thanh, những token này thay đổi theo thời lượng đầu vào. Âm thanh nhanh hơn có nghĩa là ít giây hơn và ít token hơn. Anh ấy cung cấp một số dữ liệu chi phí dựa trên tệp âm thanh 40 phút, cho thấy chi phí token đầu vào giảm 33% ở tốc độ 3 lần. Tuy nhiên, phần lớn chi phí của mô hình phiên âm vẫn là token đầu ra. Anh ấy cũng lưu ý rằng số lượng token đầu ra của phiên bản tốc độ 2 và 3 lần là hoàn toàn giống nhau, điều này có thể là do token đầu ra phản ánh khả năng hiểu và tóm tắt đầu vào của mô hình, và phiên bản “tóm tắt” (tức là giảm token) của cùng một âm thanh tạo ra mức độ hiểu tương đương. Điều này cũng có thể là sự phản ánh của giới hạn thường có là 4.096 token khi sử dụng chế độ gpt-4o-transcription để phiên âm.

HN | Độ nóng: 414 điểm | 118 bình luận | Tác giả: georgemandis #

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

Sử dụng lệnh ffmpeg có thể loại bỏ phần im lặng trong âm thanh, tiết kiệm thời gian sử dụng OpenAI.
Có người đề nghị sử dụng các công cụ như diffchecker để so sánh chất lượng văn bản trước và sau khi tăng tốc âm thanh.
Có người đề xuất sử dụng LLM (mô hình ngôn ngữ lớn) để so sánh chất lượng văn bản trước và sau khi tăng tốc âm thanh.
Có người đề cập đến việc sử dụng LLM để so sánh sẽ tiêu tốn nhiều token hơn, không bằng sử dụng trực tiếp công cụ dòng lệnh.
Có người chia sẻ kinh nghiệm nghe giảng với tốc độ 2x và hỏi người khác có cảm thấy quá nhanh không.
Có người cho rằng tốc độ nói của Andrej rất nhanh, khó có thể hiểu được ở tốc độ trên 1.25x.
Có người đưa ra ý tưởng tự động phát hiện tốc độ nói trong âm thanh.
Có người đề nghị sử dụng mô hình whisper để xuất số lượng token mỗi giây, để phát hiện tốc độ nói.
Có người đề xuất tính toán số lượng âm tiết mỗi giây thông qua FFT và phân tích cơ bản.
Có người khuyên dùng mô hình nhận dạng giọng nói lỗi thời để phát hiện số lượng âm tiết, để hướng dẫn tăng tốc và phát hiện thời gian chết.
Có người đề xuất sử dụng biến đổi Hilbert và FFT để lấy tốc độ âm vị.
Có người đề xuất sử dụng phương pháp heuristic đơn giản để tính số lượng từ và thời lượng nói trong mỗi đoạn video.
Có người đề cập đến nghiên cứu về tốc độ truyền thông tin ngôn ngữ của con người trong các bài báo khoa học, và đề nghị sử dụng các kỹ thuật tương tự để điều chỉnh tốc độ video.
Có người cho biết không thể chịu được tốc độ nói bình thường, mong muốn nền tảng hỗ trợ tốc độ trên 2x.
Có người chia sẻ tiện ích mở rộng Chrome do mình tạo ra, dùng để tăng tốc độ phát video.
Có người đề cập đến việc sử dụng tiện ích mở rộng Chrome để tăng tốc độ phát video lên 10 lần.
Có người sử dụng công cụ đánh dấu trang để điều chỉnh tốc độ phát video.
Có người đề xuất sử dụng giọng “người đấu giá” đặc biệt dễ hiểu để phát văn bản với tốc độ 10 lần.
Có người cho rằng chất lượng âm thanh là yếu tố khác biệt chính khi nghe âm thanh nhanh.

Kho Lưu trữ Quốc gia tại College Park, MD, sẽ trở thành một cơ sở liên bang hạn chế ra vào #

National Archives at College Park, MD, will become a restricted federal facility

https://www.archives.gov/college-park

Cục Lưu trữ Quốc gia Hoa Kỳ tọa lạc tại College Park, Maryland, nơi lưu giữ các hồ sơ vĩnh viễn do các cơ quan liên bang tạo ra, bao gồm:

Hồ sơ văn bản: Bao gồm các hồ sơ văn bản từ các cơ quan dân sự.
Hồ sơ đơn vị quân đội: Bao gồm hồ sơ đơn vị lục quân từ Thế chiến I và hồ sơ đơn vị hải quân từ Thế chiến II.
Ảnh tĩnh: Các tài liệu ảnh tĩnh khác nhau.
Hồ sơ điện tử: Bao gồm các tài liệu lưu trữ ở dạng điện tử.
Bản đồ và tài liệu kiến trúc: Bao gồm bản đồ và bản vẽ thiết kế kiến trúc.
Phim, âm thanh và video: Bao gồm phim, âm thanh và video lưu trữ.
Hồ sơ vụ ám sát Kennedy: Các hồ sơ liên quan đến vụ ám sát Kennedy.
Vi phim của Trung tâm Tài liệu Berlin: Các tài liệu vi phim liên quan đến Trung tâm Tài liệu Berlin.

Điểm nổi bật của bộ sưu tập bao gồm ảnh và tác phẩm đồ họa, hồ sơ văn bản, v.v. Ngoài ra, còn cung cấp thông tin về địa điểm và giờ mở cửa của bộ sưu tập. Địa chỉ của Cục Lưu trữ Quốc gia Hoa Kỳ chi nhánh College Park là 8601 Adelphi Road, College Park, MD 20740. Số điện thoại của trung tâm dịch vụ khách hàng là 1-866-272-6272, số điện thoại tìm đồ thất lạc là 301-837-2900, địa chỉ email là inquire@nara.gov. Phòng nghiên cứu mở cửa từ Thứ Hai đến Thứ Sáu, từ 9 giờ sáng đến 5 giờ chiều. Rất khuyến khích đặt lịch hẹn nghiên cứu, nhưng cũng có thể nghiên cứu với tư cách là khách vãng lai. Có thể đặt lịch hẹn nghiên cứu thông qua Eventbrite trên trang đặt lịch hẹn nghiên cứu khu vực DC của Cục Lưu trữ Quốc gia.

Các nhà nghiên cứu có thể tham khảo trước thông qua archives2reference@nara.gov và tham khảo các vấn đề về đăng ký nhà nghiên cứu hoặc đặt phòng nghiên cứu thông qua visit_archives2@nara.gov. Các câu hỏi về tư vấn và đặt lịch hẹn cho phương tiện truyền thông đặc biệt có thể liên hệ theo các email sau: tư vấn bản đồ consultation.carto@nara.gov, tư vấn ảnh tĩnh consultation.stillpix@nara.gov, tư vấn phim và âm thanh mopix@nara.gov.

Trang web cũng cung cấp các liên kết đến nghiên cứu lịch sử, bao gồm công cụ tìm kiếm, hồ sơ quân sự, công cụ nghiên cứu trực tuyến, thông tin đặt hàng, v.v. Ngoài ra, còn có các hồ sơ thường được yêu cầu, chẳng hạn như hồ sơ vụ ám sát Kennedy, hồ sơ Thế chiến I, hồ sơ Chiến tranh Việt Nam và vi phim của Trung tâm Tài liệu Berlin.

Khách truy cập có kế hoạch tham quan có thể tìm thấy chỉ đường đến tòa nhà, xem chính sách của phòng nghiên cứu và tìm hiểu những gì mong đợi khi đến nơi. Ngoài ra, còn có phần liên hệ với chúng tôi, bao gồm số điện thoại và địa chỉ email của các nhân viên và bộ phận chủ chốt.

Các công cụ và cơ sở dữ liệu nghiên cứu trực tuyến, cơ hội tình nguyện và thực tập, tài nguyên dành cho nhà giáo dục và thông tin liên hệ với chúng tôi cũng được cung cấp trên trang web. Các liên kết truyền thông xã hội bao gồm Facebook, Twitter và Instagram.

Trang web cũng đề cập đến một số cập nhật mới nhất, chẳng hạn như từ ngày 8 tháng 7 năm 2022, một số series của nhóm hồ sơ 241 (Hồ sơ của Cục Sáng chế và Nhãn hiệu Hoa Kỳ) sẽ tạm thời đóng cửa để chuẩn bị di chuyển đến Cục Lưu trữ Quốc gia ở Kansas City. Nhật ký boong tàu của Hải quân Hoa Kỳ trong thời kỳ Chiến tranh Việt Nam sẽ đóng cửa đối với nghiên cứu do thỏa thuận số hóa với Bộ Cựu chiến binh. Một số hồ sơ của A2 sẽ đóng cửa vào ngày 20 tháng 12, bao gồm sổ nhật ký tàu và trạm của Hải quân Hoa Kỳ từ năm 1976-78 và sổ nhật ký từ năm 1956-75. Sau khi hoàn tất số hóa, dự kiến sớm nhất là vào đầu năm 2020, các nhật ký boong tàu riêng lẻ sẽ có sẵn để nghiên cứu. Việc số hóa là để hỗ trợ xử lý các yêu cầu bồi thường của cựu chiến binh và cũng sẽ hỗ trợ khả năng tiếp cận công chúng lớn hơn.

Ngoài ra, nghiên cứu văn bản hiện có thể sử dụng ScanSnap cho mục đích cá nhân. Trong trường hợp thời tiết khắc nghiệt, bạn có thể xem trạng thái hoạt động của chúng tôi, Facebook và Twitter. Thông qua trang web OPM hoặc bằng cách gọi đường dây trạng thái theo số 301-837-0700, hãy tìm hiểu trạng thái hoạt động của khu vực Washington, D.C., xem có thông báo đóng cửa, mở cửa muộn hoặc đóng cửa sớm hay không.

Cuối cùng, trang web còn cung cấp phòng trưng bày truyền thông, trưng bày các tác phẩm nhiếp ảnh quân sự của Hoa Kỳ trong Chiến tranh Việt Nam, cũng như thông tin về các sự kiện sắp tới và các sự kiện trực tuyến.

HN | Độ nóng: 296 điểm | 93 bình luận | Tác giả: LastTrain #

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

Chính sách này có nghĩa là chỉ các nhà nghiên cứu mới được vào tòa nhà, để giảm số lượng người đến trực tiếp mà không hẹn trước.
Chính sách có thể nhằm mục đích nâng cao hiệu quả làm việc của nhân viên trong việc xử lý khách truy cập có mục đích nghiên cứu rõ ràng.
“Mục đích thương mại hợp pháp” có thể bị hiểu nhầm thành “nhu cầu thương mại”, thực tế là đề cập đến mục đích của khách truy cập.
Chính sách có thể cho phép những người có hẹn và có mục đích nghiên cứu rõ ràng được vào, để giảm bớt việc truy cập tùy tiện.
Chính sách có thể không ngăn cản mọi người theo đuổi bất kỳ lý thuyết điên rồ nào, miễn là họ thực hiện nó bằng một quy trình nghiên cứu hợp pháp.
Chính sách có thể đánh giá tính hợp pháp của quy trình nghiên cứu dựa trên việc có hợp tác và nộp tài liệu rõ ràng trước hay không.
Chính sách có thể có nghĩa là nếu ai đó đưa ra những nhận xét bất lợi cho lãnh đạo, họ có thể bị cấm truy cập.
Chính sách có thể có nghĩa là NARA không đủ kinh phí, đang cố gắng tìm sự cân bằng giữa chuyển đổi kỹ thuật số và đáp ứng nhu cầu KTLO.
KTLO có thể là viết tắt của “keeping the lights on” (duy trì hoạt động), tức là các nhu cầu vận hành cơ bản.
Chính sách có thể không ngăn cản mọi người theo đuổi bất kỳ lý thuyết điên rồ nào, miễn là họ thực hiện nó bằng một quy trình nghiên cứu hợp pháp.
Chính sách có thể có nghĩa là NARA không đủ kinh phí, đang cố gắng tìm sự cân bằng giữa chuyển đổi kỹ thuật số và đáp ứng nhu cầu KTLO.
Có người cho rằng việc lấy thẻ nghiên cứu không phức tạp, nhân viên thân thiện.
Có người ủng hộ các biện pháp an ninh chặt chẽ hơn, vì trong quá khứ các tài liệu lưu trữ có xu hướng bị đánh cắp và phá hoại.
Có người mong muốn niêm phong các tài liệu gốc, đồng thời tăng cường tính cởi mở của các bản quét kỹ thuật số.

Công nghệ mở rộng hiển thị cổ điển của X11 #

Ancient X11 scaling technology

https://flak.tedunangst.com/post/forbidden-secrets-of-ancient-X11-scaling-technology-revealed

Bài viết này thảo luận về một số hiểu lầm và thách thức liên quan đến máy chủ hiển thị X11 trong việc hỗ trợ DPI scaling, fractional scaling và đa màn hình. Tác giả khám phá khả năng scaling của X11 thông qua việc cố gắng thực hiện một nhiệm vụ đơn giản — vẽ một hình tròn có kích thước luôn là hai inch trên các màn hình có kích thước và độ phân giải khác nhau. Mặc dù có người cho rằng điều này là không thể, nhưng tác giả thông qua thử nghiệm thực tế đã phát hiện ra rằng, thông qua lập trình và cấu hình phù hợp, X11 thực sự có thể hỗ trợ các chức năng này.

Bài viết bắt đầu bằng việc giới thiệu thông tin về các màn hình có kích thước và độ phân giải khác nhau mà tác giả thu thập được, bao gồm màn hình máy tính xách tay, màn hình máy tính để bàn và TV màn hình lớn. Tác giả sử dụng OpenGL và các shader đơn giản để vẽ hình tròn, đồng thời định nghĩa một biến quan trọng radius trong code để xác định kích thước pixel của hình tròn. Bằng cách lắng nghe các sự kiện cấu hình của X server, chương trình có thể điều chỉnh kích thước của hình tròn theo sự di chuyển hoặc thay đổi kích thước của cửa sổ.

Tác giả giải thích thêm về cách lấy thông tin màn hình cần thiết từ X server, bao gồm chiều rộng vật lý và chiều rộng ảo, đồng thời sử dụng thông tin này để tính toán bán kính của hình tròn, nhằm duy trì kích thước thực tế của nó không đổi trên các màn hình khác nhau. Bài viết cũng đề cập đến một số xử lý code bổ sung, chẳng hạn như xử lý các sự kiện expose và vòng lặp vẽ, để đảm bảo hình tròn có thể điều chỉnh kích thước chính xác giữa các màn hình khác nhau.

Cuối cùng, tác giả chứng minh rằng X11 thực sự có thể hỗ trợ DPI scaling và cấu hình đa màn hình thông qua hiệu ứng hình ảnh của việc hiển thị hình tròn trên các màn hình khác nhau. Mặc dù gặp phải một số thách thức trong quá trình thao tác thực tế, chẳng hạn như đo kích thước TV không chính xác, nhưng tác giả đã thực hiện thành công mục tiêu trên các thiết bị khác nhau. Bài viết kết thúc bằng suy ngẫm của tác giả về những người cho rằng một số việc là không thể, khuyến khích người đọc không nên tin những gì người khác nói một cách dễ dàng, mà nên tự mình thử nghiệm và khám phá. Tác giả cũng đề cập rằng, anh không chỉ chạy thành công chương trình trên máy tính xách tay mà thậm chí còn chạy chương trình trên router ở phòng khác, mọi thứ đều hoạt động bình thường như một phép màu.

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

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

Công nghệ thu phóng cổ điển của X11 tốt hơn phương pháp thu phóng hiện tại của Wayland, vì nó hiển thị trực tiếp ở độ phân giải mục tiêu, tránh mất hiệu năng và đầu ra bị mờ.
Việc Wayland ban đầu không áp dụng phương pháp thu phóng này thật khó hiểu, vì triết lý thiết kế của nó là ủy thác phần lớn công việc cho client.
Ứng dụng cần có khả năng xử lý các hệ số thu phóng tùy ý để có được chất lượng và hiệu năng tốt nhất trên các thiết bị đầu ra khác nhau.
Apple ban đầu áp dụng chiến lược thu phóng 2x trên OS X, sau này đã thay đổi vì vấn đề chi phí phần cứng.
Trong các phiên bản đầu của OS X, Apple đã thử các phương pháp thu phóng truyền thống hơn, nhưng cuối cùng đã từ bỏ vì khó triển khai.
Unity của Ubuntu từng đạt được thu phóng không nguyên bằng cách thay đổi kích thước phông chữ, hiệu quả đối với người dùng khá tốt.
KDE Plasma và các phần mềm Wayland hoạt động tốt khác đã hỗ trợ phương pháp thu phóng mà người dùng mong muốn, đó là mã GUI sẽ đảm bảo nội dung càng gần lưới pixel càng tốt, tránh kết quả bị mờ.
Giao thức Wayland trước đây chỉ có thể truyền đạt các hệ số thu phóng nguyên cho client, giờ đây cần hỗ trợ các hệ số thu phóng phân số thông qua giao thức mới.
Nếu Wayland có thể xử lý thu phóng đúng cách ngay từ đầu, thì trình tổng hợp thậm chí không cần biết về thu phóng, có thể giao hoàn toàn vấn đề cho client xử lý.

Đọc Chip Hộ Chiếu NFC trong Linux #

Reading NFC Passport Chips in Linux

https://shkspr.mobi/blog/2025/06/reading-nfc-passport-chips-in-linux/

Bài viết này nói về cách đọc dữ liệu từ chip NFC trong hộ chiếu trên hệ thống Linux. Tác giả, vì những lý do hợp pháp chứ không phải độc hại, muốn đọc tất cả dữ liệu trong chip NFC của hộ chiếu của mình. Sau một hồi tìm kiếm, tác giả đã chọn công cụ pypassport của roeften để đạt được mục đích này.

Bối cảnh #

Chip NFC trong hộ chiếu được bảo vệ bằng mật khẩu, mật khẩu được in trên trang bên trong của hộ chiếu. Ngoài việc cần tiếp xúc vật lý với hộ chiếu để đọc NFC, bạn cũng cần có thể nhìn thấy mật khẩu. Mật khẩu được in trên “Khu vực có thể đọc bằng máy” (MRZ), đó là lý do tại sao một số nhân viên biên phòng sẽ quét hộ chiếu qua đầu đọc thẻ trước khi quét chip; họ cần mật khẩu và không muốn nhập thủ công.

Tác giả đang sử dụng hộ chiếu cũ đã hết hạn, việc hết hạn không chỉ là thu hồi tài liệu mà còn thay đổi hộ chiếu về mặt vật lý: cắt góc dưới bên trái của trang thông tin cá nhân, đảm bảo cắt góc MRZ đối diện với ảnh. Do đó, một phần của MRZ đã bị thiếu!

Xây dựng lại MRZ #

Mật khẩu bao gồm ba phần: số hộ chiếu (chữ và số), ngày sinh (YYMMDD) và ngày hết hạn (YYMMDD). Mỗi phần đều có một mã kiểm tra, và toàn bộ chuỗi cũng có một mã kiểm tra. Khi bìa hộ chiếu bị cắt, mã kiểm tra cuối cùng sẽ bị cắt. Định dạng mật khẩu cuối cùng là: Số Số-MãKiểmTra NgàySinh NgàySinh-MãKiểmTra NgàyHếtHạn NgàyHếtHạn-MãKiểmTra MãKiểmTra.

Nếu biết số hộ chiếu, ngày sinh và ngày hết hạn, bạn có thể tạo vùng có thể đọc được bằng máy (MRZ) của riêng mình, vùng này đóng vai trò là mật khẩu cho chip NFC.

Python Code Tạo MRZ #

Bài viết cung cấp một hàm Python 3, dùng để tính toán checksum và tạo MRZ. Thông qua hàm này, có thể tạo ra MRZ dùng làm mật khẩu cho chip NFC.

Có thể đọc được hộ chiếu đã hết hạn không? #

Tác giả ban đầu cho rằng việc cắt bỏ bìa hộ chiếu sẽ phá hỏng ăng-ten bên trong, nhưng theo hướng dẫn của Anh, không nên cắt bỏ bìa sau của hộ chiếu điện tử, vì chip NFC nằm ở đó. Điều này có thể là để đảm bảo rằng ngay cả khi hộ chiếu bị hủy, vẫn có thể xác minh tính xác thực của nó.

Mã hóa và các biện pháp an ninh khác #

Về mặt bảo mật, nó sử dụng công nghệ mã hóa khóa công khai tiêu chuẩn, điều này được giải thích chi tiết trong phần 11 của tài liệu 9303. Vì chip không có bộ hẹn giờ, nó không thể biết tần suất bị đọc. Chip có thể được thử mật khẩu hàng nghìn lần mà không bị khóa.

Liệu có thể bẻ khóa hộ chiếu một cách thô bạo không? #

Về lý thuyết, việc tấn công bằng phương pháp vét cạn (brute-force) là khả thi, nhưng xét đến việc hộ chiếu thường có thời hạn 10 năm, có 36525 ngày có thể là ngày hết hạn. Người sở hữu hộ chiếu thường dưới 100 tuổi, nghĩa là có 3652500 ngày có thể là ngày sinh. Như vậy đã có 133407562500 lần thử, và đó là chưa tính đến 1E24 số hộ chiếu có thể có. Trong thử nghiệm của tác giả, việc gửi MRZ sai sẽ khiến chip trả về “Trạng thái bảo mật không đáp ứng (0x6982)” trong một thời gian ngắn. Nhưng nếu biết số hộ chiếu và ngày sinh của mục tiêu, việc tấn công vét cạn để tìm ngày hết hạn có thể mất vài ngày, không phải là ngay lập tức, nhưng cũng không phải là không thể.

Có đáng để bẻ khóa mật khẩu bằng phương pháp brute-force không? #

Nếu bẻ khóa MRZ bằng phương pháp brute-force, có thể tìm ra ngày sinh của người sở hữu hộ chiếu. Ngoài ra, có thể lấy được thông tin như ảnh kỹ thuật số, họ tên đầy đủ, giới tính, quốc gia cấp và quốc tịch. Tất cả những thông tin này đều có thể lấy được bằng cách xem hộ chiếu, do đó việc cố gắng đọc điện tử không có nhiều giá trị.

Cài đặt #

Tác giả sử dụng https://github.com/roeften/pypassport. Thư viện cần cài đặt là pyasn1, sử dụng pip3 install pyasn1 để cài đặt. Sau khi tải PyPassport, tạo một file Python thử nghiệm trong cùng thư mục để xem có thể đọc được hộ chiếu không. Bài viết cung cấp một đoạn mã ví dụ để kiểm tra xem hộ chiếu có thể được đọc hay không.

Lấy Dữ Liệu Cấu Trúc #

Cấu trúc dữ liệu hộ chiếu hơi phức tạp. Tiêu chuẩn đặt dữ liệu vào các “nhóm dữ liệu” khác nhau, mỗi nhóm dữ liệu có ID riêng. Bằng cách chạy ep.keys(), bạn có thể thấy các nhóm dữ liệu có sẵn. Trong trường hợp của tác giả, có [‘60’, ‘61’, ‘75’, ‘77’]. 60 là khu vực công cộng, chứa một số metadata. 61 là DG1, chứa MRZ đầy đủ, bao gồm tên, giới tính, quốc tịch, v.v. của người sở hữu. 77 là đối tượng bảo mật tài liệu, đối với tác giả là trống. 75 là các mẫu sinh trắc học DG2 đến DG4, chứa hình ảnh và các metadata khác.

Bài viết cuối cùng đề cập rằng, bằng cách in ep[“75”], bạn có thể nhận được một số metadata thú vị, bao gồm ngày chụp, biểu cảm, màu mắt, độ dài khối hình ảnh khuôn mặt, loại hình ảnh khuôn mặt, mặt nạ đặc trưng, mã điểm đặc trưng, loại đặc trưng, vị trí ngang, bit dành riêng, vị trí dọc, v.v.

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

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

Tiêu chuẩn ICAO 9303 mô tả chi tiết cách xác minh và đọc dữ liệu tài liệu du lịch, nhưng trong ứng dụng thực tế có nhiều cách giải thích sáng tạo và lỗi.
Ứng dụng ủy quyền du lịch điện tử xác minh hộ chiếu là một quá trình phức tạp và gây đau đầu.
Tải ảnh hộ chiếu lên một máy chủ không an toàn không tốt bằng việc sử dụng công nghệ NFC để xác minh hộ chiếu.
Bằng lái xe Hà Lan chứa một dòng tương tự như MRZ, nhưng không tuân thủ tiêu chuẩn ICAO 9303, mà tuân theo tiêu chuẩn NEN-ISO-IEC 18013-3.
Nội dung MRZ của bằng lái xe Pháp tương tự như Hà Lan, nhưng tài liệu cụ thể vẫn chưa được tìm thấy.
Có người đã viết mã bằng ngôn ngữ Rust để đọc thông tin trong hộ chiếu và tò mò về cách thức hoạt động của eMRTD.
Nhiều hộ chiếu chứa bản quét dấu vân tay kỹ thuật số, nhưng thông tin này khó lấy hơn và cần khóa riêng do chính phủ nắm giữ.
Các quan chức chính phủ có thể bán khóa riêng cho người trả giá cao nhất, điều này phần nào phản ánh thị trường tự do.
Các khóa quan trọng không nên được sao chép, mà nên được kiểm tra trực tuyến, ví dụ: hộ chiếu gửi thử thách, thiết bị đầu cuối gửi thử thách đến HSM do chính phủ lưu trữ, HSM gửi phản hồi.
Kiểm soát chặt chẽ sẽ xảy ra ở biên giới và trạm kiểm soát mà không có sự đảm bảo về Internet.
Có sự khác biệt lớn trong sự hiểu biết về khóa và xử lý khóa giữa các chuyên gia bảo mật máy tính và các quan chức chính phủ.
Một nhà báo Hà Lan đã mua một hộ chiếu Syria giả có ảnh của thủ tướng, nhưng không đề cập đến việc nó có vượt qua kiểm tra kỹ thuật số hay không.
Dữ liệu nhạy cảm thực sự nên được mã hóa bằng khóa riêng duy nhất và được khóa bằng PIN, tương tự như FIDO thông qua NFC sẽ an toàn hơn.
DNA bạn để lại ở khắp mọi nơi, nhưng số hóa dữ liệu này và tự nguyện hoặc không tự nguyện chia sẻ nó với người khác, liên quan đến các vấn đề về bảo mật và quyền riêng tư dữ liệu.
Nhiều hộ chiếu cũng chứa mật khẩu máy tính của bạn, nhưng những mật khẩu này khó lấy hơn và cần khóa riêng mà chỉ chính phủ mới có.
Tạo checksum bị thiếu là không đáng kể, có thể dễ dàng tính toán từ thông tin khác.