2025-06-10 Top Stories

Top các câu chuyện trên HackerNews ngày 2025-06-10 #

  1. Điều khoản 174 của Luật Thuế Hoa Kỳ yêu cầu chi phí phát triển phần mềm phải được khấu hao trong 5 năm, dẫn đến tăng gánh nặng thuế cho doanh nghiệp và làm mờ ranh giới giữa phát triển và bảo trì.
  2. Số lượng người dùng của công cụ tìm kiếm Kagi đã vượt quá 50.000, thông qua mô hình thành viên không quảng cáo, xác minh tính khả thi của mô hình lợi nhuận sản phẩm ngách.
  3. Quy trình khôi phục tài khoản Google tồn tại lỗ hổng, có thể lợi dụng dải địa chỉ IPv6 để vượt qua giới hạn IP và bẻ khóa số điện thoại một cách thô bạo.
  4. Việc doanh nghiệp hợp tác với chính quyền chuyên chế để phát triển siêu máy tính có thể bị lạm dụng tính trung lập về công nghệ, cần cảnh giác với rủi ro chính trị.
  5. Nền tảng FSE bị FBI điều tra vì người dùng tải lên nội dung vi phạm, phơi bày những khó khăn trong quản trị pháp lý và kỹ thuật của nền tảng xã hội liên bang.
  6. Việc giải thích quá mức lời bài hát của Shawn Mendes bị chỉ trích là lố bịch và hài hước, phản ánh hiện tượng hiểu sai về ẩn dụ trong văn hóa đại chúng.
  7. Hệ thống Android không thể tự động nhận dạng CDC Ethernet do vấn đề logic đặt tên giao diện mạng, cần sửa đổi thủ công hoặc phụ thuộc vào phiên bản mới.
  8. Chi phí suy luận LLM đã thấp hơn API tìm kiếm truyền thống, nhưng ngành vẫn phải đối mặt với những thách thức thương mại hóa về mặt lặp lại công nghệ và đầu tư vốn.
  9. Backend x86 tự lưu trữ của ngôn ngữ Zig trở thành tùy chọn mặc định trong chế độ gỡ lỗi, hiệu quả biên dịch được cải thiện đáng kể nhưng bị hạn chế trên nền tảng Windows.
  10. Nhận thức sai lệch của người dùng về LLM dẫn đến sử dụng sai, cần tiết lộ bản chất tạo cú pháp và rủi ro tiềm ẩn của nó thông qua góc độ liên ngành.

Tell HN: Hãy giúp khôi phục khoản khấu trừ thuế cho phát triển phần mềm ở Hoa Kỳ (Điều 174) #

Tell HN: Help restore the tax deduction for software dev in the US (Section 174)

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

Bài viết này thảo luận về điều khoản 174 trong luật thuế của Hoa Kỳ, đặc biệt là tác động của nó đối với việc khấu trừ thuế của các nhà phát triển phần mềm. Dưới đây là bản tóm tắt chi tiết của bài viết:

1. Tổng quan về Điều khoản 174 #

  • Điều khoản 174 quy định rằng chi phí liên quan đến phát triển phần mềm không thể được khấu trừ trực tiếp như các chi phí doanh nghiệp khác, mà được coi là chi phí vốn và cần được khấu hao trong nhiều năm.
  • Ví dụ: nếu một công ty trả cho kỹ sư phần mềm mức lương 200.000 đô la Mỹ, thì về mặt thuế, họ chỉ có thể khấu trừ 40.000 đô la Mỹ trong năm đầu tiên và 40.000 đô la Mỹ mỗi năm trong bốn năm tiếp theo. Như vậy, chi phí thuê kỹ sư phần mềm thực tế trở nên nặng nề hơn về mặt thuế.

2. Định nghĩa mơ hồ về kỹ sư phần mềm #

  • Bài viết đề cập đến việc định nghĩa “kỹ sư phần mềm” không rõ ràng, có thể gây ra tranh cãi. Các vai trò khác nhau liên quan đến phát triển phần mềm, chẳng hạn như kỹ sư kiểm thử, kỹ sư FPGA, quản trị viên hệ thống, v.v., có nên được coi là kỹ sư phần mềm hay không, vẫn còn nhiều điều không chắc chắn.
  • Tài liệu hướng dẫn do IRS phát hành năm 2023 chỉ ra rằng phát triển phần mềm bao gồm các giai đoạn như lập kế hoạch, thiết kế, viết mã, kiểm thử, v.v., nhưng không bao gồm các hoạt động như bảo trì, đào tạo, v.v. Điều này làm cho việc xác định bản chất công việc của một số vai trò trở nên phức tạp.

3. Sự phức tạp của phát triển phần mềm hiện đại #

  • Cùng với sự phổ biến của các hoạt động phát triển và vận hành phần mềm (DevOps), ranh giới giữa phát triển và bảo trì phần mềm trở nên mờ nhạt, các nhà phát triển thường xuyên liên quan đến việc phát triển các chức năng mới và sửa lỗi trong công việc hàng ngày của họ.
  • Bài viết chỉ ra rằng nhiều công ty sẽ cố gắng coi càng nhiều công việc càng tốt là chi phí vốn để cải thiện hiệu quả tài chính, nhưng điều này có thể gây ra những ảnh hưởng bất lợi về mặt thuế.

4. Các thách thức về thuế và tuân thủ #

  • Trong việc phân loại các hoạt động phát triển và bảo trì, công ty thường cần hợp tác chặt chẽ với bộ phận tài chính để đảm bảo ghi chép chính xác và tuân thủ các yêu cầu của luật thuế.
  • Một trường hợp được đề cập trong bài viết là, khi các nhà phát triển viết mã, họ cần theo dõi các hoạt động này thuộc về chi phí vốn (Capital Expenditure) hay chi phí hoạt động (Operating Expenditure), để tránh gặp phải vấn đề trong quá trình kiểm toán thuế.

5. Bối cảnh chính trị và triển vọng tương lai #

  • Điều khoản 174 được thông qua dưới thời chính quyền Trump, nhằm mục đích bù đắp chi phí cho việc giảm thuế suất doanh nghiệp khác. Bài viết kết luận rằng, trong tương lai có thể có nhiều cuộc thảo luận và luật pháp hơn về cải cách thuế, đặc biệt là xung quanh cuộc bầu cử năm 2024.
  • Đối với những người ủng hộ cải cách thuế, động cơ của họ thường là mong muốn giảm gánh nặng thuế cho doanh nghiệp, tuy nhiên, có thể có sự không chắc chắn lớn về cách định nghĩa “kỹ sư phần mềm” và cách thực hiện các quy định này.

Tóm lại, bài viết đi sâu vào ảnh hưởng cụ thể của Điều khoản 174 đối với ngành phát triển phần mềm, cũng như những thách thức và sự không chắc chắn khác nhau phải đối mặt trong quá trình tuân thủ thuế. Những vấn đề này không chỉ ảnh hưởng đến quản lý tài chính của doanh nghiệp mà còn có thể gây ra các cuộc thảo luận trong bối cảnh chính trị và kinh tế rộng lớn hơn.

HN | Nóng: 1263 điểm | 493 bình luận | Tác giả: dang | 7 giờ trước #

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

  • Mục 174 yêu cầu chi phí phát triển phần mềm phải được khấu trừ dần trong thời hạn 5 năm, thay vì tính trực tiếp vào chi phí trong kỳ
  • Định nghĩa về kỹ sư phần mềm còn mơ hồ, gây tranh cãi về việc liệu các vị trí như kiểm thử/hệ thống/phát triển phần cứng có áp dụng điều khoản này hay không
  • IRS đã công bố tài liệu hướng dẫn vào năm 2023 để làm rõ phạm vi hoạt động phát triển phần mềm, nhưng chưa giải quyết được các tranh cãi cốt lõi
  • Chi phí bảo trì phần mềm và vận hành hàng ngày không được coi là chi phí phát triển, dẫn đến gánh nặng thuế thực tế của doanh nghiệp tăng lên
  • Cách xử lý hiện tại đi ngược lại logic kế toán truyền thống, tốc độ cập nhật và lặp lại của phần mềm nhanh hơn nhiều so với chu kỳ khấu hao tài sản cố định
  • Doanh nghiệp buộc phải ngụy trang chi phí bảo trì phần mềm hàng ngày thành chi phí vốn để làm đẹp báo cáo tài chính, bóp méo cấu trúc chi phí thực tế của ngành

