2025-08-01 Top Stories

2025-08-01 Top Stories #

  1. Phần mềm nhanh chóng cải thiện đáng kể hiệu quả thông qua tối ưu hóa tốc độ và trải nghiệm người dùng, nhưng việc phát triển nó đòi hỏi tối ưu hóa backend phức tạp và tập trung vào các chức năng cốt lõi.
  2. “Lập trình theo cảm hứng” là một phương pháp lập trình tạo ra code nhanh chóng nhưng thiếu khả năng bảo trì, phù hợp cho phát triển nguyên mẫu nhưng có thể nhanh chóng trở thành code kế thừa.
  3. Ollama đã phát hành ứng dụng mới cho phiên bản macOS và Windows, hỗ trợ kéo và thả tệp và mô hình hình ảnh, đồng thời cung cấp phiên bản CLI để tải xuống trên GitHub.
  4. Logo mở đầu năm 1936 của Universal Pictures được tạo ra thông qua mô hình vật lý và phong cách trang trí nghệ thuật, mất khoảng nửa năm, sử dụng vật liệu có độ phản xạ cao và hiệu ứng lân quang.
  5. Ngôn ngữ lập trình Lean thông qua mã hóa toán học hình thức, cho thấy cách chứng minh định lý toán học trong code, nhưng cũng tiết lộ sự không chắc chắn trong toán học.
  6. Có thể nhận ra code được tạo bởi các mô hình ngôn ngữ lớn thông qua phong cách code, loại code này thường không tuân thủ các quy tắc của nhóm và cần chú ý đến chất lượng và khả năng bảo trì.
  7. Figma sẽ IPO vào ngày 31 tháng 7 năm 2025 trên Sở giao dịch chứng khoán New York với mã chứng khoán “FIG”, phát hành tổng cộng 36.937.080 cổ phiếu, với giá 33 đô la Mỹ mỗi cổ phiếu.
  8. Servo là một dự án mã nguồn mở về engine trình duyệt hiệu suất cao và an toàn, nhằm mục đích thay thế Electron và Android WebView, hiện đã hỗ trợ phiên bản snapshot hàng đêm đa nền tảng.
  9. Nhiều quốc gia phản đối ChatControl vào năm 2024 hiện đang do dự, kêu gọi hành động trước cuộc bỏ phiếu vào tháng 10 để phản đối kế hoạch năm 2025 cực đoan hơn.
  10. Mẫu MacBook Pro Silicon M1 Max gặp sự cố hao pin nhanh vào ban đêm, có thể liên quan đến việc tắt tùy chọn “Wake for maintenance”, công cụ Sleep Aid có thể giải quyết vấn đề.

Nhanh #

Fast

https://www.catherinejue.com/fast

Trong lĩnh vực phần mềm, người ta hiếm khi yêu cầu “nhanh”. Chúng ta thường yêu cầu chức năng, chiết khấu số lượng lớn hoặc tích hợp dữ liệu lần tới. Chúng ta chưa bao giờ nhận ra tầm quan trọng của việc yêu cầu phần mềm nhanh. Tuy nhiên, phần mềm nhanh có thể thay đổi hành vi. Khi code được triển khai trong vài giây (hoặc mili giây) thay vì vài phút, các nhà phát triển sẽ phát hành thường xuyên hơn. Tính năng tự động hoàn thành code bằng AI có nghĩa là chúng ta có thể tạo mẫu bằng các ngôn ngữ mà chúng ta không quen thuộc lắm. Phát trực tiếp theo thời gian thực giúp công việc từ xa trở nên khả thi. Ngược lại, phần mềm chậm chạp hạn chế chúng ta, chỉ là chúng ta không nhận ra điều đó. Lần cuối cùng bạn sử dụng WiFi trên máy bay và thực sự hoàn thành được nhiều việc là khi nào? Có lẽ bạn đã gửi một vài tin nhắn Slack hoặc trả lời một vài email. Google Docs đôi khi hoạt động. Có thể bạn đã bỏ cuộc. Instagram thường hoạt động rất tốt - Facebook biết tốc độ quan trọng như thế nào.

Nhanh là điều kỳ diệu. Nhanh loại bỏ ma sát nhận thức. Raycast hiển thị đúng ứng dụng trước khi bạn gõ xong, cảm giác như một phần mở rộng của suy nghĩ của bạn. Quy tắc 100 mili giây của Superhuman - cùng với sự tập trung của họ vào các phím tắt trên bàn phím - đã thay đổi cuộc chơi email theo một cách mà không ai có thể sao chép, chứ đừng nói đến việc vượt qua. Gần đây tôi đã sử dụng Mercury để thanh toán cho một doanh nghiệp khác sử dụng Mercury, và việc thanh toán tức thì của nó đã gây ngạc nhiên trong một thế giới mà chuyển khoản ngân hàng thường mất vài ngày.

Không ai khen ngợi những công cụ này một cách rõ ràng vì tốc độ của chúng. Chúng chỉ đơn giản là mang lại cảm giác kỳ diệu. Nhanh có nghĩa là đơn giản, điều này càng hiếm hơn trong một thế giới mà code và nội dung trở thành hàng hóa. Phần mềm nhanh không có chỗ để ẩn náu. Các lệnh gọi mạng và các phụ thuộc bị phơi bày thông qua độ trễ, sự trung thực tàn khốc này buộc mọi người phải giữ kỷ luật. Những công ty làm tốt về tốc độ thường có các sản phẩm rất tập trung. Điều này là do nỗ lực làm cho phần mềm nhanh thường đòi hỏi phải loại bỏ các tính năng không cần thiết. So sánh tốc độ tải của một công cụ quản lý dự án tinh gọn như Linear với một ứng dụng doanh nghiệp như Workday (hoặc tệ hơn… Oracle). Trong một thế giới ám ảnh về việc thêm vào thay vì tinh chỉnh, tốc độ trở thành biểu hiện cuối cùng của sự tôn trọng. Nó nói, “Chúng tôi đã suy nghĩ sâu sắc về những gì quan trọng và loại bỏ mọi thứ khác.”

Để làm cho mọi thứ nhanh chóng, bạn thường cần phải làm một số điều phức tạp ở hậu trường. Tại Cash App, chúng tôi rất cẩn thận để chỉ giới thiệu các bước bổ sung trong hành trình của người dùng khi thực sự cần thiết, điều này có nghĩa là chúng tôi phải xử lý rất nhiều sự lộn xộn ở phía sau. Trong cuộc phỏng vấn này, Kevin Systrom giải thích cách Instagram tải lên ảnh của người dùng một cách lạc quan trong khi họ nhập chú thích, giúp trải nghiệm tải lên có cảm giác tức thì. Nhanh không chỉ là một thành tựu kỹ thuật - nó biểu thị các ưu tiên và sự tập trung.

Nhanh cũng thú vị. Chúng ta cũng thích nhanh vì nó rất thú vị! Chúng ta tính tốc độ gõ WPM, điều này hầu như không có lợi ích gì ngoài niềm vui khi nhanh hơn những người khác. Điều đầu tiên chúng ta làm trên một máy tính mới là thiết lập các phím nóng của mình để chúng ta có thể nhanh như lần thiết lập trước.

Nhanh là tương đối. Nhiều quy trình làm việc được tăng cường bởi LLM nhanh hơn vô số lần so với những quy trình trước đây. Yêu cầu LLM nghiên cứu trong 6 phút đã nhanh hơn 10000 lần so với một báo cáo cần vài ngày trong quá khứ.

Tuy nhiên, đối với bất kỳ ai viết code, rõ ràng là chúng ta còn rất xa so với các tiêu chuẩn của kỷ nguyên phần mềm trước đây mà chúng ta đã quen. Chúng ta quá tập trung vào khả năng, chúng ta ít tập trung vào hiệu suất hoặc trải nghiệm. Chúng ta chấp nhận sự vụng về này vì phép thuật vẫn còn mới, điều đó không sao cả! Nó vẫn nhanh hơn nhiều so với con người. Nhưng các công cụ chúng ta đang sử dụng để xây dựng, chạy và triển khai các ứng dụng AI hiện tại có cảm giác khác xa so với trải nghiệm nhà phát triển mà chúng ta sẽ có trong tương lai. Chúng ta chưa bắt đầu giai đoạn tối ưu hóa trở thành ưu tiên.

Khi chúng ta làm như vậy, bạn sẽ thấy ngày càng có nhiều công ty tối ưu hóa độ trễ thấp, thiết kế giao diện, khả năng kết nối và độ tin cậy. Điều này đến lượt nó sẽ mở ra các tính năng và trường hợp sử dụng mới mà chúng ta thậm chí chưa xem xét. Rốt cuộc, phần mềm tốt nhất thay đổi cách chúng ta sống và chúng ta xây dựng cuộc sống của mình xung quanh phần mềm có cảm giác như siêu năng lực.

HN | Độ nóng: 1488 điểm | 423 bình luận | Tác giả: gaplong #

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

  • Quy trình làm việc được hỗ trợ bởi LLM thường chậm hơn, chức năng tái cấu trúc của IDE hoàn thành trong vài giây, trong khi các trợ lý dạng agent có thể mất 15 phút.
  • Khi viết các HTTP endpoint, trợ lý dạng agent tiết kiệm được nhiều thời gian, nhưng logic phức tạp và xử lý lỗi không thành công, cuối cùng cần phải viết lại thủ công.
  • So với các nhà phát triển là con người, hiệu suất của AI agent cũng khác nhau giữa các nhiệm vụ khác nhau và vào những thời điểm khác nhau.
  • AI agent phản hồi nhanh hơn các nhà phát triển là con người, luôn sẵn sàng, không có sự cạnh tranh về mức độ ưu tiên và không phàn nàn về phạm vi công việc.
  • Thông qua tích hợp với AI agent trên điện thoại di động, có thể yêu cầu thay đổi mã và thực hiện code review từ xa, nâng cao hiệu quả công việc.
  • Sử dụng các công cụ agent chạy ngầm, có thể thực hiện thay đổi mã và triển khai từ xa khi đang đi nghỉ.
  • Chất lượng công việc của AI agent cần được kiểm tra, vì đôi khi chúng mắc lỗi, dẫn đến cần giao tiếp lặp đi lặp lại, quá trình này rất khó chịu.
  • Xu hướng LLM theo đuổi điểm chuẩn có thể không phù hợp làm công cụ lập trình, vì lỗi của chúng cần được kiểm tra thủ công, dẫn đến hiệu quả thấp.

Vibe code là legacy code #

Vibe code is legacy code

https://blog.val.town/vibe-code

Mặc dù có những hiểu lầm phổ biến, thuật ngữ “vibe coding” (lập trình theo cảm hứng) được tạo ra bởi Andrej Karpathy, nó đề cập đến một phương pháp lập trình được hỗ trợ bởi AI, cho phép bạn “quên đi sự tồn tại của code”. Chúng ta đã có một thuật ngữ để mô tả code mà không ai hiểu: legacy code (code kế thừa). Legacy code thường bị ghét bỏ, và có lý do chính đáng cho điều đó. Nhưng tại sao? Chẳng phải bạn có code đó sao? Bạn không thể hiểu nó từ đó sao? Sai. Code mà không ai hiểu là nợ kỹ thuật. Để hiểu đủ về code lạ để gỡ lỗi nó, chứ đừng nói đến việc giới thiệu các tính năng mới mà không gây ra lỗi mới, cần rất nhiều thời gian.

