2025-06-25 Top Stories

Top Câu Chuyện trên HackerNews ngày 2025-06-25 #

  1. Viết phần mềm đồ chơi là một niềm vui, nhấn mạnh tầm quan trọng của việc học thông qua sáng tạo.
  2. Ủy ban An toàn Hóa chất Hoa Kỳ có thể bị bãi bỏ, làm dấy lên lo ngại về an toàn hóa chất và an toàn cho người lao động.
  3. Starship là một công cụ dấu nhắc nhanh chóng, có thể tùy chỉnh, phù hợp với nhiều môi trường shell.
  4. Mặc dù AI trỗi dậy, mã hóa thủ công vẫn là một kỹ năng quan trọng trong phát triển phần mềm.
  5. Một quả trứng phục sinh 27 năm tuổi đã được tìm thấy trong Power Mac G3 ROM.
  6. Báo cáo thử nghiệm cho thấy các sản phẩm nhựa có thể chứa hóa chất, cần quan tâm đến an toàn thực phẩm.
  7. Phiên bản mới của Đạo luật NO FAKES có thể làm gia tăng kiểm duyệt ngôn luận trên Internet và hạn chế đổi mới.
  8. Thẩm phán bác bỏ việc tạo ra “chương trình giám sát hàng loạt”, duy trì lệnh của OpenAI về việc giữ nhật ký ChatGPT.
  9. Điểm tín dụng FICO sẽ bao gồm dữ liệu cho vay “mua trước trả sau”, có thể ảnh hưởng đến hồ sơ tín dụng của người tiêu dùng.
  10. Trong ứng dụng Flask/Django được Docker hóa, sử dụng uv thay thế pip có thể cải thiện tốc độ và hiệu quả xây dựng.

Viết phần mềm đồ chơi là một niềm vui #

Writing toy software is a joy

https://blog.jsbarretto.com/post/software-is-joy

Bài viết này thảo luận về lý do tại sao việc viết phần mềm đồ chơi lại thú vị và khuyến khích người đọc thử viết nhiều chương trình đồ chơi hơn. Bài viết bắt đầu bằng cách trích dẫn câu nói nổi tiếng của Richard Feynman: “Những gì tôi không thể tạo ra, tôi không thể hiểu”, và nhấn mạnh tầm quan trọng của việc học thông qua sáng tạo. Tác giả cho rằng, mặc dù có những lời khuyên nên tránh việc phát minh lại bánh xe, nhưng việc tự tay làm ra bánh xe của riêng mình có thể giúp người ta hiểu sâu sắc hơn về cách nó hoạt động.

I2zIbvhXnooxzfx9ip4cCScDnKd.png

Bài viết chỉ ra rằng, vào năm 2025, vẻ đẹp và sự tinh xảo của việc viết phần mềm đang bị xói mòn, trí tuệ nhân tạo đe dọa thay thế chúng ta, và phát triển phần mềm ngày càng trở nên thương mại hóa, định lượng, đóng gói và công nghiệp hóa. Tác giả cho rằng, phát triển phần mềm cần nhiều niềm vui đơn giản hơn, và việc tạo ra các chương trình đồ chơi là một cách hay để tìm lại mục đích ban đầu khi làm việc với máy tính.

Bài viết nhấn mạnh tầm quan trọng của việc giữ mọi thứ đơn giản, các chương trình đồ chơi tuân theo quy tắc 80:20, tức là 20% công sức để đạt được 80% chức năng. Mục tiêu không phải là xây dựng phần mềm cấp độ sản xuất, mà là tránh việc thiết kế quá mức, chỉ viết mã cần thiết để đạt được mục tiêu. Tác giả khuyên rằng nên để mọi đường dẫn mã (code path) đều panic/crash cho đến khi buộc phải triển khai một chức năng nào đó để đạt được tiến bộ. Tác giả ngạc nhiên khi thấy rằng việc xây dựng các phiên bản đồ chơi của một số phần mềm mà trước đây họ cho là khó tạo ra lại khá dễ dàng.

Bài viết cũng đề cập đến những lợi ích khác của việc viết chương trình đồ chơi, chẳng hạn như giá trị thực tế trong công việc hàng ngày của những kiến thức sâu sắc học được từ các dự án đồ chơi, và việc có được cái nhìn sâu sắc về những hạn chế của phần mềm bằng cách trực tiếp đối mặt với chúng, thậm chí có thể nghĩ ra một số giải pháp mới lạ.

Tiếp theo, bài viết liệt kê một số chương trình đồ chơi mà tác giả đã thử trong 15 năm qua, được xếp hạng theo độ khó và thời gian cần thiết, đồng thời cung cấp một số tài nguyên hữu ích. Các chương trình này bao gồm:

  1. Công cụ Regular Expression (Độ khó 4/10, Thời gian 5 ngày)
  2. Nhân hệ điều hành x86 (Độ khó 7/10, Thời gian 2 tháng)
  3. Trình giả lập GameBoy/NES (Độ khó 6/10, Thời gian 3 tuần)
  4. Game cho GameBoy Advance (Độ khó 3/10, Thời gian 2 tuần)
  5. Công cụ vật lý (Độ khó 5/10, Thời gian 1 tuần)
  6. Trình thông dịch động (Độ khó 4/10, Thời gian 1-2 tuần)
  7. Trình biên dịch ngôn ngữ giống C (Độ khó 8/10, Thời gian 3 tháng)
  8. Trình soạn thảo văn bản (Độ khó 5/10, Thời gian 2-4 tuần)
  9. Async Runtime (Độ khó 6/10, Thời gian 1 tuần)
  10. Hash Map (Độ khó 4/10, Thời gian 3-5 ngày)
  11. Bộ Raster hóa/Ánh xạ Texture (Độ khó 6/10, Thời gian 2 tuần)
  12. SDF Rendering (Độ khó 5/10, Thời gian 3 ngày)

Bài viết kết luận rằng, thông qua việc viết những chương trình đồ chơi này, tác giả đã có được sự hiểu biết sâu sắc về đồ họa máy tính và toán học, cũng như sự đánh giá cao về cách phần mềm và phần cứng hoạt động.

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

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

  • LLMs (Mô hình ngôn ngữ lớn) được sử dụng như một công cụ tìm kiếm, có thể nhanh chóng thu thập thông tin và cung cấp các liên kết tham khảo, nâng cao hiệu quả.
  • Thông tin do LLMs cung cấp đôi khi không chính xác, có thể dẫn đến việc theo đuổi các giải pháp không khả thi, lãng phí thời gian.
  • LLMs thể hiện xuất sắc trong “tìm kiếm ngược”, giúp tìm ra các từ khóa tìm kiếm khó nhớ.
  • Trong tương lai, các công ty có thể trả tiền để cải thiện thứ hạng sản phẩm của họ trong các so sánh LLMs, khiến kết quả có vẻ “hữu cơ”.
  • LLMs có thể làm trầm trọng thêm các vấn đề hiện có, từ “vốn đã là vấn đề” trở thành “thảm họa hiện tại”.
  • Sự tồn tại của nhiều người huấn luyện LLMs có thể khiến kết quả LLMs bắt đầu chứa quảng cáo, nhưng sự cạnh tranh có thể mang lại động lực tốt hơn.
  • Các mô hình và trọng số mã nguồn mở không thể giải quyết vấn đề quảng bá trong LLMs, vì quảng bá xảy ra sau khi huấn luyện.
  • Tối ưu hóa tìm kiếm LLMs có thể trở thành SEO mới.
  • Google có vị thế độc quyền trong lĩnh vực công cụ tìm kiếm, lĩnh vực LLMs cạnh tranh khốc liệt hơn.
  • Hiệu quả tìm kiếm của Kagi đã vượt qua Google, không bị ảnh hưởng bởi lưu lượng truy cập của Google.
  • Cảm giác sử dụng LLMs gợi nhớ đến siêu năng lực tìm kiếm của Google vào năm 2010.
  • LLMs và ChatGPT trong tương lai có thể trở nên cồng kềnh như các công cụ tìm kiếm ngày nay, xuất hiện các yếu tố gây nhiễu như công cụ SEO/SEM.
  • Có thể lưu và sử dụng các trọng số mã nguồn mở LLMs hiện tại để tìm kiếm, nhưng thông tin sẽ dần trở nên lỗi thời.
  • Chi phí phình to do con người của LLMs có thể vượt quá chi phí ảo giác hiện tại và sự phình to có thể trở thành đặc điểm của chính nội dung.
  • Có người hy vọng LLMs không phình to nhanh như Google, nhưng cũng bi quan về điều này.

Hội đồng An toàn Hóa chất Hoa Kỳ có thể bị giải thể #

U.S. Chemical Safety Board could be eliminated

https://www.ishn.com/articles/114776-us-chemical-safety-board-could-be-eliminated

Bài viết này thảo luận về vấn đề Ủy ban An toàn Hóa chất và Điều tra Nguy hiểm Hoa Kỳ (CSB) có thể bị giải thể vào năm 2026. Dưới đây là bản tóm tắt tiếng Việt của bài viết:

Chính quyền Trump đã đề xuất loại bỏ Ủy ban An toàn Hóa chất và Điều tra Nguy hiểm Hoa Kỳ (CSB) trong dự thảo ngân sách năm tài chính 2026, với lý do trách nhiệm tài chính và sự trùng lặp với các cơ quan quản lý hiện có. Đề xuất này đã gây ra sự phản đối lưỡng đảng trong Quốc hội và gây lo ngại trong ngành.

CSB được thành lập vào năm 1990 và hoạt động từ năm 1998, là một cơ quan liên bang độc lập chịu trách nhiệm điều tra các tai nạn hóa chất công nghiệp. Có trụ sở tại Washington, D.C., các thành viên ủy ban do Tổng thống bổ nhiệm và Thượng viện phê chuẩn. CSB thực hiện phân tích nguyên nhân gốc rễ các sự cố hóa chất tại các cơ sở công nghiệp cố định và đưa ra các khuyến nghị an toàn để ngăn ngừa các sự cố tương tự trong tương lai. Mặc dù CSB không có quyền hạn quản lý, nhưng những phát hiện của họ ảnh hưởng đến các chính sách của Cơ quan Bảo vệ Môi trường (EPA) và Cơ quan Quản lý An toàn và Sức khỏe Nghề nghiệp (OSHA). Các nhà điều tra của CSB bao gồm các kỹ sư hóa học và cơ khí, các chuyên gia an toàn công nghiệp và các chuyên gia khác có kinh nghiệm trong khu vực tư nhân và công cộng. Nhiều nhà điều tra có nhiều năm kinh nghiệm trong ngành công nghiệp hóa chất.