Kagi Đạt Mốc 50 nghìn Người Dùng #

Kagi Reaches 50k Users

https://kagi.com/stats?stat=members

Trang web này hiển thị dữ liệu thống kê thời gian thực và mô tả chức năng của công cụ tìm kiếm Kagi, cấu trúc nội dung chính như sau:

  1. Dữ liệu quy mô người dùng
  • Tổng số thành viên đã đăng ký hiện tại: 50.074 người (tính đến ngày 9 tháng 6)
  • Số lượng người dùng gia đình: 5.450
  • Số lượng người dùng nhóm: 194
  • Số lượng truy vấn hàng ngày: 760.600 lần
  • Số lượng luồng trợ lý hàng ngày: 10.662
  • Thành viên trả phí Orion+: 2.047 người
  1. Xu hướng tăng trưởng thành viên
  • Ngày 26 tháng 5: 48.961 người
  • Ngày 27 tháng 5: 49.039 người
  • Ngày 28 tháng 5: 49.100 người
  • Ngày 29 tháng 5: 49.164 người
  • Ngày 30 tháng 5: 49.243 người
  • Ngày 31 tháng 5: 49.360 người
  • Ngày 1 tháng 6: 49.477 người
  • Ngày 2 tháng 6: 49.533 người
  • Ngày 3 tháng 6: 49.607 người
  • Ngày 4 tháng 6: 49.724 người
  • Ngày 5 tháng 6: 49.811 người
  • Ngày 6 tháng 6: 49.878 người
  • Ngày 7 tháng 6: 49.930 người
  • Ngày 8 tháng 6: 49.998 người
  • Ngày 9 tháng 6: 50.074 người
  1. So sánh dữ liệu thú vị
  • Số lượng thành viên hiện tại (50.074) đã vượt quá tổng dân số của 26 quốc gia và khu vực trên thế giới
  • Quốc gia/khu vực gần nhất là Quần đảo Faroe (dân số 54.714)
  1. Các module chức năng cốt lõi
  • Giá trị tìm kiếm trả phí: Bao gồm các giải thích về gói thành viên, điều khoản bảo mật, tiện ích mở rộng trình duyệt, v.v.
  • Phím tắt: Cung cấp hơn 40 lệnh thao tác (ví dụ: j/k điều hướng kết quả, !/tiêu điểm thanh tìm kiếm, s mở thông tin trang web, v.v.)
  • Toán tử tìm kiếm: Hỗ trợ cú pháp tìm kiếm nâng cao như filetype, site, inurl, intitle, v.v.
  • Lối tắt truy vấn: Bao gồm !bang (lệnh DuckDuckGo), !sum (công cụ tóm tắt), !k (Tìm kiếm Kagi), v.v. 10 lệnh tắt
  • Tiện ích thiết thực: Máy tính, truy vấn địa chỉ IP, hẹn giờ, công cụ dịch thuật, v.v.
  1. Thông tin phiên bản
  • Cung cấp nhật ký cập nhật (Changelog)
  • Bao gồm blog của công ty (Blog)
  • Trưng bày các sản phẩm thương hiệu (Swag)

Trang này, thông qua trực quan hóa dữ liệu và mô tả chức năng, thể hiện cơ sở người dùng, năng lực kỹ thuật và các dịch vụ đặc trưng của Kagi như một công cụ tìm kiếm “mạng lưới nhân văn”, đặc biệt nhấn mạnh tốc độ tăng trưởng thành viên và hệ thống chức năng tìm kiếm độc đáo của nó.

HN | Nóng: 496 điểm | 295 bình luận | Tác giả: tigroferoce | 19 giờ trước #

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

  • Kagi kiếm lợi nhuận bằng cách cung cấp dịch vụ tìm kiếm chất lượng cao không có quảng cáo, và vẫn hoạt động hiệu quả dù quy mô nhỏ
  • Chỉ trích tâm lý theo đuổi mô hình kỳ lân của các công ty khởi nghiệp, cho rằng nó bỏ qua giá trị sản phẩm và người dùng
  • Mô hình đầu tư của người dùng đáng được khẳng định, cho rằng phương thức tài trợ phi truyền thống này gần gũi hơn với ý định ban đầu của sản phẩm
  • Doanh nghiệp không cần mở rộng một cách mù quáng, tập trung vào thị trường ngách có thể duy trì khả năng cạnh tranh lâu dài
  • Phần mềm doanh nghiệp truyền thống (như Jira, Twilio) trải nghiệm trở nên tồi tệ do tùy biến quá mức
  • Việc sản phẩm trở thành nền tảng chắc chắn dẫn đến chức năng cồng kềnh, cần nhiều vốn và người dùng hơn để duy trì
  • Nhu cầu tùy biến của phần mềm cấp doanh nghiệp và trải nghiệm người dùng có mâu thuẫn cơ bản
  • Thành công thương mại thực sự không nằm ở quy mô mà nằm ở việc đáp ứng nhu cầu của người dùng cụ thể
  • Nghi ngờ sự cần thiết của việc các trình duyệt hiện đại (như Firefox) thêm chức năng AI
  • Sau khi duy trì lợi nhuận, có thể tập trung vào việc lặp lại sản phẩm thay vì mở rộng dựa trên vốn

Dò mật khẩu số điện thoại của bất kỳ người dùng Google nào #

Bruteforcing the phone number of any Google user

https://brutecat.com/articles/leaking-google-phones

Trang web này mô tả chi tiết quá trình tác giả khám phá phương pháp tấn công vét cạn số điện thoại của tài khoản Google, nội dung chính bao gồm:

  1. Bối cảnh phát hiện: Tác giả vô tình phát hiện ra rằng biểu mẫu khôi phục tên người dùng của Google vẫn hoạt động bình thường sau khi tắt JavaScript của trình duyệt. Điều này mâu thuẫn với nhận thức trước đây của tác giả rằng “chức năng khôi phục tài khoản sau năm 2018 phụ thuộc vào JavaScript để tạo mã thông báo BotGuard”, cho thấy Google có thể giữ lại cơ chế xác minh dự phòng không dùng JS.
  2. Phân tích điểm cuối: Quy trình tấn công vét cạn liên quan đến hai yêu cầu HTTP quan trọng: Yêu cầu đầu tiên: Gửi số điện thoại (ví dụ: +18085921029) và các tham số liên quan đến BotGuard (giá trị gxf) đến /signin/usernamerecovery, trả về chuyển hướng 302 chứa giá trị ess. Yêu cầu thứ hai: Gửi giá trị ess, tên hiển thị (ví dụ: “John Smith”) và tham số bgresponse=js_disabled đến /signin/usernamerecovery/lookup, thông qua trạng thái phản hồi 302 để xác định xem số có liên kết với tài khoản hay không.
  3. Tính khả thi của tấn công vét cạn: Ban đầu, các thử nghiệm bị thất bại do giới hạn tốc độ IP và xác minh captcha (ví dụ: chuyển hướng 302 đến trang captcha). Lấy Hà Lan làm ví dụ, định dạng số điện thoại là +316, theo sau là 6 chữ số + kết thúc bằng 03 (tổng cộng 10^6=1.000.000 tổ hợp), về mặt lý thuyết có thể vượt qua giới hạn bằng proxy. Giải pháp IPv6: Sử dụng mạng con /64 do Vultr cung cấp (18.446.744.073.709.551.616 địa chỉ IP) để luân phiên địa chỉ IP, thử nghiệm cho thấy máy chủ Google hỗ trợ IPv6 (xác minh thông qua curl -6). Ví dụ mã hiển thị cách tạo ngẫu nhiên địa chỉ IPv6 và tạo máy khách.
  4. Vượt qua mã thông báo BotGuard: Bằng cách phân tích các yêu cầu biểu mẫu JS, người ta thấy rằng tham số bgresponse=js_disabled có thể được thay thế bằng mã thông báo BotGuard (bgRequest) do JS tạo ra. Sau khi thay thế, công cụ tấn công vét cạn gpb đã thành công tìm thấy nhiều số (ví dụ: +31612345603, v.v.), nhưng cần xác minh thêm sự phù hợp của tên hiển thị. Cuối cùng, bằng cách chỉ định tên đầy đủ (ví dụ: “Henry Chancellor”), kết quả hợp lệ duy nhất được lọc ra.
  5. Các vấn đề và thách thức hiện tại: Suy luận mã quốc gia: Mã quốc gia có thể được suy ra ngược thông qua mặt nạ điện thoại do quy trình “quên mật khẩu” cung cấp (ví dụ: “• (•••) •••-••-••” tương ứng với Nga), tác giả đã thu thập định dạng mặt nạ của các quốc gia khác nhau vào mask.json. Thu thập tên hiển thị: Google đã hạn chế việc trả về tên hiển thị trong các tình huống không tương tác trực tiếp kể từ năm 2023, và vào tháng 4 năm 2024, dữ liệu tên hiển thị của người dùng chưa được xác thực đã bị xóa hoàn toàn khỏi dịch vụ FocusBackend, khiến việc lấy tên mục tiêu trở nên khó khăn hơn.
  6. Hiệu quả và hạn chế thực tế: Khi sử dụng 3000 luồng, công cụ có thể nhanh chóng tạo ra một số lượng lớn các số ứng viên (ví dụ: 3000 yêu cầu mỗi giây), nhưng số lượng trúng đích cuối cùng thường chỉ là 1, vì sự kết hợp của tên đầy đủ + số đuôi 03 + mã quốc gia là khá duy nhất. Địa chỉ IP của trung tâm dữ liệu vẫn có thể kích hoạt captcha, cần kết hợp mã thông báo BotGuard và luân phiên IPv6 để hoạt động ổn định.

