2025-07-14 Top Stories #
- Sự chuyển đổi từ MV2 sang MV3 của Google Chrome đã loại bỏ quyền webRequestBlocking, nhưng phát hiện ra một lỗi cho phép vượt qua giới hạn đó.
- Các thành viên cộng đồng Mozilla đề xuất thu phí Firefox để hỗ trợ phát triển và cung cấp phiên bản không quảng cáo, không đo từ xa.
- Phán quyết của Tòa án Tối cao Hoa Kỳ khiến việc viết trực tuyến liên quan đến nội dung khiêu dâm gần như mất đi sự bảo vệ tự do ngôn luận.
- Tác giả lần đầu đọc “Neuromancer” vào năm 2025, ấn tượng sâu sắc với những mô tả công nghệ mang tính tương lai của nó.
- Ngôn ngữ lập trình Zig giới thiệu các tính năng I/O không đồng bộ mới, cho phép tùy chỉnh việc triển khai I/O và đưa vào mã phụ thuộc.
- Mô hình ngôn ngữ Kimi K2 do Moonshot AI ra mắt dựa trên kiến trúc Mixture of Experts, phù hợp cho nghiên cứu và trải nghiệm trò chuyện thông thường.
- Bài viết giải thích chi tiết nguyên lý hoạt động của màn hình, từ súng điện tử đến sự phát triển của bóng bán dẫn hiện đại.
- Một cư dân ở Arizona đã qua đời vì bệnh dịch hạch, các quan chức y tế công cộng kêu gọi người dân chú ý phòng ngừa.
- Vấn đề công nhân IT giả mạo từ Triều Tiên rất phổ biến, lợi dụng các phương tiện như deepfake để lừa đảo cơ hội làm việc từ xa.
- Bài viết khám phá các phương pháp triển khai coroutine trong ngôn ngữ C, không cần phụ thuộc vào hệ điều hành thời gian thực.
Vượt qua bản cập nhật lớn chống chặn quảng cáo của Google #
Bypassing Google’s big anti-adblock update
https://0x44.xyz/blog/web-request-blocking/
Bài viết này được Derin Eryılmaz đăng vào ngày 12 tháng 7 năm 2025, với chủ đề về cách tìm ra một phương pháp vượt qua bản cập nhật chống trình chặn quảng cáo lớn của Google Chrome. Bài viết bắt đầu bằng cách giới thiệu “MV” (manifest version) của trình duyệt, đặc biệt là việc Google Chrome đang loại bỏ MV2 để hỗ trợ MV3, điều này gây bất lợi cho các trình chặn quảng cáo. MV3 giới thiệu một thời gian chạy mới cho các tiện ích mở rộng của Chrome, loại bỏ quyền webRequestBlocking, một quyền quan trọng mà các trình chặn quảng cáo dựa vào để hoạt động bình thường.
Bài viết tiếp tục kể về một lỗi của trình duyệt Chrome mà tác giả đã phát hiện và báo cáo cho Google vào năm 2023, lỗi này cho phép vẫn sử dụng webRequestBlocking (cũng như các trình chặn quảng cáo) trong MV3. Tác giả cho rằng đây là một trong những lỗi thú vị nhất mà anh từng phát hiện và kêu gọi ngừng viết trình duyệt bằng JavaScript, vì các tiện ích mở rộng được viết bằng JavaScript và các hàm API trông giống như các hàm JavaScript, nhưng thực tế chúng là các hàm đặc biệt, thực thi các thao tác C++ của trình duyệt thông qua liên kết. Thiết kế này về mặt lý thuyết là an toàn, nhưng trước đây Google đã từng chèn các tệp JavaScript vào các trang sử dụng Chrome API, các “mô-đun liên kết tiện ích mở rộng” này sẽ khởi tạo các hàm API và xác thực các tham số trước khi chuyển chúng cho trình duyệt. Cách làm này đã dẫn đến nhiều lỗ hổng XSS phổ biến vào năm 2015 và 2016.
Mặc dù Google đã rút ra bài học từ những sai lầm và chuyển hầu hết các liên kết API sang C++ thuần túy, nhưng vẫn còn một số tệp liên kết JavaScript tồn tại và được sử dụng cho đến ngày nay. Ví dụ: nếu một tiện ích mở rộng của Chrome chạy một đoạn mã cụ thể, nó sẽ rơi vào một vòng lặp JavaScript và bị treo vô thời hạn. Sau đó, tác giả đề cập đến một API liên quan đến trình chặn quảng cáo - chrome.webRequest, API này vẫn sử dụng liên kết JavaScript.
Bài viết mô tả chi tiết lỗi mà tác giả đã phát hiện: Trong tiện ích mở rộng MV2, bằng cách thêm một trình lắng nghe để chặn các yêu cầu đến example.com. Nhưng trong MV3, phương pháp thêm trình lắng nghe chặn này không còn hiệu quả nữa. Tuy nhiên, tác giả đã tìm ra một cách điên rồ: tạo sự kiện của riêng mình. Mặc dù về mặt lý thuyết điều này là không thể, nhưng trên thực tế có thể thực hiện được do cách hoạt động của liên kết JavaScript. Tác giả đã tìm ra một lỗ hổng bằng cách nghiên cứu sâu vào mã C++: tham số opt_webViewInstanceId. Tham số này được thiết lập cho các ứng dụng nền tảng Chrome, cho phép chúng quản lý các trang web nhúng của mình (WebViews). Nếu một sự kiện có WebView ID, thì việc kiểm tra quyền webRequestBlocking sẽ bị bỏ qua. Vấn đề là trình duyệt chưa bao giờ xác minh xem một sự kiện có WebView ID có thực sự thuộc về một ứng dụng nền tảng hay không, vì vậy tiện ích mở rộng có thể giả mạo nó, bỏ qua kiểm tra và sử dụng chức năng chặn.
Cuối cùng, tác giả chỉ ra rằng, mặc dù về mặt lý thuyết ai đó có thể sử dụng lỗi này để tạo một trình chặn quảng cáo hoạt động hoàn toàn bình thường trong MV3, nhưng bản thân anh ta không biết cách tạo trình chặn quảng cáo, vì vậy anh ta đã chọn báo cáo vấn đề này cho Google vào tháng 8 năm 2023. Vấn đề này đã được khắc phục trong phiên bản Chrome 118, bằng cách kiểm tra xem tiện ích mở rộng sử dụng opt_webViewInstanceId có thực sự có quyền WebView hay không. Đối với báo cáo này, tác giả đã nhận được phần thưởng 0 đô la, vì Google cho rằng đây không phải là một vấn đề bảo mật, vì nó không cung cấp cho các tiện ích mở rộng quyền truy cập dữ liệu mà chúng vốn không có. Tác giả kết thúc bài viết bằng một đoạn hồi tưởng về trải nghiệm thú vị này và đề cập đến một lỗi khác của tiện ích mở rộng Chrome mà anh đã phát hiện trong cùng năm, lỗi đó đã nhận được số CVE và phần thưởng 10.000 đô la.
HN | Độ nóng: 947 điểm | 819 bình luận | Tác giả: deryilz #
https://news.ycombinator.com/item?id=44544266
- Nếu mọi người không đồng ý với cách làm của Google, cách đúng đắn là từ bỏ Chrome và tất cả các trình duyệt dựa trên Chromium, đánh vào vị thế độc quyền của chúng.
- Nhiều người quên bài học từ IE, thay vì học các tiêu chuẩn Web, họ lại phân phối Chrome cùng với ứng dụng của họ.
- Một số nhà phát triển, vì áp lực hoặc thiếu hiểu biết, đánh đồng “hoạt động trên Chrome” với “hoạt động”, ngay cả khi đó có thể chỉ là một tính năng của Chrome hoặc sử dụng các thủ thuật liên quan đến Chrome phá vỡ khả năng tương thích với các trình duyệt khác.
- Đôi khi tiêu chuẩn không định nghĩa một số hành vi chính xác, để cho người triển khai trình duyệt quyết định, Chrome và các trình duyệt khác có thể triển khai theo những cách khác nhau, nhưng đều tuân thủ tiêu chuẩn.
- Đôi khi ứng dụng chứa lỗi, nhưng một số hành vi khoan dung của Chrome có nghĩa là nó có thể hoạt động bình thường, sau đó ứng dụng được phát hành.
- Đôi khi mọi người sẽ sử dụng các API hoặc tính năng dành riêng cho Chrome hoặc Mobile Safari, vì họ không biết cách tốt hơn.
- Một số phần mềm bảo mật/WAF/chống bot dựa vào các điểm kỳ quặc JavaScript cụ thể của Chrome và cho rằng người dùng sử dụng Firefox hoặc các trình duyệt không phải Chrome hoặc iOS Safari là bot và chặn họ.
- Chrome đã trở thành IE mới về nhiều mặt, đây không phải là lỗi của Google hoặc các tác giả trình duyệt khác.
- Safari là IE mới, nó chứa đầy lỗi và Apple tích cực ngăn chặn sự tiến bộ của các tiêu chuẩn Web.
- Apple ngăn chặn sự phát triển của các ứng dụng Web bằng cách chặn Web Push và phá vỡ phần lớn chức năng ở chế độ PWA.
- Safari gây ra đau khổ cho các nhà phát triển thông qua vô số vấn đề nhỏ, hành vi trì hoãn phát lại âm thanh của nó không xảy ra trên các trình duyệt khác.
- Trước khi phát hành bất kỳ trang web/ứng dụng nào, hãy đảm bảo rằng nó cũng hoạt động trên Apple Safari Mobile, vì nó thường làm chậm sự tiến bộ của các tiêu chuẩn Web.
- Apple là người kháng cự cuối cùng trước sự chiếm lĩnh Web của Google như một nền tảng phát triển ChromeOS, nếu không có Safari thì chúng ta xong đời.
- Một khi Chrome có được sự thống trị tự do trên các biến thể iOS, đã đến lúc mài giũa sơ yếu lý lịch thành nhà phát triển ứng dụng ChromeOS thay vì nhà phát triển Web.
- Các engine trình duyệt khác có thể tồn tại, miễn là JIT thuộc về hệ thống, những engine khác có thể sử dụng JavaScriptCore của Apple.
- JIT phải thuộc về hệ thống vì chủ nghĩa tư bản, nếu người dùng có thể cài đặt bất kỳ phần mềm nào, Apple sẽ không thể tồn tại.
- Chủ nghĩa tư bản không tồn tại, vì sự tồn tại của nhãn hiệu, bản quyền và bằng sáng chế khiến chủ nghĩa tư bản chỉ còn là cái tên.
- Chủ nghĩa tư bản thực sự không bao giờ có thể tồn tại do thiếu minh bạch, tính cấp bách, độc quyền, v.v., chúng ta nhiều nhất chỉ có thể có chủ nghĩa tư bản do chính phủ kiểm soát.
- Tiêu chuẩn Web được quyết định bởi các kỹ sư Chrome triển khai các tính năng để nâng cao đánh giá hiệu suất hàng năm của họ.
- Ở Bồ Đào Nha/Tây Ban Nha, chúng ta cũng cần lo lắng về vấn đề này, người dùng Safari Mobile là thiểu số ở đây, nhưng họ thường có nhiều tiền hơn để chi tiêu.
- Những người giàu có không biết điều gì tốt cho họ, cứ mua iPhone, tôi tự hỏi tại sao?
- Họ không đủ thích bạn bè của mình để giúp họ giải quyết các vấn đề về điện thoại Android.
- Chrome có thị phần lớn đến mức họ kiểm soát các cơ quan tiêu chuẩn, con chó bị cái đuôi vẫy.
- Google phát hành thông số kỹ thuật, xin ý kiến phản hồi từ các nhóm Mozilla và WebKit, sau đó bỏ qua các vấn đề về bảo mật và quyền riêng tư, vẫn triển khai thực hiện, khiến các nhà phát triển Web phàn nàn rằng Safari tụt hậu, chỉ trích Apple cản trở sự phát triển của Web, và không ai quan tâm đến Firefox.
- Nhiều nhà phát triển Web đã ngừng quan tâm đến quy trình tiêu chuẩn, bất kỳ tính năng nào Google thêm vào đều là định nghĩa của họ về “web”, điều này cũng xảy ra trong thời kỳ thống trị của Internet Explorer, nhiều nhà phát triển Web sẵn lòng viết các trang web chỉ hoạt động trên Internet Explorer, văn hóa đơn nhất này đã gây tổn hại lớn đến web. Chrome là Internet Explorer mới.
Hãy để tôi trả tiền cho Firefox #
Let me pay for Firefox
https://discourse.mozilla.org/t/let-me-pay-for-firefox/141297
Bài viết này nói về quan điểm của John Karahalis, một thành viên của cộng đồng Mozilla, rằng Mozilla nên xem xét việc thu phí trình duyệt Firefox. John Karahalis là một người ủng hộ lâu năm của Mozilla, ông từng tham gia các dự án quảng bá Firefox và làm việc toàn thời gian tại Mozilla trong tám năm. Ông cho rằng, bây giờ là thời điểm thích hợp để xem xét việc thu phí Firefox, điều này không mâu thuẫn với tinh thần tự do của phần mềm nguồn mở, bởi vì ngay cả Quỹ Phần mềm Tự do cũng cho rằng chi phí phần mềm và sự tự do của phần mềm là tương thích.
John Karahalis đề cập rằng, thế giới Firefox lý tưởng của ông là bất kỳ người dùng nào không muốn trả tiền đều có thể không trả tiền. Miễn là Firefox vẫn tự do và nguồn mở, người dùng có thể chọn sử dụng các phiên bản phân nhánh, mặc dù họ có thể không nhận được dịch vụ khách hàng hoặc cập nhật phần mềm nhanh chóng như nhau. Ông nhấn mạnh rằng, ngay cả khi Firefox thu phí, người dùng vẫn có quyền sử dụng các gói thay thế, chẳng hạn như LibreWolf, Waterfox và IceCat, v.v.
Trong bài viết, John Karahalis bày tỏ mối lo ngại của mình về mô hình doanh thu quảng cáo mà các công ty Internet hiện đang dựa vào, ông cho rằng mô hình này dẫn đến những hậu quả xấu, chẳng hạn như tác động tiêu cực của Facebook đối với xã hội. Ông hy vọng Mozilla có thể tránh được số phận này và cho phép người dùng tài trợ trực tiếp cho việc phát triển Firefox.
Ông cũng đề cập rằng, ông sẵn sàng trả tiền cho những phần mềm đặt người dùng lên hàng đầu, bao gồm cả phần mềm miễn phí và nguồn mở. Ông tin rằng, nếu Firefox trở thành một sản phẩm do người dùng tài trợ, nhiều người sẽ quay lại, vì họ không thích mô hình kinh doanh hiện tại của Mozilla. Ông đề nghị Mozilla ít nhất nên cung cấp một tùy chọn để thử nghiệm, phát hành một phiên bản Firefox không có nội dung được tài trợ, không có đo từ xa, mặc định không sử dụng Google và tích hợp chức năng chặn quảng cáo, ông sẵn sàng trả tiền cho điều này.
Trong phần bình luận của bài viết, người dùng pmg bày tỏ sự đồng ý với quan điểm của John Karahalis và đề cập rằng ông sẵn sàng chấp nhận đo từ xa tùy chọn chỉ được sử dụng nội bộ Mozilla cho việc phát triển sản phẩm. Một người dùng khác, mzmzM114h, nói rằng ông không phải là người duy nhất có quan điểm này, ông nói thêm rằng, mặc dù có người cho rằng không ai trả tiền cho trình duyệt, nhưng thực tế là chúng ta chưa bao giờ có cơ hội trả tiền cho Firefox. Ông đề cập rằng Thunderbird, một thành viên của gia đình Mozilla, là một trường hợp thành công, nó hoàn toàn được tài trợ bởi các khoản quyên góp trực tiếp. Ông tin rằng, nếu Mozilla có thể xây dựng một kênh quyên góp trực tiếp dành riêng cho việc phát triển Firefox và cung cấp một phiên bản “không vô nghĩa” chính thức hoặc một trình cấu hình bản dựng minh bạch, điều này sẽ giúp xây dựng thiện cảm và sự tin tưởng của cộng đồng.
HN | Độ nóng: 705 điểm | 555 bình luận | Tác giả: csmantle #
https://news.ycombinator.com/item?id=44548610
- Có người thất vọng về Mozilla Foundation, cho rằng các khoản quyên góp có thể được sử dụng vào những nơi không hợp lý, chẳng hạn như quảng cáo tích hợp, tiền thưởng cho giám đốc điều hành, v.v.
- Có người cho rằng việc chỉ trích Mozilla trên Hacker News đã trở thành một xu hướng, một số người bình luận dường như đang cạnh tranh xem ai ghét Mozilla hơn.
- Mặc dù Mozilla có những vấn đề của nó, nhưng vẫn có người ủng hộ Firefox, cho rằng nó hỗ trợ các tiện ích mở rộng phong phú và hiệu suất tốt.
- Có người chỉ ra rằng Firefox có nhiều vấn đề nhỏ, cho rằng mức lương cao của CEO đủ để thuê thêm nhiều nhà phát triển hơn.
- Có quan điểm cho rằng, giá trị của lãnh đạo có thể lớn hơn 30 nhà phát triển, nhưng ban lãnh đạo của Mozilla hoạt động không tốt, khiến mức lương cao trở nên khó biện minh.
- Có người đặt câu hỏi tại sao cần phải trả hơn 150 nghìn đô la Mỹ tổng lương để thuê các kỹ sư phần mềm giỏi.
- Có người cho rằng nếu lương dựa trên giá trị được tạo ra, thì lương của nhiều nhà phát triển phần mềm sẽ cao hơn nhiều.
- Có người chỉ ra rằng nhiều nhà phát triển sẽ không rời bỏ công việc để làm tự do hoặc khởi nghiệp, vì làm tự do cần phải xử lý nhiều vấn đề phi kỹ thuật hơn và lương bổng không ổn định hơn.
- Có người đề cập rằng, ngay cả trong các doanh nghiệp có doanh thu hàng tỷ đô la, các nhà phát triển cũng có thể tạo ra giá trị to lớn thông qua những cải tiến nhỏ.
- Có người cho rằng, do các vấn đề như bảo hiểm y tế, số lượng người làm tự do ở Mỹ ít hơn, trong khi ở Anh từng rất phổ biến, nhưng đã giảm do quy tắc IR35.
- Có người giải thích quy tắc IR35 có thể có nghĩa là nếu bạn chỉ có một khách hàng, bạn là nhân viên, điều này là bất hợp pháp ở hầu hết các quốc gia EU.
- Có người cho rằng nhiều nhà phát triển được trả lương dưới 150 nghìn đô la Mỹ và nhiều người phóng đại thu nhập của họ.
- Có người cho rằng 150 nghìn đô la Mỹ là mức lương cao đối với nhiều kỹ sư châu Âu, đặc biệt là trong trường hợp làm việc từ xa.
- Có người cho rằng 150 nghìn đô la Mỹ cũng là một mức lương tốt ở Mỹ, cho rằng những người nghĩ con số này thấp có thể đang sống trong bong bóng.
- Có người cho rằng ở châu Âu với tư cách là một cá nhân đóng góp, có khả năng nhận được tổng lương gấp hơn 2 lần 150 nghìn đô la Mỹ.
- Có người cho rằng việc nhận được mức lương như vậy ở châu Âu là có thể, nhưng không phổ biến.
Phán quyết của Tòa án Tối cao gần như xóa bỏ quyền tự do ngôn luận đối với việc viết về tình dục trực tuyến #
Supreme Court’s ruling practically wipes out free speech for sex writing online
https://ellsberg.substack.com/p/free-speech
Bài viết này thảo luận về phán quyết gần đây của Tòa án Tối cao Hoa Kỳ, phán quyết gần như loại bỏ hoàn toàn sự bảo vệ quyền tự do ngôn luận đối với các bài viết trực tuyến liên quan đến nội dung tình dục. Tác giả Michael Ellsberg chỉ ra rằng phán quyết của Tòa án Tối cao cho phép các bang bảo thủ, thông qua sự hợp tác của các luật sư chuyên về thương tích cá nhân và phụ huynh, khởi kiện xuyên bang những người sáng tạo nội dung tình dục trên trang web cá nhân của họ. Theo phán quyết này, những người viết như tác giả, nếu không thực hiện các biện pháp xác minh độ tuổi trên trang web, có thể phải đối mặt với trách nhiệm pháp lý khổng lồ, thậm chí là cáo buộc hình sự.
Bài viết nhấn mạnh rằng phán quyết của Tòa án Tối cao cho phép luật pháp của một số bang (như Tennessee và South Dakota) có hiệu lực, những luật này cho phép các công tố viên bang truy tố bất kỳ nội dung nào bị coi là “có hại cho trẻ vị thành niên”, thậm chí có thể truy tố những người sáng tạo ở các bang khác. Một đạo luật của Tennessee quy định rằng nếu một trang web chứa hơn 33% nội dung “có hại cho trẻ vị thành niên” và chủ sở hữu trang web không thực hiện các biện pháp xác minh độ tuổi phức tạp và xâm phạm quyền riêng tư, thì có thể phải đối mặt với án tù từ ba đến mười lăm năm.
Ellsberg tuyên bố rõ ràng rằng ông sẽ không yêu cầu độc giả cung cấp giấy tờ tùy thân trên trang web của mình và cũng sẽ không đặt trang web của mình chỉ dành cho người lớn. Ông cho rằng môi trường pháp lý mới này gây ra mối đe dọa lớn cho những người sáng tạo và khiến quyền tự do ngôn luận của họ bị đàn áp. Ông đề cập rằng “hiệu ứng ớn lạnh” này là rất nghiêm trọng, vì nó không chỉ ảnh hưởng đến các bài viết về tình dục mà còn có thể gây ra thách thức cho tất cả các quyền tự do sáng tạo.
Ông cũng chỉ ra rằng luật mới của South Dakota quy định rằng việc xuất bản bất kỳ tài liệu nào bị coi là “có hại cho trẻ vị thành niên” đều có thể cấu thành tội nhẹ, thậm chí là trọng tội. Ellsberg cho rằng sự đàn áp quyền tự do ngôn luận của những luật này là không thể chấp nhận được và kêu gọi những người sáng tạo khác chú ý đến vấn đề này và tích cực bảo vệ quyền lợi của mình.
Cuối cùng, Ellsberg nhấn mạnh rằng ngay cả khi đối mặt với các mối đe dọa pháp lý, ông sẽ tiếp tục duy trì phong cách viết của mình và sẽ không khuất phục trước các yêu cầu pháp lý vô lý. Ông khuyến khích những người sáng tạo khác cũng phải giữ vững lập trường và bảo vệ quyền tự do ngôn luận.
HN | Độ nóng: 653 điểm | 928 bình luận | Tác giả: macawfish #
https://news.ycombinator.com/item?id=44543865
- Tất cả những luật xác thực danh tính này đều quá khắt khe, các bậc phụ huynh kỳ vọng chính phủ và các trang web ngẫu nhiên giáo dục con cái họ.
- Nếu những luật này tiếp tục được thúc đẩy, cần phải có một cách để xác minh danh tính trưởng thành mà không cần gửi ảnh ID hoặc cung cấp thông tin chi tiết cá nhân cho bên thứ ba.
- Có thể thực hiện xác thực danh tính như Apple Pay, thông qua công nghệ sinh trắc học để xác minh trên điện thoại, sau đó gửi tín hiệu đến trình duyệt.
- Mọi người nên có thể thiết lập trình duyệt/máy tính để tự động gửi thông tin này, đặc biệt là trên các thiết bị một người dùng.
- Khi trang web yêu cầu dữ liệu, trang web nên bao gồm các quy tắc truy cập của họ, chẳng hạn như phải đủ 18 tuổi hoặc phải ở một quốc gia cụ thể, v.v., sau đó thiết bị kiểm tra xem ID có tuân thủ các quy tắc hay không và chỉ trả về kết quả kiểm tra.
- Chứng minh không tiết lộ kiến thức là giải pháp, trang web gửi chức năng xác minh đến thiết bị của người dùng, thiết bị của người dùng trả về một bằng chứng cho thấy nó biết một đầu vào, đầu vào đó được chức năng xác minh chấp nhận.
- Có thể sử dụng thông tin xác thực dựa trên thuộc tính, thông tin xác thực cụ thể của người thách thức chỉ chứa các thuộc tính được yêu cầu.
- Dự án Yivy (trước đây là IRMA) cần được tái định vị thương hiệu, tiêu chuẩn hóa và cần cơ sở hạ tầng cấp doanh nghiệp để quảng bá và hỗ trợ các nhà cung cấp dịch vụ thay thế.
- Apple nhạy cảm với các vấn đề về quyền riêng tư, mục đích của đặc tả ISO là cho phép yêu cầu dữ liệu chi tiết, chẳng hạn như chỉ năm sinh, tiêu chuẩn W3C chỉ rõ rằng quyền riêng tư là một vấn đề phức tạp và có thể cần quy định.
- Quy định có thể là vấn đề, nếu không có quy định, không ai bị buộc phải tiết lộ thông tin cá nhân cho mọi ứng dụng và trang web đáng ngờ.
- Công nghệ có tiềm năng lớn để tăng cường quyền riêng tư, nhưng hành vi lạm dụng công nghệ một cách có hệ thống sẽ thúc đẩy việc áp dụng.
- Xác minh tuổi tác từ ngớ ngẩn đến rùng mình, không thể đẩy những vấn đề này cho các câu đố đơn giản.
- Yêu cầu ai đó có ID chính phủ không phải là 100% hiệu quả, vì mọi người có thể mượn ID của người khác hoặc sử dụng thiết bị đã đăng nhập cho người khác.
- Nếu chúng ta thừa nhận rằng giải pháp không phải là 100% hiệu quả, tại sao chúng ta không thể thừa nhận những giải pháp không phải là 100% hiệu quả nhưng bảo vệ quyền riêng tư tốt hơn?
Đọc Neuromancer lần đầu tiên vào năm 2025 #
Reading Neuromancer for the first time in 2025
https://mbh4h.substack.com/p/neuromancer-2025-review-william-gibson
Bài viết này được James Bareham chấp bút, thảo luận về trải nghiệm lần đầu đọc cuốn tiểu thuyết khoa học viễn tưởng kinh điển Neuromancer của William Gibson vào năm 2025. Tác giả thẳng thắn thừa nhận rằng anh chưa từng nghe nói về Neuromancer trước khi gia nhập The Verge vào năm 2016. Mặc dù anh đã quen thuộc với nhiều chủ đề khoa học viễn tưởng hiện đại (như cyberpunk, cyberspace, tin tặc máy tính, gián điệp doanh nghiệp, thực tế ảo trên mạng và trí tuệ nhân tạo), nhưng anh không biết rằng nhiều chủ đề trong số đó lần đầu tiên xuất hiện hoặc trở nên nổi bật trong cuốn sách của Gibson.
Lý do tác giả chọn đọc Neuromancer chủ yếu có hai: một là để bắt đầu một năm mới, cố gắng tránh sự xao nhãng từ mạng xã hội; hai là muốn đọc thêm những cuốn sách khoa học viễn tưởng bìa cứng. Kế hoạch của anh trong lĩnh vực này bao gồm đọc A Scanner Darkly và Do Androids Dream of Electric Sheep? của Philip K. Dick, cũng như Foundation Trilogy của Asimov. Tuy nhiên, lựa chọn hàng đầu của anh vẫn là Neuromancer, và anh đã đọc xong cuốn sách trong vòng một tuần.
Neuromancer được coi là một tác phẩm kinh điển của cyberpunk, mô tả một thế giới tương lai đen tối do công nghệ thúc đẩy. Mặc dù cuốn sách khá ngắn, nhưng trải nghiệm đọc không hề dễ dàng. Gibson đã tạo ra rất nhiều thuật ngữ kỹ thuật, đặc biệt là khi mô tả cyberspace, ngôn ngữ có vẻ rất khó hiểu. Tác giả nhận thấy mình thường xuyên phải đọc đi đọc lại mới có thể hiểu nội dung.
Bài viết đề cập rằng phong cách viết của Gibson đôi khi gây cảm giác trừu tượng, đặc biệt là so với văn bản “Lorem Gibson” mà anh đã sử dụng trước đây. Mặc dù vậy, sau khi đọc kỹ, ý nghĩa của nhiều đoạn trừu tượng dần trở nên rõ ràng. Tác giả chỉ ra rằng một trong những thách thức khi đọc Neuromancer là lượng lớn nội dung trong sách đã được nhiều bộ phim, chương trình truyền hình, anime và trò chơi điện tử khoa học viễn tưởng sau này hấp thụ, lấy mẫu và phối lại, khiến nhiều cảnh và khái niệm trở nên quá quen thuộc trong thời hiện đại.
Tác giả cũng đề cập rằng mặc dù Neuromancer là một tác phẩm năm 1984, nhưng nhiều dự đoán công nghệ của nó vẫn còn khá tiên tiến cho đến ngày nay, chẳng hạn như miêu tả về trí tuệ nhân tạo và thực tế ảo. Tuy nhiên, cuốn sách không đề cập đến các công nghệ hiện đại như điện thoại di động, mà thay vào đó lại giữ lại một số yếu tố lỗi thời, chẳng hạn như việc hút thuốc trong quán bar và sự phổ biến của các phương tiện in ấn.
Ngoài ra, các công nghệ mà Gibson đề cập trong cuốn sách chủ yếu là các thương hiệu Nhật Bản và Đức, phản ánh quan điểm về công nghệ tương lai vào năm 1984, đặc biệt là sự thống trị của Nhật Bản trong lĩnh vực điện tử tiêu dùng. Tác giả trích dẫn quan điểm của một nhà tương lai học rằng mọi người thường đánh giá quá cao sự phát triển của công nghệ sau 50 năm, nhưng lại đánh giá thấp những thay đổi trong hai năm tới.
Nói chung, Neuromancer không chỉ là một cuốn tiểu thuyết khoa học viễn tưởng quan trọng, mà còn là bản thiết kế cho toàn bộ thể loại cyberpunk. Ngay cả khi chưa đọc cuốn sách này, nhiều người vẫn có thể cảm nhận được ảnh hưởng của nó trong các bộ phim và tác phẩm khoa học viễn tưởng hiện đại. Mặc dù thời đại thay đổi, nhưng những suy nghĩ của Gibson về bản chất con người vẫn mang ý nghĩa thực tế, điều này khiến cho việc đọc Neuromancer ngày nay vẫn mang tính khai sáng và giá trị.
HN | Độ nóng: 363 điểm | 320 bình luận | Tác giả: keiferski #
https://news.ycombinator.com/item?id=44548353
- Neuromancer có ảnh hưởng sâu sắc đến tác giả, trở thành cuốn sách phải đọc hàng năm của anh ấy, ngay cả khi có thể đọc thuộc lòng cũng không mất đi sự hấp dẫn.
- Tác giả kết hôn và có con với cô gái tặng sách, mặc dù cuối cùng ly hôn nhưng vẫn giữ mối quan hệ bạn bè.
- Neuromancer, giống như các tác phẩm khoa học viễn tưởng khác, có một thế giới nền phong phú, đáng để đọc đi đọc lại.
- Tác giả cho rằng so với bản gốc, các phiên bản dịch đôi khi có thể mang lại trải nghiệm đọc khác biệt.
- Trong văn hóa Nga, một số tác phẩm dịch được coi là vượt trội hơn bản gốc.
- Các tác phẩm Shakespeare do nhà thơ Alterman người Israel dịch không được coi là kiệt tác ở Israel.
- “Chúa tể những chiếc nhẫn” có hai phiên bản dịch ở Israel, phiên bản cũ được coi là đẹp hơn, phiên bản mới thì mang tính học thuật hơn.
- Tác động cảm xúc của các tác phẩm dịch mạnh mẽ hơn trong tiếng mẹ đẻ.
- Một số tác phẩm dịch có sức hấp dẫn độc đáo nhờ tài năng của người dịch.
- Trong thời kỳ Liên Xô, nhiều nhà văn tài năng không thể viết do kiểm duyệt, đã chuyển sang làm dịch giả.
- Một số tác phẩm dịch được coi là những nỗ lực táo bạo nhờ sự nỗ lực của người dịch.
- Tác giả không thích các tác phẩm dịch, thích đọc bản gốc hơn.
- Người dịch không hài lòng với bản dịch tiếng Hy Lạp Neuromancer của mình.
- Tác giả sử dụng GPT để dịch các câu chuyện tiếng Hy Lạp sang tiếng Anh.
- Một số độc giả tiếp cận và đọc sách tiếng Anh thông qua BBS và file TXT.
- Tác giả quan tâm đến tiếng Anh nhờ đọc Neuromancer và dự định sẽ đọc lại.
Async I/O Mới của Zig #
Zig’s New Async I/O
https://kristoff.it/blog/zig-new-async-io/
Loris Cro đã đăng một bài viết trên trang web cá nhân của mình về các tính năng mới của asynchronous I/O trong ngôn ngữ lập trình Zig. Bài viết được đăng vào ngày 13 tháng 7 năm 2025, với thời gian đọc ước tính khoảng 13 phút.
Bài viết trước tiên chỉ ra rằng “tính không đồng bộ không phải là tính đồng thời”. Trong buổi phát trực tiếp về lộ trình Zig 2026, Andrew đã công bố một phương pháp xử lý I/O mới. Bài viết tiếp theo giới thiệu giao diện I/O được thiết kế mới này, đây là một trong những thay đổi đáng chú ý nhất trong ngôn ngữ Zig. Giao diện I/O mới được cung cấp bởi người gọi, tương tự như bộ cấp phát bộ nhớ (Allocator) đã được sử dụng trước đây. Bài viết trình bày sự khác biệt giữa các thao tác I/O trong ngôn ngữ Zig cũ và mới thông qua các ví dụ mã.
Bài viết nhấn mạnh rằng tác động chính của sự thay đổi này là tác giả của chương trình giờ đây có thể quyết định việc triển khai I/O cụ thể và có thể đưa việc triển khai này vào mã phụ thuộc. Giao diện Io không chỉ chịu trách nhiệm cho các thao tác I/O mà còn chịu trách nhiệm cho các thao tác đồng thời, vì các thao tác đồng thời có thể xen kẽ với các thao tác I/O, đặc biệt là trong trường hợp vòng lặp sự kiện. Nếu mã thể hiện chính xác tính đồng thời của các thao tác, thì việc triển khai Io có cơ hội giới thiệu tính song song.
Bài viết trình bày một ví dụ mã về cách sử dụng giao diện Io để thực hiện ghi đồng thời vào hai tệp khác nhau. Ví dụ này cho thấy cách đạt được tính đồng thời thông qua giao diện Io, ngay cả trong trường hợp I/O chặn, mã vẫn hoạt động chính xác vì io.async
sẽ gọi ngay lập tức hàm saveFile
và Future.await
sẽ trở thành một thao tác trống.
Bài viết cũng đề cập rằng khi xử lý các thao tác không đồng bộ, cần sử dụng await
và try
riêng biệt, thay vì thực hiện một lần, vì nếu try a_future.await(io)
thất bại, chúng ta sẽ không thể đợi b_future
. Bài viết giải thích rằng tài nguyên Future cần được giải phóng, do đó việc không đợi một Future là một lỗi lập trình.
Bài viết tiếp tục thảo luận về cách cải thiện mã bằng cách giới thiệu hỗ trợ hủy bỏ. Bằng cách sử dụng Future.cancel()
và Future.await()
, chúng ta có thể triển khai chức năng hủy bỏ mà không cần giới thiệu thêm sự phức tạp và có thể sử dụng try
một cách trực quan.
Cuối cùng, bài viết giới thiệu một số triển khai I/O do thư viện chuẩn Zig cung cấp, bao gồm triển khai các thao tác I/O chặn cơ bản và triển khai bao gồm vòng lặp sự kiện, chẳng hạn như thread pool và green thread. Bài viết cũng đề cập đến việc triển khai coroutine không stack, điều này sẽ phụ thuộc vào các quy ước gọi hàm đặc biệt và việc viết lại phần thân hàm thành một state machine không yêu cầu stack rõ ràng.
Mục tiêu thiết kế của bài viết là làm cho mã có thể tái sử dụng, đây là một trong những mục tiêu chính của ngôn ngữ Zig. Bài viết chỉ ra rằng khả năng tái sử dụng mã luôn là một vấn đề khó khăn khi nói đến asynchronous I/O. Bài viết trích dẫn một bài đăng trên blog nổi tiếng “Hàm của bạn có màu gì?” để thảo luận thêm về chủ đề này.
HN | Độ nóng: 347 điểm | 251 bình luận | Tác giả: afirium #
https://news.ycombinator.com/item?id=44545949
- Async I/O mới của Zig không hoàn toàn giải quyết vấn đề tô màu hàm, nó chỉ phân biệt các hàm IO và không IO.
- Cách gọi hàm phụ thuộc vào “màu” của nó, mặc dù trông giống như một lệnh gọi hàm thông thường, nhưng thực tế cần cung cấp tham số IO.
- Chỉ các hàm IO mới có thể gọi từ các hàm IO khác, điều này tương tự như quy tắc hàm “đỏ” trước đây.
- Quan điểm cho rằng các hàm IO khó gọi hơn vẫn đúng.
- Một số hàm thư viện lõi có “màu đỏ”, điều này không liên quan đến Zig, Rust cũng gặp phải vấn đề tương tự.
- Cách triển khai của Zig không thực sự giải quyết được vấn đề hàm cần ngữ cảnh (như trình thực thi không đồng bộ, thông tin xác thực, v.v.).
- Cách triển khai async I/O của Zig thực hiện tốt việc trừu tượng hóa việc sử dụng và triển khai, điều mà Rust đã thất bại.
Io
không dành riêng cho async, mà cần thiết bất cứ khi nào cần thực hiện các thao tác IO (như đọc và ghi tệp, tạm dừng, v.v.).- Trong thực tế, hầu hết các codebase đều có thể truy cập
Io
, chỉ các hàm lá thực hiện tính toán thuần túy mới không cần đến nó. - Nếu một hàm bắt đầu cần thực hiện IO, thì thường không cần phải truyền nó như một tham số, mà có thể dễ dàng lấy được thông qua kiểu trạng thái ứng dụng.
- Mặc dù về mặt lý thuyết, việc tô màu hàm vẫn tồn tại, nhưng trên thực tế, vấn đề này được giải quyết bằng cách cung cấp quyền truy cập
Io
cho hầu hết các hàm. - Việc truyền
Allocator
vàIo
cùng nhau không gây ra sự khó chịu khi tô màu hàm, vì chúng thường có thể dễ dàng truy cập được. - Việc dựa vào trình biên dịch/thư viện chuẩn để âm thầm chuyển đổi các triển khai không đồng bộ có thể dẫn đến các vấn đề về luồng điều khiển ẩn.
- Phương pháp này chỉ giải quyết vấn đề tô màu “hiển thị” của các hàm đồng bộ và không đồng bộ, nhưng không xử lý vấn đề các hàm chặn và không chặn.
- Thiết kế của
Io
giới hạn tập hợp các thao tác không đồng bộ, chỉ hỗ trợ các thao tác trong vtableIo
, điều này có thể buộc nó phải bao gồm các thao tác không hoàn toàn là I/O, chẳng hạn như mutex. - Bộ cấp phát có thể nhường quyền điều hành hệ điều hành khi yêu cầu hoặc giải phóng bộ nhớ, nhưng điều này không thuộc phạm trù “yield” có thể khiến chương trình chuyển đổi giữa các luồng khác nhau.
Kimi K2 là một mô hình ngôn ngữ mixture-of-experts (MoE) hiện đại. #
Kimi K2 is a state-of-the-art mixture-of-experts (MoE) language model
https://github.com/MoonshotAI/Kimi-K2
Trang web này giới thiệu về dòng mô hình ngôn ngữ lớn Kimi K2 do nhóm Moonshot AI phát triển.