CSB hiện chỉ có ba thành viên được Thượng viện phê chuẩn, ít hơn so với số lượng năm thành viên đầy đủ, nhưng vẫn công bố các báo cáo an toàn quan trọng, bao gồm báo cáo gần đây nhất về ba sự cố thảm khốc tại cơ sở Honeywell ở Louisiana. Trong lịch sử 25 năm của CSB, cơ quan này đã được triển khai đến hơn 170 sự cố hóa chất và đã đưa ra hơn 1000 khuyến nghị, dẫn đến nhiều cải tiến an toàn trong các ngành công nghiệp khác nhau.

Sau khi CSB đến hiện trường sự cố hóa chất, các nhà điều tra bắt đầu làm việc bằng cách phỏng vấn chi tiết các nhân chứng, chẳng hạn như nhân viên nhà máy, quản lý và hàng xóm. Các mẫu hóa chất và thiết bị thu được từ hiện trường tai nạn được gửi đến các phòng thí nghiệm độc lập để kiểm tra. Các nhà điều tra xem xét hồ sơ an toàn, hàng tồn kho và quy trình vận hành của công ty để hiểu các tình huống dẫn đến tai nạn.

Theo nhiệm vụ an toàn công cộng của mình, CSB thực hiện các cuộc điều tra nguyên nhân gốc rễ các sự cố hóa chất tại các cơ sở công nghiệp cố định. Nguyên nhân gốc rễ thường là những thiếu sót trong hệ thống quản lý an toàn, nhưng cũng có thể là bất kỳ yếu tố nào mà nếu yếu tố đó không xảy ra thì có thể ngăn ngừa được tai nạn. Các nguyên nhân khác của tai nạn thường liên quan đến hỏng hóc thiết bị, lỗi của con người, phản ứng hóa học không lường trước được hoặc các nguy cơ khác. Cơ quan này không đưa ra các khoản tiền phạt hoặc trích dẫn, Quốc hội thiết kế CSB là phi quản lý và độc lập với các cơ quan khác để các cuộc điều tra của họ tăng cường an toàn công cộng, an toàn cho người lao động và thông báo cho ngành.

Điều tra tai nạn và điều tra nguy hiểm đều dẫn đến các khuyến nghị an toàn mới, đây là công cụ chính để ủy ban đạt được những thay đổi tích cực. Các khuyến nghị được ban hành cho các cơ quan chính phủ, công ty, hiệp hội ngành, công đoàn và các nhóm khác. Nhân viên CSB theo dõi và giám sát việc thực hiện từng khuyến nghị an toàn. Khi các hành động được khuyến nghị đã được hoàn thành một cách thỏa đáng, các khuyến nghị có thể được đóng lại bằng một cuộc bỏ phiếu của hội đồng quản trị.

Mặc dù một số khuyến nghị có thể được chấp nhận ngay lập tức, nhưng những khuyến nghị khác đòi hỏi những nỗ lực và vận động đáng kể để thực hiện. Các thành viên hội đồng quản trị và nhân viên nỗ lực thúc đẩy các hành động an toàn dựa trên các khuyến nghị của CSB. Trong nhiều trường hợp, kinh nghiệm từ các cuộc điều tra của CSB có thể áp dụng cho nhiều tổ chức bên ngoài công ty bị điều tra. Nhiều khuyến nghị của CSB đã được thực hiện trong ngành, dẫn đến các nhà máy, công nhân và cộng đồng an toàn hơn.

Các lĩnh vực trọng tâm chính bao gồm:

  • Điều tra sự cố hóa chất: Xác định nguyên nhân gốc rễ của các vụ nổ công nghiệp, phát tán chất độc và rò rỉ hóa chất.
  • Khuyến nghị an toàn và phát triển chính sách: Cung cấp hướng dẫn an toàn phi quản lý cho ngành và chính phủ.
  • Phân tích dữ liệu và mô hình hóa kỹ thuật số: Sử dụng trí tuệ nhân tạo và phân tích dự đoán để đánh giá các yếu tố rủi ro công nghiệp.
  • Tiếp cận cộng đồng và báo cáo: Phát hành báo cáo sự cố, hoạt hình video và khuyến nghị an toàn.
  • An ninh mạng và hiện đại hóa CNTT: Bảo vệ dữ liệu điều tra, báo cáo và các công cụ phân tích pháp y của CSB.
  • Phòng ngừa nguy cơ công nghiệp: Xác định các vấn đề an toàn có hệ thống trong các nhà máy hóa chất, nhà máy lọc dầu và cơ sở lưu trữ.

Thông tin chi tiết về đề xuất đóng cửa: Văn phòng Quản lý và Ngân sách (OMB) của Nhà Trắng cho biết rằng việc đóng cửa CSB phù hợp với những nỗ lực đưa quốc gia đi theo hướng trách nhiệm tài chính và xác định lại vai trò của chính phủ liên bang. Các tài liệu ngân sách chỉ định rằng nguồn tài trợ của CSB nên được “hủy bỏ vĩnh viễn” trước ngày 30 tháng 9 năm 2026.

Điều đáng chú ý là yêu cầu ngân sách năm tài chính 2026 của chính CSB là 0 đô la, ngôn ngữ này ngụ ý rằng các chức năng của nó trùng lặp với EPA và OSHA. Tuy nhiên, cựu quan chức OSHA Jordan Barab mô tả điều này là “rất bất thường”, cho thấy yêu cầu này có thể do Nhà Trắng áp đặt, chứ không phải từ ban lãnh đạo CSB.

Tại sao điều này lại quan trọng đối với Trái Đất: Việc đóng cửa CSB sẽ làm suy yếu sự giám sát của liên bang đối với an toàn hóa chất vào thời điểm các tai nạn công nghiệp gây ra rủi ro ngày càng tăng đối với môi trường và sức khỏe cộng đồng.

Các cuộc điều tra của CSB không chỉ ngăn chặn các thảm họa lặp đi lặp lại mà còn cung cấp những hiểu biết quan trọng về ô nhiễm, an toàn tại nơi làm việc và quản lý vật liệu nguy hiểm.

Sự vắng mặt của nó có thể làm chậm hoặc ngừng tiến trình công bằng môi trường, đặc biệt là ở các cộng đồng tiền tuyến nằm gần các khu công nghiệp.

Cản trở sự hợp tác để tăng cường các khuyến nghị an toàn quan trọng nhằm lấp đầy những khoảng trống hiện tại giữa các quy định của liên bang và tiểu bang với các quy định của địa phương.

Hỗ trợ ngành công nghiệp hóa chất cần bảo vệ người lao động, công chúng và môi trường khỏi bị tổn hại.

Việc đóng cửa CSB là một sai lầm:

  • Nó lấp đầy một vai trò an toàn độc đáo: CSB điều tra các tai nạn hóa chất công nghiệp - không phải để quy trách nhiệm, mà là để tìm hiểu lý do tại sao chúng xảy ra và làm thế nào để ngăn chặn chúng. Không có cơ quan liên bang nào khác thực hiện phân tích nguyên nhân gốc rễ tập trung hoàn toàn vào cải tiến an toàn như vậy. OSHA và EPA thực thi các quy tắc, nhưng họ không thực hiện các cuộc điều tra chuyên sâu, dựa trên hệ thống như CSB.
  • Nó có một hồ sơ thành tích mạnh mẽ: Mặc dù quy mô nhỏ và ngân sách hạn chế, CSB đã tạo ra các báo cáo có tác động cao, dẫn đến những cải tiến an toàn trong thế giới thực.

HN | Độ nóng: 363 điểm | 234 bình luận | Tác giả: z991 #

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

  • Ủy ban An toàn Hóa chất Hoa Kỳ có thể bị bãi bỏ, nhưng các video điều tra an toàn của họ trên YouTube rất có tính giáo dục.
  • Quảng cáo tự quảng bá của Ủy ban An toàn Hóa chất Hoa Kỳ cho thấy đề xuất giá trị của họ.
  • Có người chỉ ra rằng tham số si trong liên kết chia sẻ là một hình thức theo dõi, đề nghị loại bỏ.
  • Có người nói rằng video của Ủy ban An toàn Hóa chất là nội dung yêu thích của họ trên YouTube.
  • Có người nghi ngờ hiệu quả tổ chức của Ủy ban An toàn Hóa chất, nhưng cho rằng nhân viên và chi phí ngân sách của họ hiệu quả hơn.
  • Có người chỉ trích tư duy phản công nghệ, phản khoa học của chính phủ hiện tại, cho rằng có thể dẫn đến sự thụt lùi của Hoa Kỳ.
  • Có người lo ngại Hoa Kỳ có thể đi theo hình thức phong kiến hiện đại, các công ty lớn trở thành giới quý tộc mới.
  • Có người chỉ ra rằng các quốc gia độc tài thường sụp đổ nhanh chóng vì bỏ qua sự thật, chẳng hạn như vấn đề cung cấp thực phẩm giả ở Liên Xô.
  • Có người phản bác rằng Trung Quốc là một ngoại lệ, các quốc gia độc tài không nhất thiết phải sụp đổ nhanh chóng.
  • Có người cho rằng sự ổn định của Trung Quốc một phần bắt nguồn từ sự hiểu biết của các nhà lãnh đạo về thực tế và cuộc chiến chống tham nhũng.
  • Có người đặt câu hỏi nếu Trump nắm quyền ở Trung Quốc thì sẽ như thế nào.
  • Có người chỉ ra rằng chủ nghĩa độc tài hiệu quả khi nhà lãnh đạo hiệu quả, chế độ dân chủ thắng thế về lâu dài vì ít chọn ra những nhà lãnh đạo tồi hơn.
  • Có người chỉ trích Hoa Kỳ và Liên minh Châu Âu đã bỏ qua thực tế, ít nhất là từ các quyết định của các nhà lãnh đạo của họ.
  • Có người nhấn mạnh nền tảng khoa học và kỹ thuật của các nhà lãnh đạo Trung Quốc, cho rằng đây là một trong những lý do khiến chế độ độc tài của Trung Quốc không sụp đổ nhanh chóng.
  • Có người đặt câu hỏi tại sao người Mỹ không bỏ phiếu cho những người thông minh có bằng kỹ sư, mà lại chọn những chính trị gia nói dối.
  • Có người giải thích rằng việc tranh cử vào các chức vụ công là một hành vi rất rủi ro, đặc biệt đối với các kỹ sư hoặc những người trong lĩnh vực kỹ thuật.
  • Có người chỉ ra rằng, so với Hoa Kỳ, luật sư ở các quốc gia khác không có xu hướng tham gia chính trị nhiều như vậy.
  • Có người phản bác rằng, ở nhiều quốc gia, những người có bằng luật cũng chiếm tỷ lệ lớn trong số các quan chức và thành viên Nghị viện Châu Âu.