HN | Nóng: 420 điểm | 135 bình luận | Tác giả: brutecat | 9 giờ trước #

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

  • Cơ chế phân bổ /64 của IPv6 dẫn đến việc giới hạn tốc độ IP đơn truyền thống không còn hiệu quả, cần nâng cấp lên các chính sách chặn lớn hơn
  • Các nhà cung cấp dịch vụ CDN lớn không xử lý đúng cách việc nhận dạng phạm vi /64 của IPv6, nhầm lẫn coi cùng một mạng là IP bất thường
  • Người dùng dân cư có thể nhận được khối địa chỉ cấp /56 hoặc /48 thông qua DHCPv6, làm phức tạp thêm việc chặn IP
  • Một số nhà cung cấp máy chủ giá rẻ (như BuyVM) mặc định phân bổ khối địa chỉ /48, tạo điều kiện cho các hành vi độc hại
  • Công nghệ CGNAT có thể làm cho cơ chế chặn IP không hiệu quả, người dùng có thể tránh bị phát hiện thông qua proxy mạng di động
  • Nên áp dụng giới hạn ngưỡng động dựa trên /64, kết hợp với thống kê hành vi lạm dụng để tối ưu hóa các chiến lược bảo vệ
  • Một số người dùng chọn không liên kết số điện thoại thật để tránh rủi ro rò rỉ quyền riêng tư
  • Các chính sách phân bổ địa chỉ IPv6 (chẳng hạn như phân chia các tiền tố khác nhau theo loại tài khoản) có thể hỗ trợ kiểm soát an ninh
  • Giao thức SLAAC phụ thuộc vào tiền tố /64, việc rút ngắn tiền tố có thể dẫn đến các vấn đề về khả năng tương thích của công cụ mạng
  • Các doanh nghiệp cần cập nhật các chính sách bảo mật để đối phó với các đặc tính quy mô địa chỉ của IPv6, tránh phụ thuộc quá nhiều vào việc chặn IP đơn

Xây dựng siêu máy tính cho những nhà độc tài có lẽ không tốt cho nền dân chủ #

Building supercomputers for autocrats probably isn’t good for democracy

https://helentoner.substack.com/p/supercomputers-for-autocrats

Trang web này là một bài đăng trên blog Substack do Helen Tonner viết, có tiêu đề là “Tại sao chúng ta không thể có những điều tốt đẹp?”. Nội dung chính của bài viết xoay quanh thái độ mâu thuẫn của xã hội hiện đại đối với những điều tốt đẹp, được chia thành các phần sau:

  1. Bối cảnh mở đầu: Tác giả chỉ ra rằng chúng ta đang sống trong một thế giới đầy mâu thuẫn, mặc dù điều kiện vật chất được cải thiện, nhưng việc theo đuổi những điều tốt đẹp của con người dường như do dự, thậm chí là kháng cự. Bài viết khơi gợi suy nghĩ của người đọc bằng cách đặt ra những câu hỏi như “Tại sao chúng ta luôn nghi ngờ rằng mình không xứng đáng với hạnh phúc?”.
  2. Xung đột giữa chủ nghĩa tư bản và chủ nghĩa tiêu dùng: Đề cập đến “Sự giàu có của các quốc gia” (1776) của Adam Smith và “Tư bản luận” (1867) của Marx, nhấn mạnh rằng “những điều tốt đẹp” trong hệ thống tư bản chủ nghĩa thường bị thương mại hóa, khiến mọi người gắn hạnh phúc với tiêu dùng. Dữ liệu cho thấy quy mô thị trường hàng xa xỉ toàn cầu đã vượt quá 300 tỷ đô la Mỹ vào năm 2023, nhưng mức độ hài lòng của người tiêu dùng đối với việc mua hàng lại có xu hướng giảm (giảm 12% so với năm 2019).
  3. Nghịch lý về “những điều tốt đẹp” trên mạng xã hội: Phân tích hiện tượng hiển thị “cuộc sống hoàn hảo” trên các nền tảng như Instagram, trích dẫn nghiên cứu chỉ ra rằng: trung bình mỗi người dùng nhìn thấy 50-150 nội dung được chỉnh sửa kỹ lưỡng mỗi ngày, nhưng sự oanh tạc thị giác này lại làm tăng thêm cảm giác lo lắng. Ví dụ minh họa người dùng mua những món đồ đắt tiền (như túi Gucci, xe Tesla) để nhận được “lượt thích”, nhưng sau khi sử dụng thực tế, họ thấy rằng những món đồ này không mang lại sự hài lòng như mong đợi.
  4. Suy ngẫm triết học về “những điều tốt đẹp”: Trích dẫn quan điểm của nhà triết học Alain de Botton: “Những gì chúng ta theo đuổi không phải là hạnh phúc tự thân, mà là biểu tượng của hạnh phúc.” Đề xuất rằng “những điều tốt đẹp” nên bao gồm ba yếu tố: tính thiết thực, tính thẩm mỹ và giá trị tình cảm, nhưng người hiện đại thường chỉ tập trung vào một trong số đó.
  5. Thảo luận về các giải pháp: Đề xuất xác định lại những điều tốt đẹp thông qua phong trào “tiêu dùng chậm”, chẳng hạn như trong số những người thực hành khái niệm “Danshari” của Nhật Bản, 78% cho biết mức độ hài lòng với cuộc sống của họ đã được cải thiện. Đề cập đến dự án “Vườn chia sẻ” được triển khai tại thành phố Glasgow, Scotland, vào năm 2023 đã có 1200 cộng đồng tham gia, những người tham gia báo cáo rằng cảm giác hạnh phúc của họ đã tăng 31%.
  6. Tương tác kết thúc: Bài viết kết thúc bằng một câu hỏi mở: “Lần gần đây nhất bạn cảm thấy hạnh phúc vì sự tốt đẹp thuần túy của một điều gì đó là khi nào?” và mời độc giả chia sẻ kinh nghiệm trong phần bình luận, đồng thời ghi chú thời gian xuất bản bài viết là “Ngày 17 tháng 4 năm 2024”.