Lập trình về bản chất là xây dựng lý thuyết, chứ không phải tạo ra các dòng code. Chúng ta biết điều này. Đó là lý do tại sao chúng ta chế giễu những doanh nhân cố gắng đo lường năng suất của nhà phát triển bằng số lượng dòng code. Khi bạn thực hiện vibe coding, bạn đang tích lũy nợ kỹ thuật với tốc độ mà LLM (mô hình ngôn ngữ lớn) có thể xuất ra nhanh chóng. Đó là lý do tại sao vibe coding rất phù hợp cho các nguyên mẫu và các dự án dùng một lần: nó chỉ trở thành legacy code khi bạn cần bảo trì nó!

Tôi đã vui vẻ thực hiện vibe coding cho:

  • Tính toán tỷ lệ tăng trưởng hàng tuần
  • Đánh giá trò chơi Connections của tờ New York Times
  • Cầu hôn vị hôn thê của tôi

Tôi không cần phải tiếp tục phát triển các ứng dụng này, vì vậy việc tôi không hiểu code của chúng không phải là vấn đề. Các ứng dụng này cũng rất nhỏ, có nghĩa là nếu tôi cần đọc code vào một thời điểm nào đó, tôi đã không tích lũy quá nhiều nợ. Tôi đã có thể vibe coding các ứng dụng này nhanh hơn là xây dựng chúng, điều đó thật thú vị.

Vibe coding là một phổ hệ về mức độ bạn hiểu code. Bạn càng hiểu nhiều, bạn càng ít vibe coding. Chỉ cần là một kỹ sư yêu cầu một ứng dụng web với cơ sở dữ liệu bền vững, bạn đã vibe coding ít hơn so với một người không phải là lập trình viên, người không hiểu sự khác biệt giữa ứng dụng web và ứng dụng native, hoặc không hiểu cách lưu trữ dữ liệu bền vững hoạt động, yêu cầu một “ứng dụng”.

Trường hợp tồi tệ nhất là một người không phải là lập trình viên vibe coding một dự án lớn mà họ định bảo trì. Nó giống như đưa cho một đứa trẻ một chiếc thẻ tín dụng mà không giải thích khái niệm về nợ. Bạn có thể tưởng tượng, giai đoạn đầu là sự ngây ngất. Tôi có thể vung vẩy mảnh nhựa nhỏ này trong cửa hàng và lấy bất cứ thứ gì tôi muốn! Nó rất giống với việc AI bây giờ có thể xây dựng bất cứ thứ gì! Không ai cần học cách lập trình! Hãy xem nó đã làm gì cho tôi!

Nhưng nếu bạn đợi một tháng, bạn sẽ nhận được hóa đơn thẻ tín dụng. Tôi có thực sự cần phải mua tất cả những thứ này không? Làm thế nào tôi có thể thoát khỏi mớ hỗn độn này? Điều tương tự cũng xảy ra với vibe coder. Code của tôi bị hỏng. Những tệp và thư mục này thực sự làm gì? Làm thế nào tôi có thể sửa nó? Tôi có thể yêu cầu hoàn lại tiền cho 400 đô la mà tôi đã chi cho vibe coding không? Nếu bạn không hiểu code, lựa chọn duy nhất của bạn là để AI sửa nó cho bạn, điều này giống như trả nợ thẻ tín dụng bằng một thẻ tín dụng khác.

Nếu bạn đang xây dựng một thứ gì đó nghiêm túc mà bạn định bảo trì vào năm 2025, Andrej nói đúng: [giữ] sự kiểm soát rất chặt chẽ đối với thiên tài thực tập sinh mới, nhiệt tình quá mức này, người có kiến thức bách khoa toàn thư về phần mềm, nhưng cũng luôn nói nhảm, có quá nhiều can đảm và hầu như không có gu về code tốt. Nhấn mạnh việc chậm rãi, phòng thủ, cẩn thận, hoang tưởng và luôn nắm bắt cơ hội học tập nội tuyến, đừng ủy thác.

Tại Val Town, chúng tôi đã tích hợp AI vào sản phẩm của mình theo hàng chục cách. Townie là trợ lý AI của chúng tôi, nó tích cực đọc và viết code, chạy nó, xem nhật ký và liên tục lặp lại cho đến khi hoàn thành. Townie là một công cụ tuyệt vời cho vibe coding. Tôi rất khuyến khích nó cho những người hiểu những đánh đổi này. Đôi khi tôi sử dụng nó để vibe coding. Những lúc khác, tôi kiểm soát nó chặt chẽ khi nó thực hiện các chỉnh sửa phẫu thuật trên các dự án của tôi. Cả hai đều thú vị và hữu ích.

Những thay đổi trong việc lập trình với AI diễn ra quá nhanh đến nỗi thật khó để biết ngày mai sẽ mang lại điều gì, nhưng tôi chắc chắn rằng việc xây dựng lý thuyết sẽ vẫn là trung tâm của hoạt động xây dựng phần mềm phức tạp. Chuyên môn kỹ thuật của chúng tôi vẫn phù hợp! Tôi lạc quan rằng AI sẽ tiếp tục làm cho việc lập trình trở nên tốt hơn theo những cách đáng ngạc nhiên. Nhưng nếu bạn biết bất kỳ người không phải là lập trình viên nào đang chi hàng nghìn đô la để vibe coding ý tưởng ứng dụng trị giá hàng tỷ đô la của họ, hãy gửi cho họ bài viết này. Vibe coding sẽ không đưa họ đến nơi họ muốn đến. Họ sẽ phải học cách đọc code bằng mắt người 😱, và học cách đôi khi xây dựng một codebase được viết tốt từ đầu dễ hơn là sửa một legacy code mà không ai hiểu.

HN | Độ nóng: 708 điểm | 439 bình luận | Tác giả: simonw #

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

  • Một người bạn đã xây dựng một ứng dụng SaaS bằng Replit và Supabase, gần như không cần marketing mà vẫn có doanh thu, nhưng chất lượng code kém và dễ bị hacker tấn công.
  • Đối thủ cạnh tranh có thể thuê hacker tấn công ứng dụng SaaS, vì sản phẩm của bạn bè có giá thấp hơn và hiện đại hơn.
  • Các cuộc tấn công của hacker có thể là do trang web bị các trình quét lỗ hổng tự động đánh dấu là dễ bị tấn công.
  • Các cuộc tấn công của hacker có thể là vì danh tiếng, chẳng hạn như bằng cách lấy được khóa Stripe và hoàn tiền để thể hiện khả năng.
  • Các cuộc tấn công của hacker có thể không chỉ để hoàn tiền cho khách hàng, mà còn có các mục đích khác, chẳng hạn như kiểm tra thẻ tín dụng bị đánh cắp.
  • Nhiều trang web và ứng dụng có lỗ hổng bảo mật, nhưng không phải tất cả đều bị khai thác.
  • Ngay cả một trang web nhỏ, nếu code và việc triển khai bảo trì không được thực hiện tốt, cũng có thể bị tấn công.
  • Ai đó có thể thực hiện các cuộc tấn công của hacker vì “cho vui”.
  • Trên Internet, các máy chủ mới được triển khai sẽ sớm bị các trình quét lỗ hổng chú ý.

Ứng dụng mới của Ollama #

Ollama’s new app

https://ollama.com/blog/new-app

Ứng dụng mới của Ollama hiện đã có mặt trên các nền tảng macOS và Windows. Ứng dụng mới này cung cấp một cách dễ dàng hơn để trò chuyện với các mô hình. Các phiên bản macOS và Windows của Ollama hiện bao gồm các chức năng tải xuống và trò chuyện với các mô hình.

Ứng dụng mới hỗ trợ chức năng kéo và thả tệp, giúp việc suy luận với các tệp văn bản hoặc PDF trở nên dễ dàng hơn. Đối với việc xử lý các tài liệu lớn, độ dài ngữ cảnh của Ollama có thể được tăng lên trong phần cài đặt. Cần lưu ý rằng điều này sẽ đòi hỏi nhiều bộ nhớ hơn.

Dựa trên công cụ đa phương thức mới của Ollama, bạn có thể gửi hình ảnh đến các mô hình hỗ trợ hình ảnh, chẳng hạn như mô hình Gemma 3 của Google DeepMind.

Các tệp mã có thể được xử lý bởi mô hình để đạt được sự hiểu biết. Giờ đây, bạn có thể tải xuống ứng dụng mới của Ollama, dành cho các nền tảng macOS và Windows. Đối với phiên bản giao diện dòng lệnh thuần túy của Ollama, bạn có thể tìm thấy các liên kết tải xuống độc lập trên trang phát hành GitHub của Ollama.

HN | Độ nóng: 530 điểm | 271 bình luận | Tác giả: BUFU #

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

  • Ứng dụng mới của Ollama dường như đã chuyển từ nhắm mục tiêu đến nhà phát triển sang người dùng thông thường
  • Phiên bản CLI của Ollama vẫn có sẵn trên trang phát hành GitHub
  • LM Studio và Msty là hai ứng dụng LLM cục bộ tuyệt vời
  • Phím tắt của ứng dụng ChatGPT trên máy tính để bàn để mở chức năng trò chuyện mới rất hữu ích cho các ứng dụng LLM cục bộ
  • Ollama được tạo ra cho các nhà phát triển và sẽ tiếp tục cải thiện các chức năng của nó
  • Ollama không cung cấp phiên bản Linux, điều này khiến một số nhà phát triển thất vọng
  • Có một nhà phát triển đã không sử dụng ứng dụng Linux GUI trong 15 năm
  • Ollama thực sự có một máy khách Linux, nhưng không được đề cập trong blog
  • Có một nhà phát triển tin rằng các nhà phát triển Linux sẽ không sử dụng bất cứ thứ gì khác ngoài trình quản lý cửa sổ xếp lát
  • Các bản cập nhật và tính năng mới của Ollama cho thấy sự tập trung của nó vào nhu cầu của nhà phát triển
  • Ollama mặc định chọn một mô hình mà người dùng không có, điều này gây bất tiện cho người dùng
  • Người dùng đề xuất rằng biểu tượng tải xuống nên có thể nhấp trực tiếp để bắt đầu tải xuống
  • Người dùng thích giao diện người dùng mới của Ollama và đưa ra các đề xuất để cải thiện việc tải xuống và hiển thị thông tin mô hình
  • Có một người dùng hỏi liệu GitHub CLI của Ollama có sử dụng cùng một mô hình hay không
  • Có một người dùng tò mò về cách sử dụng Ollama và các mô hình phổ biến
  • Ollama không cập nhật mô hình, người dùng buộc phải sử dụng các ứng dụng khác
  • Người dùng có thể trực tiếp tìm và triển khai các mô hình được Ollama hỗ trợ trên Hugging Face
  • Ollama hỗ trợ các mô hình mới, chẳng hạn như 235B và 30B Qwen3
  • Ollama hợp tác trực tiếp với hầu hết các phòng thí nghiệm nghiên cứu và người tạo mô hình, và thường hỗ trợ các mô hình mới vào ngày phát hành
  • Người dùng muốn có thể thêm trực tiếp các mô hình vào Ollama
  • Người dùng có thể nhận bất kỳ mô hình gguf nào bằng cách chỉ định phiên bản lượng tử hóa
  • Mô hình qwen3 đã được cập nhật gần đây
  • Chức năng gọi công cụ có thể sẽ không sớm được kích hoạt cho mô hình Gemma3
  • Mô hình gemma 3 không hỗ trợ gọi công cụ, Ollama đang hợp tác với Google để cải thiện các mô hình trong tương lai

Logo mở đầu của Universal Pictures năm 1936 được tạo ra như thế nào? #

How was the Universal Pictures 1936 opening logo created?

https://movies.stackexchange.com/questions/128020/how-was-the-universal-pictures-1936-opening-logo-created