Starship: Dấu nhắc tối giản, nhanh và tùy biến cho mọi shell #

Starship: The minimal, fast, and customizable prompt for any shell

https://starship.rs/

Trang web này giới thiệu về dự án Starship và hướng dẫn cài đặt. Starship là một công cụ dấu nhắc tối giản, cực nhanh và có khả năng tùy biến vô hạn, được thiết kế cho bất kỳ shell nào.

LURtbw1YjotbPYx5d3IcMDSLn2e.png
  1. Khả năng tương thích: Starship có thể được sử dụng trên các hệ điều hành phổ biến nhất với các shell phổ biến nhất. Nó được phát triển bằng ngôn ngữ Rust để đảm bảo tốc độ và tính bảo mật của dấu nhắc.
  2. Khả năng tùy biến: Mọi chi tiết của Starship đều có thể được tùy chỉnh theo sở thích của người dùng, khiến nó có thể rất đơn giản hoặc giàu tính năng.
  3. Điều kiện tiên quyết: Cần cài đặt và kích hoạt một Nerd Font trong terminal.
  4. Cài đặt nhanh chóng: Cung cấp các lệnh để cài đặt tệp nhị phân Starship, bao gồm các phương pháp cài đặt thông qua shell và trình quản lý gói. Để cập nhật Starship, chỉ cần chạy lại tập lệnh cài đặt, nó sẽ thay thế phiên bản hiện tại mà không ảnh hưởng đến cấu hình.
  5. Các bước cài đặt: Đối với các shell khác nhau (như Bash, Fish, Zsh, Powershell, v.v.), trang web cung cấp các bước để thêm tập lệnh khởi tạo vào tệp cấu hình shell tương ứng. Ví dụ: đối với Bash, cần thêm eval "$(starship init bash)" vào cuối tệp ~/.bashrc. Đối với Fish, cần thêm starship init fish | source vào cuối tệp ~/.config/fish/config.fish. Đối với Zsh, cần thêm eval "$(starship init zsh)" vào cuối tệp ~/.zshrc. Đối với Powershell, cần thêm Invoke-Expression (&starship init powershell) vào cuối tệp Microsoft.PowerShell_profile.ps1. Cũng cung cấp các bước cài đặt cho Ion, Elvish, Tcsh, Nushell và Xonsh.
  6. Cài đặt Cmd: Nếu sử dụng Cmd, cần kết hợp với Clink (phiên bản 1.2.30+). Cần tạo một tệp có tên starship.lua và đặt nó trong thư mục tập lệnh Clink, nội dung tệp là tập lệnh Lua để tải Starship khởi tạo Cmd.

Cấu trúc nội dung của trang web rõ ràng, cung cấp tổng quan về Starship, khả năng tương thích, khả năng tùy biến, chuẩn bị trước khi cài đặt, các bước cài đặt chi tiết và phương pháp cấu hình cho các shell khác nhau. Thông qua những thông tin này, người dùng có thể hiểu cách cài đặt và cấu hình Starship trong hệ thống của mình, cũng như cách sử dụng các chức năng tùy chỉnh mạnh mẽ của nó để tối ưu hóa giao diện dòng lệnh của mình.

HN | Độ nóng: 353 điểm | 170 bình luận | Tác giả: benoitg #

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

  • Starship cung cấp dấu nhắc dòng lệnh có khả năng tùy biến cao, nhưng không phải ai cũng thích dấu nhắc phức tạp.
  • Có người đề xuất thêm thời gian xuất hiện của dấu nhắc hiện tại và thời gian chạy của lệnh trước đó vào dấu nhắc dòng lệnh để dễ dàng ghi nhật ký và khắc phục sự cố.
  • Sử dụng dấu thời gian UNIX có thể dễ dàng và nhanh chóng tính toán chênh lệch thời gian.
  • nushell mặc định cung cấp thông tin như thời gian thực thi lệnh, giúp hiểu được thời gian chạy thực tế của lệnh.
  • Có người vì sử dụng trình soạn thảo Emacs nên không cần hiển thị quá nhiều thông tin trong dấu nhắc dòng lệnh.
  • Starship giúp người khác hiểu được trạng thái làm việc hiện tại khi có nhiều người cộng tác.
  • Có người thấy hữu ích khi dấu nhắc dòng lệnh hiển thị trạng thái thoát của lệnh trước đó.
  • Có người đề xuất sử dụng thời gian chạy lệnh làm chú thích cho lịch sử, thay vì hiển thị trong dấu nhắc.
  • Công cụ Atuin có thể tăng cường lịch sử, thêm dữ liệu như thư mục làm việc, mã thoát và thời gian chạy lệnh.
  • Chức năng history của Bash mặc định không ghi dấu thời gian, cần phải bật thủ công.
  • Có người thấy chỉ cần hiển thị thư mục hiện tại và trạng thái của lệnh trước đó là đủ, không cần thông tin khác.
  • Có người nhấn mạnh việc biết nhánh hiện tại là rất quan trọng, vì đã nhiều lần thực thi lệnh trên nhánh sai.
  • Có người duy trì nhận thức về nhánh hiện tại bằng cách chuyển đổi nhánh thủ công.
  • Khi làm việc trong nhiều kho mã, có người thấy kiểm tra git status thủ công đáng tin cậy hơn.
  • Có người thấy thông tin nhánh hiển thị trong dấu nhắc dòng lệnh là một lời nhắc nhở kín đáo, giúp biết mình có đang ở trong đường dẫn kiểm soát phiên bản hay không.
  • Có người thấy tính năng tích hợp AWS hữu ích, có thể biết tài khoản và khu vực hiện tại.
  • Có người thấy tích hợp kubeconfig rất hữu ích cho việc chuyển đổi công việc giữa các cụm khác nhau.
  • Có người khuyên dùng thử công cụ jj, cho rằng nó có thể thay đổi cuộc sống.
  • Có người đánh giá cao dấu nhắc nhánh git của oh-my-zsh, cho rằng nó rất gọn gàng.
  • Có người hài lòng với việc kiểm tra git status thủ công, cho rằng như vậy là đủ.
  • Có người sử dụng cài đặt dấu nhắc dòng lệnh rất cơ bản, cho rằng như vậy có thể cảm thấy quen thuộc ở bất cứ đâu.
  • Có người cho rằng tmux là công cụ duy nhất vượt qua được thử thách của thời gian.

CEO GitHub: lập trình thủ công vẫn là chìa khóa dù AI bùng nổ #

GitHub CEO: manual coding remains key despite AI boom

https://www.techinasia.com/news/github-ceo-manual-coding-remains-key-despite-ai-boom

CEO của GitHub, Thomas Dohmke, đã nhấn mạnh tầm quan trọng của việc duy trì các kỹ năng lập trình thủ công trong phát triển phần mềm, ngay cả khi các công cụ trí tuệ nhân tạo (AI) trở nên phổ biến, trong “The MAD Podcast with Matt Turck”. Dohmke cho biết các nhà phát triển cần có khả năng sửa đổi mã do AI tạo ra để ngăn ngừa các vấn đề về năng suất. Ông mô tả một quy trình làm việc hiệu quả, trong đó các công cụ AI tạo mã và gửi yêu cầu kéo (pull request), và các nhà phát triển có thể sử dụng các kỹ năng lập trình của mình để điều chỉnh ngay lập tức. Ông cảnh báo rằng việc hoàn toàn dựa vào các tác nhân tự động có thể dẫn đến sự kém hiệu quả, ví dụ: tốn quá nhiều thời gian để giải thích các thay đổi đơn giản bằng ngôn ngữ tự nhiên thay vì chỉnh sửa trực tiếp mã.

Ngoài ra, Dohmke cũng thảo luận về “vibe coding” (lập trình theo cảm hứng), một thuật ngữ do Andrej Karpathy, đồng sáng lập của OpenAI, đưa ra để mô tả việc lạm dụng mã do AI tạo ra.