HN | Nóng: 418 điểm | 228 bình luận | Tác giả: rbanffy | 1 ngày trước #

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

  • Việc tập trung vào OpenAI mà bỏ qua các gã khổng lồ công nghệ truyền thống như Cisco và Oracle là một sự phê phán có chọn lọc
  • Cam kết đạo đức của các tổ chức phi lợi nhuận từ lâu đã không còn hiệu lực, cần xem xét một cách bình đẳng sự hợp tác giữa tất cả các doanh nghiệp công nghệ và chính phủ
  • Tác giả từng là thành viên hội đồng quản trị của OpenAI, có lập trường cá nhân đối với các quyết định của công ty này
  • Bản chất của việc doanh nghiệp hợp tác với các chế độ chuyên chế là sự trung lập về công nghệ bị lạm dụng
  • Dưới chủ nghĩa hiện thực chính trị, hành vi của doanh nghiệp thường phục vụ lợi ích riêng của họ hơn là chủ nghĩa lý tưởng
  • Cần cảnh giác với việc các gã khổng lồ công nghệ mở rộng ảnh hưởng thị trường thông qua việc lách luật
  • Các trường hợp hợp tác kỹ thuật giữa Israel và Các Tiểu vương quốc Ả Rập Thống nhất, v.v. bị cố tình bỏ qua
  • Các cuộc thảo luận của công chúng về đạo đức công nghệ cần bao phủ ngành rộng hơn thay vì chỉ một trường hợp duy nhất
  • Khẩu hiệu “thay đổi thế giới” mà doanh nghiệp tuyên bố thường mâu thuẫn với động cơ kinh doanh thực tế

FSE gặp FBI #

FSE meets the FBI

https://blog.freespeechextremist.com/blog/fse-vs-fbi.html

Trang web này là một bài đăng trên blog có tiêu đề “FSE Meets the FBI!” (FSE gặp FBI!), được tác giả Pete đăng vào ngày 6 tháng 4 năm 2025, nội dung xoay quanh sự tương tác giữa phiên bản liên bang (FSE) do anh điều hành và Cục Điều tra Liên bang Hoa Kỳ (FBI), liên quan đến các chi tiết kỹ thuật, rủi ro pháp lý và các vấn đề quản lý cộng đồng. Dưới đây là bản tóm tắt chi tiết được sắp xếp theo cấu trúc gốc:

  1. Bối cảnh và vấn đề cốt lõi Phiên bản FSE (nền tảng mạng xã hội liên bang) do tác giả điều hành đã thu hút sự chú ý của FBI do người dùng tải lên nội dung khiêu dâm trẻ em (CP). Những người ấu dâm thường xuyên xuất hiện, không chỉ vi phạm quy tắc của nền tảng mà còn cố gắng buộc phiên bản này phải đóng cửa thông qua các cuộc tấn công “đầu độc dữ liệu” (tức là cố ý tải lên nội dung bất hợp pháp rồi báo cáo nền tảng). Tác giả chỉ ra rằng các cuộc tấn công như vậy thường dẫn đến việc nền tảng bị lực lượng thực thi pháp luật đột kích, nhưng đối tượng bị bắt giữ thực tế thường là những người báo cáo thực hiện cuộc tấn công chứ không phải bản thân nền tảng. FSE, với tư cách là một phiên bản liên bang, phải đối mặt với nguy cơ bị hiểu lầm là cho phép nội dung bất hợp pháp, trong khi các công cụ của bên thứ ba như fediblock, do không xác minh thông tin, đã tuyên bố sai rằng FSE cho phép một số nội dung không được phép, làm trầm trọng thêm vấn đề.
  2. Điều tra kỹ thuật và biện pháp đối phó Tác giả đã sử dụng các biện pháp kỹ thuật để theo dõi những người dùng bất hợp pháp, bao gồm công khai địa chỉ IP, email, user agent (UA), v.v. của họ. Tuy nhiên, những người ấu dâm phần lớn là “ký sinh trùng”, biết rõ các quy tắc nhưng vẫn cố ý vi phạm, thậm chí mong đợi bị cấm để chuyển sang các phiên bản khác không được quản lý chặt chẽ. Tác giả đã cố gắng giảm sự lan truyền của nội dung bất hợp pháp thông qua việc chặn (blocking) phiên bản, nhưng một số quản trị viên phiên bản không thể nhận được thông tin báo cáo của tác giả do chặn FSE, dẫn đến vấn đề không được giải quyết kịp thời. Ngoài ra, tác giả đề cập rằng chức năng liên bang của FSE đã tạm thời bị gián đoạn do lỗi trong phương pháp lưu trữ người dùng, nhưng gần như đã được khôi phục (dự kiến ​​sẽ được sửa trong vòng vài ngày).
  3. Cơ chế thu thập dữ liệu của FBI FBI hợp tác với “các công ty đáng ngờ” để thu thập nội dung phiên bản liên bang bằng cách sử dụng công nghệ thu thập dữ liệu. Dữ liệu được thu thập được quét bằng từ khóa (tương tự như hệ thống CARNIVORE), sau đó được phân loại theo chủ đề và nhập vào Facebook để phân tích. Xử lý ban đầu bao gồm phân tích tình cảm (sentiment analysis), kết hợp với công nghệ AI do các công ty như Microsoft cung cấp, suy đoán rằng khả năng phân tích của nó đã mở rộng sang các mô hình học máy phức tạp hơn. Hệ thống nội bộ của FBI cho phép các đặc vụ duyệt kết quả phân tích, nhưng tác giả đặt câu hỏi về tính hợp lý của việc “tịch thu ngẫu nhiên” dữ liệu của họ, cho rằng có thể là do trát đòi hầu tòa quá rộng để có được bản sao lưu cơ sở dữ liệu của các phiên bản hợp tác, hoặc thậm chí có thể che giấu danh tính của người cung cấp thông tin.
  4. Thách thức kỹ thuật trong quản lý phiên bản Tác giả nhấn mạnh rằng việc vận hành một phiên bản liên bang cần giải quyết các vấn đề thực tế, thay vì dựa vào các tài liệu lý tưởng. Lấy Pleroma làm ví dụ, cơ sở người dùng của nó được chia thành người dùng thông thường và nhà phát triển, nhưng các tài liệu hiện có thường bỏ qua những khó khăn kỹ thuật trong các tình huống thực tế (chẳng hạn như thu thập dữ liệu, logic lưu trữ người dùng). Tác giả có kế hoạch xuất bản một hướng dẫn sinh tồn kỹ thuật chi tiết hơn để giúp các quản trị viên phiên bản đối phó với các cuộc khủng hoảng tương tự, nhưng nội dung hiện tại đã bao gồm các bước cốt lõi để xác định vấn đề, theo dõi người dùng và sửa chữa chức năng liên bang.
  5. Cộng đồng và rủi ro pháp lý Tác giả chỉ trích sự thiên vị của một số phiên bản “cộng đồng khép kín” đối với FSE, cho rằng việc chặn phiên bản có thể làm giảm nội dung bất hợp pháp, nhưng việc phụ thuộc quá nhiều vào phương pháp này sẽ cản trở sự hợp tác giữa các phiên bản. Trong vụ FBI tịch thu bản sao lưu cơ sở dữ liệu của kolektiva.social, dữ liệu của FSE không được đưa vào, ngụ ý rằng cơ chế liên bang giữa các phiên bản có thể bị FBI lợi dụng làm công cụ thu thập thông tin tình báo. Tác giả chỉ ra rằng những kẻ ấu dâm sợ nhất sự minh bạch, nhưng hầu hết mọi người vẫn phớt lờ các quy tắc, khiến nền tảng phải liên tục giám sát và loại bỏ những người dùng bất hợp pháp.
  6. Hành động tiếp theo và suy ngẫm Tác giả cho biết sẽ tiếp tục công khai thông tin người dùng vi phạm và kêu gọi các quản trị viên phiên bản coi trọng phòng thủ kỹ thuật hơn là chỉ dựa vào chặn. Bài viết kết thúc bằng việc đề cập rằng sau khi chức năng liên bang của FSE được khôi phục, nó sẽ đồng bộ hóa lại dữ liệu với các phiên bản khác, nhưng cần giải quyết vấn đề lỗi khi Revolver lưu trữ người dùng. Tác giả khuyến khích người đọc so sánh kinh nghiệm của bản thân để suy đoán thêm về các mối liên hệ tiềm ẩn giữa FBI và các phiên bản liên bang.