Trang web này thảo luận về cách logo mở đầu năm 1936 của Universal Pictures được tạo ra. Logo này bắt đầu được sử dụng từ năm 1936 và tiếp tục được sử dụng trong vài năm. Thiết kế của logo này trùng với thời điểm Universal Pictures Corporation đổi tên thành Universal Productions Inc., còn được gọi là logo thứ bảy. So với các phiên bản trước, logo này có nhiều yếu tố động, độ trong suốt và hiệu ứng phản xạ, việc sản xuất khá phức tạp.

Trang web đề cập rằng việc sản xuất logo này liên quan đến các mô hình vật lý thực tế chứ không phải hình ảnh do máy tính tạo ra. Alexander Golitzen, một đạo diễn nghệ thuật nổi tiếng làm việc tại Universal hơn 30 năm, đã áp dụng phong cách trang trí nghệ thuật và sử dụng polymethyl methacrylate (plexiglass) để tạo ra logo. Các ngôi sao xoay có kích thước khác nhau trước tiên được chụp ảnh, sử dụng polymethyl methacrylate mỏng nhất, trên đỉnh được phủ một lớp mỏng kẽm sunfua hoạt hóa bạc, một vật liệu có độ phản xạ cao, thường được sử dụng trong tia X và ống tia âm cực.

Các ngôi sao xoay độc lập, xung quanh có một vài đèn (trong đó hai đèn di chuyển, xoay quanh các ngôi sao) và một khẩu độ máy ảnh rất chặt, để ánh sáng và sự phản xạ của các ngôi sao có thể di chuyển dọc theo chiều dài của chúng. Tiếp theo, các ngôi sao được kết nối với Trái đất. Bên trong Trái đất được phủ cùng một vật liệu lân quang, nhưng được pha loãng một nửa, hạn chế khả năng phản xạ của nó. Nó được sơn màu đen, loại bỏ độ trong suốt. Lần chụp đầu tiên của hình ảnh được thực hiện mà không có chữ, Trái đất ở phía trước màn hình chiếu trước 6 feet.

Hình ảnh của các ngôi sao được chiếu lên phía trên Trái đất, tạo ra sự phản xạ của các mẫu ánh sáng ngoạn mục. Lần chụp tiếp theo sử dụng Trái đất thứ hai - lớn hơn, được đánh bóng và sơn màu đen. Trái đất này có các chữ cái của công ty và được gắn trên các thanh kim loại, xoay bằng tay. Nghệ sĩ hiệu ứng đặc biệt John Fulton đã quay Trái đất đang xoay ở góc thấp, các chữ cái tự phát sáng ở tốc độ cao (ước tính 32 khung hình mỗi giây).

Hình ảnh này sau đó được in ba lần lên hình ảnh Trái đất ban đầu, lần đầu tiên là để tạo ra sự phản xạ của tiêu đề, lần thứ hai được chụp mà không có ánh sáng trên Trái đất hoặc các chữ cái. Nền là một màn hình chiếu sau. Điều này tạo ra đường viền của Trái đất, được sử dụng làm mặt nạ để che lớp cuối cùng - tiêu đề thực tế. Việc sản xuất logo này mất khoảng nửa năm.

Theo Golitzen, sau này trong bộ phim “This Island Earth” (1955) của Universal, Trái đất này đã được nhìn thấy, được bao phủ bởi các quả cầu nhỏ hơn, như một thiết bị “Interociter”.

HN | Độ nóng: 450 điểm | 64 bình luận | Tác giả: azeemba #

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

  • Bí mật để tạo ra phép thuật nằm ở việc bỏ ra nhiều nỗ lực hơn bất kỳ người hợp lý nào, đến mức không một người hợp lý nào tin rằng bạn đã hoàn thành nó một cách khó khăn.
  • Có một nguyên tắc tương tự trong “Lawrence of Arabia”, nơi Lawrence dùng đầu ngón tay dập tắt que diêm như một kỹ xảo phô trương, những người khác thử thì thấy đau, khi hỏi về kỹ xảo, anh ta trả lời “Kỹ xảo, William Potter, là không quan tâm đến việc nó đau”.
  • Trong “Prometheus”, cảnh này được dùng để nhấn mạnh việc một Android hành xử không nhất quán với phi hành đoàn, không quan tâm đến hậu quả của hành động tiếp theo.
  • Chủ đề này cũng xuất hiện trong “The Prestige”, mặc dù những lời đó có thể không phải là những lời dễ nhớ nhất.
  • Dòng Lawrence of Arabia đến từ bộ phim năm 1962, có thể ai đó đã nói điều đó trước đó.
  • BBC 1 ident từ những năm 1960 đến những năm 1980 là một mô hình vật lý, phát sóng trực tiếp (thậm chí không được ghi lại!).
  • Có người đã đề cập đến BBC 1 ident của những năm 1960, đây là một mô hình vật lý, phát sóng trực tiếp, không được ghi lại.
  • Có người đã đề cập đến máy quay Noddy và cung cấp một liên kết video cho thấy cách máy quay Noddy hoạt động.
  • Có người đã đề cập đến sự khác biệt về trải nghiệm giữa TV 4K và màn hình 1080p.
  • Có người đã đề cập rằng nhiều đài truyền hình hoặc không truyền 4K hoặc mã hóa luồng của họ với tốc độ bit cực thấp, dẫn đến trải nghiệm xem rất tệ.
  • Có người đã đề cập rằng khi xem khúc côn cầu, họ nhận thấy sự khác biệt về chất lượng giữa các đài truyền hình khác nhau.
  • Có người đã đề cập rằng sự khác biệt về chất lượng 4K giữa Apple TV và YouTube, hoặc giữa Crunchyroll và YouTube là rất lớn.
  • Có người đã đề cập đến phần mở đầu gốc của “Doctor Who” những năm 1960, một sự đổi mới gây sốc vào thời điểm đó.
  • Có người đã đề cập rằng BBC Radiophonic Workshop rất sáng tạo.
  • Có người đã đề cập đến việc sản xuất phần mở đầu “Feature Presentation” của HBO, tất cả đều được thực hiện bằng các mô hình thu nhỏ và các hiệu ứng tương tự trước khi kỹ thuật số/CGI tồn tại hoặc khả thi.
  • Có người đã đề cập đến quá trình sáng tạo logo mở đầu năm 1936 của Universal Pictures, đề cập đến phong trào Art Deco và đóng góp của Golitzen.

Toán Học Bị Ám Ảnh #

The Math Is Haunted

https://overreacted.io/the-math-is-haunted/

Lean là một ngôn ngữ lập trình, chủ yếu được sử dụng bởi các nhà toán học, điều này khá bất thường, vì nó được thiết kế để hình thức hóa toán học. Lean cho phép các nhà toán học coi toán học như mã — chia nó thành các cấu trúc, định lý và chứng minh, nhập các định lý lẫn nhau và đặt nó lên GitHub. Mục tiêu cuối cùng là, phần lớn kiến thức toán học của nhân loại có thể tồn tại dưới dạng mã — được kiểm tra tĩnh, có thể xác minh và có thể kết hợp.

Cảm giác khi sử dụng Lean như thế nào? Bài viết đưa ra một ví dụ đơn giản về định lý, đó là 2 bằng 2:

sorry```Đối với các nhà toán học, cú pháp này trông giống như đang trình bày một định lý. Còn đối với các lập trình viên, nó trông giống như hàm. Nhưng làm thế nào mà 2=2 lại trở thành kiểu? 2=2 chẳng phải là giá trị boolean sao? Nếu 2=2 thực sự là kiểu, thì giá trị của kiểu này là gì? Những câu hỏi này rất thú vị, nhưng chúng ta phải tạm gác lại bây giờ.

Bài viết tiếp tục giới thiệu quá trình chứng minh:```theorem two_eq_two : 2 = 2 := by
sorry```Đặt con trỏ trước "sorry", bạn sẽ thấy một bảng có tên "Tactic state", hiển thị ⊢ 2 = 2, trong đó ⊢ biểu thị mục tiêu, tức là tuyên bố bạn định chứng minh. Mục tiêu hiện tại là chứng minh 2=2.

Đặt con trỏ sau "sorry", mục tiêu biến mất, có nghĩa là bằng cách nói "sorry" đã "chứng minh" 2=2. Tất nhiên, điều này là vô nghĩa, bạn có thể coi "sorry" như một chứng minh chung — nó đóng bất kỳ mục tiêu nào. Nó là một lời nói dối. Theo nghĩa này, "sorry" giống như bất cứ thứ gì trong TypeScript. Nó cho phép bạn ngăn chặn trình kiểm tra chứng minh, nhưng bạn thực sự không hiển thị bất cứ điều gì hữu ích.

Bài viết tiếp tục hướng dẫn cách loại bỏ "sorry", thực sự chứng minh 2=2:```theorem two_eq_two : 2 = 2 := by
rfl```Ở đây rfl biểu thị "tính phản xạ", đến từ "phản xạ", giống như một tấm gương. Bất cứ khi nào bạn có một mục tiêu "gương" như một cái gì đó = một cái gì đó, rfl sẽ đóng nó. Bạn có thể coi rfl như kiến thức tích hợp, tức là "một thứ bằng chính nó".

Bài viết cũng trình bày cách tham chiếu đến các sự kiện đã được chứng minh:```theorem two_eq_two_again : 2 = 2 := by
exact two_eq_two```Ở đây, two\_eq\_two\_again ủy thác chứng minh cho two\_eq\_two, vì mục tiêu hiện tại (⊢ 2 = 2) chính xác là những gì two\_eq\_two đã chứng minh. Đối với các lập trình viên, điều này có thể trông giống như trả về kết quả của một lệnh gọi hàm.

Bài viết tiếp tục thảo luận về quá trình sử dụng Lean để chứng minh các định lý phức tạp hơn, bao gồm việc sử dụng tactics (chiến thuật) để đóng các mục tiêu khác nhau. Ví dụ: rfl có thể đóng các mục tiêu như x=x, exact some\_other\_theorem có thể đóng các mục tiêu đã được chứng minh và sorry có thể đóng bất kỳ mục tiêu nào (nhưng có rủi ro).

Cuối cùng, bài viết thảo luận về sự không chắc chắn của toán học, chỉ ra rằng toán học không phải là bất biến, bạn có thể có "toán học ma ám" của riêng mình. Bằng cách giới thiệu một tiên đề math\_is\_haunted, khiến 2=3, bạn có thể chứng minh nhiều điều kỳ lạ hơn, chẳng hạn như 2+2=6. Điều này cho thấy, nếu có một mâu thuẫn trong toán học, chúng ta có thể chứng minh bất cứ điều gì. Điều này gây khó chịu, nhưng trên thực tế, những mâu thuẫn như vậy đã được phát hiện trong lý thuyết tập hợp vào đầu thế kỷ 20, sau đó được "sửa chữa" bằng cách chọn các tiên đề khác nhau. Sau khi xóa tiên đề math\_is\_haunted, các chứng minh phụ thuộc vào tiên đề xấu này cũng sẽ bị phá vỡ, điều này là tốt.

---


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

[https://news.ycombinator.com/item?id=44739315](https://news.ycombinator.com/item?id=44739315)

- Sử dụng các công cụ tương tự như Lean để viết lại tin tức và các bài viết phi hư cấu, coi các tuyên bố như các định lý cần chứng minh và chứng minh bằng cách trích dẫn, có thể thu được các phiên bản tài liệu được gắn nhãn "đã chứng minh".
- Hình thức hóa các tuyên bố bằng ngôn ngữ tự nhiên là một lĩnh vực đầy khó khăn, vì cần phải xác định chính xác các khái niệm như danh tính, thời gian, nhân quả, v.v., để các sự kiện có thể liên quan đến nhau hoặc được diễn đạt.
- Các hình thức logic khác nhau phù hợp với các ngữ cảnh khác nhau, chẳng hạn như các hình thức hóa khác nhau của danh tính.
- Việc kết hợp các logic khác nhau dường như tiến triển tốt trong cộng đồng kiểm tra mô hình, nhưng tốt nhất là khi các logic khác nhau này có thể được đơn giản hóa thành các cấu trúc dữ liệu nguyên thủy giống nhau.
- Các nhà triết học sử dụng các logic khác nhau để hình thức hóa các loại tranh luận khác nhau liên quan đến thời gian/phương thức/xác suất, những logic này không hoàn toàn "mô-đun" và khó kết hợp.
- Từ góc độ loại logic, tính phương thức có thể được coi là đơn tử, vì vậy vấn đề "kết hợp" tính phương thức tương tự như vấn đề kết hợp đơn tử trong ngôn ngữ lập trình.
- Những niềm tin quan trọng nhất trong tin tức hiếm khi có thể được chứng minh bằng một loạt các tuyên bố tuyệt đối, các công cụ sử dụng chuỗi suy luận Bayes có thể hiệu quả hơn.
- Sử dụng xác suất và phương pháp Bayes để cập nhật niềm tin là cách duy nhất để tránh sự phi lý trí về kinh tế.
- Học toán giúp cải thiện tính nghiêm ngặt của văn bản phi hư cấu, chẳng hạn như kiểm tra tính đầy đủ của chuỗi logic.
- Sử dụng các mô hình ngôn ngữ lớn (LLMs) để lập trình nhiệm vụ này dường như là khả thi, nhưng vấn đề ảo giác cản trở kế hoạch này.
- Tồn tại các kỹ thuật tu từ dựa vào sự không đầy đủ của chuỗi logic, khiến mọi người lầm tưởng rằng có một kết luận logic, trong khi thực tế có thể chỉ là ngữ cảnh liên quan lỏng lẻo, không có chuỗi logic.

---


## Tôi biết khi nào bạn đang "vibe coding"

> I know when you’re vibe coding

[https://alexkondov.com/i-know-when-youre-vibe-coding/](https://alexkondov.com/i-know-when-youre-vibe-coding/)

Tôi không quan tâm code được đưa vào IDE bằng cách nào. Cho dù nó được viết tay, sao chép từ diễn đàn, được tạo ra bởi LLM (Large Language Model) hay bằng cách mô phỏng vô số thời gian để lũ khỉ tạo ra giải pháp, tôi không quan tâm. Điều tôi quan tâm là nội dung được hợp nhất vào codebase. Khi tôi nhấp vào nút "Phê duyệt", trong đầu tôi chỉ có một vài lo ngại: liệu nó có tạo ra kết quả đúng không? Liệu mọi người có thể hiểu nó trong quý tới không? Họ có thể thay đổi nó không?

Nhưng gần đây, tôi bắt đầu nhận thấy một số điều ngay lập tức cho tôi biết code được viết bởi LLM. Không, tôi không nói đến những comment lặp đi lặp lại (tôi không quan tâm đến những điều đó), thậm chí không phải là các câu lệnh `switch` mà chúng rất thích.

Tôi biết code được tạo ra vì cách nó được viết không phải là cách bất kỳ nhà phát triển nào trong nhóm sẽ sử dụng. Nó hiệu quả, rõ ràng, đã được kiểm tra và có thể bảo trì. Nhưng cách nó được viết không tuân theo các quy ước dự án mà chúng tôi đã chấp nhận. Tôi biết nó không phải do con người viết.

Bởi vì không ai viết một implementation HTTP `fetch` bao gồm tất cả các trường hợp đặc biệt khi dự án đã có một thư viện lấy dữ liệu. Không ai triển khai một loạt các hàm tiện ích khi chúng ta đã có các hàm tiện ích trong các module khác nhau. Không ai thay đổi cấu hình toàn cục khi có cơ chế cấp module. Không ai viết một class khi chúng ta sử dụng phương pháp hàm ở khắp mọi nơi.

Tôi không muốn biết bạn đã viết nó như thế nào. Tôi chỉ muốn biết bạn quan tâm đến những gì mô hình đưa ra. Đây là code mà bạn sẽ không tạo ra vài năm trước.

Chúng tôi đã dành hàng thập kỷ để xây dựng các pattern và tiêu chuẩn giúp chúng tôi xây dựng phần mềm có thể bảo trì. Đây luôn là một thách thức - đưa một thứ gì đó vào production mà bạn có thể chăm sóc nó trong những năm tới. Bất kỳ ai cũng có thể tạo ra một implementation hoạt động. Bạn sẽ vá một đoạn code trông giống như quái vật Frankenstein, và nó sẽ hoàn thành công việc.

Phần mà chúng tôi luôn cố gắng là thay đổi nó sau khi ra mắt.

Tốc độ có phải là đức tính lớn nhất?

Vài ngày trước, tôi ở quán cà phê địa phương, họ đang đào tạo một barista mới. Hàng rất dài, anh chàng mới đến hoảng sợ, vội vàng pha ly cà phê tiếp theo, cà phê và sữa vương vãi khắp nơi.

Chúng ta lại quay trở lại giai đoạn này, vội vàng tung ra phần mềm tiếp theo vì chúng ta nghĩ rằng tốc độ là đức tính lớn nhất. Nhưng mọi người muốn một tách cà phê ngon, ngay cả khi họ cần đợi một chút.

Tôi luôn nghĩ rằng tôi sẽ tức giận với những người làm tài chính đang tìm cách viết những con số nhỏ hơn trong bảng tính, nhưng tôi thất vọng với những đồng nghiệp phát triển phần mềm nhanh chóng vứt bỏ mọi nguyên tắc để tăng tốc độ phát triển phần mềm.

Điều tôi thực sự muốn

Tôi không quan tâm code được đưa vào IDE của bạn bằng cách nào.

Tôi muốn các bạn quan tâm.

Tôi muốn mọi người quan tâm đến chất lượng, tôi muốn họ quan tâm đến tính nhất quán, tôi muốn họ quan tâm đến tác động lâu dài của công việc của họ. LLM là những kỳ quan kỹ thuật, tôi dành sự tôn trọng sâu sắc nhất cho những người tạo ra chúng. Nhưng chúng ta vẫn cần xây dựng phần mềm, không phải sản xuất nguyên mẫu.

Viết các prompt tốt hơn. Đưa ra mô tả tốt hơn. Cho LLM biết thư viện nào cần sử dụng. Cung cấp cho nó các ví dụ để làm theo. Viết các file nhỏ hơn. Không có nguyên tắc mới nào cả - hãy tuân theo những nguyên tắc đã có.

Đừng giao khả năng bảo trì codebase cho trọng số của mô hình.

---


### HN | Độ nóng: 326 điểm | 156 bình luận | Tác giả: thunderbong

[https://news.ycombinator.com/item?id=44742251](https://news.ycombinator.com/item?id=44742251)

- Một số người trong nhóm sẽ lặp lại việc triển khai các chức năng đã có hoặc thay đổi cấu hình toàn cục, vì họ không biết các công cụ và cơ chế đã có.
- Nếu một codebase lớn có tài liệu không rõ ràng, những người đóng góp mới có thể phát minh lại nhiều thứ.
- Mã tự ghi lại thường có nghĩa là không có tài liệu, khiến các lập trình viên tốn nhiều thời gian để hiểu mã.
- Code review là thời điểm tốt để thêm chú thích vào mã, có thể phát hiện ra những điểm khó khăn và rõ ràng trong mã.
- Viết tài liệu đồng bộ khi viết mã có thể giảm nợ kỹ thuật và giữ cho mã linh hoạt.
- Đôi khi bản thân mã là tài liệu kỹ thuật tốt nhất, đặc biệt đối với các thuật toán hình học được viết rõ ràng.
- Tài liệu không chỉ dành cho nhà phát triển, các định dạng tài liệu khác nhau hữu ích hơn cho những người khác nhau.
- Tài liệu mã nên giúp các nhà phát triển mới nhanh chóng hiểu dự án, sau đó hướng dẫn họ xem mã.

---


## Figma sẽ IPO vào ngày 31 tháng 7

> Figma will IPO on July 31

[https://www.figma.com/blog/ipo-pricing/](https://www.figma.com/blog/ipo-pricing/)

Figma đã công bố giá cho đợt phát hành cổ phiếu lần đầu ra công chúng (IPO) vào ngày 30 tháng 7 năm 2025. Figma dự kiến bắt đầu giao dịch trên Sở giao dịch chứng khoán New York vào ngày 31 tháng 7 năm 2025 với mã chứng khoán "FIG". Figma là một nền tảng thiết kế và phát triển sản phẩm, nơi các nhóm biến ý tưởng thành các sản phẩm và trải nghiệm kỹ thuật số tốt nhất thế giới. IPO này sẽ phát hành 36.937.080 cổ phiếu phổ thông loại A, với giá 33,00 đô la Mỹ mỗi cổ phiếu.

Cổ phiếu dự kiến sẽ bắt đầu giao dịch trên Sở giao dịch chứng khoán New York vào ngày 31 tháng 7 năm 2025 và dự kiến sẽ hoàn tất việc phát hành vào ngày 1 tháng 8 năm 2025, tùy thuộc vào việc đáp ứng các điều kiện bàn giao thông thường. Đợt phát hành này bao gồm 12.472.657 cổ phiếu phổ thông loại A do Figma cung cấp và 24.464.423 cổ phiếu phổ thông loại A do các cổ đông hiện hữu của Figma cung cấp. Ngoài ra, một số cổ đông bán cổ phần đã cấp cho các nhà bảo lãnh phát hành quyền chọn trong 30 ngày để mua thêm 5.540.561 cổ phiếu phổ thông loại A với giá IPO trừ đi chiết khấu và hoa hồng bảo lãnh phát hành để trang trải việc phân bổ vượt mức. Figma sẽ không nhận được bất kỳ khoản tiền nào từ việc bán cổ phần của các cổ đông bán cổ phần.

Morgan Stanley, Goldman Sachs & Co. LLC, Allen & Company LLC và J.P. Morgan là các nhà bảo lãnh phát hành chính liên kết cho đợt phát hành này. BofA Securities, Wells Fargo Securities và RBC Capital Markets là các nhà bảo lãnh phát hành cho đợt phát hành này. William Blair và Wolfe | Nomura Alliance là các đồng quản lý cho đợt phát hành này. Tuyên bố đăng ký liên quan đến các chứng khoán này đã được Ủy ban Chứng khoán và Giao dịch Hoa Kỳ tuyên bố có hiệu lực vào ngày 30 tháng 7 năm 2025. Đợt phát hành này chỉ được thực hiện thông qua bản cáo bạch. Bản sao của bản cáo bạch cuối cùng có thể được lấy từ Morgan Stanley, Goldman Sachs & Co. LLC, Allen & Company LLC và J.P. Morgan Securities.

Thông cáo báo chí này không cấu thành một lời chào bán hoặc lời mời chào mua, cũng như không có bất kỳ việc bán chứng khoán nào ở bất kỳ tiểu bang hoặc khu vực pháp lý nào mà việc chào bán, mời chào hoặc bán đó sẽ là bất hợp pháp trước khi đăng ký hoặc đủ điều kiện theo luật chứng khoán của tiểu bang hoặc khu vực pháp lý đó.

Figma được thành lập vào năm 2012, đã phát triển từ một công cụ thiết kế thành một nền tảng kết nối, được hỗ trợ bởi AI, giúp các nhóm từ ý tưởng đến khi giao sản phẩm. Cho dù là lên ý tưởng, thiết kế, xây dựng hay giao hàng, Figma giúp toàn bộ quá trình thiết kế và phát triển sản phẩm trở nên hợp tác, hiệu quả và thú vị hơn, đồng thời đảm bảo mọi người đều có chung quan điểm.

---


### HN | Độ nóng: 322 điểm | 226 bình luận | Tác giả: nevir

[https://news.ycombinator.com/item?id=44740222](https://news.ycombinator.com/item?id=44740222)

- Figma, với tư cách là một công cụ, đã trở nên phổ biến rộng rãi nhờ việc sử dụng ứng dụng web thay vì ứng dụng desktop nặng nề ngay từ đầu, giúp dễ dàng chia sẻ thiết kế và cộng tác.
- Sự thành công của Figma chứng minh rằng những người không am hiểu về kỹ thuật không quan tâm liệu đó có phải là ứng dụng native hay tệp được lưu trữ trên đám mây hay không, miễn là ứng dụng web được thực hiện tốt, chẳng hạn như Google Docs.
- Cơ chế lan truyền nhanh chóng của Figma là điều mà các sản phẩm của Adobe không thể đạt được, vì Figma cho phép nhiều người chỉnh sửa và xem trước tài liệu theo thời gian thực.
- Tính nhanh chóng và khả năng phản hồi của Figma khiến nó hoạt động tốt hơn Adobe Photoshop, Illustrator, v.v., thể hiện tốt hơn các đặc điểm của phần mềm native.
- Tính độc đáo của lĩnh vực thiết kế nằm ở chỗ nhà thiết kế không tạo ra tài sản cuối cùng, mà là tạo ra bản thiết kế tài sản cần người khác xây dựng, điều này thúc đẩy sự chuyển đổi của các ứng dụng thiết kế từ ứng dụng native sang ứng dụng web.
- Sự đơn giản của Figma khiến nó trở thành một công cụ chung mà cả người dùng không chuyên và nhà thiết kế đều có thể sử dụng, đây là điểm độc đáo của nó.
- Nhiều loại công việc không yêu cầu tài sản lớn, nhưng những lĩnh vực này không có các ứng dụng web phổ biến như Figma, có thể là do cơ hội thị trường chưa xuất hiện hoặc những đột phá về công nghệ chưa đến.
- Sự chú trọng của Figma vào khả năng phản hồi và tốc độ khung hình giúp nó có hiệu suất cao ngay cả khi là công nghệ web.
- Figma giảm thời gian tải và cải thiện hiệu suất thông qua công nghệ WebAssembly.

---


## Tôi đã thử Servo

> I tried Servo

[https://www.spacebar.news/servo-undercover-web-browser-engine/](https://www.spacebar.news/servo-undercover-web-browser-engine/)

"Mọi thứ đều là Chrome trong tương lai" là một câu nói của SpongeBob trong một tập phim năm 1999, và hóa ra đó là một lời tiên tri về trình duyệt web. Google Chrome là trình duyệt phổ biến nhất trên thế giới và hầu hết các đối thủ cạnh tranh đều dựa trên cùng một mã Chromium: Microsoft Edge, Vivaldi, Opera, Brave và Arc, chỉ là một vài ví dụ. Các ngoại lệ chính là Safari và Firefox.

Vào đầu thiên niên kỷ, tình hình không phải vậy. Internet Explorer sử dụng engine Trident của riêng mình trên Windows, Tasman trên Mac, Opera sử dụng Presto, một số thiết bị nhúng sử dụng NetFront, Netscape sở hữu Gecko và KDE tạo KHTML cho trình duyệt Konqueror. Những trình duyệt này cuối cùng đã biến mất hoặc áp dụng các engine cạnh tranh để đơn giản hóa việc phát triển. KHTML là cơ sở của WebKit của Safari, đến lượt nó trở thành engine Blink của Chromium, và engine Gecko của Netscape trở thành cơ sở của Firefox. Opera đã từ bỏ engine Presto tùy chỉnh của mình vào năm 2013 để chuyển sang Chromium, và Microsoft Edge cũng thực hiện động thái tương tự vào năm 2020. Điều này gây ra nhiều mối đe dọa cho web mở. Nếu chỉ có một triển khai chức năng tiêu chuẩn, thì việc triển khai sẽ trở thành tiêu chuẩn. Web đối với Google giống như Java đối với Oracle. Điều này cũng có nghĩa là các hạn chế và lỗ hổng bảo mật của Chromium ảnh hưởng đến hầu hết các trình duyệt khác, điều này đã trở thành một chủ đề trong quá trình chuyển đổi Manifest V3 gần đây của Google.

May mắn thay, có một engine trình duyệt thay thế, một ngày nào đó có thể khiến Chrome, Safari và Firefox cảm thấy áp lực cạnh tranh, và bạn có thể chưa từng nghe nói về nó. Nó được gọi là Servo.

Mục tiêu của Servo là tạo ra một engine kết xuất web hoàn toàn bằng ngôn ngữ lập trình Rust, một ngôn ngữ được xây dựng xung quanh các hoạt động đa luồng và an toàn bộ nhớ. Phần đầu tiên rất quan trọng, vì các CPU hiện đại được thiết kế để phân phối công việc trên nhiều lõi hoặc luồng. Bạn càng chuyển nhiều mã kết xuất sang các hoạt động song song, bạn càng đạt được hiệu suất nhanh hơn. Phần thứ hai rất quan trọng vì nó làm giảm khả năng xảy ra các lỗ hổng bảo mật - các nhà phát triển Chromium đã từng nói rằng "khoảng 70% các lỗ hổng bảo mật nghiêm trọng của chúng tôi là các vấn đề về an toàn bộ nhớ". Servo cũng độc đáo ở một số khía cạnh khác. Nó được quản lý bởi Linux Foundation Europe và các quyết định được đưa ra bởi một ủy ban chỉ đạo kỹ thuật, thay vì một công ty công nghệ lớn. Một mục tiêu chính là trở thành một "engine kết xuất web có thể nhúng", có nghĩa là nó không chỉ dành cho trình duyệt - nó có thể thay thế Electron hoặc Android WebView. Servo cũng là engine trình duyệt hoàn toàn mới đầu tiên sau nhiều thập kỷ, vì vậy nó rút ra được những bài học kinh nghiệm từ các trình duyệt chính thống trong khi xây dựng một nền tảng mới.

Hiện tại không có trình duyệt web đầy đủ tính năng nào sử dụng Servo, nhưng bạn có thể thử các bản dựng hàng đêm cho Windows, macOS, Android và Linux. Các bản dựng này chỉ là engine với giao diện trình duyệt web cơ bản. Không có đồng bộ hóa dữ liệu, dấu trang, tiện ích mở rộng hoặc bất cứ thứ gì khác. Hầu hết các trang web đều có ít nhất một số lỗi kết xuất và một số thì hoàn toàn bị hỏng. Kết quả tìm kiếm của Google có nhiều yếu tố chồng chéo và trang chủ MacRumors bị sập sau khi cuộn. Các trang web như Wikipedia, CNN Lite, trang web cá nhân của tôi và NPR chỉ có văn bản hoạt động tốt.

Trang web Servo cũng có một số trang demo hiển thị khả năng đồ họa của engine. Bài kiểm tra Dogemania chạy mượt mà với tốc độ 60 FPS trên MacBook Pro M4 Pro của tôi cho đến khi đạt khoảng 400 hình ảnh, trong khi bài kiểm tra vật lý hạt trung bình khoảng 55 FPS. Trên cùng một máy tính, Safari 18.5 có thể xử lý hơn 1500 hình ảnh trên Dogemania và gần như 60 FPS trên vật lý hạt. Vì chưa có bản dựng ARM trên macOS, Servo chạy dưới dạng mô phỏng x86, vì vậy đây không phải là một cuộc cạnh tranh hoàn toàn công bằng về hiệu suất. Tôi cũng đã thử bài kiểm tra Acid3 cổ điển, được tạo vào năm 2008 để kiểm tra các tiêu chuẩn trình duyệt web khác nhau - Internet Explorer đã không đạt điểm cho đến khi bản dựng IE 9 beta vào cuối năm 2010 đẩy điểm số lên 95/100. Hầu hết các trình duyệt hiện đại đều đạt khoảng 95 điểm vì một số yếu tố của bài kiểm tra hiện đã bị hỏng, nhưng Servo tụt lại một chút với 83/100. Servo còn một chặng đường dài phía trước để duyệt web chung, nhưng tôi rất ấn tượng với nó. Lộ trình hiện tại liệt kê Shadow DOM và CSS Grid là các ưu tiên, điều này sẽ khắc phục các vấn đề kết xuất trên nhiều trang web phổ biến, cùng với các cải tiến khác.

Tình tiết bất ngờ ở đây là: Servo ban đầu là một dự án của Mozilla. Việc phát triển bắt đầu vào năm 2012 và Samsung tham gia vào năm 2013. Kế hoạch là phát triển một trình duyệt dựa trên Android hoặc các ứng dụng khác xung quanh Servo, và một khi công nghệ được chứng minh và ổn định, nó có thể thay thế engine Gecko mà Firefox đã sử dụng từ lâu. Mozilla sau đó quyết định thay thế các phần của Gecko bằng mã Servo, thay vì chờ toàn bộ engine trở thành một sự thay thế trực tiếp. Một bài đăng trên blog năm 2017 mô tả nó là "thay thế động cơ phản lực trong khi máy bay vẫn đang bay". Thành phần chính đầu tiên được thay thế trong Firefox là engine CSS, cuối cùng được ra mắt với bản phát hành Firefox 57. Mozilla đặt biệt danh cho bản cập nhật là Firefox Quantum và các bài kiểm tra điểm chuẩn cho thấy trình duyệt nhanh hơn đáng kể và sử dụng ít RAM hơn. Kế hoạch thay thế dần mã Gecko của Firefox dường như đang tiến triển tốt cho đến khi Mozilla sa thải 250 nhân viên vào năm 2020, bao gồm nhiều nhà phát triển chịu trách nhiệm phát triển Servo. Việc Mozilla vứt bỏ tương lai công nghệ của Firefox, chưa kể đến những công nhân bị ảnh hưởng bởi việc sa thải, vẫn khiến tôi bối rối. Năm năm sau, các dự án phụ của Mozilla vẫn chưa thành công và công ty đã thực hiện thêm nhiều đợt sa thải. Dự án Servo đã được tái tổ chức tại Linux Foundation vào tháng 11 năm đó, và sau đó vào năm 2023, nó đã nhận được sự hỗ trợ mới từ Igalia và các tổ chức khác, đồng thời chuyển sang Linux Foundation Europe. Servo đã có cơ hội sống thứ hai và việc phát triển khá tích cực.

Bộ Tư pháp Hoa Kỳ hiện đang kết thúc vụ kiện pháp lý chống lại Google, cáo buộc Google duy trì sự độc quyền công cụ tìm kiếm thông qua sự phổ biến của Chrome và Android. Google đã thua kiện tại tòa án và Bộ Tư pháp muốn Google bán trình duyệt Chrome và ngừng các thỏa thuận công cụ tìm kiếm với các trình duyệt khác. Mozilla đã yêu cầu thẩm phán trong vụ án này không chấm dứt các thỏa thuận này, vì vị trí công cụ tìm kiếm mặc định của Google trong Firefox là phần lớn doanh thu của Mozilla. Công ty cho biết họ có thể phải "thu hẹp hoạt động và cắt giảm hỗ trợ cho các dự án quan trọng như Gecko, engine trình duyệt duy nhất cạnh tranh với Chromium của Google và WebKit của Apple".

Bây giờ là thời gian cho lý thuyết trò chơi. Giả sử Mozilla mất tấm séc của Google và Firefox chuyển sang WebKit hoặc Chromium/Blink để tiết kiệm chi phí phát triển. Tôi chắc chắn rằng ai đó sẽ cố gắng phân nhánh Firefox dựa trên Gecko và duy trì hoạt động của nó bên ngoài Mozilla - có thể là Linux Foundation, có thể là ai đó khác. Nếu engine Gecko thuộc sở hữu của cộng đồng giống như Servo, có lẽ có thể khôi phục kế hoạch ban đầu là từ từ biến Gecko thành Servo. Hoặc, Gecko có thể chỉ biến mất. WebKit đã được thiết lập trong hệ sinh thái Linux và công chúng có thể tiếp tục sử dụng Chrome và Safari. Mặc dù vậy, việc suy nghĩ về những khả năng này vẫn rất thú vị. Bất kể điều gì xảy ra với Firefox hoặc Gecko, tôi rất hào hứng với những gì tiếp theo cho Servo.

---


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

[https://news.ycombinator.com/item?id=44744324](https://news.ycombinator.com/item?id=44744324)

- Dự án Servo đang thúc đẩy hỗ trợ CSS Grid, đặc biệt là các đường lưới và vùng được đặt tên, để cải thiện bố cục trang web
- Thư viện Taffy được sử dụng rộng rãi trong hệ sinh thái Rust UI, bao gồm các dự án như Blitz, Zed và Bevy, góp phần vào việc mô-đun hóa và sử dụng độc lập
- Blitz là một engine Web mới hơn và ít được biết đến hơn, được thiết kế để linh hoạt và có thể tùy chỉnh, để phù hợp với các trường hợp sử dụng khác nhau
- Dự án tìm kiếm nhiều người đóng góp hơn, có thể tham gia thông qua GitHub và Discord
- Hỗ trợ mạng của Blitz là một lớp trừu tượng, cho phép người dùng tùy chỉnh triển khai, đồng thời cung cấp các tùy chọn mặc định
- Dự án cần hỗ trợ mạng để kiểm tra và tạo sự thuận tiện cho người dùng, mặc định sử dụng thư viện reqwest để xử lý HTTP, cookies và mã hóa biểu mẫu
- Có người bày tỏ sự đánh giá cao và ủng hộ Blitz, cho rằng đây là một lựa chọn quan trọng để chống lại tình trạng độc quyền song phương của trình duyệt hiện tại
- Có người bày tỏ sự nghi ngờ về hiệu suất và hiệu quả phát triển của bộ công cụ Rust UX, cho rằng các framework JavaScript tuy dễ phát triển và tuyển dụng, nhưng hiệu suất và mức tiêu thụ tài nguyên kém
- Có người đề xuất sử dụng bộ công cụ immediate mode, như Blender hoặc Reaper, để có hiệu suất tốt hơn và các điều khiển gốc
- Có người đề cập đến các bộ công cụ Rust UX như Egui và Iced, nhưng cho rằng chúng có thể không phù hợp để xây dựng các ứng dụng phức tạp hoặc chuyên sâu về đồ họa
- Có người cho rằng, việc đồng thời đạt được hiệu suất cao và trải nghiệm phát triển tốt trên các nền tảng khác nhau là gần như không thể, đặc biệt là khi sử dụng các ngôn ngữ không phổ biến

---


## Nhiều quốc gia từng nói không với ChatControl vào năm 2024 hiện đang do dự

> Many countries that said no to ChatControl in 2024 are now undecided

[https://digitalcourage.social/@echo\_pbreyer/114946559233051667](https://digitalcourage.social/@echo_pbreyer/114946559233051667)

digitalcourage.social là một trong số nhiều máy chủ Mastodon độc lập, người dùng có thể thông qua đó tham gia fediverse. Phiên bản này do Digitalcourage e.V. vận hành cho công chúng. Để vận hành bền vững, họ thu phí thường niên 1 Euro/tháng, thanh toán thông qua hình thức ghi nợ trực tiếp SEPA.

Quản trị viên là Digitalcourage @digitalcourage. Thống kê máy chủ cho thấy có 815 người dùng hoạt động. digitalcourage.social cung cấp các trang về, trạng thái, thư mục người dùng, chính sách bảo mật, v.v. Mastodon cung cấp thông tin về, tải ứng dụng, phím tắt, xem mã nguồn, phiên bản hiện tại là v4.4.2.

Patrick Breyer @echo\_pbreyer đăng tin trên Mastodon, đề cập đến việc nhiều quốc gia phản đối #ChatControl (Kiểm soát trò chuyện) vào năm 2024 hiện đang do dự, mặc dù kế hoạch năm 2025 còn cực đoan hơn. Cuộc bỏ phiếu sẽ diễn ra vào tháng 10, ông kêu gọi mọi người nói với chính phủ #StopChatControl (Dừng kiểm soát trò chuyện). Ông cung cấp một liên kết hành động: https://chatcontrol.eu.

Sarah @xgebi hỏi liệu có biết ngày cụ thể trong tháng 10 không, vì ngày 3 và 4 tháng 10, Cộng hòa Séc sẽ tổ chức bầu cử quốc hội, tình hình có thể thay đổi.

Gonçalo Valério @dethos bày tỏ sự tiếc nuối khi thấy chính phủ nước ông tiếp tục ủng hộ hành vi điên rồ này, ngay cả trong quá trình chuyển giao quyền lực. Ông cho rằng, nhìn chung, giới chính trị không hiểu đầy đủ về tác động của vấn đề này, họ dường như chỉ dựa vào những ý định được tuyên bố, không ai tỏ ra quan tâm đến chủ đề này.

Kierkegaanks @Kierkegaanks cho biết, ông phải nói rằng trang đó là một cơn ác mộng truyền thông.

Peter Motte @PeterMotte hỏi ChatControl cụ thể có nghĩa là gì.

Norbert @norberteder cho biết Chat Control cũng có kế hoạch ở Áo.

Raphael Albert @r\_alb hỏi liệu Áo vẫn phản đối hoặc ít nhất là giữ thái độ trung lập không, vì chính phủ Áo dường như rất ủng hộ việc giám sát.

\*Dark and and Stormy @darkandandstormy chỉ ra rằng Áo chưa bao giờ thực sự phản đối bản thân việc kiểm soát trò chuyện, mà là phản đối việc Ursula #vonderLeyen chịu trách nhiệm về việc này. Bộ trưởng Nội vụ Karner, với tư cách là người hâm mộ lớn nhất của Engelbert Dollfuß, có ý kiến về quyền lực của Đức. Do đó, ông trở thành người ủng hộ mạnh mẽ #Chatcontrol Made In #Austria, hy vọng rằng ông sẽ chịu trách nhiệm. Vì ÖVP màu xanh lá cây vẫn đang nắm quyền, ảnh hưởng của Sebastian #Kurz và Peter #Thiel sẽ luôn tồn tại, quốc gia giám sát sẽ tăng trưởng.

Al Ovchin @alovchin91 cho biết, với tư cách là công dân Hà Lan, anh cảm thấy tự hào, nhưng anh vẫn sẽ gửi thêm một email để nhắc nhở lý do tại sao chúng ta vẫn nên phản đối nó.

fuomag9 @fuomag9 cho biết ở Ý, có một chính phủ bao gồm những người theo chủ nghĩa phát xít, họ không may thích kế hoạch này.

hex\_06 @ex\_06 cho biết, nếu tôi nhớ không nhầm, các cuộc bầu cử ở châu Âu có một chút khác biệt, và có nhiều sự chia rẽ giữa các nhóm vận động hành lang hơn là phản ứng thực sự đối với chính phủ. Dù sao đi nữa, tốt hơn hết là nên viết thư cho đại diện.

vrtxd @vrtxd cho biết anh bị mù màu, bản đồ không có ý nghĩa gì với anh.

Samir @thesdev cung cấp văn bản thay thế.

Nick @nick đề xuất rằng, văn bản thay thế đi kèm sẽ có thể giải quyết vấn đề, nếu không hãy kiểm tra cài đặt/bộ lọc hệ điều hành/trình duyệt hoặc những thứ tương tự để thích ứng với khuyết tật của bạn.

Tom DB @TomDB cho biết anh cũng gặp vấn đề tương tự, không chỉ vì mù màu.

elexia @vrtxd chỉ ra rằng, thực tế chỉ có Hà Lan, Ba Lan và Áo phản đối/trung lập.

Chris Reinbothe @phneutral xác nhận NL, AT và PL phản đối/trung lập.

Rens @RensBloom cảm ơn vì đã cung cấp thông tin, trước đây anh hoàn toàn không thấy những nội dung này.

---


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

[https://news.ycombinator.com/item?id=44744715](https://news.ycombinator.com/item?id=44744715)

- Hành động cá nhân phản đối ChatControl gặp nhiều khó khăn, khó chống lại vận động hành lang có tổ chức.
- Trong quá trình lập pháp, tình huống 1 triệu người mỗi người mất 1 đô la, 100 người mỗi người thu lợi 100 nghìn đô la là rất phổ biến, người dân bình thường khó phản đối.
- Nỗ lực đơn giản hóa quy trình khai thuế ở Mỹ luôn thất bại.
- Trực tiếp bày tỏ ý kiến với nhà lập pháp là điều lành mạnh, nhưng hoạt động vận động hành lang có tổ chức khiến người dân khó chống lại.
- Về lý thuyết, các nhà lập pháp nên đại diện cho cử tri, nhưng trên thực tế, các hoạt động vận động hành lang có thể ảnh hưởng đến quyết định của họ.
- Hạn chế vận động hành lang và quyên góp tranh cử có thể giúp giảm ảnh hưởng của tiền bạc đối với chính trị.
- Cấm hoàn toàn vận động hành lang có thể dẫn đến chủ nghĩa toàn trị, ảnh hưởng của tư bản sẽ không chảy về phía người dân mà chảy về phía chính phủ.
- Giao tiếp với nhà lập pháp không phải là vận động hành lang, vận động hành lang là việc các nhóm lợi ích đặc biệt tài trợ cho người tiếp xúc với nhà lập pháp.
- Dân chủ trực tiếp là tốt, mỗi người một phiếu bầu cho tất cả các luật có thể hiệu quả.
- Mọi người khó có thể hiểu hết tất cả các vấn đề, dễ bị ảnh hưởng bởi giới truyền thông, dân chủ trực tiếp có thể dẫn đến các giải pháp nghe có vẻ hợp lý.

---


## MacBook Pro Mất Ngủ

> MacBook Pro Insomnia

[https://manuel.bernhardt.io/posts/2025-07-24-macbook-pro-insomnia](https://manuel.bernhardt.io/posts/2025-07-24-macbook-pro-insomnia)

Bài viết này kể về việc chiếc MacBook Pro Silicon M1 Max của tác giả sau vài năm sử dụng đã gặp phải vấn đề pin nhanh chóng cạn kiệt vào ban đêm khi không cắm nguồn. Để giải quyết vấn đề này, tác giả đã bắt đầu nghiên cứu.

Trong hệ thống MacOS, có thể xem nhật ký liên quan đến quản lý nguồn thông qua lệnh terminal `pmset -g log`. Thông tin nhật ký này rất chi tiết, nhưng không dễ đọc, vì vậy tác giả đã viết một chương trình nhỏ để phân tích nhật ký. Mặc dù công cụ này chỉ cung cấp trợ giúp hạn chế, tác giả vẫn cố gắng điều chỉnh một số cài đặt, chẳng hạn như `tcpkeepalive`, nhưng hiệu quả không đáng kể.

Một cuộc điều tra sâu hơn đã giúp tác giả biết đến công cụ Sleep Aid, nó có thể hiển thị các sự kiện đánh thức một cách trực quan hơn và có giao diện đơn giản để thay đổi cài đặt. Trong trường hợp của tác giả, tùy chọn "Wake for maintenance" đã bị tắt, Sleep Aid trong giao diện cài đặt cho biết điều này có thể dẫn đến các sự kiện đánh thức thường xuyên. Sau khi bật lại cài đặt này, MacBook Pro của tác giả không còn nhanh chóng cạn kiệt pin vào ban đêm khi không cắm điện.

Bài viết cũng đề cập đến các nội dung liên quan như phần cứng, macos, và đề cập đến một số hoạt động khác của tác giả, chẳng hạn như lặn biển.

---


### HN | Độ nóng: 294 điểm | 156 bình luận | Tác giả: speckx

[https://news.ycombinator.com/item?id=44745897](https://news.ycombinator.com/item?id=44745897)

- Một số ứng dụng sẽ ngăn macOS chuyển sang trạng thái ngủ, chẳng hạn như Devonthink, người dùng hy vọng Apple có thể đưa ra các cảnh báo liên quan.
- Quản lý năng lượng của Apple nên cảnh báo về các ứng dụng ngăn chặn chế độ ngủ, đặc biệt khi ứng dụng gây ra tình trạng quá nhiệt hoặc cạn kiệt pin.
- Một số người dùng cần máy tính tiếp tục chạy khi đóng nắp máy tính xách tay, các ứng dụng như Amphetamine có thể cung cấp chức năng này.
- Ở cấp độ phần cứng, Apple sẽ tắt micrô khi đóng nắp, do đó cần phải sử dụng micrô ngoài.
- Một số người dùng giữ nắp đóng khi kết nối Mac với màn hình và bàn phím ngoài.
- Người dùng muốn có thể chọn có cho phép ứng dụng ngăn chặn chế độ ngủ hay không, thay vì mặc định cho phép.
- Một số người dùng khuyên nên sử dụng ứng dụng Amphetamine để kiểm soát những ứng dụng nào có thể chạy ở chế độ ngủ.
- Một số người dùng cho rằng hành vi ứng dụng ngăn chặn chế độ ngủ nên cần sự kiểm soát quyền rõ ràng của người dùng.
- Người dùng phát hiện ra rằng trong tab Energy của Safari có thể xem các tiến trình con ngăn chặn chế độ ngủ, bao gồm cả các tab cụ thể.
- Một số người dùng cho rằng hành vi ứng dụng ngăn chặn chế độ ngủ nên minh bạch hơn và người dùng nên có quyền kiểm soát.

---


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

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

---


### Vibe code is legacy code

---


[https://news.ycombinator.com/item?id=44740554](https://news.ycombinator.com/item?id=44740554)

Tôi sẽ không mặc định cho rằng đó là đối thủ cạnh tranh của anh ta, điều đó nghe giống như đổ lỗi để trốn tránh trách nhiệm. Điều có khả năng nhất là trang web của anh ta đã bị quét bởi một trong những trình thu thập thông tin khai thác ngày càng tinh vi (bất kỳ ai điều hành một trang web hướng ra Internet và có thể xem lưu lượng truy cập đều biết tôi đang nói về điều gì). Trang web của anh ta bị gắn cờ là dễ bị tấn công, hacker phát hiện ra nó được xây dựng như pho mát Thụy Sĩ và đã vui vẻ với nó.

WD-42

Tôi sẽ không vội vàng cho rằng đó là do đối thủ cạnh tranh của anh ta gây ra, nghe có vẻ như là tìm dê tế thần để trốn tránh trách nhiệm. Rất có thể là trang web của anh ta đã bị quét bởi một trong những trình thu thập thông tin khai thác lỗ hổng ngày càng tinh vi (bất kỳ ai vận hành một trang web kết nối Internet và có thể xem lưu lượng truy cập đều hiểu tôi đang nói về điều gì). Trang web của anh ta bị đánh dấu là có lỗ hổng, hacker phát hiện ra nó đầy rẫy lỗ hổng và đã thỏa sức khai thác.

---


### Ứng dụng xác minh độ tuổi của EU cấm mọi hệ thống Android …


[https://news.ycombinator.com/item?id=44706081](https://news.ycombinator.com/item?id=44706081)

"Kiểm tra bảo mật thiết bị" là khía cạnh đáng sợ nhất vì về cơ bản nó có nghĩa là "phần cứng và phần mềm được phê duyệt chính thức", và dẫn thẳng đến chế độ phản địa đàng mà Stallman đã cảnh báo chúng ta trong Quyền được đọc.

Có một sự trớ trêu thú vị khi EU dựa vào Mỹ để thúc đẩy chủ nghĩa độc tài của chính mình. Thật không may là tự do (theo nghĩa nổi loạn, kiểu Mỹ cổ điển) chưa bao giờ trở nên phổ biến ở EU, hoặc ở Anh.

"Kiểm tra an ninh thiết bị" là khía cạnh đáng sợ nhất, bởi vì về cơ bản nó có nghĩa là "phần cứng và phần mềm được phê duyệt chính thức", và điều này trực tiếp dẫn chúng ta đến kiểu phản địa đàng mà Stallman đã cảnh báo trong bài viết "Quyền được đọc".

Việc EU phải dựa vào Mỹ để thúc đẩy chủ nghĩa độc tài của mình thật là một điều trớ trêu. Đáng tiếc là ý tưởng tự do kiểu Mỹ cổ điển, nổi loạn, chưa bao giờ thực sự phổ biến ở EU hay thậm chí là ở Anh.

---


### Giấc ngủ suy cho cùng đều phụ thuộc vào ty thể


[https://news.ycombinator.com/item?id=44732539](https://news.ycombinator.com/item?id=44732539)

> Vậy là bí ẩn cổ xưa về lý do tại sao chúng ta cần ngủ có lẽ vừa được giải đáp.
> 
> 

Tôi sẽ rất ngạc nhiên nếu giấc ngủ chỉ phục vụ một mục đích duy nhất. Trong các hệ thống phức tạp, liên kết với nhau, bạn thường không đi được xa với những giải thích đơn nhân quả.

kbrkbr

Vậy thì bí ẩn cổ xưa về việc tại sao chúng ta cần ngủ, giờ đây có lẽ đã có câu trả lời. Nếu giấc ngủ chỉ phục vụ cho một mục đích duy nhất, tôi chắc chắn sẽ rất ngạc nhiên. Trong các hệ thống phức tạp, liên kết với nhau, những giải thích đơn nhân quả thường không hiệu quả.

---


### Không tải ứng dụng, hãy sử dụng trang web


[https://news.ycombinator.com/item?id=44690092](https://news.ycombinator.com/item?id=44690092)

Tôi hoàn toàn đồng ý và đây luôn là một điều khiến tôi khó chịu.

Hầu hết các ứng dụng native đều có dung lượng khoảng nửa gig, trong khi ngay cả những trang web nặng nhất cũng chỉ vài mb. Chúng không cho phép bạn tô sáng văn bản và có những lựa chọn thiết kế kỳ quặc khác. Tệ hơn nữa, chúng yêu cầu nhập danh bạ, điều này thậm chí không phải là một tùy chọn trên web.

Ứng dụng native có thể mượt mà như bơ, nhưng thường thì chúng giống như bơ thực vật hơn. Mượt, nhờn và không tốt cho bạn.

Tôi hoàn toàn đồng ý, và đây luôn là một nỗi ám ảnh lớn của tôi.

Hầu hết các ứng dụng native đều có dung lượng nửa Gigabyte, ngay cả những trang web nặng nề nhất cũng chỉ vài Megabyte. Chúng không cho phép chọn văn bản, và có những lựa chọn thiết kế vô lý khác. Tệ hơn nữa, chúng yêu cầu bạn nhập danh bạ, nhưng trên web lại không có tùy chọn này.

Ứng dụng native lẽ ra có thể mượt mà như bơ, nhưng thường thì chúng giống như bơ nhân tạo hơn. Mượt mà, nhờn dính, và không tốt cho sức khỏe.

---


### "Tôi đã chứng kiến tội ác chiến tranh" ở Gaza - cựu nhân viên...

---


[https://news.ycombinator.com/item?id=44715162](https://news.ycombinator.com/item?id=44715162)

Có ai còn cần những lời chứng thực như thế này để tin rằng Israel đang hệ thống tiêu diệt người Palestine bằng vũ lực và bỏ đói không? Chúng ta đã vượt qua giai đoạn đó rồi. Biến Gaza thành nơi không thể sống được bằng cách ném bom rải thảm, báo trước các vụ giết người hàng loạt bằng những tuyên bố rõ ràng ở cấp cao nhất của chính phủ, phi nhân tính hóa người Palestine và bịt miệng bất kỳ ai dám lên tiếng?

Về phần tôi, tôi rất biết ơn vì điều này chưa bị gỡ xuống như bất kỳ bài viết nào dù chỉ trích Israel từ xa.

Và điều này đã loại bỏ hoàn toàn những lời lẽ vớ vẩn của phương Tây về chủ nghĩa tối đa nhân quyền - lúc nào cũng chỉ là một trò hề. Giống như những hành động tàn bạo ở Nhà nước Tự do Congo, Cuộc tranh giành châu Phi, v.v., phương Tây sẽ tài trợ cho những hành động tàn bạo không thể diễn tả được ở nước ngoài và sau đó lại tỏ ra sốc khi chúng thực sự xảy ra.

Nhiều người ở phương Tây không nhận ra điều đó, nhưng Palestine sẽ gây ra thiệt hại nghiêm trọng cho phương Tây. Giống như việc Gorbachev đến thăm một cửa hàng ngẫu nhiên ở Mỹ và nhìn thấy sự phong phú điên cuồng trong một cửa hàng ở một nơi khỉ ho cò gáy trong khi công dân Liên Xô chết đói, điều giết chết Liên Xô là sự vỡ mộng; mọi người ở mọi cấp độ đều nhận ra rằng một hệ thống không thể cung cấp cho người dân những điều cơ bản thì không xứng đáng tồn tại.

Đó là những gì đang xảy ra ở phương Tây: Các cựu chiến binh GWOT (Chiến tranh toàn cầu chống khủng bố) của Mỹ vẫn cảm thấy vỡ mộng về những gì họ đã đến làm ở Iraq & Afghanistan (và Việt Nam, trước đó), và giờ đây con cái của họ đang nghiêm túc hỏi, "Chúng ta có phải là kẻ xấu không?"

Mục đích của năng lực công nghiệp và sự giàu có này là gì nếu tất cả những gì chúng ta làm với nó là ném bom trẻ em? Không có hệ thống chính trị nào có thể sống sót sau sự vỡ mộng, đó là thời điểm mà mọi người trên toàn bộ hệ tư tưởng bắt đầu coi quốc gia của họ là đạo đức giả.

Liệu có ai còn cần những lời chứng thực như vậy để tin chắc rằng Israel đang sử dụng vũ lực quân sự và nạn đói để tiêu diệt người Palestine một cách có hệ thống không? Chúng ta đã vượt qua giai đoạn đó từ lâu rồi. Biến dải Gaza thành nơi không thể ở được bằng cách ném bom rải thảm, đưa ra những tuyên bố rõ ràng về việc báo trước các vụ thảm sát ở cấp cao nhất của chính phủ, phi nhân tính hóa người Palestine và đàn áp bất kỳ ai dám lên tiếng?

Về phần cá nhân tôi, tôi rất vui vì điều này không bị xóa, xét cho cùng, bất kỳ bài viết nào dù chỉ trích Israel một chút cũng có thể bị gỡ xuống.

Điều này đã chấm dứt hoàn toàn những lời vô nghĩa của phương Tây về chủ nghĩa tối đa nhân quyền - lần nào cũng là một chiêu trò chết tiệt. Giống như những hành động tàn bạo ở Nhà nước Tự do Congo, thời kỳ tranh giành châu Phi, v.v., phương Tây sẽ tài trợ cho những hành động tàn bạo không thể diễn tả được ở nước ngoài, và sau đó lại giả vờ sốc khi chúng thực sự xảy ra.

Nhiều người phương Tây không nhận ra điều đó, nhưng vấn đề Palestine sẽ gây ra thiệt hại nghiêm trọng cho phương Tây. Giống như việc Gorbachev đến thăm một cửa hàng bình thường ở Hoa Kỳ và nhìn thấy sự phong phú đáng kinh ngạc của hàng hóa trong một cửa hàng ở vùng hoang dã, trong khi công dân Liên Xô đang chết đói, điều cuối cùng đã giết chết Liên Xô là sự vỡ mộng - mọi người ở mọi cấp độ đều nhận ra rằng một hệ thống xã hội không thể cung cấp những nhu yếu phẩm cơ bản cho người dân thì không xứng đáng tồn tại.

Tình hình tương tự đang xảy ra ở phương Tây: Các cựu chiến binh trong cuộc chiến chống khủng bố toàn cầu của Mỹ vẫn cảm thấy vỡ mộng về những gì họ đã làm ở Iraq và Afghanistan (và Việt Nam trước đó), và giờ đây con cái của họ đang nghiêm túc hỏi: "Chúng ta có phải là kẻ xấu không?"

Nếu tất cả những gì chúng ta làm với năng lực công nghiệp và sự giàu có này là ném bom trẻ em, thì những thứ này có ý nghĩa gì? Không có hệ thống chính trị nào có thể chịu đựng được sự vỡ mộng, tức là thời điểm mà mọi người ở mọi tầng lớp bắt đầu coi quốc gia của mình là đạo đức giả.

---


### Giới hạn tỷ lệ hàng tuần của Claude Code


[https://news.ycombinator.com/item?id=44714494](https://news.ycombinator.com/item?id=44714494)

Có lẽ tôi sẽ không đạt đến giới hạn sử dụng hàng tuần, nhưng việc giới hạn được đặt theo tuần thay vì cứ mỗi 36 giờ hoặc gì đó khiến tôi hơi lo lắng. Nếu tôi thực sự đạt đến giới hạn, thì cả tuần đó tôi sẽ không thể sử dụng được — một khoảng thời gian dài không được sử dụng một công cụ mà tôi đã quen dùng!

Tôi cảm thấy sẽ có ai đó trả lời rằng tôi quá phụ thuộc vào Claude hay gì đó. Có lẽ đúng vậy, nhưng nếu tôi mất ripgrep trong một tuần, hoặc bất kỳ công cụ nào khác, tôi cũng sẽ cảm thấy như vậy. Mất nó trong vài ngày thì dễ chấp nhận hơn.

Ngoài ra, tôi thấy đáng chú ý là họ nói điều này sẽ ảnh hưởng đến "ít hơn 5% người dùng". Tôi đã quen với những thông báo kiểu này, thường thì họ sẽ nói là ảnh hưởng đến ít hơn 1%. Anthropic đang nói rằng cứ 20 người dùng thì sẽ có 1 người đạt đến giới hạn mới.

Wowfunhappy

---


### CEO của AMD dự đoán chip từ nhà máy của TSMC tại Mỹ sẽ đắt hơn 5%...


[https://news.ycombinator.com/item?id=44676704](https://news.ycombinator.com/item?id=44676704)

Nếu đó là cái giá phải trả để giữ giá trị trong các nền kinh tế phương Tây, chúng ta nên trả. Rõ ràng và đơn giản. Tôi thậm chí còn cho rằng nó rẻ.

---


### Visa và Mastercard đang bị choáng ngợp bởi gam…


[https://news.ycombinator.com/item?id=44713909](https://news.ycombinator.com/item?id=44713909)

Thật điên rồ khi chúng ta sống trong một thế giới mà có lẽ chỉ một vài chục người với những ý tưởng kỳ quặc về những điều "không nên được phép" có thể khiến các bộ xử lý thanh toán gây áp lực lên các cửa hàng để gỡ bỏ các tựa game. Đó là sự kiểm duyệt đối với những thứ mà cá nhân họ cảm thấy khó chịu. Đoán xem: không ai ép bạn phải chơi những trò chơi nghệ thuật kỳ lạ về chấn thương cả.

Rõ ràng, chúng ta phải tiếp tục gây áp lực lên các bộ xử lý thanh toán để đảo ngược tình thế, nhưng chúng ta cũng cần phải phản đối những người trong xã hội nghĩ rằng họ có thể quyết định những người trưởng thành khác được phép làm gì trong thời gian riêng của họ. Nếu mọi người IRL phản đối những ý tưởng kỳ quặc này ngay tại IRL thì chúng ta đã không rơi vào những điểm khủng hoảng như thế này.

Kapura
Chúng ta lại sống trong một thế giới mà chỉ cần vài chục người có những ý tưởng kỳ quặc về việc "cái gì không nên được phép" là có thể khiến các bộ xử lý thanh toán gây áp lực lên các cửa hàng để gỡ bỏ các tựa game. Đây là sự kiểm duyệt đối với những thứ mà cá nhân họ thấy không thích. Đoán xem: không ai ép bạn chơi những trò chơi nghệ thuật kỳ lạ về chấn thương cả.

Rõ ràng, chúng ta phải tiếp tục gây áp lực lên các bộ xử lý thanh toán để họ thay đổi đường lối, nhưng chúng ta cũng cần phải phản đối những người trong xã hội nghĩ rằng họ có thể quyết định những người trưởng thành khác được phép làm gì trong thời gian riêng của họ. Nếu mọi người trong đời thực phản đối những ý tưởng kỳ quặc này ngay trong đời thực, thì chúng ta đã không rơi vào những điểm khủng hoảng như thế này.

---


### Sự trở lại của loài sói ở Yellowstone đã dẫn đến sự gia tăng…


[https://news.ycombinator.com/item?id=44701025](https://news.ycombinator.com/item?id=44701025)

Thật đáng kinh ngạc về tác động mà việc tái du nhập đã mang lại. Trong một chuyến đi mùa đông gần đây, tôi cũng biết rằng việc tái du nhập thực sự đã làm thay đổi dòng chảy của các con sông [1]:

- Nai sừng tấm không còn lảng vảng dọc theo các con suối, vì vậy cây liễu và cây bông mọc lên nhanh chóng, neo giữ đất và thu hẹp các kênh.
- Sự phát triển của cây thân gỗ mới đã cung cấp gỗ cho hải ly; các đàn của chúng đã tăng vọt từ một đàn vào năm 1996 lên hàng chục đàn trong vòng mười lăm năm, nâng cao mực nước ngầm và tái tạo các vùng đất ngập nước.
- Với các vùng ven sông khỏe mạnh hơn, các vũng nước sâu hơn, nước lạnh hơn và sự gia tăng số lượng cá hồi bản địa và tổ chim hót.

[1] [https://phys.org/news/2025-02-predators-ecosystems-yellowstone-wolves-carnivores.html](https://phys.org/news/2025-02-predators-ecosystems-yellowstone-wolves-carnivores.html)

mkw5053

Tác động mà dự án tái du nhập mang lại thật đáng kinh ngạc. Trong chuyến du lịch mùa đông gần đây, tôi biết rằng dự án tái du nhập thực sự đã thay đổi dòng chảy của các con sông:

- Nai sừng tấm không còn quanh quẩn bên các dòng suối, cây liễu và cây dương bông nhờ đó mà phát triển mạnh mẽ, chúng cố định đất và thu hẹp lòng sông.
- Cây thân gỗ mới mọc cung cấp gỗ cho hải ly, số lượng đàn của chúng đã tăng vọt từ một đàn năm 1996 lên hơn chục đàn sau mười lăm năm, từ đó nâng cao mực nước ngầm và tái tạo vùng đất ngập nước.
- Với hệ sinh thái ven sông ngày càng tốt hơn, các vũng nước sâu hơn, nhiệt độ nước giảm và số lượng cá hồi bản địa và chim hót làm tổ cũng tăng vọt.

---


### Nhanh

---


[https://news.ycombinator.com/item?id=44739199](https://news.ycombinator.com/item?id=44739199)

Chỉ muốn nói tôi cảm ơn YCom rất nhiều vì đã không phá hỏng giao diện HN, và giữ cho nó nhanh.

Tôi nhớ rất rõ khi Slashdot tự sát. Họ có một giao diện rất dễ để tôi quét và tìm các bình luận có giá trị cao, và nhân danh "UI hiện đại" hoặc một số lý do vô nghĩa khác để giữ chân một vài nhà thiết kế, đã hoàn toàn tân trang lại nó để nó có rất nhiều khoảng trắng và về cơ bản khiến tôi không thể lướt qua các bình luận.

Tôi nghĩ tôi đã thử nó trong khoảng 3 ngày trước khi tôi bỏ cuộc, và trước đó tôi là một độc giả hàng ngày của Slashdot.

Tôi chỉ muốn bày tỏ lòng biết ơn sâu sắc đến Y Combinator vì đã không làm hỏng giao diện HN và vẫn giữ cho nó nhanh chóng.

Tôi nhớ rất rõ khoảnh khắc Slashdot tự hủy hoại chính mình. Giao diện trước đây của họ cho phép tôi dễ dàng duyệt và quét để tìm những bình luận chất lượng cao, nhưng vì cái gọi là "UI hiện đại" hoặc những lý do vô nghĩa khác để nuôi sống một vài nhà thiết kế, họ đã hoàn toàn thay đổi giao diện, tạo ra rất nhiều khoảng trắng và khiến tôi gần như không thể duyệt nhanh các bình luận.

Tôi nhớ là đã thử nó khoảng 3 ngày rồi bỏ cuộc, trong khi trước đó tôi là độc giả hàng ngày của Slashdot.

---


### Steam, Itch.io đang gỡ các trò chơi 'khiêu dâm'. Các nhà phê bình s…


[https://news.ycombinator.com/item?id=44686753](https://news.ycombinator.com/item?id=44686753)

Những người cố gắng chặn một số nội dung nhất định này có vấn đề gì vậy?

Không thích nội dung khiêu dâm? Vậy thì đừng mua. Đơn giản vậy thôi. Không ai, kể cả chính phủ hay các bộ xử lý thanh toán, nên ở vị trí quyết định xem một nền tảng có thể bán thứ gì đó hay không.

Tôi ước có một bộ xử lý thanh toán đủ dũng cảm để nói một tiếng "ĐM" thật to với kiểm duyệt.

Những người cố gắng chặn một số nội dung nhất định này đang nghĩ cái quái gì vậy? Không thích nội dung khiêu dâm? Vậy thì đừng mua. Đơn giản vậy thôi. Bất kể là chính phủ hay các đơn vị xử lý thanh toán, không ai nên có quyền quyết định một nền tảng có thể bán cái gì hay không. Tôi thực sự ước có một đơn vị xử lý thanh toán nào đó dám lớn tiếng nói "ĐM" với chế độ kiểm duyệt!

---


### Debian chuyển sang thời gian 64-bit cho mọi thứ


[https://news.ycombinator.com/item?id=44709842](https://news.ycombinator.com/item?id=44709842)

Họ chỉ đang trì hoãn vấn đề thôi. Mọi người sẽ làm gì vào ngày 4 tháng 12 năm 292277026596, lúc 15:30:07 UTC?

Họ chỉ đang đá quả bóng trách nhiệm đi. Vào ngày 4 tháng 12 năm 292277026596, lúc 15:30:07 UTC, mọi người sẽ làm gì?

---
Facebook X