Dưới đây là một số quan điểm đáng suy ngẫm:

  1. Phương pháp kết hợp trở thành công thức chiến thắng cho việc lập trình bằng AI Quan điểm của Dohmke phù hợp với sự đồng thuận của ngành, đó là chiến lược lập trình AI hiệu quả nhất là kết hợp tự động hóa với các kỹ năng lập trình của con người. Nghiên cứu của Deloitte cho thấy các nhà phát triển chủ yếu sử dụng các công cụ AI để thực hiện các tác vụ cụ thể, chẳng hạn như viết mã soạn sẵn (boilerplate code), đồng thời duy trì sự giám sát của con người, có thể cải thiện năng suất từ 10-20 phút mỗi ngày. Chiến lược “tin tưởng và xác minh” này đang trở thành tiêu chuẩn, vì nghiên cứu cho thấy khoảng một nửa số mã do AI tạo ra chứa các lỗi một phần, làm nổi bật nhu cầu liên tục về chuyên môn của con người. Kinh nghiệm của Google cũng phản ánh mô hình kết hợp này, khi công ty báo cáo rằng hiện tại hơn 25% mã được tạo ra bởi AI, nhưng vẫn cần sự xem xét và hoàn thiện đáng kể của con người.
  2. Vai trò của nhà phát triển đang phát triển, chứ không phải biến mất AI không loại bỏ công việc lập trình, mà đang chuyển đổi các nhà phát triển từ những người chỉ viết mã thuần túy thành những người điều phối quy trình phát triển được hỗ trợ bởi AI. Các chuyên gia trong ngành dự đoán rằng vai trò của nhà phát triển sẽ phân chia thành hai loại chính: kỹ sư sản phẩm sử dụng AI để tạo mã và kiến trúc sư mã hóa cao cấp đảm bảo chất lượng và bảo mật của hệ thống phần mềm. Sự phát triển này đòi hỏi các kỹ năng mới, tập trung vào giải quyết vấn đề mang tính chiến lược, hướng dẫn AI hiệu quả và đưa ra các quyết định thiết kế cấp cao, thay vì viết thủ công từng dòng mã. Tình trạng thiếu kỹ sư phần mềm liên tục, cùng với nghiên cứu cho thấy các công cụ AI đặc biệt có lợi cho các nhà phát triển mới vào nghề, cho thấy AI sẽ giúp thu hẹp khoảng cách về nhân tài, đồng thời tạo ra các cơ hội mới cho các lập trình viên có kinh nghiệm.
  3. “Lập trình theo cảm hứng” tiết lộ nghịch lý giữa năng suất và chất lượng Phương pháp “lập trình theo cảm hứng” mới nổi thể hiện lời hứa và những hạn chế của mã do AI tạo ra, đặc biệt đối với các công ty khởi nghiệp và các dự án phức tạp. Mặc dù các công cụ AI cho phép tạo mẫu nhanh và phát triển lặp đi lặp lại phù hợp với phương pháp luận Agile, nhưng chúng cũng làm dấy lên những lo ngại đáng kể về chất lượng mã, lỗ hổng bảo mật và khả năng bảo trì. Các sự kiện trong thế giới thực đã cho thấy sự nguy hiểm của việc quá phụ thuộc vào mã do AI tạo ra chưa được xác minh, đặc biệt là về các vấn đề bảo mật có thể không hiển thị ngay lập tức. Đối với các công ty khởi nghiệp, sự căng thẳng này đặc biệt liên quan, vì những người sáng lập không có kiến thức kỹ thuật có thể gặp khó khăn trong việc xây dựng các hệ thống phức tạp, bền vững chỉ bằng mã do AI tạo ra, có thể tạo ra các khoản nợ kỹ thuật cản trở sự tăng trưởng trong tương lai. Kinh nghiệm của các công ty công nghệ trưởng thành cho thấy rằng việc tích hợp AI thành công đòi hỏi sự cân bằng giữa tự động hóa và các quy trình đảm bảo chất lượng nghiêm ngặt, đây có thể là một bài học quan trọng đối với các tổ chức nhỏ hơn.

HN | Độ nóng: 339 điểm | 257 bình luận | Tác giả: andrewstetsenko #

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

  • Fred Brooks trong cuốn “Không có viên đạn bạc” đã chỉ ra rằng thách thức cốt lõi của phát triển phần mềm nằm ở sự phức tạp bản chất ở cấp độ khái niệm, chứ không phải sự phức tạp ngẫu nhiên ở cấp độ cú pháp.
  • Mặc dù AI có thể giảm bớt sự phức tạp ngẫu nhiên như các hạn chế về công cụ, nhưng việc chuyển đổi các ý tưởng mơ hồ thành các hệ thống chi tiết, mạnh mẽ vẫn là công việc cốt lõi của các kỹ sư.
  • Mọi người thường dựa vào sự hiểu biết của lập trình viên về lĩnh vực để lấp đầy các chi tiết, giờ đây AI có thể thay thế vai trò này.
  • Ưu điểm hiện tại của AI là thỉnh thoảng cung cấp các kết quả tầm thường có thể chấp nhận được, đáp ứng những người quản lý dự án và các bên liên quan có yêu cầu không rõ ràng.
  • Vai trò của AI trong phát triển phần mềm bị đánh giá quá cao, vì nó không thể thực sự hiểu được các yêu cầu kinh doanh và bối cảnh sâu sắc.
  • Nhiều người tham gia vào phát triển phần mềm thực sự không giỏi lập trình, những người này dễ bị AI thay thế.
  • Đề xuất sàng lọc các nhà phát triển phần mềm bằng cách thiết lập các tiêu chuẩn cao, tương tự như kỳ thi lấy chứng chỉ trong ngành luật sư.

Tìm kiếm một easter egg 27 năm tuổi trong ROM của Power Mac G3 #

Finding a 27-year-old easter egg in the Power Mac G3 ROM

https://www.downtowndougbrown.com/2025/06/finding-a-27-year-old-easter-egg-in-the-power-mac-g3-rom/

Doug Brown đã chia sẻ trên blog của mình về việc anh vô tình phát hiện ra một Easter Egg 27 năm tuổi trong ROM của Power Macintosh G3 khi khám phá nó, Easter Egg này trước đây chưa từng được ghi lại. Doug đã hồi tưởng lại phát hiện này vào giữa năm 2025 và cảm thán rằng Power Mac G3 đã ra mắt được 27 năm.

Cuộc khám phá của Doug bắt đầu vào một ngày Chủ nhật lười biếng, anh sử dụng Hex Fiend và template Mac ROM của Eric Harmon (ROM Fiend) để xem các tài nguyên được lưu trữ trong ROM của Power Mac G3. ROM này được sử dụng cho các model G3 dạng desktop màu be, mini-tower và all-in-one từ năm 1997 đến năm 1999.

Trong khi duyệt ROM, Doug nhận thấy hai điều: Thứ nhất là tài nguyên có kiểu HPOE, chứa một ảnh JPEG có thể là của những người tham gia vào việc phát triển các model Mac này. Đây không phải là một phát hiện mới, Pierre Dandumont đã viết về nó vào năm 2014. Nhưng trong bài viết của mình, anh ấy đã không làm rõ cách hiển thị hình ảnh ẩn này trên một máy thật. Nhiều máy Mac cũ có các tổ hợp phím bí mật để hiển thị các hình ảnh tương tự, nhưng cơ chế để hiển thị hình ảnh này vẫn là một bí ẩn.

Thứ hai, Doug đã tìm thấy một manh mối quan trọng: Khi tìm kiếm các thông tin thú vị khác trong ROM, anh tình cờ bắt gặp tài nguyên ID 43, được đặt tên là “Native 4.3”. Nhờ nghiên cứu trước đây của Keith Kaisershot về Pippin, Doug nhanh chóng kết luận rằng đây là mã PowerPC Native SCSI Manager 4.3. SCSI Manager không phải là thứ thu hút sự chú ý của Doug, mà là ở cuối dữ liệu, anh tìm thấy một số chuỗi Pascal thú vị, đặc biệt là văn bản “secret ROM image”, có vẻ như có liên quan đến hình ảnh ở trên. Doug quyết định nghiên cứu sâu hơn để xem liệu anh có thể tìm ra lý do tại sao SCSI Manager lại chứa các chuỗi này, với hy vọng tìm ra cách hướng dẫn Power Mac G3 hiển thị hình ảnh đó.

Thông qua tìm kiếm trên Internet cụm từ “secret ROM image”, Doug phát hiện ra rằng nó đã được sử dụng cho một Easter Egg trong các máy PowerPC Mac đời đầu. Trên những máy đó, bạn chỉ cần nhập văn bản, chọn nó và kéo nó vào màn hình desktop, hình ảnh sẽ xuất hiện. Nhưng trên G3, phương pháp này không hoạt động.

Doug nghi ngờ rằng có một phương pháp tương tự để truy cập hình ảnh ẩn này, nhưng không ai ghi lại nó, ít nhất là anh không tìm thấy. Vì vậy, anh phải dịch ngược mã để xem văn bản này được sử dụng ở đâu. Anh đã trích xuất toàn bộ tài nguyên nitt ID 43 vào một file và kiểm tra, phát hiện ra rằng đây là một header của file thực thi PowerPC PEF. Anh đã nhập toàn bộ file vào Ghidra, Ghidra ngay lập tức nhận ra nó là một file PEF và có thể tải một cách trơn tru. Mặc dù Doug quen thuộc với việc đọc mã hợp ngữ x86 và ARM, nhưng anh hầu như không biết gì về mã hợp ngữ PowerPC. May mắn thay, trình biên dịch ngược của Ghidra hoạt động tốt với file này.

Tuy nhiên, Ghidra không phát hiện bất kỳ tham chiếu nào đến chuỗi “secret ROM image”, ngoại trừ trong một danh sách lớn các con trỏ trỏ đến các biến. Sau một hồi suy nghĩ, Doug nhận ra rằng Ghidra đã không làm tốt việc tìm kiếm các tham chiếu đến một vài biến. May mắn thay, việc chạy lại phân tích tự động sau phân tích ban đầu dường như đã giúp nó tìm thấy nhiều tham chiếu hơn, bao gồm tất cả các chuỗi mà anh quan tâm. Anh không thay đổi bất kỳ tùy chọn nào của trình phân tích; nó chỉ tìm thấy nhiều thứ hơn trong lần chạy thứ hai.

Hàm sử dụng các chuỗi này chắc chắn có liên quan đến trình điều khiển .EDisk, Doug đã biết đây là trình điều khiển RAM disk vì những lần hack trước đây của anh. Nó dường như đang sử dụng strncmp() để kiểm tra xem một chuỗi có bằng “secret ROM image” hay không, nếu có, nó sẽ tạo/mở/ghi một file có tên “The Team”.

Doug đã dọn dẹp quá trình dịch ngược này bằng cách đặt tên cho các biến và xác định các kiểu dữ liệu, may mắn thay, có rất nhiều tài liệu công khai về các hàm như PBGetVInfoSync(), vì vậy anh chỉ cần cho Ghidra biết cấu trúc Mac Toolbox đang được sử dụng.

Mã đã dịch ngược cho thấy nó tìm kiếm một trình điều khiển có tên là .Edisk (trình điều khiển thực sự có tên là .EDisk, nhưng Mac OS không phân biệt chữ hoa chữ thường). Nó tìm thấy một disk (RAM disk) liên quan đến trình điều khiển đó. Nó tìm kiếm một volume liên quan đến disk đó. Nếu volume được đặt tên là “secret ROM image”: nó tải tài nguyên HPOE ID 1, chứa dữ liệu ảnh JPEG. Nó tạo một file có tên “The Team”, với creator là ttxt và type là JPEG. Nó mở file, ghi dữ liệu JPEG vào đó, sau đó đóng file. Sau đó, nó thực hiện một số việc liên quan đến mục điều khiển trình điều khiển, Doug không hiểu sâu hơn.

Doug phát hiện ra rằng đoạn mã này rõ ràng đang tìm kiếm một RAM disk được đặt tên là “secret ROM image”, nhưng anh không chắc làm thế nào để kích hoạt nó. Hàm này chỉ được gọi ở một nơi khác: một hàm khác, nó kiểm tra xem tham số đầu tiên của nó có bằng giá trị 0x3DA (thập phân 986) hay không.