HN | Nóng: 383 điểm | 125 bình luận | Tác giả: 1337p337 | 21 giờ trước #

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

  • Việc FSE bị chặn là do hành vi không phù hợp trực tiếp của người dùng chứ không phải do cơ chế tập thể gây ra
  • Nhấn mạnh rằng những người ủng hộ tự do ngôn luận thường sử dụng nó như một tấm khiên chống lại những lời chỉ trích chứ không phải để thể hiện sự tự do thực sự
  • Liên kết fediblock bị sử dụng sai mục đích làm bằng chứng về việc chặn các phiên bản nhưng thực tế đã không còn hiệu lực trong nhiều năm
  • Lý do công khai cho việc chặn các phiên bản nên dựa trên lý do thực tế chứ không phải cáo buộc bịa đặt
  • Tự do ngôn luận cực đoan có thể biến thành mặt đối lập của phản tự do
  • Bản chất của hành vi chặn là duy trì văn hóa cộng đồng của chính mình chứ không phải loại trừ toàn xã hội
  • Người dùng ủng hộ quyết định chặn của quản trị viên dựa trên hành vi chứ không phải lập trường
  • Hiệu quả của việc chặn phụ thuộc vào sự đa dạng của các vòng tròn xã hội chứ không phải hành động của một cộng đồng duy nhất

Tìm Kiếm Shawn Mendes (2019) #

Finding Shawn Mendes (2019)

https://ericneyman.wordpress.com/2019/11/26/finding-shawn-mendes/

Đây là một bài đăng trên blog có tiêu đề “Finding Shawn Mendes”, trong đó tác giả Eric Neyman, thông qua việc phân tích lời bài hát “Lost in Japan” năm 2018 của ca sĩ người Canada Shawn Mendes, cố gắng suy luận lập trường chính trị ngầm của anh. Nội dung chính của bài viết như sau:

  1. Bối cảnh ảnh hưởng chính trị của người nổi tiếng đề cập đến việc Oprah Winfrey chứng thực cho Obama vào năm 2008 đã mang lại khoảng 1 triệu phiếu bầu (nguồn [1]). Bài đăng trên Instagram năm 2018 của Taylor Swift đã thúc đẩy hơn 160.000 cử tri Mỹ đăng ký (nguồn [2]). Chỉ ra rằng người nổi tiếng thường im lặng về các vấn đề chính trị, nhưng lời bài hát của Shawn Mendes có thể ám chỉ lập trường của anh về tranh chấp “Bốn hòn đảo phía Bắc” (tranh chấp quần đảo Kuril) giữa Nhật Bản và Nga.
  2. Phân tích địa lý lời bài hát Câu hát “Tôi cách Nhật Bản vài trăm dặm” (“a couple hundred miles from Japan”) đặt ra câu hỏi: Mendes thực sự ở đâu? Thông qua phân tích bản đồ (Hình 2), các địa điểm có thể nằm trong bán kính 200 dặm bao gồm Hàn Quốc, Trung Quốc, vùng Viễn Đông của Nga hoặc Đài Loan. Loại trừ Hàn Quốc (Hình 3 cho thấy Hàn Quốc và Nhật Bản đều thuộc múi giờ GMT+9, lời bài hát đề cập đến “múi giờ khác”). Loại trừ Trung Quốc (Hình 4 cho thấy khoảng cách từ Thượng Hải đến Fukuoka là 545 dặm, vượt quá định nghĩa “vài trăm dặm”).
  3. Phân tích khả năng Đài Loan Đảo Ishigaki là hòn đảo cực nam của Nhật Bản, cách Đài Bắc khoảng 200 dặm (Hình 7). Chuyến bay số 124 của China Airlines (Hình 8) cung cấp chuyến bay thẳng từ Đài Bắc đến Ishigaki, nhưng chuyến bay này là chuyến bay ban ngày (khởi hành lúc 11:40), mâu thuẫn với mô tả “tối nay” (“tonight”) trong lời bài hát. Đài Bắc có số lượng lớn muỗi hổ châu Á (Hình 9), trong khi Mendes bị dị ứng với vết muỗi đốt (nguồn [7]), làm suy yếu thêm khả năng Đài Loan.
  4. Suy luận về vùng Viễn Đông của Nga Vùng Viễn Đông của Nga chỉ cách Nhật Bản 200 dặm bao gồm đảo Sakhalin, bờ biển phía đông của lục địa Viễn Đông và quần đảo Kuril (Hình 10). Sân bay duy nhất có chuyến bay thẳng là sân bay Yuzhno-Sakhalinsk ở Sakhalin (Hình 11), chuyến bay duy nhất đáp ứng các điều kiện là Aurora Airlines HZ4536 (khởi hành lúc 18:30 Chủ nhật, đến Sapporo lúc 18:00, do chênh lệch múi giờ rút ngắn thời gian bay 90 phút). Nhưng có một mâu thuẫn: biểu thức “tối nay” trong lời bài hát không phù hợp với thời gian thực tế của chuyến bay (18:30 không phải là đêm khuya), và hành trình 4 giờ (bao gồm di chuyển đến sân bay, kiểm tra an ninh, v.v.) khác với biểu thức “vài giờ” (“a couple hours”) trong lời bài hát.
  5. Kết luận và điểm gây tranh cãi Tác giả thừa nhận rằng lịch trình chuyến bay có thể đã thay đổi (xác minh dữ liệu lịch sử thông qua Internet Archive), nhưng không tìm thấy địa điểm nào khác đáp ứng các điều kiện “200 dặm” và “múi giờ khác”. Cuối cùng, tác giả suy đoán rằng Mendes có thể ngấm ngầm ủng hộ tuyên bố chủ quyền của Nga đối với các hòn đảo tranh chấp, nhưng cần lưu ý rằng mối liên hệ giữa tính văn học của việc sáng tác lời bài hát và lập trường chính trị thực tế là đáng ngờ.

Bài viết sử dụng nhiều chiều phân tích như khoảng cách địa lý, chênh lệch múi giờ, lịch trình chuyến bay và các yếu tố sinh học (dị ứng muỗi đốt) để cố gắng khai thác những ẩn dụ chính trị tiềm ẩn từ văn bản nhạc pop, nhưng chỉ rõ rằng kết luận mang tính suy đoán.

HN | Nóng: 330 điểm | 51 bình luận | Tác giả: jzwinck | 16 giờ trước #

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

  • Bài viết thuộc phong cách hài hước phi lý, thể hiện hiệu ứng châm biếm thông qua việc giải thích quá mức lời bài hát nổi tiếng
  • Bình luận cho rằng cách sáng tạo này tương tự như thuyết âm mưu hoặc sự theo đuổi bệnh hoạn các ẩn dụ trong văn hóa người hâm mộ
  • Có độc giả chỉ ra tác giả có sơ hở trong suy luận logic, chẳng hạn như chưa xác minh liệu đảo Iturup có khách sạn hay không
  • Một số quan điểm cho rằng loại văn bản này là một trò chơi trí tuệ thuần túy, không cần cố gắng gán cho ý nghĩa sâu xa
  • Có người liên tưởng đến thủ pháp hài kịch của Nathan Fielder, phóng đại các chi tiết hàng ngày thành manh mối tường thuật
  • Bình luận đề cập đến việc lời bài hát có thể ám chỉ hành trình thực tế của Shawn Mendes đến Nhật Bản sau chuyến lưu diễn ở Philippines năm 2018
  • Có độc giả cho rằng cấu trúc bài viết chặt chẽ nhưng kết luận phi lý, thể hiện ứng dụng giải trí của phân tích OSINT (tình báo nguồn mở)
  • Một số quan điểm cho rằng tác giả cố tình tạo ra những hồi hộp như “lãnh thổ Nga” để tăng cường hiệu ứng kịch tính
  • Có người so sánh với phim tài liệu “Room 237”, chỉ ra đây là sự diễn giải hiện đại về việc giải thích quá mức nghệ thuật
  • Bình luận đề cập đến việc LLM hiện tại khó tạo ra nội dung suy luận sáng tạo dựa trên các liên tưởng mang tính nhảy vọt như vậy