- Giới thiệu mô hình Kimi K2 là một mô hình ngôn ngữ hỗn hợp chuyên gia (MoE) tiên tiến, sở hữu 32 tỷ tham số kích hoạt và 1 nghìn tỷ tổng tham số. Mô hình này được huấn luyện bằng trình tối ưu hóa Muon, thể hiện xuất sắc trong các nhiệm vụ tri thức, suy luận và mã hóa tiên tiến, đồng thời được tối ưu hóa cẩn thận cho khả năng agent.
- Đặc điểm mô hình Huấn luyện quy mô lớn: Mô hình MoE 1T tham số được huấn luyện trước trên 15.5T token, không có hiện tượng không ổn định trong quá trình huấn luyện.Trình tối ưu hóa MuonClip: Áp dụng trình tối ưu hóa Muon trên quy mô chưa từng có và phát triển các kỹ thuật tối ưu hóa mới để giải quyết sự không ổn định trong quá trình mở rộng.Trí tuệ Agent: Được thiết kế đặc biệt để sử dụng công cụ, suy luận và giải quyết vấn đề tự chủ.
- Các biến thể mô hìnhKimi-K2-Base: Mô hình cơ bản, phù hợp cho các nhà nghiên cứu và nhà xây dựng muốn kiểm soát hoàn toàn các giải pháp tinh chỉnh và tùy chỉnh.Kimi-K2-Instruct: Mô hình hậu huấn luyện phù hợp nhất cho trải nghiệm trò chuyện và agent đa năng, cắm và chạy. Đây là một mô hình cấp độ phản xạ, không có suy nghĩ dài dòng.
- Tóm tắt mô hìnhKiến trúc: Hỗn hợp chuyên gia (MoE)Tổng số tham số: 1TTham số kích hoạt: 32BLớp (bao gồm lớp dày đặc): 61Số lớp dày đặc: 1Kích thước ẩn của Attention: 7168Kích thước ẩn của MoE (mỗi chuyên gia): 2048Số lượng đầu Attention: 64Số lượng chuyên gia: 384Số lượng chuyên gia được chọn cho mỗi token: 8Số lượng chuyên gia dùng chung: 1Từ vựng: 160KĐộ dài ngữ cảnh: 128KCơ chế Attention: MLAHàm kích hoạt: SwiGLU
- Kết quả đánh giáKết quả đánh giá mô hình hướng dẫn cho thấy hiệu suất của Kimi K2 trong nhiều điểm chuẩn, bao gồm các nhiệm vụ mã hóa, nhiệm vụ sử dụng công cụ và nhiệm vụ STEM toán học, cũng như các nhiệm vụ chung. Kimi K2 đã đạt được kết quả tốt nhất trên toàn cầu (SOTA) trong một số điểm chuẩn.Kết quả đánh giá mô hình cơ bản cho thấy hiệu suất của Kimi K2 Base trong nhiều điểm chuẩn, bao gồm các nhiệm vụ chung.
Trang web cũng đề cập đến một số chi tiết về kết quả đánh giá, ví dụ: Kimi K2 đạt 65,8% pass@1 trong thử nghiệm SWE-bench Verified và đạt 47,3% pass@1 trong thử nghiệm đa ngôn ngữ. Ngoài ra, một số điểm dữ liệu kết quả đánh giá đã bị bỏ qua vì chi phí đánh giá quá cao.
HN | Độ nóng: 347 điểm | 2 bình luận | Tác giả: ConteMascetti71 #
https://news.ycombinator.com/item?id=44543508
- Kimi K2 hoạt động tốt khi xử lý các vấn đề lập trình, nhưng cần hỗ trợ phần cứng đắt tiền, phù hợp để triển khai hơn là sử dụng cục bộ.
- Sử dụng lượng tử hóa 4bit có thể đạt được tốc độ hợp lý trên một số thiết bị hiệu năng cao, nhưng vẫn cần nhiều tài nguyên.
- Hiện tại có thể chạy Kimi K2 thông qua các nhà cung cấp dịch vụ đám mây, và chi phí thấp hơn so với các đối thủ cạnh tranh, chẳng hạn như Claude 4 Sonnet.
- Có người dùng cho rằng tốc độ phản hồi của Claude 4 Sonnet quá chậm, sẵn sàng trả phí cao hơn để có được suy luận đám mây nhanh hơn.
- Một số mô hình có thể hoạt động không tốt trong các tác vụ đơn giản, trong khi Kimi K2 tạo ra mã ngắn gọn và dễ đọc hơn so với Claude.
- Đối với quy trình làm việc tương tác phức tạp, tốc độ phản hồi thấp có thể không đáp ứng được nhu cầu.
- Kimi K2 thể hiện một cá tính phi robot, với giọng điệu trực tiếp và chính xác hơn.
- Có quan điểm cho rằng, mặc dù mô hình lớn có chi phí vận hành cao đối với người dùng gia đình, nhưng vẫn hấp dẫn đối với người dùng doanh nghiệp và người dùng có nhu cầu về quyền riêng tư.
- Chi phí và tài nguyên phần cứng cần thiết cho việc chưng cất mô hình vẫn chưa rõ ràng.
- Đối với việc so sánh Kimi K2 với các mô hình khác, người dùng kỳ vọng vào hiệu suất của nó về khả năng suy luận và xử lý các tác vụ phức tạp.
Màn hình hoạt động như thế nào? #
How does a screen work?
https://www.makingsoftware.com/chapters/how-a-screen-works
Tiêu đề trang web: Màn hình hoạt động như thế nào?
Tóm tắt:
Màn hình kỹ thuật số luôn là người hùng thầm lặng trong lĩnh vực máy tính. Từ súng điện tử đến các bóng bán dẫn siêu nhỏ, công nghệ màn hình đã trải qua một chặng đường phát triển dài. Bài viết này sẽ khám phá nguyên lý hoạt động của màn hình, bao gồm các khía cạnh sau:
Nguyên lý hoạt động của màn hình: Từ súng điện tử đến các bóng bán dẫn siêu nhỏ, công nghệ màn hình đã trải qua một chặng đường phát triển dài. Màn hình hiển thị hình ảnh bằng cách điều khiển độ sáng và màu sắc của các điểm ảnh.
Công nghệ màn hình cảm ứng: Công nghệ màn hình cảm ứng cho phép người dùng tương tác trực tiếp với nội dung trên màn hình. Bài viết này sẽ giới thiệu nguyên lý hoạt động và các loại công nghệ màn hình cảm ứng khác nhau.
Hình ảnh là gì? Hình ảnh là thông tin trực quan được tạo thành từ các điểm ảnh. Bài viết này sẽ khám phá các khái niệm cơ bản và cấu trúc của hình ảnh.
Không gian màu, mô hình màu và gam màu: Không gian màu là một cách để mô tả màu sắc, các mô hình màu và gam màu khác nhau quyết định cách biểu diễn và hiển thị màu sắc. Bài viết này sẽ giải thích các khái niệm này và tầm quan trọng của chúng.
Tại sao việc tính toán độ tương phản màu sắc lại khó khăn đến vậy? Việc tính toán độ tương phản màu sắc liên quan đến nhiều yếu tố, bài viết này sẽ khám phá những yếu tố đó và lý do tại sao việc tính toán độ tương phản màu sắc là một vấn đề phức tạp.
Chuyển màu và tính đồng nhất về nhận thức: Chuyển màu và tính đồng nhất về nhận thức là những khái niệm quan trọng trong xử lý ảnh. Bài viết này sẽ thảo luận về vai trò của chúng trong thiết kế và hiển thị hình ảnh.
Toán học đằng sau các chế độ hòa trộn: Các chế độ hòa trộn hình ảnh liên quan đến các phép tính toán học phức tạp. Bài viết này sẽ tiết lộ các nguyên tắc toán học đằng sau những phép tính này.
Phông chữ và đồ họa vector: Phông chữ và đồ họa vector là những yếu tố cơ bản trong thiết kế kỹ thuật số. Bài viết này sẽ giới thiệu nguyên lý hoạt động và đặc điểm của chúng.
Vẽ đường cong: Đường cong đóng một vai trò quan trọng trong thiết kế đồ họa. Bài viết này sẽ khám phá cách vẽ đường cong và các kỹ thuật liên quan.
Raster hóa và khử răng cưa: Raster hóa là quá trình chuyển đổi đồ họa vector thành đồ họa pixel. Bài viết này sẽ thảo luận về các kỹ thuật raster hóa và khử răng cưa.
Khung nhìn SVG: SVG là một định dạng đồ họa vector dựa trên XML. Bài viết này sẽ giới thiệu khái niệm và ứng dụng của khung nhìn SVG.
Đường dẫn và bộ lọc SVG: Đường dẫn và bộ lọc SVG là những yếu tố quan trọng trong đồ họa SVG. Bài viết này sẽ khám phá các chức năng và cách sử dụng của chúng.
Thực hiện các phép toán với hình dạng: Hình dạng có thể được sử dụng cho các phép toán, bài viết này sẽ giới thiệu cách sử dụng hình dạng để thực hiện các phép tính toán học.
3D và Shader: Đồ họa 3D và shader là những công nghệ quan trọng trong xử lý đồ họa hiện đại. Bài viết này sẽ khám phá nguyên lý hoạt động của GPU và các khái niệm cơ bản về shader.
Shader là gì? Shader là một chương trình được sử dụng để kết xuất đồ họa 3D. Bài viết này sẽ giải thích nguyên lý hoạt động và tầm quan trọng của shader.
Trường khoảng cách có dấu (Signed Distance Field): Trường khoảng cách có dấu là một kỹ thuật được sử dụng cho đồ họa 3D. Bài viết này sẽ giới thiệu kỹ thuật này và các ứng dụng của nó.
Làm mờ, nhiễu và các hiệu ứng khác: Các hiệu ứng như làm mờ, nhiễu đóng một vai trò quan trọng trong xử lý ảnh. Bài viết này sẽ khám phá các phương pháp thực hiện các hiệu ứng này.
Chế độ xem phối cảnh, dò tia và dò tia từng bước: Chế độ xem phối cảnh, dò tia và dò tia từng bước là những kỹ thuật quan trọng trong kết xuất đồ họa 3D. Bài viết này sẽ thảo luận về nguyên lý hoạt động của chúng.
Phép chiếu 3D: Phép chiếu 3D là quá trình chuyển đổi đồ họa 3D thành hình ảnh 2D. Bài viết này sẽ giới thiệu các khái niệm và phương pháp cơ bản của phép chiếu 3D.
Trí tuệ nhân tạo và học máy: Trí tuệ nhân tạo và học máy là những thành phần quan trọng của công nghệ hiện đại. Bài viết này sẽ khám phá mối quan hệ giữa học máy và mạng nơ-ron, cũng như nguyên lý hoạt động của các mô hình ngôn ngữ lớn.
Tạo ảnh: Công nghệ AI có thể được sử dụng để tạo ảnh. Bài viết này sẽ giới thiệu cách AI tạo ảnh và các công nghệ đằng sau nó.
Cơ sở hạ tầng AI: Cơ sở hạ tầng AI là nền tảng hỗ trợ hoạt động của công nghệ AI. Bài viết này sẽ khám phá cấu trúc và nguyên lý hoạt động của cơ sở hạ tầng AI.
Nén và dữ liệu: Nén dữ liệu là một kỹ thuật quan trọng trong xử lý thông tin. Bài viết này sẽ giới thiệu các khái niệm về byte, nhị phân, thập lục phân và thập phân, cũng như sự khác biệt giữa entropy, nén không mất dữ liệu và nén mất dữ liệu.
Công nghệ mã hóa: Công nghệ mã hóa được sử dụng để bảo vệ an ninh dữ liệu. Bài viết này sẽ khám phá các nguyên tắc và ứng dụng của công nghệ mã hóa.
Nén ảnh: Nén ảnh là một kỹ thuật để giảm kích thước tệp ảnh. Bài viết này sẽ giới thiệu các phương pháp và tiêu chuẩn nén ảnh.
CRDTs: CRDTs là một công nghệ đồng bộ hóa dữ liệu. Bài viết này sẽ giải thích nguyên lý hoạt động và các tình huống ứng dụng của CRDTs.
Mạng và Web: Mạng và công nghệ Web là nền tảng của Internet hiện đại. Bài viết này sẽ khám phá nguyên lý hoạt động của trình duyệt, mối quan hệ giữa máy khách và máy chủ, quy trình truy vấn DNS và các giao thức mạng.
Tuần tự hóa và luồng: Tuần tự hóa và luồng là những kỹ thuật quan trọng trong truyền tải và xử lý dữ liệu. Bài viết này sẽ giới thiệu các khái niệm cơ bản và ứng dụng của các kỹ thuật này.
Bộ nhớ đệm (Cache): Bộ nhớ đệm là một kỹ thuật quan trọng để cải thiện hiệu suất mạng. Bài viết này sẽ khám phá nguyên lý hoạt động và vai trò của bộ nhớ đệm.
Trình biên dịch và trình thông dịch: Trình biên dịch và trình thông dịch là nền tảng của việc chạy mã. Bài viết này sẽ giới thiệu cách mã chạy, cũng như sự khác biệt giữa trình biên dịch và trình thông dịch.
Hiệu suất mã: Hiệu suất mã là một yếu tố quan trọng trong phát triển phần mềm. Bài viết này sẽ khám phá các yếu tố ảnh hưởng đến hiệu suất mã.
Các chủ đề khác: Bài viết này cũng sẽ đề cập đến các chủ đề kỹ thuật khác như biểu thức chính quy (Regular Expression), mã QR, máy quét dấu vân tay và điện toán lượng tử.
Tóm tắt trên bao gồm các nội dung chính được đề cập trong trang web, cung cấp một giới thiệu toàn diện về nguyên lý hoạt động của màn hình và các công nghệ liên quan.
HN | Độ nóng: 307 điểm | 64 bình luận | Tác giả: chkhd #
https://news.ycombinator.com/item?id=44550572
- Màn hình hiện đại không vẽ hình ảnh theo từng dòng mà bật sáng đồng thời từng pixel, làm mới toàn bộ màn hình.
- Có thể xác minh bằng thực nghiệm rằng màn hình thường được làm mới theo từng dòng thông qua quay chậm.
- Có người thấy rằng giải thích và sơ đồ trong bài viết rất rõ ràng và trực quan, gây ấn tượng sâu sắc.
- Có người hy vọng tác giả có thể viết tài liệu giảng dạy cho tất cả sách giáo khoa khoa học và toán học để giúp học sinh hiểu rõ hơn về kiến thức học thuật.
- Có người ca ngợi khả năng giao tiếp của tác giả, so sánh nó với công việc của Bartosz Ciechanowski.
- Màn hình CRT được coi là công nghệ thú vị hơn so với những người kế nhiệm kỹ thuật số vì công nghệ analog của chúng.
- Màn hình phẳng ma trận chủ động được coi là công nghệ rất thú vị khi chúng xuất hiện vào những năm 90.
- Điểm chết của màn hình LCD từng là một vấn đề lớn, nhưng bây giờ thì không còn nữa.
- Màn hình CRT vẫn có một sự kỳ diệu nhất định, hình ảnh thực sự không tồn tại, mà là một ảo ảnh.
- Video quay chậm có thể gây hiểu lầm vì thời gian phát sáng của chất lân quang dài hơn so với hiển thị trong video.
- Sự suy giảm của chất lân quang rất nhanh, do đó cần có màn hình LCD/OLED có tốc độ làm mới cao và độ sáng cao để xấp xỉ độ rõ nét chuyển động của CRT.
- Màn hình CRT vượt trội hơn màn hình hiện đại về độ rõ nét chuyển động vì chúng hiển thị vật thể chỉ trong một phần nhỏ của thời lượng khung hình, trong khi màn hình LCD/OLED hiển thị hình ảnh trong toàn bộ khung hình.
- Có người thích màn hình 240Hz 4K OLED HDR mới, cho rằng chúng đang tiến gần đến sự hoàn hảo, đặc biệt là tốc độ dữ liệu 4K HDR không nén được truyền qua DisplayPort thật đáng kinh ngạc.
Cư dân Arizona chết vì bệnh dịch hạch #
Arizona resident dies from the plague
https://www.independent.co.uk/news/health/arizona-plague-death-cases-b2787325.html
Cư dân bang Arizona, Hoa Kỳ chết vì bệnh dịch hạch, các triệu chứng xuất hiện chưa đầy 24 giờ sau khi qua đời. Một người ở Bắc Arizona đã chết vì bệnh dịch hạch trong bối cảnh chó đồng cỏ chết hàng loạt gần Flagstaff, người này đã được đưa đến bệnh viện với các triệu chứng nghiêm trọng và qua đời cùng ngày. Khám nghiệm tử thi cho thấy vi khuẩn gây ra bệnh dịch hạch - Yersinia pestis. Thông tin chi tiết hơn về bệnh nhân hoặc danh tính của họ vẫn chưa được tiết lộ. Trường hợp này xảy ra sau khi chó đồng cỏ chết hàng loạt ở phía đông bắc Flagstaff, đây là một dấu hiệu cảnh báo điển hình về hoạt động của bệnh dịch hạch, vì những loài gặm nhấm này thường mang bọ chét bị nhiễm bệnh. Các quan chức hạt Coconino đang điều tra số lượng chó đồng cỏ chết liên quan đến bệnh dịch hạch và họ đang hợp tác với một chủ sở hữu tài sản để thu thập bọ chét để xét nghiệm.