Doug không có chiếc G3 màu be của mình để nghịch, vì vậy anh đã đề cập đến phát hiện của mình trên #mac68k trên Libera. ^alex sau khi nghịch ngợm một chút trong Infinite Mac, dựa trên những gợi ý mà Doug đưa ra, họ nhanh chóng phát hiện ra mẹo là format RAM disk và nhập văn bản đặc biệt vào hộp thoại format. Doug lấy chiếc G3 desktop của mình, thử nghiệm nó trên phần cứng thực tế và nó thực sự hoạt động! Nếu bạn muốn tự mình thử, giống như ^alex, bạn có thể sử dụng liên kết này để chạy Infinite Mac trong trình duyệt, nó thiết lập một chiếc G3 màu be được mô phỏng chạy Mac OS 8.1 bằng DingusPPC. Có một vấn đề nhỏ khiến nó không thể phân giải bí danh khi khởi động. Doug đã cố tình tắt nó; khi lỗi bật lên, chỉ cần nhấp vào Stop. Đây là hướng dẫn:

Bật RAM disk trong bảng điều khiển Memory. Chọn Restart từ menu Special. Sau khi desktop trở lại, chọn biểu tượng RAM disk. Chọn Erase Disk từ menu Special. Nhập chính xác văn bản secret ROM image như hiển thị ở trên. Nhấp vào Erase. Khi bạn mở RAM disk mới được format, bạn sẽ thấy một file có tên “The Team”: Nếu bạn nhấp đúp vào file, SimpleText sẽ mở nó: Theo thử nghiệm của nhiều người, bao gồm cả Doug, thủ thuật này có thể hoạt động cho đến Mac OS 9.0.4, nhưng 9.1 có thể là phiên bản cuối cùng nó hoạt động.

Theo Doug biết, bí mật cụ thể này cho đến bây giờ mới được phát hiện. Mọi người chắc chắn biết rằng có hình ảnh này trong ROM, nhưng không ai biết cách thực sự kích hoạt nó. Đây có thể là Easter Egg cuối cùng tồn tại trong Mac trước khi Steve Jobs được cho là đã cấm Easter Egg khi ông trở lại Apple vào năm 1997. Anh tự hỏi liệu Steve Jobs có biết về cái này không?

Đặc biệt cảm ơn ^alex đã phát hiện ra rằng cần phải xóa RAM disk để kích hoạt Easter Egg! Anh không chắc mình sẽ nghĩ đến việc thử điều đó, và sẽ tốn rất nhiều thời gian…

HN | Độ nóng: 292 điểm | 84 bình luận | Tác giả: zdw #

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

  • Những easter egg (trứng phục sinh) trong kỷ nguyên PC để bàn thời kỳ đầu khiến người ta cảm nhận được tính nhân văn đằng sau sản phẩm, kết nối người sử dụng và nhà sản xuất.
  • Các sản phẩm hiện đại có xu hướng phi nhân tính hóa, để kiểm soát hình ảnh sản phẩm, tránh những người trong danh sách gặp vấn đề.
  • Trước khi có Agile, các thành viên trong nhóm có thể thêm easter egg vì buồn chán trong khi chờ đợi.
  • Kiểm toán hiện đại có thể yêu cầu nộp báo cáo sai lệch và cập nhật tài liệu thiết kế bảo mật vì easter egg vi phạm ITGCs.
  • Easter egg có thể mang lại các vấn đề về quản lý rủi ro, chẳng hạn như tên hoặc ảnh có thể liên quan đến kiện tụng trong tương lai.
  • Sản phẩm thiếu linh hồn là do quản lý rủi ro quá mức, khiến sản phẩm trở nên vô trùng và vô tri.
  • Easter egg và các hoạt động Ngày Cá tháng Tư là một phần của việc nhân tính hóa sản phẩm, nhưng quản lý rủi ro quá mức đã dẫn đến việc chúng bị loại bỏ.
  • Các nhóm phần cứng cảm thấy tức giận vì các nhóm phần mềm chiếm quá nhiều không gian ROM để hiển thị nhóm của họ mà bỏ qua đóng góp của các nhóm phần cứng.
  • Những người nhỏ bé thực sự để lại dấu ấn trong lịch sử thông qua easter egg, trong khi những người lớn thì tuyên bố “Tôi đã xây dựng cái này”.
  • Steve Jobs không phản đối easter egg, thực tế ông là người khởi xướng hành vi này.
  • Microsoft đã thực hiện chính sách “không easter egg” vào đầu những năm 2000, đây không phải là đặc quyền của Steve Jobs.
  • Easter egg phần mềm khác với chữ ký phần cứng, chữ ký phần cứng không bị ẩn và không có tác dụng phụ bất ngờ.
  • Khi ngành công nghiệp máy tính phát triển, sự khoan dung đối với easter egg giảm trong môi trường doanh nghiệp.

PlasticList – Mức độ Nhựa trong Thực phẩm #

PlasticList – Plastic Levels in Foods

https://www.plasticlist.org/

Trang web này cung cấp báo cáo thử nghiệm về hàm lượng hóa chất trong các sản phẩm nhựa. Báo cáo bao gồm một số tuyên bố từ chối trách nhiệm quan trọng và hướng dẫn đọc, nhấn mạnh rằng những dữ liệu này không nên được coi là kết luận có độ tin cậy cao, mà là điểm khởi đầu và nguồn cảm hứng cho các nghiên cứu sâu hơn. Dưới đây là bản tóm tắt chi tiết:

Tuyên bố từ chối trách nhiệm: Trang web trước tiên nhắc nhở người đọc rằng những kết quả thử nghiệm này không đại diện cho kết luận cuối cùng và không nên được sử dụng làm cơ sở cho các khuyến nghị chính sách hoặc quyết định mua hàng cá nhân. Những kết quả này chỉ đại diện cho các thử nghiệm tức thời trên một mẫu nhỏ sản phẩm và có thể không đại diện cho hàm lượng trong sản phẩm thực tế. Tất cả các thử nghiệm đều có sự không chắc chắn và các phương pháp thử nghiệm khác nhau có thể dẫn đến các kết quả khác nhau. Giá trị đậm trong báo cáo biểu thị phần trăm cao trong tập dữ liệu, nhưng không nhất thiết biểu thị có vấn đề. Sự hiện diện của hóa chất trong thực phẩm không tự động có nghĩa là có hại. Trang web khuyến khích sao chép những kết quả này và hoan nghênh mọi sửa chữa.

Cách đọc dữ liệu: Trang web cung cấp liên kết để tải xuống tệp TSV, để người dùng có thể lấy dữ liệu mới nhất. Dữ liệu trong báo cáo được trình bày ở dạng bảng, bao gồm hàm lượng hóa chất trên mỗi gam nhựa (tính bằng nanogram) và hàm lượng hóa chất trên mỗi khẩu phần ăn (cũng tính bằng nanogram). Bảng cũng cung cấp tỷ lệ phần trăm của lượng tiêu thụ hàng ngày tạm thời (TDI) của Cơ quan An toàn Thực phẩm Châu Âu (EFSA) và tỷ lệ phần trăm của liều tham khảo (RfD) của Cơ quan Bảo vệ Môi trường Hoa Kỳ (EPA) cho các nhóm tuổi khác nhau (trẻ em và người lớn), dành cho trẻ em và người lớn có trọng lượng cơ thể lần lượt là 14 kg và 70 kg.

Giải thích dữ liệu: Trang web giải thích cách đọc những dữ liệu này, nhưng các giá trị và tỷ lệ phần trăm cụ thể không được cung cấp trong bản tóm tắt. Dữ liệu trong báo cáo được sử dụng để đánh giá hàm lượng hóa chất trong các sản phẩm nhựa và so sánh với các tiêu chuẩn về lượng tiêu thụ an toàn. Những dữ liệu này có thể giúp hiểu được các rủi ro tiềm ẩn của hóa chất trong các sản phẩm nhựa, nhưng cần nhiều nghiên cứu và thử nghiệm hơn để xác định tác động chính xác của chúng đối với sức khỏe.

Tóm tắt: Trang web nhấn mạnh sự quan tâm đến hàm lượng hóa chất trong các sản phẩm nhựa và cung cấp một báo cáo thử nghiệm sơ bộ. Báo cáo này nhằm mục đích kích thích nhiều nghiên cứu và thảo luận hơn, thay vì đưa ra kết luận cuối cùng. Trang web khuyến khích người đọc thận trọng và mong đợi các nghiên cứu trong tương lai có thể cung cấp dữ liệu và kết luận chính xác hơn.

HN | Độ nóng: 255 điểm | 120 bình luận | Tác giả: homebrewer #

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

  • Một số lọ tiêu có tích hợp máy nghiền nhựa có thể nghiền nhựa vào thức ăn trong khi nghiền tiêu.
  • Máy nghiền nhựa, dù là loại dùng một lần hay sản phẩm bền, đều không nên tồn tại.
  • Tìm kiếm “máy nghiền nhựa” trên Walmart hiển thị một vài danh sách, không rõ là hộp đựng hay chính máy nghiền làm bằng nhựa.
  • Máy nghiền tiêu và máy nghiền nhục đậu khấu bằng thép của thương hiệu Peugeot có chất lượng cao.
  • Một máy nghiền tiêu tốt là một khoản đầu tư đáng giá, có thể sử dụng trong mười năm và hương vị tiêu tươi cũng ngon hơn.
  • Máy nghiền Peugeot có thiết kế bị lỗi, phần trên bị lỏng ra khi nghiền và cần phải vặn lại thường xuyên.
  • Cân nhắc sử dụng cối và chày để kiểm soát độ mịn của tiêu, không lo lắng về nhựa.
  • Một nguồn tiếp xúc với nhựa ít được thảo luận hơn có thể là máy sấy quần áo thổi các hạt vi nhựa từ quần áo tổng hợp vào không khí.
  • Nên sử dụng máy nghiền kim loại kiểu Thổ Nhĩ Kỳ nhỏ, dung tích khoảng một lượng cho một công thức nấu ăn.
  • Máy nghiền làm bằng Zamak (đồng thau và kẽm) ít nhất có hàm lượng chì thấp.
  • Nước là nguồn chính của nhựa và PFAS, cách lưu trữ và lọc nước là rất quan trọng.
  • Nếu ngân sách hạn hẹp, nên ưu tiên lọc PFAS trong nước hơn là lo lắng về vi nhựa.
  • Đã lắp đặt bộ lọc Wedell Water trên tất cả các vòi hoa sen và lắp đặt hệ thống lọc cho nước bồn rửa nhà bếp.
  • Vi nhựa xâm nhập vào cơ thể qua nước tắm bằng cách nuốt hoặc qua da.
  • 3M và DuPont nên bị trừng phạt nghiêm khắc vì gây ô nhiễm và đánh lừa công chúng.
  • Có thắc mắc về các đề xuất cụ thể cho các sản phẩm lọc nước, vì trang web cho thấy nước máy chưa lọc không tệ.
  • Sẽ kiểm tra máy nghiền tiêu giá rẻ mới mua gần đây để đảm bảo không có nhựa trong quá trình nghiền.
  • Đã chuyển từ bàn chải đánh răng nhựa sang bàn chải đánh răng tre, vì lông bàn chải nhựa cọ xát vào răng dễ khiến nhựa xâm nhập vào cơ thể.
  • Peugeot (công ty ô tô) đã sản xuất máy nghiền tiêu chất lượng cao và giá cả phải chăng trong hơn một thế kỷ.
  • Răng dường như rất cứng và cần chuyên gia sử dụng dụng cụ kim loại để xử lý.