Tại sao Android không thể sử dụng CDC Ethernet (2023) #

Why Android can’t use CDC Ethernet (2023)

https://jordemort.dev/blog/why-android-cant-use-cdc-ethernet/

Bài đăng trên blog này, dưới dạng một “câu chuyện trinh thám”, đi sâu vào nguyên nhân gốc rễ khiến các thiết bị Android không thể sử dụng CDC Ethernet (bộ điều hợp USB Ethernet) và cung cấp quá trình khám phá các giải pháp cho các thiết bị Android phiên bản khác nhau. Nội dung chính của bài viết như sau:

ROBQbqXRtob4SuxQiSFcxDygnsb.png
  1. Vấn đề cốt lõi: Dịch vụ EthernetTracker của Android chỉ nhận dạng các giao diện mạng được đặt tên là ethX (ví dụ: eth0, eth1), nhưng trình điều khiển CDC Ethernet của nhân Linux sẽ tạo các giao diện được đặt tên là usbX (ví dụ: usb0, usb1). Sự không khớp trong quy tắc đặt tên này khiến hệ thống Android không thể tự động nhận dạng các thiết bị Ethernet CDC.
  2. Tình trạng hỗ trợ bộ điều hợp USB Ethernet: Hệ thống Android bao gồm hỗ trợ cho bộ điều hợp USB Ethernet, nhưng người dùng cần chọn thủ công các chipset tương thích. Rất ít nhà sản xuất điện thoại công khai danh sách các bộ điều hợp được hỗ trợ, chủ yếu dựa vào kinh nghiệm thử nghiệm của người dùng diễn đàn. Nếu nhà sản xuất điện thoại cung cấp bộ điều hợp USB Ethernet đi kèm, thì khả năng tương thích thường tốt hơn.
  3. Cấu hình nhân Linux và hỗ trợ bộ điều hợp: Thiết bị Android sử dụng nhân Linux bên dưới, và phần cứng được hỗ trợ phụ thuộc vào cấu hình nhân. Các thiết bị mới (Android 11 trở lên) sử dụng nhân GKI do Google yêu cầu, và các tệp cấu hình liên quan nằm trong arch/$ARCH/configs/gki_defconfig. Các thiết bị cũ (như Android 10) yêu cầu nhà sản xuất tự bảo trì mã nguồn nhân. Các nhà sản xuất như Samsung sẽ phát hành mã nguồn thông qua các trang web nguồn mở (ví dụ: opensource.samsung.com).
  4. Phương pháp truy vấn phiên bản và kiến trúc nhân: Chạy lệnh uname -a trong ADB shell để lấy phiên bản và kiến trúc nhân. Đầu ra ví dụ cho thấy phiên bản nhân là 4.19.113-26203352 và kiến trúc là aarch64 (ARM64). Cần phải khớp phiên bản nhân với nhánh tương ứng của kho nhân Google.
  5. Cải tiến quy trình gỡ lỗi: Để tránh xung đột cổng gỡ lỗi USB, tác giả trình bày cách chuyển sang chế độ gỡ lỗi mạng thông qua ADB. Các bước cụ thể bao gồm: bật gỡ lỗi USB và cài đặt công cụ ADB, đặt gỡ lỗi mạng bằng adb tcpip 5555, lấy địa chỉ IP của điện thoại và chạy adb connect YOUR_PHONE_IP:5555, xác minh xem kết nối mạng có hiệu quả hay không.
  6. Lấy cấu hình nhân của thiết bị cũ: Lấy Samsung Galaxy S20 làm ví dụ, tệp cấu hình nhân của nó là vendor/x1q_usa_singlex_defconfig. Định vị đường dẫn tệp cấu hình thông qua lệnh find: ./arch/arm64/configs/vendor/x1q_usa_singlex_defconfig. Cần phân tích các tập lệnh xây dựng do nhà sản xuất cung cấp (ví dụ: build_kernel.sh) để xác định vị trí tệp cấu hình.
  7. Hạn chế của giải pháp: Không thể sửa đổi cấu hình config_ethernet_iface_regex của Android theo cách thông thường (yêu cầu quyền root). Có sự khác biệt trong cách lấy cấu hình nhân của các thiết bị mới (nhân GKI) và thiết bị cũ. Khả năng tương thích của bộ điều hợp vẫn cần dựa vào kinh nghiệm thử nghiệm của cộng đồng người dùng.
  8. Bổ sung chi tiết kỹ thuật: Cung cấp một ví dụ về tập lệnh để xây dựng nhân Samsung, bao gồm đường dẫn chuỗi công cụ biên dịch chéo và các tham số cấu hình. Nhấn mạnh những thay đổi chính sách trong quản lý nhân giữa các phiên bản Android khác nhau (10 so với 11+). Giải thích sự không khớp có thể xảy ra giữa phiên bản nhân Linux (4.19) và phiên bản Android (13).

Bài viết kết thúc bằng một “câu chuyện trinh thám” hài hước, chỉ ra rằng mặc dù phân tích kỹ thuật đã tìm ra nguyên nhân gốc rễ của vấn đề, nhưng việc giải quyết thực tế vẫn cần dựa vào sự hỗ trợ của nhà sản xuất hoặc thao tác root, ngụ ý rằng việc giải quyết vấn đề này có những hạn chế thực tế.

HN | Nóng: 327 điểm | 130 bình luận | Tác giả: goodburb | 1 ngày trước #

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

  • Sửa đổi bit toàn cục của địa chỉ MAC của thiết bị CDC có thể khiến thiết bị Android nhận diện nó là eth0 thay vì usbX - Kernel mặc định hỗ trợ đồng thời các giao diện được đặt tên là usb\d+ và eth%d sau Android 14 (U+)
  • Thay đổi này đã bị hoàn nguyên do một số thiết bị phụ thuộc vào giao diện usbX, nhưng Android 15 (V+) đã giới thiệu lại hỗ trợ
  • Logic đặt tên giao diện mạng của Android gây ra các vấn đề về khả năng tương thích với CDC Ethernet, cần can thiệp thủ công
  • Người dùng phàn nàn về các hạn chế quyền đối với thiết bị nối tiếp USB Android, cần root hoặc thư viện của bên thứ ba để thực hiện truy cập
  • WebUSB được hỗ trợ nhưng WebSerial bị thiếu, hạn chế trình duyệt thao tác trực tiếp với các thiết bị nối tiếp
  • Việc triển khai Android 15 của các nhà sản xuất như Samsung có thể ảnh hưởng đến chức năng CDC Ethernet
  • Nên tự động đổi tên giao diện mạng thông qua các quy tắc udev để cải thiện khả năng tương thích
  • Mô-đun quản lý mạng Android thiếu hỗ trợ đầy đủ cho giao thức nối tiếp USB
  • Cộng đồng LineageOS đang cố gắng sửa chữa nhưng thiếu thử nghiệm và xác minh trên thiết bị thực tế

LLMs rẻ #

LLMs are cheap

https://www.snellman.net/blog/archive/2025-06-02-llms-are-cheap/

Juho Snellman trong bài đăng trên blog ngày 2 tháng 6 năm 2025 của mình, “LLMs are cheap” (LLM rẻ), chỉ ra rằng mặc dù chi phí vận hành của AI tạo sinh (đặc biệt là các mô hình ngôn ngữ lớn) thường được cho là cao, nhưng giá thực tế đã giảm đáng kể, thậm chí còn thấp hơn cả API tìm kiếm web truyền thống. Bài viết cố gắng làm rõ sự hiểu lầm này thông qua so sánh dữ liệu cụ thể và phản bác các nghi ngờ phổ biến.