Bệnh dịch hạch vẫn còn hiếm ở Hoa Kỳ hiện đại, Trung tâm Kiểm soát và Phòng ngừa Dịch bệnh Hoa Kỳ báo cáo rằng trung bình có bảy trường hợp ở người mỗi năm, hầu hết xảy ra ở các vùng nông thôn của miền tây Hoa Kỳ, bao gồm miền bắc Arizona cũng như các khu vực của New Mexico và Colorado.
Bệnh dịch hạch có ba dạng: dịch hạch hạch, dịch hạch nhiễm trùng huyết và dịch hạch phổi, tùy thuộc vào việc nhiễm trùng ảnh hưởng đến các hạch bạch huyết, máu hay phổi. Hầu hết các trường hợp ở Hoa Kỳ là dịch hạch hạch, thường lây lan qua vết cắn của bọ chét từ động vật gặm nhấm bị nhiễm bệnh. Theo Cleveland Clinic, trên toàn cầu có khoảng 1000 đến 2000 ca bệnh dịch hạch mỗi năm, với khoảng bảy ca được báo cáo ở Hoa Kỳ. Các triệu chứng thường bắt đầu trong vòng một tuần sau khi nhiễm bệnh và có thể bao gồm sốt, ớn lạnh, sưng hạch bạch huyết, buồn nôn và suy nhược.
Nếu được điều trị kịp thời bằng thuốc kháng sinh (lý tưởng nhất là trong vòng 24 giờ sau khi các triệu chứng xuất hiện), tỷ lệ sống sót của bệnh dịch hạch hạch vượt quá 90%. Tuy nhiên, nếu không được điều trị, tỷ lệ tử vong có thể tăng lên đáng kể. Các quan chức y tế công cộng kêu gọi cư dân báo cáo chó đồng cỏ và các loài gặm nhấm khác bị bệnh hoặc chết, sử dụng các sản phẩm kiểm soát bọ chét để điều trị cho vật nuôi và tìm kiếm sự chăm sóc y tế ngay lập tức nếu họ phát triển các triệu chứng như sốt hoặc sưng hạch sau khi có thể tiếp xúc.
HN | Độ nóng: 249 điểm | 145 bình luận | Tác giả: Anon84 #
https://news.ycombinator.com/item?id=44543368
- Không có bản tin nào nói rằng bệnh nhân tử vong chưa đầy 24 giờ sau khi xuất hiện triệu chứng, mà đưa tin bệnh nhân tử vong vào ngày đến bệnh viện.
- Nếu không được điều trị, diễn biến bệnh điển hình là 36 giờ, vì vậy tử vong trong vòng 24 giờ là hoàn toàn bình thường.
- Khu vực này có một vài ca bệnh dịch hạch mỗi năm, thường không nghiêm trọng.
- Dịch hạch rất dễ lây lan qua chó đồng cỏ.
- Các quần thể chó đồng cỏ tự nhiên phân tách dựa trên việc chúng có mang bệnh dịch hạch hay không.
- Việc giám sát và phân tách bệnh dịch hạch do các bộ phận tài nguyên động vật hoang dã cấp tiểu bang đảm nhiệm.
- Việc tái du nhập chồn chân đen có thể giúp giảm bệnh dịch hạch, vì chúng săn chó đồng cỏ.
- Việc tái du nhập chồn chân đen có thể làm giảm số lượng và mật độ chó đồng cỏ, từ đó làm giảm sự lây lan của bệnh dịch hạch.
- Sự lây lan của bệnh dịch hạch thường thông qua bọ chét trên chó đồng cỏ, chứ không phải bản thân chó đồng cỏ.
- Mọi người có thể tiếp xúc với chó đồng cỏ do công việc hoặc sở thích, do đó phơi nhiễm với bệnh dịch hạch.
- Sự lây lan của bệnh dịch hạch thường liên quan đến việc tiếp xúc trực tiếp với chó đồng cỏ.
- Sự lây lan của bệnh dịch hạch thường liên quan đến việc quản lý chó đồng cỏ, chứ không phải công chúng nói chung.
- Mỗi năm có khoảng một người chết vì bệnh dịch hạch.
- Sự lây lan của bệnh dịch hạch có thể liên quan đến việc bọ chét lây từ chuột sang thú cưng.
- Sự lây lan của bệnh dịch hạch có thể liên quan đến chó đồng cỏ và các loài gặm nhấm khác.
- So với quá khứ, những tiến bộ của y học hiện đại giúp chúng ta có nhiều cơ hội sống sót hơn khi chống lại bệnh dịch hạch.
Vấn đề lao động IT giả mạo Triều Tiên lan rộng khắp nơi #
The North Korean fake IT worker problem is ubiquitous
https://www.theregister.com/2025/07/13/fake_it_worker_problem/
Bài viết này thảo luận về vấn đề công nhân IT giả mạo từ Bắc Triều Tiên, một hiện tượng phổ biến mà nhiều công ty có thể gặp phải trong quá trình tuyển dụng, đó là sơ yếu lý lịch giả hoặc người mạo danh. Charles Carmakal, CTO của Mandiant Consulting, cho biết tại một hội nghị bàn tròn về tình báo mối đe dọa rằng hầu hết tất cả các Giám đốc An ninh Thông tin (CISO) của các công ty thuộc Fortune 500 mà ông đã nói chuyện đều thừa nhận họ đang đối mặt với vấn đề công nhân IT Bắc Triều Tiên, ngay cả công ty mẹ của Mandiant là Google cũng không tránh khỏi. Iain Mulholland, Giám đốc cấp cao về Kỹ thuật An ninh Đám mây của Google, và Brad Jones, CISO của Snowflake, cũng xác nhận điều này.
Những trò lừa đảo này, chủ yếu đến từ Bắc Triều Tiên, hoặc ít nhất là chuyển tiền về Bình Nhưỡng, theo Bộ Tư pháp năm ngoái, đã gây ra thiệt hại ít nhất 88 triệu đô la cho các doanh nghiệp Mỹ trong sáu năm qua. Trong một số trường hợp, những kẻ lừa đảo này lợi dụng quyền truy cập nội bộ để đánh cắp mã nguồn độc quyền và các dữ liệu nhạy cảm khác, sau đó tống tiền nhà tuyển dụng bằng cách đe dọa làm rò rỉ dữ liệu công ty.
Khi các công ty Mỹ ngày càng cảnh giác với vấn đề công nhân IT giả mạo, những người tìm việc này ngày càng nhắm mục tiêu vào các nhà tuyển dụng châu Âu. Hầu hết tất cả các giám đốc điều hành đã nói chuyện với The Register trong những tháng gần đây đều cho biết họ đã thấy một lượng lớn những người nộp đơn như vậy cho các vị trí còn trống, hầu hết là các vị trí kỹ thuật và phát triển phần mềm, và tất cả đều là công việc từ xa. Trong một số trường hợp, những kẻ lừa đảo thậm chí còn sử dụng video deepfake để cố gắng có được việc làm, kể cả tại một công ty sử dụng AI để phát hiện các lỗ hổng trong mã. Dawid Moczadło, đồng sáng lập của Vidoc Security Lab, cho biết trong một cuộc phỏng vấn trước đó rằng nếu họ gần như lừa được ông, một chuyên gia an ninh mạng, thì chắc chắn họ cũng đã lừa được một số người khác.
Rivka Little, Giám đốc Tăng trưởng của Socure, cho biết Socure đã thấy một lượng lớn ứng viên giả mạo nộp đơn vào các vị trí đang mở trong vài tháng qua, điều này dường như là một lựa chọn đặc biệt trớ trêu, vì Socure cung cấp dịch vụ xác thực danh tính cho các công ty khác. Đối với một vị trí kỹ thuật cấp cao, Socure trước đây sẽ nhận được 150 đến 200 đơn đăng ký trong ba hoặc bốn tháng, nhưng gần đây con số này đã tăng vọt lên hơn 1999 người được gọi là tìm việc trong vòng hai tháng. Ít nhất một số ứng viên bổ sung có hồ sơ đáng ngờ kỳ lạ.
Nhóm tuyển dụng của Socure đã nhận thấy một số hiện tượng kỳ lạ khi thực hiện các cuộc họp video với một số ứng viên: những cái tên rất phương Tây, chẳng hạn như James Anderson, đi kèm với khuôn mặt Đông Á và tiếng Anh có giọng, với số lượng cao hơn nhiều so với dự kiến. Nhóm của Little cũng nhận thấy một số bất thường khác: địa chỉ email mới, số điện thoại không khớp với vị trí địa lý được khai báo, mọi thứ đều được định tuyến qua VPN và không thể xác minh được trình độ học vấn.
Little đã nhập các câu hỏi cho một số người tìm việc vào ChatGPT và lưu các câu trả lời của chatbot để tham khảo trong các cuộc phỏng vấn. Nếu câu trả lời của người tìm việc gần giống với câu trả lời của ChatGPT, thì họ sẽ biết có vấn đề, và điều đó đã thực sự xảy ra. Mặc dù vậy, Little thực sự thích ứng viên này, anh ta rất hòa đồng, là một người tốt, kể chuyện cười và không có điều gì khiến cô không muốn hợp tác với anh ta.
Little đã từng lãnh đạo một dự án chống gian lận tại một ngân hàng, và cũng lãnh đạo bộ phận nhân sự tại Socure, nhưng hiếm có người quản lý nhân sự hoặc tuyển dụng nào đồng thời được đào tạo về an ninh mạng và quản lý danh tính - công việc của họ là đánh giá tài năng, chứ không phải xác định các rủi ro bảo mật tiềm ẩn. James Robinson, CISO của Netskope, cho biết công ty bảo mật đám mây của ông cũng nhận được các đơn đăng ký của công nhân giả mạo. Ông cho rằng mọi CISO đều đang phải vật lộn: Đây có phải là vấn đề của CISO không? Hay là một vấn đề của tổ chức, thực sự là một vấn đề nhân sự sớm hơn? Và làm thế nào để hợp tác với nhân sự? Các nhân viên an ninh rất hiểu cách tiến hành điều tra, nhưng họ không nhất thiết phải biết những gì có thể và không thể hỏi trong một cuộc phỏng vấn.
HN | Độ nóng: 158 điểm | 166 bình luận | Tác giả: rntn #
https://news.ycombinator.com/item?id=44549762
- LinkedIn bị tấn công, dẫn đến hồ sơ cá nhân thật bị sửa đổi, có thể bị nhầm lẫn là công nhân IT giả mạo người Bắc Triều Tiên.
- Các công ty Mỹ xác minh danh tính nhân viên một cách nghiêm ngặt, các nhà tuyển dụng châu Âu ít có cơ hội làm việc từ xa hơn, vì vậy vấn đề công nhân IT giả mạo người Bắc Triều Tiên ít nghiêm trọng hơn.
- Các nhà tuyển dụng châu Âu thường yêu cầu phỏng vấn và thông thạo ngôn ngữ địa phương, điều này gây khó khăn cho công nhân IT giả mạo người Bắc Triều Tiên.
- Công nhân IT giả mạo người Bắc Triều Tiên sử dụng thiết bị KVM để giả dạng thành người làm việc từ xa ở các quốc gia khác.
- Thiết bị KVM vượt qua các kiểm tra bảo mật bằng cách mô phỏng màn hình và bàn phím vật lý.
- Yêu cầu nhân viên phải đến làm việc trực tiếp trong tuần đầu tiên có thể là một phương pháp để ngăn chặn công nhân IT giả mạo người Bắc Triều Tiên.
- Bắt buộc phải đến làm việc trực tiếp trong tuần đầu tiên sẽ hạn chế lựa chọn nhân tài của công ty.
- Để nhập cảnh vào hầu hết các quốc gia cần có visa, có thể mất vài tháng để xin và chờ đợi.
- Các công ty Đức thường giúp giải quyết các vấn đề về visa để nhân viên nước ngoài có thể bắt đầu làm việc càng sớm càng tốt.
- Tuyên bố đơn phương kết thúc Chiến tranh Triều Tiên không giải quyết được vấn đề, chính quyền Bắc Triều Tiên dựa vào tình trạng chiến tranh để duy trì.
- Bắc Triều Tiên sẽ không chấp nhận hòa bình và cũng sẽ không tuân thủ các hiệp định hòa bình.
- Công nhân IT giả mạo người Bắc Triều Tiên có thể bị lộ danh tính vì yêu cầu chỉ trích Kim Jong-un.
- Yêu cầu chỉ trích các nhân vật chính trị có thể khiến những người tìm việc thực sự cảm thấy khó chịu và không muốn hợp tác.
- Các vấn đề chính trị không nên là một phần của cuộc phỏng vấn xin việc, trừ khi được trả thù lao cao.
Hacking Coroutines vào C #
Hacking Coroutines into C
https://wiomoc.de/misc/posts/hacking_coroutines_into_c.html
Bài viết này kể về sự nghi ngờ và khám phá của tác giả đối với máy trạng thái trong phát triển phần mềm nhúng. Tác giả từng tham gia một nhóm phát triển phần mềm nhúng, phần mềm sử dụng rất nhiều máy trạng thái, các máy trạng thái này được phân bố trong nhiều hàm. Mặc dù kiến trúc này rất phổ biến trong phát triển nhúng không có hệ điều hành, nhưng tác giả bắt đầu suy nghĩ liệu có cách nào diễn đạt luồng điều khiển rõ ràng hơn không.
Tác giả đề cập rằng, mặc dù máy trạng thái hoạt động bình thường, nhưng việc hiểu và bảo trì chúng thường gây đau đầu. Chúng thiếu quy trình tuyến tính, cần xử lý các cờ, trạng thái và chuyển đổi trong nhiều hàm thăm dò (polling). Tác giả tự hỏi, nếu có thể viết logic giống như một chương trình tuần tự, chờ đợi sự kiện và tiếp tục thực thi tại điểm ngắt, liệu có đơn giản hơn không?
Vì dự án không cho phép sử dụng hệ điều hành thời gian thực (RTOS), nên các phương pháp truyền thống sử dụng luồng (thread) hoặc các lệnh gọi hệ thống chặn (blocking system call) để quản lý đồng thời không khả thi. Nhưng tác giả biết rằng phải có một giải pháp thỏa hiệp. Vào thời điểm đó, tác giả đã sử dụng coroutine trong các ngôn ngữ như Python, JavaScript, Dart và Rust, chúng cho phép tạm dừng và tiếp tục thực thi mà không cần dựa vào luồng, cung cấp một hình thức đa nhiệm hợp tác.
Tác giả nhận ra rằng, mô hình coroutine này có thể là giải pháp tốt nhất cho vấn đề của họ - cung cấp tính đồng thời mà không yêu cầu hệ điều hành. Trước khi đi sâu vào giải pháp dựa trên coroutine, tác giả xem xét lại một ví dụ nhỏ để minh họa vấn đề. Họ muốn triển khai một mạch nháy LED với chu kỳ có thể điều khiển bởi người dùng, chu kỳ ban đầu là 2 giây, và người dùng có thể thay đổi chu kỳ bất kỳ lúc nào bằng cách nhấn giữ nút. Khi nút được nhả ra, LED sẽ bắt đầu lại chu kỳ nháy với chu kỳ mới (tức là một nửa thời gian giữ nút).
Để mô phỏng hành vi này, có thể sử dụng hai máy trạng thái đơn giản. Máy trạng thái đầu tiên, led_blinker
, chứa hai trạng thái: LED_ON
và LED_OFF
. Hệ thống chuyển từ LED_ON
sang LED_OFF
sau độ trễ p/2
, và ngược lại. Nếu nhận được sự kiện resetLed
từ máy trạng thái thứ hai, led_blinker
sẽ chuyển ngay lập tức sang trạng thái LED_OFF
, bất kể trạng thái hiện tại của nó là gì. Máy trạng thái thứ hai, button_record
, cũng có hai trạng thái: WAIT_BUTTON_PRESSED
và WAIT_BUTTON_UNPRESSED
. Nó chờ người dùng nhấn nút ở trạng thái ban đầu, sau khi nút được nhấn, nó ghi lại thời gian hiện tại t_s
và chuyển sang trạng thái WAIT_BUTTON_UNPRESSED
. Ở trạng thái này, nó chờ người dùng nhả nút. Khi nút được nhả ra, nó ghi lại thời gian hiện tại t_e
, tính toán nửa chu kỳ mới là p/2 = t_e - t_s
, phát ra sự kiện resetLed
và quay trở lại trạng thái WAIT_BUTTON_PRESSED
.
Bài viết tiếp tục cung cấp mã triển khai dựa trên thăm dò (polling) cho Arduino, cũng như mã triển khai sử dụng FreeRTOS. Tác giả cho rằng, phương pháp sử dụng FreeRTOS dễ đọc và dễ hiểu hơn, đồng thời loại bỏ nhu cầu thiết kế máy trạng thái rời rạc từ trước - có thể diễn đạt logic trực tiếp dưới dạng mã tuần tự.
Cuối cùng, tác giả đề cập đến việc triển khai coroutine dựa trên macro của họ, cấu trúc triển khai tác vụ rất giống với phương pháp FreeRTOS. Bài viết kết thúc bằng một đoạn mã triển khai hàm button_recorder
.
HN | Độ nóng: 151 điểm | 39 bình luận | Tác giả: jmillikin #
https://news.ycombinator.com/item?id=44546640
- Protothreads là một cách triển khai coroutine (tiểu trình) gọn nhẹ, có thể được hiện thực trong ngôn ngữ C mà không cần phụ thuộc vào thư viện nào.
- Bằng cách sử dụng tiện ích mở rộng “labels as values” của GCC hoặc Clang, có thể tránh sử dụng câu lệnh switch và các so sánh liên quan, để hiện thực coroutine một cách ngắn gọn và nhanh chóng hơn.
- proto_activities cung cấp một cách ngắn gọn hơn để định nghĩa coroutine, tự động tạo cấu trúc để lưu trạng thái.
- Trong phần mềm nhúng, nếu chỉ có một instance (thể hiện) của coroutine, có thể sử dụng biến static bên trong hàm để hiện thực coroutine, như vậy code sẽ nhanh hơn một chút.
- State machine (máy trạng thái) là cần thiết trong một số trường hợp, nhưng chúng thường được viết một lần rồi không đọc lại (khó đọc và sửa đổi), vì vậy tốt nhất là giữ chúng đơn giản và số lượng ít.
- Vấn đề của state machine là chúng rất khó để mô-đun hóa, việc thêm hoặc chia nhỏ trạng thái tốn nhiều công sức hơn dự kiến.
- State machine và coroutine có thể giải quyết các vấn đề phi tuyến tính và đồng thời, nhưng đôi khi cố gắng quá mức để giải quyết cả hai vấn đề cùng một lúc bằng một giải pháp có thể gây ra vấn đề.
- Sử dụng bộ lập lịch hợp tác (cooperative scheduler) của FreeRTOS có thể là một giải pháp khi không có hệ điều hành.
- Trong trường hợp không có RTOS, dự án cuối cùng có thể hiện thực một giải pháp gần giống RTOS.
- Sử dụng PWM peripheral (hoặc nếu không có PWM peripheral, thì sử dụng ngắt timer) và ngắt thay đổi chân, CPU gần như 100% thời gian ở trạng thái dừng, có thể là một giải pháp đơn giản hơn.
- Không nên sử dụng ngắt để xử lý đầu vào nút bấm, vì hiện tượng rung công tắc (switch bounce) có thể khiến bộ xử lý bị “dội bom” bởi các ngắt vô ích. Giao diện người-máy (HMI) có thể được thăm dò (polling) đồng thời vẫn đảm bảo tính phản hồi.