Đạo luật NO FAKES đã thay đổi và nó còn tệ hơn #

The NO FAKES act has changed, and it’s worse

https://www.eff.org/deeplinks/2025/06/no-fakes-act-has-changed-and-its-so-much-worse

Bài viết này thảo luận về những thay đổi của “Đạo luật NO FAKES” và những tác động tiêu cực tiềm tàng của nó đối với ngôn luận và sự đổi mới trên Internet. “Đạo luật NO FAKES” nhằm mục đích giải quyết các vấn đề về thông tin sai lệch và phỉ báng do “bản sao” được tạo ra bởi trí tuệ nhân tạo (AI) tạo sinh, nhưng đạo luật này đã phát triển thành một thứ có thể thay đổi Internet mãi mãi, gây tổn hại đến ngôn luận và sự đổi mới.

“Đạo luật NO FAKES” cố gắng giải quyết những lo ngại chính đáng về “bản sao” do AI tạo sinh tạo ra bằng cách tạo ra một quyền sở hữu trí tuệ mới rộng lớn. Cách tiếp cận này là sai lầm đầu tiên: thay vì cung cấp cho mọi người các công cụ nhắm mục tiêu để bảo vệ khỏi những xuyên tạc có hại, cân bằng nhu cầu bảo vệ ngôn luận hợp pháp (như bắt chước và châm biếm), NO FAKES ban đầu đã biến thành một hệ thống cấp phép hình ảnh liên bang hóa.

Phiên bản cập nhật của đạo luật nhân đôi cách tiếp cận sai lầm ban đầu, yêu cầu thiết lập một cơ sở hạ tầng kiểm duyệt hoàn toàn mới cho hệ thống này, không chỉ bao gồm hình ảnh mà còn cả các sản phẩm và dịch vụ được sử dụng để tạo ra chúng, với rất ít biện pháp bảo vệ chống lạm dụng.

Phiên bản mới của NO FAKES yêu cầu hầu hết tất cả những người gác cổng Internet tạo ra một hệ thống sẽ: a) xóa ngôn luận sau khi nhận được thông báo; b) duy trì việc xóa bất kỳ trường hợp tái diễn nào - điều này có nghĩa là, trên hết các bộ lọc bản quyền vốn đã có nhiều thiếu sót, áp dụng một bộ lọc bản sao không thể tránh khỏi việc lọc quá mức; c) xóa các công cụ có thể được sử dụng để tạo hình ảnh; d) chỉ dựa trên tuyên bố của người bị “sao chép”, tiết lộ người dùng đã tải tài liệu lên.

Bài viết này cho rằng, đạo luật này sẽ gây ra thảm họa cho ngôn luận và sự đổi mới trên Internet.

Đạo luật nhắm vào các công cụ Phiên bản đầu tiên của NO FAKES tập trung vào các bản sao kỹ thuật số. Phiên bản mới đi xa hơn, nhắm vào các công cụ mà không có sự cho phép của cá nhân, bất kỳ ai sở hữu quyền đối với hình ảnh cá nhân hoặc được pháp luật cho phép. Bất kỳ ai sản xuất, bán hoặc lưu trữ các công cụ như vậy sẽ phải chịu trách nhiệm. Có một số hạn chế - công cụ phải được thiết kế chủ yếu để, hoặc ngoài việc tạo ra hình ảnh trái phép, chỉ có mục đích thương mại hạn chế - nhưng những hạn chế này không mang lại sự an ủi nào cho các nhà phát triển, vì họ có thể bị nhắm mục tiêu chỉ dựa trên một cáo buộc trần trụi. Các quy định này thực tế trao cho người nắm giữ quyền phủ quyết đối với sự đổi mới mà họ đã tìm kiếm từ lâu trong các cuộc chiến bản quyền, dựa trên sự hoảng loạn về công nghệ tương tự.

Thông báo gỡ xuống và nhiệm vụ lọc Phiên bản đầu tiên của NO FAKES đã thiết lập một hệ thống thông báo và gỡ xuống, mô phỏng DMCA, nhưng với ít biện pháp bảo vệ hơn. NO FAKES mở rộng nó để bao gồm nhiều nhà cung cấp dịch vụ hơn và yêu cầu các nhà cung cấp này không chỉ gỡ xuống tài liệu (hoặc công cụ) mục tiêu mà còn ngăn chặn việc tải lên chúng trong tương lai. Nói cách khác, áp dụng các bộ lọc rộng rãi hoặc mất đi bến cảng an toàn.

Bộ lọc đã là một vấn đề lớn trong bản quyền, ít nhất trong trường hợp này, nó chỉ nên làm là gắn cờ để xem xét thủ công nếu quá trình tải lên có vẻ là bản sao đầy đủ của tác phẩm. Thực tế là, các hệ thống này thường gắn cờ những thứ tương tự nhưng không giống nhau(ví dụ: hai người khác nhau chơi cùng một bản nhạc thuộc phạm vi công cộng). Chúng cũng gắn cờ vi phạm dựa trên chỉ vài giây khớp và chúng thường không xem xét bối cảnh pháp lý có thể làm cho việc sử dụng trở nên hợp pháp.

Nhưng bộ lọc bản quyền chưa được pháp luật yêu cầu. NO FAKES sẽ tạo ra một nhiệm vụ pháp lý, điều này chắc chắn sẽ dẫn đến quyền phủ quyết của những kẻ gây rối và các hình thức kiểm duyệt quá mức khác.

Mối đe dọa đối với ngôn luận ẩn danh Như hiện tại, NO FAKES cũng cho phép bất kỳ ai lấy trát đòi hầu tòa từ thư ký tòa án - không phải thẩm phán, không có bất kỳ hình thức chứng minh nào - buộc các nhà cung cấp dịch vụ giao thông tin nhận dạng về người dùng.

Chúng ta đã thấy sự lạm dụng các hệ thống tương tự. Trong các vụ bản quyền, những người không hài lòng với những lời chỉ trích sẽ lấy được trát đòi hầu tòa như vậy để bịt miệng những người chỉ trích. Thông thường, những lời chỉ trích bao gồm lời nói của chính người khiếu nại làm bằng chứng cho những lời chỉ trích, một ví dụ điển hình về sử dụng hợp lý. Nhưng trát đòi hầu tòa vẫn được ban hành và trừ khi dịch vụ rất nhạy bén, nếu không người dùng có thể bị lộ.

Điều này không chỉFurther suppress ngôn luận, việc tiết lộ bản thân cũng có thể gây hại cho người dùng. Dù là về mặt danh tiếng hay trong cuộc sống cá nhân.

Mối đe dọa đối với sự đổi mới Hầu hết chúng ta đều không hài lòng với hiện trạng của các công ty công nghệ lớn. Dường như chúng ta không chỉ ngày càng bị buộc phải sử dụng các gã khổng lồ công nghệ mà chất lượng dịch vụ của họ đang tích cực suy giảm. Bằng cách tăng số lượng cơ sở hạ tầng mà các dịch vụ mới phải tuân thủ theo luật, NO FAKES khiến bất kỳ dịch vụ mới nào thách thức các công ty công nghệ lớn trở nên khó khăn hơn. Có lẽ đây không phải là sự trùng hợp ngẫu nhiên khi một số gã khổng lồ này hài lòng với phiên bản mới của NO FAKES.

Yêu cầu loại bỏ các công cụ, ứng dụng và dịch vụ cũng có thể cản trở sự đổi mới. Đầu tiên, nó sẽ gây tổn hại cho những người sử dụng các dịch vụ này để sáng tạo hợp pháp. Thứ hai, nó sẽ ngăn cản các nhà đổi mới phát triển các công cụ mới. Ai muốn đầu tư vào một công cụ hoặc dịch vụ có thể bị buộc phải gỡ xuống chỉ dựa trên một cáo buộc?

Bài viết này cho rằng, đạo luật này đang tìm kiếm một giải pháp cho một vấn đề. Chỉ vài tháng trước, Quốc hội đã thông qua “Đạo luật Take It Down”, đạo luật này nhắm vào hình ảnh liên quan đến nội dung thân mật hoặc tình dục. Đạo luật có nhiều thiếu sót đó buộc các nền tảng phải tích cực giám sát ngôn luận trực tuyến, bao gồm cả ngôn luận hiện đang được mã hóa. Nhưng nếu Quốc hội thực sự lo lắng về những tổn hại về quyền riêng tư, thì ít nhất họ nên chờ đợi hiệu quả của quy định Internet lần trước trước khi tiến hành thêm các quy định mới. Việc Quốc hội không làm như vậy cho thấy rõ ràng rằng, điều này không phải là về việc bảo vệ các nạn nhân của các bản sao kỹ thuật số có hại.