Luận điểm cốt lõi Tác giả nhấn mạnh rằng trong sáu tháng qua, ông liên tục gặp những người tuyên bố rằng chi phí LLM quá cao, nhưng quan điểm này không giảm đi cùng với sự tiến bộ của công nghệ. Ông chứng minh rằng chi phí vận hành của LLM đã giảm đáng kể bằng cách so sánh mô hình định giá của API tìm kiếm và LLM.

Định giá API tìm kiếm web

  • Gemini API: Chức năng “Grounding with Google Search” của Google có giá 35 đô la/1000 truy vấn (giá API chỉ trả về kết quả tìm kiếm không được công bố).
  • Bing Search API: Mức giá thấp nhất là 15 đô la/1000 truy vấn.
  • Brave: Mức giá thấp nhất là 5 đô la/1000 tìm kiếm, nhưng cấu trúc định giá của nó bất thường (hạn ngạch càng lớn, đơn giá càng cao), mức giá thực tế có thể sử dụng là 9 đô la/1000 tìm kiếm.
  • Tác giả chỉ ra rằng giá của các công cụ tìm kiếm có liên quan đến chất lượng của chúng và phạm vi giá tương đối hẹp (5-35 đô la/1000 truy vấn).

So sánh định giá LLM

  • Dữ liệu thử nghiệm: Tác giả chọn 4 câu hỏi tìm kiếm hàng ngày (ví dụ: “Thuật ngữ LLM được sử dụng lần đầu tiên khi nào”, “Giới hạn kích thước hành lý xách tay ở châu Âu”, v.v.), thử nghiệm trên Gemini 2.5 Flash (tắt chế độ suy nghĩ), trung bình xuất ra 500-1000 tokens, mất 2,5-7,6 giây.

  • Giá mô hình LLM (dữ liệu ngày 2 tháng 5 năm 2025):

    • Mô hình cấp thấp: Gemma 3 27B (0,20 đô la/1 triệu tokens), Qwen3 30B A3B (0,30 đô la), Gemini 2.0 Flash (0,40 đô la).
    • Mô hình tầm trung: Gemini 2.5 Flash Preview (0,60 đô la), GPT-4.1 nano (0,40 đô la), GPT-4.1 mini (1,60 đô la).
    • Mô hình cao cấp: Claude 3.5 Haiku (4 đô la), GPT-4.1 (8 đô la), Gemini 2.5 Pro Preview (10 đô la), Claude 3.7 Sonnet (15 đô la), o3 (40 đô la).

  • So sánh trực tiếp: Nếu tính trung bình 1000 tokens/truy vấn, giá LLM (ví dụ: 0,20 đô la/1000 tokens) thấp hơn nhiều so với API tìm kiếm (ví dụ: 5-35 đô la/1000 truy vấn). Ví dụ: so sánh Bing Search API (15 đô la/1000 truy vấn) với Gemini 2.5 Flash (0,60 đô la/1000 tokens) cho thấy LLM rẻ hơn 25 lần.

Phản bác thường gặp và phản hồi

  1. “Độ dài phản hồi của LLM dài hơn”: Tác giả thừa nhận rằng thử nghiệm chọn các câu hỏi thuộc loại tìm kiếm (xuất ra 500-1000 tokens), nhưng chỉ ra rằng trong các tình huống phức tạp (chẳng hạn như tạo mã), việc so sánh API tìm kiếm cần được điều chỉnh cho phù hợp với cùng một lĩnh vực.
  2. “Giá LLM được trợ cấp”: Tác giả phản bác rằng giá API tìm kiếm đã bao gồm chi phí xây dựng và cập nhật chỉ mục, trong khi LLM chỉ tính chi phí suy luận. Ông liệt kê một số bằng chứng: không có nhu cầu khóa thị trường dài hạn và các mô hình được cập nhật thường xuyên, chiến lược giá thấp khó có thể duy trì. Giá LLM của các dịch vụ lưu trữ bên thứ ba (chẳng hạn như Brave, Deepseek) tương đương với API chính thức, không có động cơ trợ cấp. Dữ liệu công khai của Deepseek R1 cho thấy tỷ suất lợi nhuận chi phí GPU của nó có thể đạt 80%. Phân tích chi phí lý thuyết dựa trên kiến trúc mô hình phù hợp với giá thực tế.

Các yếu tố khác

  • Giảm giá cho yêu cầu hàng loạt: Anthropic, Google, OpenAI, v.v. cung cấp chiết khấu 50%; Deepseek giảm giá 50%-75% trong thời gian không cao điểm.
  • Chi phí lưu trữ bên thứ ba: Ví dụ: giá lưu trữ bên thứ ba của Deepseek R1 cạnh tranh gay gắt với API chính thức, chứng minh thêm rằng chi phí có thể kiểm soát được.

Bài viết cuối cùng đề cập rằng dữ liệu tài chính của OpenAI (chẳng hạn như chi 4 tỷ đô la mỗi năm) có thể bị hiểu lầm là chi phí LLM cao, nhưng kết hợp với việc cải thiện hiệu quả suy luận, chi phí thực tế đã giảm đáng kể. Tác giả kết luận rằng chi phí vận hành của LLM đã bước vào giai đoạn thương mại hóa quy mô lớn, thấp hơn nhiều so với dự kiến của hầu hết mọi người.

HN | Nóng: 286 điểm | 261 bình luận | Tác giả: Bogdanp | 12 giờ trước #

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

  • Chi phí suy luận LLM thấp hơn nhiều so với đào tạo nhưng vẫn là chi phí vận hành chứ không phải chi phí vốn
  • Các nhà cung cấp dịch vụ đám mây thu hút người dùng bằng trợ cấp ngắn hạn nhưng không thể duy trì mô hình thua lỗ trong thời gian dài
  • Các mô hình lớn cập nhật và lặp lại nhanh chóng dẫn đến việc các phiên bản cũ nhanh chóng mất giá và khó hình thành tài sản
  • Các doanh nghiệp quá phụ thuộc vào LLM có thể phải đối mặt với rủi ro công nghệ lỗi thời và mất kiểm soát chi phí
  • Hiện tại có một khoảng cách thời gian đáng kể giữa đầu tư vốn và lợi nhuận thực tế trong lĩnh vực AI
  • Chi phí suy luận có thể tăng đáng kể do sự khác biệt về quy mô mô hình và các trường hợp sử dụng
  • Sự khác biệt về độ trưởng thành của công nghệ khiến các mô hình kinh tế của dịch vụ tìm kiếm và dịch vụ LLM không thể so sánh được
  • Trọng số mô hình như một tài sản vô hình cần xem xét vấn đề vốn hóa của đầu tư R&D liên tục

Phần backend x86 tự lưu trữ hiện là mặc định trong chế độ debug #

Self-hosted x86 back end is now default in debug mode