NO FAKES được thiết kế để củng cố quyền kiểm soát đối với việc khai thác thương mại hình ảnh kỹ thuật số, thay vì ngăn chặn nó. Trong quá trình này, nó sẽ gây ra thiệt hại phụ cho tất cả chúng ta.

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

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

  • Phiên bản mới của dự luật NO FAKES yêu cầu hầu hết tất cả những người gác cổng trên mạng tạo ra một hệ thống sẽ xóa các phát ngôn ngay khi nhận được thông báo, ngăn chặn bất kỳ trường hợp tái diễn nào, áp dụng các bộ lọc sao chép quá rộng, xóa các công cụ có thể được sử dụng để tạo hình ảnh và tiết lộ danh tính của người tải lên chỉ dựa trên cáo buộc của người bị sao chép mà không có bất kỳ bằng chứng nào.
  • Các công ty nhỏ không thể triển khai hệ thống này và các công ty lớn sẽ không quan tâm đến việc triển khai.
  • Hệ thống này có thể là kết quả của việc vận động hành lang của các công ty lớn để nâng cao rào cản cạnh tranh cho các công ty nhỏ.
  • Sự chiếm đoạt quy định này là lý do tại sao các công ty lớn có xu hướng ủng hộ quy định sau khi đạt đến một quy mô/lợi nhuận/tiêu chuẩn nhất định, mặc dù chúng không như vậy khi “phá vỡ” ban đầu.
  • Hệ thống này là một ví dụ điển hình về việc các công ty lớn bảo vệ mình khỏi các tác động của quy định, trong khi các công ty nhỏ lại bị ràng buộc bởi quy định.
  • Hệ thống này sẽ được các công ty lớn sử dụng để đàn áp bất kỳ cuộc thảo luận trực tuyến nào mà chính phủ không thích.
  • Hệ thống này được thiết kế để ngăn chặn và xác định sự bất đồng chính kiến bằng cách gắn cờ bất kỳ nội dung nào là “giả”.
  • Các công ty lớn sẽ tuân theo nghĩa đen của luật, tích cực chặn bất kỳ nội dung nào bị báo cáo (sai), nhưng sẽ không tuân theo tinh thần của nó.
  • Các công ty lớn sẽ tuân theo tinh thần của luật, đó là cho các nhà chức trách biết ai là người không có khả năng chống lại, các công ty lớn chắc chắn sẽ tuân theo tinh thần này.
  • Hệ thống này sẽ được sử dụng để đàn áp những người bất đồng chính kiến, tước đoạt bục giảng và máy in của họ, yêu cầu xác định và giao những người bất đồng chính kiến cho chế độ, và khiến tất cả những người có thể bị chế độ coi là giúp đỡ những người bất đồng chính kiến thông qua hành động hoặc không hành động phải sợ hãi các biện pháp trừng phạt.
  • EFF (Electronic Frontier Foundation - Tổ chức Biên giới Điện tử) không còn quan tâm đến các vấn đề lớn về tự do Internet, mà chỉ tập trung vào các tiêu đề tiêu cực của các công ty công nghệ lớn.
  • Những lời chỉ trích của EFF đối với dự luật NO FAKES có thể không đáng tin cậy, vì sự im lặng của họ đối với các công ty công nghệ lớn và thái độ của họ đối với luật AI.
  • Khi bạn tức giận với người nói “Này, đây là một đạo luật thực sự tồi tệ” hơn là với một đạo luật thực sự tồi tệ, bạn có thể cần lùi lại một bước, hít một hơi thật sâu và có lẽ tạm thời rời khỏi Internet.
  • Ngay cả một chút mỉa mai rất nhỏ (vô ý) cũng có thể đọc gay gắt hơn so với khi viết.

Thẩm phán bác bỏ việc tạo ra “chương trình giám sát hàng loạt” gây hại cho tất cả người dùng ChatGPT #

Judge denies creating “mass surveillance program” harming all ChatGPT users

https://arstechnica.com/tech-policy/2025/06/judge-rejects-claim-that-forcing-openai-to-keep-chatgpt-logs-is-mass-surveillance/

Bài viết này thảo luận về những thách thức pháp lý mà dịch vụ ChatGPT của OpenAI đang phải đối mặt, đặc biệt là về vấn đề quyền riêng tư của người dùng và lưu giữ dữ liệu. Bài viết bắt đầu bằng việc đề cập đến việc tòa án yêu cầu OpenAI lưu giữ “vô thời hạn” tất cả nhật ký ChatGPT, bao gồm cả các cuộc trò chuyện đã xóa, quyết định này đã gây ra sự hoảng sợ cho hai người dùng, những người đã cố gắng can thiệp nhưng không thành công. Lệnh này nhằm mục đích giữ lại bằng chứng tiềm năng trong vụ kiện vi phạm bản quyền do các tổ chức tin tức đệ trình.

Bài viết tiếp tục đề cập đến việc thẩm phán Ona Wang đã bác bỏ yêu cầu của người dùng đầu tiên thay mặt cho công ty của mình vào tháng Năm, với lý do công ty nên thuê luật sư để soạn thảo tài liệu. Nhưng gần đây, Wang đã bác bỏ yêu cầu thứ hai của một người dùng ChatGPT khác, Aidan Hunt, lệnh này tiết lộ chi tiết hơn về cách thẩm phán xem xét các ý kiến phản đối lệnh và đưa ra các chi tiết trước các tranh luận bằng miệng trong tuần này, những tranh luận này được đưa ra bởi yêu cầu khẩn cấp của OpenAI.

Aidan Hunt tuyên bố rằng anh ta thỉnh thoảng gửi “thông tin cá nhân và thương mại có độ nhạy cảm cao” cho OpenAI, anh ta lập luận rằng lệnh giữ lại của Wang đã tạo ra một “chương trình giám sát hàng loạt trên toàn quốc” ảnh hưởng đến tất cả người dùng ChatGPT, những người không được cảnh báo rằng các cuộc trò chuyện đã xóa và ẩn danh của họ đột nhiên bị giữ lại. Hunt cảnh báo rằng việc giới hạn lệnh giữ lại chỉ các đầu ra của ChatGPT cũng nguy hiểm như việc bao gồm các đầu vào của người dùng, vì đầu ra “về bản chất tiết lộ và thường lặp lại rõ ràng các câu hỏi hoặc chủ đề đầu vào”.

Hunt tuyên bố rằng anh ta chỉ tình cờ phát hiện ra trên các diễn đàn trực tuyến rằng ChatGPT đã giữ lại những thông tin này, mặc dù chính sách quy định rằng họ sẽ không làm như vậy. Anh ta cảm thấy các quyền sửa đổi thứ tư và quyền thủ tục tố tụng hợp pháp của mình đã bị vi phạm, vì vậy anh ta đã cố gắng tác động đến quyết định của tòa án và đưa ra một kiến nghị yêu cầu thu hồi lệnh của Wang, lệnh này “trên thực tế yêu cầu bị cáo thực hiện một chương trình giám sát hàng loạt ảnh hưởng đến tất cả người dùng ChatGPT”.

Bài viết trích dẫn lời của Corynne McSherry, giám đốc pháp lý của tổ chức quyền kỹ thuật số Electronic Frontier Foundation, bà nói với Ars rằng lệnh khám phá này tự nó đã gây ra rủi ro thực sự cho quyền riêng tư của người dùng và là tiền lệ cho nhiều vụ kiện khác trên toàn quốc. Bà nói: “Các chatbot AI mở ra một kênh khác để các công ty giám sát, đặc biệt nếu người dùng không có quyền kiểm soát đáng kể đối với những gì xảy ra với các cuộc trò chuyện và bản ghi của họ.”

Hunt lập luận rằng Wang đã không “xem xét việc miễn trừ ‘các cuộc trò chuyện ẩn danh’, những cuộc trò chuyện được dự kiến một cách hợp lý là chứa thông tin nhạy cảm nhất và có khả năng gây tổn hại nhất của người dùng” và tuyên bố rằng điều này “cấu thành một hành động quá rộng và không hợp lý”. Ông kêu gọi thẩm phán sửa đổi lệnh, bao gồm cả việc miễn trừ này, cũng như bất kỳ cuộc trò chuyện nào thảo luận về “các chủ đề y tế, tài chính, pháp lý và cá nhân, chứa thông tin riêng tư sâu sắc của người dùng, không liên quan gì đến lợi ích mà các tổ chức tin tức nguyên đơn tuyên bố”.

Đối với Hunt và nhiều người dùng khác bị lệnh này làm cho bất ngờ, rủi ro dường như rất cao. Ông gợi ý rằng Wang nên cho phép ông can thiệp, vì “vụ án này liên quan đến các vấn đề hiến pháp quan trọng và mới lạ về quyền riêng tư của trí tuệ nhân tạo”.

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

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

  • Có vẻ như thẩm phán không hiểu ý kiến phản đối, cho rằng ngay cả khi tòa án xem xét những vấn đề này, nó cũng chỉ trì hoãn một cách không cần thiết việc giải quyết các vấn đề pháp lý thực tế.
  • Lý do thẩm phán từ chối rất kỳ lạ, bởi vì việc luật sư từ chối một điều gì đó mà không soạn thảo là trái với những gì thẩm phán nên làm.
  • “Động thái can thiệp” do người khiếu nại đưa ra không đáp ứng các yêu cầu nghiêm ngặt, thẩm phán hành động theo cách giải thích của luật pháp.
  • Thẩm phán cho rằng cá nhân có quyền tự đại diện, nhưng công ty thì không, trong khi vụ án này ban đầu do một công ty đệ trình.
  • Thẩm phán nói thêm rằng ông cho rằng những lập luận này cũng không có cơ sở.
  • Nên có luật bảo mật rất mạnh để ngăn chặn tình trạng này, ngăn chặn các lệnh của tòa án quá rộng.
  • Hãy tưởng tượng, tòa án ra lệnh cho dịch vụ hẹn hò lưu giữ tất cả các cuộc trò chuyện và tin nhắn giữa những người kết nối thông qua dịch vụ, thay vì chỉ lưu giữ các cuộc trò chuyện của những người bị cáo buộc lạm dụng.
  • Các công ty điện thoại di động đã lưu giữ tất cả các tin nhắn văn bản thông qua chúng, đây là nguyên tắc bên thứ ba.
  • Cụm từ “lưu giữ” có thể là phương ngữ địa phương, nhưng nó đã được sử dụng trong một thời gian dài ở một số nơi.
  • Quyền riêng tư có nên được ưu tiên hơn tất cả các luật khác, ví dụ như cảnh sát không thể đo tốc độ xe để bảo vệ quyền riêng tư.
  • Nên có một thứ gì đó tương tự như “quyền được lãng quên” của Châu Âu, cảnh sát có thể nhận được lệnh khám xét trong thời gian thực, nhưng điều bị phản đối là luật pháp và phán quyết yêu cầu ghi lại lịch sử của mọi người.
  • Nhà nước nên trả chi phí cho việc lưu trữ thương mại không cần thiết, nhưng trên thực tế, khi dữ liệu được yêu cầu, nhà nước sẽ trả một khoản phí rất tốt cho những bất tiện mà doanh nghiệp phải chịu.

FICO sẽ tích hợp các khoản vay mua trước trả sau vào điểm tín dụng #

FICO to incorporate buy-now-pay-later loans into credit scores

https://www.axios.com/2025/06/23/fico-credit-scores-bnpl-buy-now-pay-later

Điểm tín dụng FICO sẽ lần đầu tiên bao gồm dữ liệu về các khoản vay mua trước trả sau (BNPL). Sự thay đổi này rất quan trọng vì dự kiến sẽ có hơn 90 triệu người Mỹ sử dụng BNPL để mua sắm trong năm nay, và các nhà phê bình cho rằng điểm tín dụng hiện tại không phản ánh đầy đủ khả năng trả nợ của một cá nhân. Fair Isaac Corp. (công ty điều hành FICO) đã công bố vào thứ Hai rằng họ sẽ ra mắt hai điểm tín dụng bao gồm dữ liệu BNPL, đó là FICO Score 10 BNPL và FICO Score 10 T BNPL. Công ty tuyên bố rằng những điểm này sẽ “đại diện cho một tiến bộ đáng kể trong việc chấm điểm tín dụng, có tính đến tầm quan trọng ngày càng tăng của các khoản vay BNPL trong hệ thống tín dụng của Hoa Kỳ”. Những điểm này sẽ cung cấp cho các tổ chức cho vay một cái nhìn sâu sắc hơn về hành vi trả nợ của người tiêu dùng, từ đó hiểu toàn diện hơn về khả năng chuẩn bị tín dụng của họ, và cuối cùng là cải thiện trải nghiệm vay mượn.

Vấn đề quan trọng là, sau khi tích hợp các khoản vay BNPL, tình trạng tín dụng của người vay sẽ được cải thiện hay xấu đi? FICO và nhà cung cấp BNPL Affirm đã công bố một nghiên cứu vào tháng Hai, mô phỏng tác động của các khoản vay BNPL đối với điểm tín dụng, kết quả cho thấy “phần lớn” người tiêu dùng có từ năm khoản vay Affirm BNPL trở lên sẽ trải qua “sự cải thiện điểm tín dụng hoặc không thay đổi”. Tuy nhiên, các nhà phê bình cho rằng BNPL có thể dẫn đến “nợ ma”, có khả năng làm tổn hại đến điểm tín dụng. Cục Dự trữ Liên bang đã báo cáo vào tháng Năm rằng gần một phần tư người dùng BNPL đã thanh toán quá hạn vào năm 2024, tăng so với 18% vào năm 2023.

Tình hình hiện tại là, Affirm đã thông báo vào đầu năm nay rằng họ sẽ bắt đầu báo cáo tất cả các giao dịch mua ngắn hạn không lãi suất của mình cho cơ quan báo cáo tín dụng Experian. Nhưng những khoản vay này sẽ không ảnh hưởng ngay lập tức đến điểm tín dụng truyền thống của người tiêu dùng, mặc dù chúng có thể ảnh hưởng trong tương lai khi các mô hình chấm điểm tín dụng mới được phát triển.

Penny Lee, Giám đốc điều hành của Hiệp hội Công nghệ Tài chính, cho biết trong một tuyên bố qua email: “Thật đáng khích lệ khi thấy FICO bắt đầu hiện đại hóa mô hình chấm điểm của mình để phản ánh chính xác việc người tiêu dùng sử dụng mua trước trả sau. Ngành công nghiệp từ lâu đã tin rằng những người tiêu dùng sử dụng BNPL một cách có trách nhiệm nên được hưởng lợi từ điểm tín dụng tích cực, vì hầu hết người dùng đều thanh toán đầy đủ và đúng hạn.”

HN | Độ nóng: 237 điểm | 551 bình luận | Tác giả: cebert #

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

  • Tín dụng nên được dùng để kiếm tiền thay vì trì hoãn công việc, người bình thường sử dụng tín dụng để tiêu dùng thay vì đầu tư, cuối cùng dẫn đến thâm hụt thời gian.
  • Toàn bộ hệ thống dựa trên tăng trưởng và tiêu dùng, rất khó để trách người bình thường.
  • Mọi người nên hoài nghi về quảng cáo và truyền thông, nhưng lại thiếu tư duy phản biện.
  • Giáo dục ở trường học thiếu nội dung bồi dưỡng sự hoài nghi và tư duy phản biện.
  • Sự hoài nghi trên mạng xã hội giống với sự hoang tưởng hơn là tư duy phản biện.
  • Giáo dục về tín dụng có liên quan đến sự suy giảm của giáo dục nghệ thuật tự do.
  • Các nhà lãnh đạo giáo dục nghệ thuật tự do đã từ bỏ tư duy phản biện trong thời kỳ đại dịch, dẫn đến sự không tin tưởng của công chúng đối với họ.
  • Một số chính sách trong đại dịch, chẳng hạn như việc đóng cửa bãi biển và công viên, là các biện pháp an toàn thiển cận.
  • Các biện pháp ứng phó với đại dịch bị chính trị hóa, dẫn đến sự không tin tưởng không cần thiết.
  • Các bãi biển ở Anh không bị hạn chế, khác với ở Mỹ.

Chuyển Pip sang Uv trong Ứng dụng Flask / Django được Docker hóa #

Switching Pip to Uv in a Dockerized Flask / Django App

https://nickjanetakis.com/blog/switching-pip-to-uv-in-a-dockerized-flask-or-django-app

Bài viết này nói về cách thay thế pip bằng uv trong Docker container để tăng tốc độ build cho các ứng dụng Flask và Django. Tác giả Nick Janetakis nhận thấy rằng việc sử dụng uv có thể mang lại tốc độ nhanh hơn khoảng 10 lần và tránh được việc sử dụng môi trường ảo (venv), đồng thời cho phép chạy ứng dụng với tư cách người dùng không phải root.

Bài viết bắt đầu bằng cách giới thiệu cách xác định các dependency của dự án. Tác giả khuyên nên tạo một file pyproject.toml và nhập các dependency và phiên bản của chúng vào đó, sau đó xóa file requirements.txt. uv sẽ tự động tạo một file lock, tương tự như file được tạo bởi pip freeze, nhưng file lock của uv có cây dependency chính xác hơn và tốt hơn.

Tiếp theo, bài viết thảo luận về việc sửa đổi Dockerfile. Tác giả nhấn mạnh tầm quan trọng của thứ tự các bước, chẳng hạn như xác định các biến môi trường trước khi cài đặt các dependency. Bài viết cung cấp các ví dụ về cách cài đặt các binary uv và uvx, đồng thời giải thích lý do tại sao chỉ cần các binary được biên dịch tĩnh. Đồng thời, bài viết cũng đề cập đến cách tham chiếu đến các file dependency của uv, cũng như cách thiết lập các biến môi trường để biên dịch các file nguồn Python thành bytecode và hướng dẫn uv không tạo môi trường ảo.

Bài viết cũng giới thiệu cách sửa đổi lệnh cài đặt dependency. Tác giả cung cấp một ví dụ về shell script để cập nhật file lock khi build hoặc runtime. Script đảm bảo rằng có một file lock hợp lệ, mới nhất và sử dụng lệnh uv sync để đồng bộ hóa các dependency, thay vì sử dụng các sub-command của pip.

Bài viết tiếp tục thảo luận về cách thêm, cập nhật hoặc xóa các dependency. Tác giả cung cấp một số shortcut để chạy script, đây là các shell script được sử dụng để chạy các lệnh cụ thể trong container. Ví dụ: bạn có thể sử dụng các script này để build image mới, cập nhật file lock, thực thi các lệnh uv, v.v.

Cuối cùng, bài viết cung cấp một video demo, trình bày cách chạy các lệnh này cùng nhau và cung cấp dấu thời gian của video để người đọc có thể nhanh chóng chuyển đến các phần mà họ quan tâm. Nội dung video bao gồm giới thiệu về uv, cách sử dụng pyproject.toml để thay thế requirements.txt, cách cài đặt uv trong Dockerfile, thiết lập biến môi trường, sử dụng các lệnh uv lock/sync, phương pháp cập nhật package, kiểm tra các package đã lỗi thời và cách sử dụng uv add để thêm hoặc cập nhật package, v.v.

Cuối bài viết, tác giả mời người đọc chia sẻ kinh nghiệm chuyển sang uv của họ và cung cấp tùy chọn đăng ký cập nhật để người đọc không bỏ lỡ bất kỳ mẹo, thủ thuật hoặc hướng dẫn nào.

HN | Độ nóng: 233 điểm | 141 bình luận | Tác giả: tosh #

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

  • uv có thể thay thế pyenv, virtualenv và pip, không cần thay đổi file khóa/cấu hình dự án
  • Tính linh hoạt và tốc độ của uv được khen ngợi, cài đặt nhanh hơn so với pip
  • Có người thấy poetry tuy tốt nhưng cũng có khuyết điểm, ví dụ như xung đột hợp nhất trong file khóa
  • Sự tiện lợi của uv được đề cập, nhưng có người phản ánh uv pip tốc độ chậm, có thể liên quan đến mạng
  • Có người thắc mắc uv có cần file phiên bản Python không, vì uv có thể đọc thông tin phiên bản trong pyproject.toml
  • Có người chỉ ra uv lock khi lệnh thất bại sẽ xuất ra thông tin lỗi hữu ích, và được script chấm dứt thực thi
  • Có người đề cập đến việc xử lý lỗi của lệnh uv lock –check, cho rằng nên tránh lặp lại việc xuất lỗi
  • Có người đề xuất khi file uv.lock bị thiếu hoặc hết hạn nên được xử lý bởi người quen thuộc với dự án, thay vì tự động cập nhật
  • Có người chỉ ra tác giả đã sửa đổi nội dung bài viết, giải quyết các vấn đề đã thảo luận trước đó
  • Có người nghi ngờ tại sao tác giả lại giả vờ như các vấn đề trước đây không tồn tại
  • Có người đề cập đến tùy chọn –locked của lệnh uv sync có thể ngăn việc tự động cập nhật khi file khóa không tồn tại hoặc hết hạn
  • Có người nhấn mạnh trong dự án Python, file khóa nên được commit vào kiểm soát phiên bản
Facebook X