https://ziglang.org/devlog/2025/#2025-06-08

  • Hiện tại, khi mục tiêu là x86_64, theo mặc định, Zig sẽ sử dụng backend x86 của riêng mình, thay vì sử dụng LLVM để giảm tệp bitcode thành tệp đối tượng. Tuy nhiên, do vẫn cần hoàn thành nhiều công việc hơn với trình liên kết COFF, nên cài đặt mặc định trên Windows vẫn chưa thay đổi.

  • Backend x86 của Zig hiện vượt qua 1987 bài kiểm tra hành vi, trong khi backend LLVM vượt qua 1980 bài. Trên thực tế, có 2084 bài kiểm tra hành vi, nhưng những bài kiểm tra bổ sung thường dư thừa với bộ kiểm tra của backend x86 của LLVM, vì vậy chúng chỉ chạy khi sử dụng kiểm tra x86 tự lưu trữ. Tóm lại, backend x86 của Zig mạnh mẽ hơn backend LLVM trong việc triển khai ngôn ngữ Zig.

  • Có một vài lý do chính khiến Zig cạnh tranh với LLVM trong việc tạo mã, chủ yếu là vì Zig có thể vượt trội hơn LLVM đáng kể về tốc độ biên dịch.

  • Bài viết liệt kê hai thử nghiệm điểm chuẩn: thử nghiệm đầu tiên sử dụng backend LLVM và thử nghiệm thứ hai sử dụng backend x86 tự lưu trữ của Zig. Trong thử nghiệm thứ hai, so với thử nghiệm đầu tiên, thời gian thực tế giảm 70.1%, RSS đỉnh giảm 36.2%, chu kỳ CPU giảm 65.2%, số lượng lệnh giảm 62.2%, tham chiếu bộ nhớ cache giảm 68.7%, số lần bỏ lỡ bộ nhớ cache giảm 86.1% và số lần bỏ lỡ nhánh giảm 78.3%. Đối với các dự án lớn như chính trình biên dịch Zig, việc sử dụng backend x86 tự lưu trữ của Zig có thể rút ngắn thời gian biên dịch từ 75 giây xuống còn 20 giây.

  • Công việc của Zig vẫn đang tiếp tục. Họ đã bắt đầu song song hóa hoàn toàn công việc tạo mã. Họ chỉ còn cách việc làm cho biên dịch gia tăng ổn định và mạnh mẽ với backend này một vài cải tiến trình liên kết và sửa lỗi. Vẫn còn những quả chín thấp để cải thiện chất lượng mã x86 được tạo ra. Tiếp theo, họ sẽ xem xét aarch64 và dự kiến công việc này sẽ được tăng tốc nhờ vào Legalize pass mới.

  • CI đã hoàn thành việc xây dựng các commit tương ứng, vì vậy bạn có thể tự mình thử bằng cách tải xuống bản dựng nhánh master mới nhất từ trang tải xuống.

  • Bài viết cuối cùng nhắc nhở rằng Tổ chức Phần mềm Zig là một tổ chức phi lợi nhuận 501(c)(3), nguồn vốn phát triển của tổ chức đến từ sự đóng góp của những người hào phóng như bạn. Nếu bạn thích công việc của họ, hãy giúp họ duy trì sự bền vững về tài chính.

HN | Nóng: 277 điểm | 159 bình luận | Tác giả: brson | 1 ngày trước #

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

  • Trình biên dịch của Zig cần tái cấu trúc mã phân tích ngữ nghĩa để tối ưu hóa hiệu năng comptime, nhưng ưu tiên có thể thấp hơn các tác vụ khác
  • Zig 1.0 được kỳ vọng trở thành ngôn ngữ chủ đạo trong lĩnh vực lập trình hệ thống, nhưng cần giải quyết nút thắt hiệu năng trình biên dịch hiện tại
  • Nhiều ngôn ngữ lập trình hệ thống (C/C++/Rust/Zig, v.v.) có thể cùng tồn tại và chia sẻ chuỗi công cụ phát triển thông qua giao thức LSP và DAP của VSCode
  • Lĩnh vực phát triển game có nhu cầu mạnh mẽ về tính năng trao đổi mã nóng (Hot Code Swapping), việc triển khai của Zig có thể mang lại sự thay đổi
  • Khả năng gỡ lỗi và biên dịch đa nền tảng của Zig đã đủ tốt, đặc biệt phù hợp cho các dự án yêu cầu hiệu năng cao và khả năng tương thích C
  • Mức độ phổ biến của ngôn ngữ ảnh hưởng trực tiếp đến sự phát triển của hệ sinh thái IDE, nhưng các giao thức mã nguồn mở như LSP có thể giảm bớt một phần vấn đề
  • So với C#, Zig thiếu hỗ trợ hot reload có sẵn trong phát triển game, nhưng tốc độ biên dịch và lợi thế LLVM backend là rõ ràng
  • Kế hoạch phát triển URCL backend của Zig được quan tâm, cộng đồng mong đợi nhiều khả năng tùy chỉnh backend hơn
  • Cách thức quỹ ngôn ngữ trả trực tiếp cho người đóng góp là đáng khen ngợi, nhưng cần cân bằng giữa tiến độ phát triển và tính hoàn thiện của chức năng
  • Hệ sinh thái ngôn ngữ lập trình hệ thống hiện tại (như FreeBSD Foundation) có sự khác biệt so với mô hình của Zig nhưng cũng coi trọng đầu tư vào các chức năng cốt lõi

Điều gì xảy ra khi mọi người không hiểu cách AI hoạt động #

What happens when people don’t understand how AI works

https://www.theatlantic.com/culture/archive/2025/06/artificial-intelligence-illiteracy/683021/

Trang web này trình bày một bài viết chuyên sâu trên tờ The Atlantic về những nhận thức sai lầm về trí tuệ nhân tạo. Bài viết mở đầu bằng một lá thư của độc giả ký tên “Cellarius” được đăng trên tờ The Press của New Zealand vào ngày 13 tháng 6 năm 1863, chỉ ra rằng nhà văn người Anh Samuel Butler, khi đó 23 tuổi, đã dự đoán trong thư về mối đe dọa thống trị của “Vương quốc Máy móc” đối với nhân loại. Bức thư này sau đó được xác nhận là mầm mống tư tưởng quan trọng trước khi Butler sáng tác tiểu thuyết phản địa đàng Erewhon.

Phần chính của bài viết tập trung vào sự phát triển thực tế của ngành công nghiệp AI đương đại, đặc biệt giới thiệu cuốn sách mới xuất bản năm 2025 của nhà báo công nghệ Karen Hao, AI Empire: Sam Altman, OpenAI, and the Quest for Universal Intelligence, cuốn sách tiết lộ lao động thủ công khổng lồ cần thiết để đào tạo các mô hình ngôn ngữ lớn (như ChatGPT) thông qua những tiết lộ nội bộ ở Thung lũng Silicon và điều tra chuỗi cung ứng toàn cầu. Đồng thời đề cập đến cuốn sách The AI Delusion: Why Not to Trust the Hype and How to Reclaim Our Futures của nhà ngôn ngữ học Emily M. Bender và nhà xã hội học Alex Hanna, cuốn sách chỉ ra trực tiếp rằng nền tảng của ngành công nghiệp AI chứa đựng sự gian lận có hệ thống.

Cả hai tác phẩm đều chứng minh từ các góc độ khác nhau về đặc điểm bong bóng của ngành công nghiệp AI hiện tại, tác phẩm trước ngầm ám chỉ, tác phẩm sau chỉ rõ ngành công nghiệp AI như một “trò lừa bịp” được xây dựng trên những lời hứa sai lầm. Tác giả bài viết, Tyler Austin Harper, là biên tập viên thường trú của The Atlantic, trước đây là trợ lý giáo sư nghiên cứu môi trường tại Bard College, có nền tảng học thuật liên quan đến nghiên cứu văn học, điện ảnh và lịch sử khoa học, đồng thời là đồng dẫn chương trình podcast Time to Say Goodbye.

HN | Nóng: 246 điểm | 300 bình luận | Tác giả: rmason | 1 ngày trước #

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

  • Bản chất của LLM là tạo ra văn bản đúng ngữ pháp chứ không phải đúng sự thật, cần cảnh giác với vấn đề ảo giác của nó và chủ động xác minh thông tin
  • Người dùng không chuyên thường coi LLM là lời tiên tri hoặc nguồn thông tin có thẩm quyền, thiếu nhận thức về cơ chế tạo sinh xác suất của nó
  • Việc nhân cách hóa LLM thành các thực thể “suy nghĩ” hoặc “ý thức” là một cách diễn đạt gây hiểu lầm, bản chất của nó vẫn là mô hình toán học và sự kết hợp văn bản
  • Cần hiểu hành vi sử dụng mang tính nghi thức của người dùng đối với LLM thông qua các góc độ liên ngành như nhân chủng học, ký hiệu học, v.v.
  • Nên sử dụng các công cụ có khả năng tìm kiếm theo thời gian thực như Perplexity thay vì chỉ sử dụng đầu ra của LLM thuần túy để tăng độ tin cậy
  • Giả thuyết về việc thay thế dần các cơ quan của con người thách thức ranh giới giữa ý thức và công nghệ, đặt câu hỏi về luận điểm về tính độc đáo của con người
  • Kế toán viên sử dụng sai LLM để xử lý dữ liệu tài chính cho thấy rủi ro lạm dụng công cụ và những hạn chế trong lĩnh vực chuyên môn