2025-07-15 Top Stories #

Kiro là một IDE (môi trường phát triển tích hợp) AI mới, giúp các nhà phát triển chuyển đổi từ giai đoạn tạo mẫu sang sản xuất thông qua phương pháp phát triển dựa trên đặc tả và cung cấp chức năng kiểm tra lỗi tự động.
Cảnh sát San Francisco và Oakland bị cáo buộc cung cấp trái phép dữ liệu biển số xe cho các cơ quan liên bang, vi phạm luật pháp California, gây ra tranh cãi về quyền riêng tư và giám sát.
Apple vẫn hạn chế các công cụ trình duyệt của bên thứ ba theo Đạo luật Thị trường Kỹ thuật số, cản trở cạnh tranh và bảo vệ thị phần của Safari.
OpenCut là một giải pháp thay thế CapCut mã nguồn mở, chú trọng bảo vệ quyền riêng tư, các tính năng miễn phí, áp dụng cho nhiều nền tảng và cung cấp hướng dẫn phát triển chi tiết.
Các loại thuốc GLP-1 tác động đến ngành bảo hiểm nhân thọ thông qua việc cải thiện các chỉ số sức khỏe, các công ty bảo hiểm đang điều chỉnh chiến lược bảo lãnh để đối phó với các rủi ro tiềm ẩn.
Bài viết này là hướng dẫn nhập môn học ngôn ngữ hợp ngữ x86-64, giới thiệu các kiến thức cơ bản như lựa chọn công cụ, thanh ghi, địa chỉ bộ nhớ và tập lệnh.
Các nhà môi giới dữ liệu thu thập thông tin chuyến bay của hành khách thông qua các công ty báo cáo hàng không và bán cho CBP và ICE, gây ra lo ngại về quyền riêng tư và pháp lý.
Refine là một trợ lý viết lách cục bộ, được thiết kế riêng cho Mac, sử dụng mô hình AI cục bộ để đảm bảo quyền riêng tư, hỗ trợ tích hợp nhiều ứng dụng, mua một lần không cần đăng ký.
Django đang kỷ niệm 20 năm thành lập, là một framework trưởng thành, nó đã hỗ trợ sự nghiệp của vô số nhà phát triển và có kế hoạch tiếp tục mở rộng hệ sinh thái của mình.
Bài viết này chia sẻ kinh nghiệm xây dựng phần mềm nhanh chóng, nhấn mạnh tầm quan trọng của việc bắt đầu từ bản nháp, giảm bớt chức năng và tránh trừu tượng hóa quá mức để đạt được hiệu quả phát triển cao.

Kiro: Một IDE đại diện mới #

Kiro: A new agentic IDE

Bài viết này giới thiệu một môi trường phát triển tích hợp (IDE) AI mới có tên là Kiro, được thiết kế để giúp các nhà phát triển từ giai đoạn tạo mẫu đến giai đoạn sản xuất. Ưu điểm cốt lõi của Kiro nằm ở phương pháp phát triển dựa trên đặc tả (specification-driven development), thông qua các tính năng đặc tả (specs) và móc (hooks), giúp cho việc chuyển đổi từ nguyên mẫu sang hệ thống sản xuất diễn ra suôn sẻ.

Bài viết bắt đầu bằng việc mô tả những thách thức mà các nhà phát triển phải đối mặt khi chuyển ứng dụng từ giai đoạn tạo mẫu sang giai đoạn sản xuất, chẳng hạn như các giả định khi xây dựng mô hình, sự mơ hồ của các yêu cầu và tác động của thiết kế hệ thống đến môi trường và hiệu suất. Kiro giúp các nhà phát triển suy nghĩ tốt hơn về các quyết định thông qua phát triển dựa trên đặc tả, từ đó xây dựng các ứng dụng dễ bảo trì.

Các đặc tả (specs) của Kiro là các công cụ giúp các nhà phát triển suy nghĩ sâu sắc về các chức năng, lập kế hoạch cho công việc tái cấu trúc hoặc hiểu hành vi của hệ thống. Chúng tương tự như các đặc tả mà các nhà phát triển sử dụng khi xây dựng ứng dụng, có thể hướng dẫn các AI agent thực hiện các chức năng tốt hơn. Các móc (hooks) của Kiro giống như các nhà phát triển giàu kinh nghiệm, âm thầm nắm bắt những điều bạn có thể bỏ lỡ hoặc hoàn thành các tác vụ mẫu.

Bài viết tiếp tục giới thiệu chi tiết ba bước sử dụng Kiro để phát triển:

Từ một gợi ý duy nhất đến các yêu cầu: Kiro có thể giải nén các yêu cầu từ một gợi ý đơn giản, chẳng hạn như nhập “thêm hệ thống đánh giá cho sản phẩm”, nó sẽ tạo ra các user story, bao gồm xem, tạo, lọc và xếp hạng đánh giá. Mỗi user story đều chứa các tiêu chí chấp nhận được gắn thẻ EARS (Easy Approach to Requirements Syntax), bao gồm các trường hợp ngoại lệ mà các nhà phát triển thường xử lý khi xây dựng từ các user story cơ bản.
Thiết kế kỹ thuật dựa trên yêu cầu: Kiro tạo ra tài liệu thiết kế bằng cách phân tích codebase và các yêu cầu đặc tả đã được phê duyệt, tạo ra sơ đồ luồng dữ liệu, giao diện TypeScript, kiến trúc database và các API endpoint, chẳng hạn như giao diện Review của hệ thống đánh giá. Điều này loại bỏ sự chậm trễ trong quá trình phát triển thường do sự rõ ràng của các yêu cầu.
Thực hiện nhiệm vụ: Kiro tạo ra các task và subtask, sắp xếp chúng đúng thứ tự theo các dependency và liên kết chúng với các yêu cầu. Mỗi task bao gồm các chi tiết như unit test, integration test, trạng thái tải, khả năng đáp ứng trên thiết bị di động và các yêu cầu về khả năng truy cập. Kiro đơn giản hóa toàn bộ quy trình bằng cách tự động tạo các task và subtask, sắp xếp chúng đúng thứ tự và liên kết chúng trở lại các yêu cầu.

Bài viết cũng đề cập rằng các đặc tả của Kiro được đồng bộ hóa với codebase đang phát triển, các nhà phát triển có thể viết code và yêu cầu Kiro cập nhật các đặc tả hoặc cập nhật thủ công các đặc tả để làm mới các task. Điều này giải quyết vấn đề phổ biến là các nhà phát triển ngừng cập nhật các artifact ban đầu trong quá trình thực hiện, dẫn đến tài liệu không khớp, làm tăng thêm sự phức tạp cho việc bảo trì trong tương lai.

Cuối cùng, bài viết nhấn mạnh tính năng móc (hooks) của Kiro, chúng giúp các nhà phát triển kiểm tra các vấn đề tiềm ẩn trước khi commit code, chẳng hạn như liệu các test đã được cập nhật hay chưa, tài liệu đã được cập nhật hay chưa, v.v. Các móc của Kiro giống như các nhà phát triển giàu kinh nghiệm, nắm bắt những điều bạn có thể bỏ lỡ. Hooks là tự động hóa dựa trên sự kiện, chúng được thực thi khi lưu hoặc tạo tệp, tương tự như giao nhiệm vụ cho cộng tác viên. Thiết lập hooks một lần và Kiro sẽ xử lý phần còn lại. Ví dụ: khi bạn lưu một React component, hook sẽ cập nhật tệp test; khi bạn sửa đổi một API endpoint, hook sẽ làm mới tệp README; khi bạn chuẩn bị commit, hook bảo mật sẽ quét các thông tin xác thực bị lộ. Hooks đảm bảo tính nhất quán cho toàn bộ nhóm, mọi người đều được hưởng lợi từ cùng một kiểm tra chất lượng, tiêu chuẩn code và các bản sửa lỗi xác thực bảo mật.

HN | Độ nóng: 641 điểm | 281 bình luận | Tác giả: QuinnyPig #

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

Câu hỏi thường gặp của Kiro nhấn mạnh rằng nội dung của người dùng Pro hoặc Pro+ sẽ không được sử dụng để huấn luyện các mô hình cơ bản, nhưng AWS có thể thu thập dữ liệu sử dụng để cải thiện dịch vụ và người dùng có thể chọn không tham gia thu thập dữ liệu.
Có quan điểm cho rằng, mặc dù công ty cho rằng dữ liệu ngữ cảnh của các công cụ này có giá trị, nhưng hiệu quả thực tế của nó như dữ liệu huấn luyện có thể bị hạn chế, vì phần lớn đầu vào có thể chỉ là đầu ra của LLM trước đó.
Có người dùng hỏi làm thế nào để thoát khỏi việc chia sẻ dữ liệu đo từ xa trong Kiro, và các bước cụ thể đã được cung cấp.
NathanKP đã chia sẻ tính năng “phát triển hướng theo đặc tả” của Kiro và trình bày một kho mã được viết gần như hoàn toàn bởi AI.
Có người dùng cho biết, sẽ rất hữu ích nếu Kiro có thể chạy hoàn toàn cục bộ và sử dụng khóa API của riêng họ.
Có người dùng đề cập rằng, công ty của họ không thể sử dụng các công cụ IDE dựa trên đám mây do các hạn chế của NDA, và hy vọng Kiro có thể cung cấp các tùy chọn BYOK (Bring Your Own Key - Tự mang khóa của bạn) và BYOIE (Bring Your Own Inference Endpoint - Tự mang điểm cuối suy luận của bạn).
Có người dùng hỏi Kiro sử dụng mô hình nào và liệu các mô hình này có đủ mạnh hay không.
Có người dùng phản hồi rằng, việc di chuyển các quy tắc tùy chỉnh từ các tác nhân lập trình khác là rào cản lớn nhất khiến họ không muốn thử các tác nhân mã hóa mới, và họ hy vọng có một quy trình di chuyển tốt hơn.
NathanKP trả lời rằng, tính năng “chuyển đổi quy tắc” của Kiro có thể giúp người dùng viết các quy tắc chuyển đổi và các quy tắc được tạo tự động rất hữu ích cho các dự án lớn.
Có người dùng lo ngại rằng, ngay cả khi Kiro có thể tự động di chuyển các tệp, nó cũng có thể dẫn đến hai đặc tả ý định khác nhau, gây ra vấn đề.
Có người dùng cho rằng, theo thời gian, các quy tắc và đặc tả ý định của các công cụ này sẽ trở nên tiêu chuẩn hơn.

Cảnh sát Oakland đã cung cấp dữ liệu biển số xe cho ICE; SFPD cũng chia sẻ trái phép với liên bang #

Oakland cops gave ICE license plate data; SFPD also illegally shared with feds

https://sfstandard.com/2025/07/14/oakland-san-francisco-ice-license-plate-readers/

Cảnh sát San Francisco và Oakland Cung Cấp Dữ Liệu Biển Số Xe Cho Các Cơ Quan Liên Bang Bất Hợp Pháp

Theo các hồ sơ mà The Standard thu được thông qua yêu cầu hồ sơ công khai, cảnh sát San Francisco và Oakland dường như đã nhiều lần vi phạm luật tiểu bang khi chia sẻ dữ liệu từ camera nhận dạng biển số xe tự động với các cơ quan thực thi pháp luật liên bang. Hồ sơ cho thấy, kể từ khi lắp đặt hàng trăm máy đọc biển số xe vào năm ngoái, các sở này đã chia sẻ dữ liệu cho các cuộc điều tra của bảy cơ quan liên bang, bao gồm cả Cục Điều tra Liên bang (FBI). Trong ít nhất một trường hợp, Sở Cảnh sát Oakland đã đáp ứng yêu cầu liên quan đến cuộc điều tra của Cơ quan Thực thi Di trú và Hải quan (ICE).

Theo luật tiểu bang cách đây một thập kỷ, cảnh sát California bị cấm chia sẻ dữ liệu từ máy đọc biển số xe tự động với các cơ quan ngoài tiểu bang và liên bang. Tổng chưởng lý tiểu bang Rob Bonta đã xác nhận điều này trong một thông báo gửi cho cảnh sát vào năm 2023.

Những camera do Flock Safety sản xuất này ghi lại biển số xe của mọi chiếc xe đi qua chúng, sau đó lưu trữ thông tin trong cơ sở dữ liệu để cảnh sát sử dụng cho các cuộc điều tra. Các nhà bảo vệ quyền riêng tư và các quan chức dân cử đã chỉ trích việc các cơ quan thực thi pháp luật ở California xử lý dữ liệu không đúng cách. Nhưng vấn đề này đã nhận được sự chú ý mới sau khi 404 Media đưa tin vào tháng 5 rằng ICE có thể truy cập thông tin từ mạng lưới camera toàn quốc do Flock có trụ sở tại Atlanta sản xuất.

Hồ sơ mà The Standard thu được cho thấy mọi trường hợp Sở Cảnh sát Oakland tìm kiếm mạng lưới máy đọc biển số xe của mình hoặc cho phép các cơ quan khác truy cập dữ liệu của mình. Mỗi hồ sơ bao gồm cơ quan yêu cầu, lý do yêu cầu, thời gian gửi và số lượng mạng lưới Flock có trong tìm kiếm. Trong hầu hết các trường hợp, Sở Cảnh sát Oakland không trực tiếp chia sẻ thông tin với các cơ quan liên bang. Thay vào đó, các sở cảnh sát khác của California đã thay mặt các đồng nghiệp liên bang tìm kiếm hệ thống Oakland hơn 200 lần, với các lý do được đưa ra như “điều tra của FBI”, điều này dường như phản ánh chiến thuật mà 404 Media đã báo cáo lần đầu tiên, đó là các cơ quan liên bang không có hợp đồng với Flock đã chuyển sang cảnh sát địa phương để tìm kiếm quyền truy cập cửa sau.

Tuy nhiên, nhân viên của Sở Cảnh sát Oakland đã hai lần tìm kiếm hệ thống của họ một cách rõ ràng thay mặt cho FBI. Sở Cảnh sát Oakland đã chia sẻ dữ liệu với các cơ quan liên bang ngay sau khi camera được kích hoạt vào tháng 8 năm 2024. Hai nhật ký sớm nhất của OPD là các tìm kiếm vào ngày 16 tháng 9, trong đó Sở Cảnh sát San Francisco thay mặt cho các điều tra viên của FBI và Cục Rượu, Thuốc lá, Súng và Chất nổ Liên bang trích xuất dữ liệu từ camera của Oakland.

Sở Cảnh sát San Francisco kể từ đó đã thay mặt cho Cơ quan Phòng chống Ma túy, Cơ quan Cảnh sát Tư pháp Hoa Kỳ, Cảnh sát Công viên Hoa Kỳ và Cơ quan Kiểm tra Bưu điện Hoa Kỳ tìm kiếm hệ thống của OPD. Vào ngày 22 tháng 4, một cuộc tìm kiếm hệ thống OPD của Tuần tra Đường cao tốc California được liệt kê là “vụ án ICE” mà không có thêm giải thích nào. Người phát ngôn của Tuần tra Đường cao tốc California cho biết cơ quan này đang “tích cực điều tra” cuộc tìm kiếm này sau khi The Standard đưa ra yêu cầu bình luận. Người phát ngôn viết: “Nếu bất kỳ nhân viên CHP nào yêu cầu dữ liệu biển số xe thay mặt cho ICE cho mục đích thực thi luật di trú, đó sẽ là hành vi vi phạm trắng trợn luật tiểu bang và chính sách lâu dài của bộ.” “Nếu những cáo buộc này được chứng minh là đúng, sẽ có hậu quả.”

Sở Cảnh sát San Francisco vẫn chưa trả lời yêu cầu của The Standard để có được hồ sơ của mình, yêu cầu này đã được đưa ra hơn một tháng trước, nhưng hồ sơ của OPD cho thấy cảnh sát San Francisco đã truy cập dữ liệu của Oakland ít nhất 100 lần thay mặt cho các cơ quan liên bang. Người phát ngôn của OPD viết: “OPD sẽ xem xét kỹ lưỡng thông tin này để xác định xem có bất kỳ hành động nào không phù hợp với chính sách của chúng tôi hay không.” “Chúng tôi cũng sẽ hợp tác với các cơ quan bên ngoài để xác định bất kỳ vấn đề tiềm ẩn nào và đảm bảo trách nhiệm giải trình.”

Người phát ngôn của Sở Cảnh sát San Francisco cho biết bộ này “hiện đang xem xét thông tin này.” Người phát ngôn viết: “Chúng tôi rất coi trọng quyền riêng tư và chúng tôi có các chính sách mạnh mẽ để bảo vệ thông tin cá nhân và đảm bảo việc sử dụng công nghệ giám sát một cách có trách nhiệm và hợp pháp.”

Adam Schwartz, giám đốc kiện tụng về quyền riêng tư tại Electronic Frontier Foundation, xác nhận rằng Dự luật Thượng viện 34 năm 2015 cấm cảnh sát California chia sẻ dữ liệu từ máy đọc biển số xe tự động với các cơ quan ngoài tiểu bang và liên bang, bất kể họ dự định làm gì với dữ liệu đó hoặc họ có làm việc trong một lực lượng đặc nhiệm chung hay không. Schwartz nói: “Chỉ vì Oakland thu thập dữ liệu ALPR để giải quyết tội phạm địa phương, không có nghĩa là đó là một bữa tiệc buffet ‘ai đến trước được phục vụ trước’.”

Oakland và San Francisco đã ký hợp đồng lắp đặt hàng trăm camera Flock vào tháng 3 năm 2024. Các quan chức thành phố đã quảng cáo khả năng của những camera này trong việc ngăn chặn các vụ nổ súng, cướp bóc và giận dữ trên đường. Thật vậy, hồ sơ cho thấy phần lớn các cuộc tìm kiếm do Sở Cảnh sát San Francisco và Oakland thực hiện đều liên quan đến việc thực thi luật tội phạm địa phương. Nhưng những camera này đã bị các nhà bảo vệ quyền riêng tư chỉ trích, một số người đã đệ đơn kiện, cáo buộc vi phạm Tu chính án thứ tư.

Schwartz nói: “Chúng tôi tự hào là một nơi an toàn cho người di cư, những người tìm kiếm phá thai và những người tìm kiếm dịch vụ chăm sóc sức khỏe khẳng định giới tính.” “Để trở thành một tiểu bang trú ẩn hoàn toàn, chúng ta cũng phải là một tiểu bang trú ẩn dữ liệu.”

Nhà hoạt động của tổ chức bảo vệ quyền riêng tư Oakland, Mike Katz-Lacabe, cho biết ông muốn thấy nhiều vụ kiện hơn hoặc sự thực thi pháp luật từ các quan chức tiểu bang để buộc cảnh sát tuân thủ luật cấm chia sẻ dữ liệu với các cơ quan liên bang. Katz-Lacabe nói: “Thông thường, các vụ kiện tốn kém là điều cần thiết để các cơ quan và khu vực pháp lý thay đổi cách làm của họ.” “Trừ khi họ thực sự có trách nhiệm giải trình, tôi không nghĩ sẽ có bất kỳ thay đổi nào.”

HN | Độ nóng: 516 điểm | 434 bình luận | Tác giả: danso #

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

Hành vi của các cơ quan thực thi pháp luật có thể đoán trước được, họ luôn hành động theo cách của mình và sẽ lạm dụng dữ liệu.
Chính phủ không thể hoặc không muốn kiểm soát các cơ quan thực thi pháp luật của mình, đây là một vấn đề sâu sắc hơn.
Xâm phạm quyền riêng tư phụ thuộc vào thiện chí của những người nắm quyền, và chúng ta hoàn toàn phụ thuộc vào những người mạnh hơn chúng ta.
Hoa Kỳ có một lịch sử lâu dài về việc các cơ quan tự quyết định thực hiện các hoạt động bất hợp pháp để bảo vệ công chúng.
Cần có sự trừng phạt nhanh chóng đối với các cá nhân tham gia và các cơ quan cho phép hành vi này, nhưng trên thực tế điều này sẽ không xảy ra.
Những người có quyền lực trong chính phủ và giới kinh doanh không còn bị ràng buộc bởi luật pháp, trong khi “luật pháp và trật tự” luôn được thực thi đối với những người nhỏ bé.
Bất kỳ tập dữ liệu nào được thu thập đều có thể bị lạm dụng, vì vậy nên xem xét khả năng sử dụng sai mục đích của nó.
Công nghệ mã hóa có thể khuếch đại sự nguy hiểm của những kẻ xấu, nhưng trong một số cuộc trò chuyện, những kẻ xấu giả định này không được coi là một mối quan tâm hợp lệ.
Mã hóa giúp cứu sống mạng người, nếu việc hủy bỏ mã hóa bị ép buộc, những kẻ xấu vẫn sẽ sử dụng mã hóa bất hợp pháp.
Việc các cơ quan thực thi pháp luật sử dụng dữ liệu biển số xe để tìm và trừng phạt tội phạm có khiến chúng ta an toàn hơn hay không vẫn chưa có bằng chứng.
Yêu cầu cung cấp bằng chứng về việc các cơ quan thực thi pháp luật sử dụng dữ liệu để cứu sống mạng người, trong khi lập luận về việc mã hóa cứu sống mạng người thì không bị nghi ngờ.
Có thể dễ dàng tìm thấy các ví dụ về việc các chế độ độc tài sử dụng công nghệ thông tin để giám sát, kiểm duyệt và tuyên truyền, cũng như cách các cơ quan chính phủ Hoa Kỳ lách Tu chính án thứ tư, mua dữ liệu dân sự nhạy cảm từ các nhà môi giới dữ liệu tư nhân.

Lệnh Cấm Trình Duyệt của Apple Vẫn Tồn Tại, Ngay Cả Khi Có DMA #

Apple’s Browser Engine Ban Persists, Even Under the DMA

https://open-web-advocacy.org/blog/apples-browser-engine-ban-persists-even-under-the-dma/

Bài viết này thảo luận về hành vi của Apple theo Đạo luật Thị trường Kỹ thuật số (DMA), đặc biệt là các hạn chế của hãng đối với các trình duyệt engine của bên thứ ba. Quan điểm cốt lõi của bài viết là các quy tắc và giới hạn kỹ thuật của Apple đang cản trở các nhà sản xuất trình duyệt khác cung cấp thành công engine của riêng họ trên iOS, do đó kìm hãm sự cạnh tranh của trình duyệt và ứng dụng web.

Tóm tắt các quan điểm chính: #

Kiểm soát thị trường của Apple: Trình duyệt Safari là một sản phẩm có lợi nhuận cao của Apple, lợi nhuận hoạt động hàng năm chiếm 14-16%, và Apple kiếm được 20 tỷ đô la Mỹ mỗi năm từ công cụ tìm kiếm của Google. Apple hy vọng sẽ bảo vệ thị phần của mình bằng cách hạn chế sự cạnh tranh của các trình duyệt khác, tránh mất người dùng Safari.
Lệnh cấm đối với các engine trình duyệt của bên thứ ba: Apple cấm các trình duyệt của bên thứ ba sử dụng engine trình duyệt của riêng họ trên iOS, điều này dẫn đến việc các trình duyệt này bị hạn chế về hiệu suất và chức năng, do đó không thể cạnh tranh công bằng với các ứng dụng gốc. Mặc dù Apple tuyên bố tại hội thảo DMA rằng họ không rõ tại sao không có nhà sản xuất trình duyệt nào chuyển engine sang iOS, nhưng trên thực tế, Apple hiểu những trở ngại này và chọn không giải quyết chúng.
Các rào cản kỹ thuật và hợp đồng: Các nhà sản xuất trình duyệt của bên thứ ba phải đối mặt với nhiều rào cản khi chuyển engine của họ sang iOS, chẳng hạn như: phải tạo một ứng dụng hoàn toàn mới, do đó từ bỏ người dùng hiện tại và bắt đầu lại. Không có cơ hội thử nghiệm bên ngoài EU, ảnh hưởng đến công việc của nhà phát triển. Khó đảm bảo có thể nhận được các bản cập nhật trình duyệt (chẳng hạn như bản vá bảo mật) khi người dùng đi du lịch. Các điều khoản hợp đồng khắc nghiệt, thường không phù hợp với các yêu cầu của DMA.
Các quy định liên quan của DMA: Theo Điều 5 (7) của DMA, Apple không được yêu cầu người dùng sử dụng engine trình duyệt của mình, nhưng trên thực tế, các điều kiện kỹ thuật và hợp đồng mà Apple áp đặt khiến cho các trình duyệt của bên thứ ba không khả thi về mặt kinh tế. DMA không chỉ yêu cầu tuân thủ bề ngoài mà còn yêu cầu thúc đẩy cạnh tranh một cách thực chất, các biện pháp của Apple đã không đạt được mục tiêu này một cách hiệu quả.
Ý kiến phản đối và trách nhiệm pháp lý: Trong 15 tháng qua, không có nhà sản xuất trình duyệt nào thành công trong việc chuyển engine của riêng họ sang iOS, điều này cho thấy sự không tuân thủ của Apple trong hoạt động thực tế. Apple cần thực hiện các nghĩa vụ pháp lý của mình và loại bỏ các hạn chế đối với engine của bên thứ ba, nhưng cần có áp lực bên ngoài để thúc đẩy hành động của họ.
Tại sao điều này quan trọng: Đảm bảo cạnh tranh công bằng giữa các trình duyệt web là một biện pháp quan trọng để duy trì một Internet mở. Chỉ khi các nhà sản xuất trình duyệt khác nhau được phép cạnh tranh công bằng, các ứng dụng web mới có thể thực sự phát huy hết tiềm năng của mình. Nếu Apple tiếp tục hạn chế cạnh tranh, kết quả sẽ ảnh hưởng đến khả năng truy cập nội dung và dịch vụ Internet của người dùng trên toàn thế giới.

Tóm lại, bài viết nhấn mạnh trách nhiệm và nghĩa vụ của Apple theo DMA, đồng thời cho rằng Apple cần thực hiện các biện pháp để loại bỏ các hạn chế đối với engine trình duyệt của bên thứ ba, nhằm thúc đẩy cạnh tranh thị trường và bảo vệ quyền lợi của người tiêu dùng.

HN | Độ nóng: 471 điểm | 338 bình luận | Tác giả: yashghelani #

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

Google tích cực quảng bá trình duyệt Chrome trên iOS, ngay cả khi Chrome trên iOS vẫn sử dụng WebKit.
Apple ép buộc sử dụng Apple Maps trong iMessage, không cho phép chia sẻ lên Google Maps.
Một số người dùng phản ánh rằng khi nhấp vào địa chỉ, ứng dụng mặc định được mở là ứng dụng “Điều hướng” mặc định, nếu đặt Google Maps làm mặc định, thì khi nhấp vào địa chỉ sẽ mở Google Maps.
Một số người dùng ở New Zealand và Hoa Kỳ cho biết họ không tìm thấy tùy chọn cài đặt mặc định cho ứng dụng điều hướng.
Google Maps không đăng ký nhà cung cấp chia sẻ, do đó không thể chia sẻ trực tiếp từ tin nhắn lên Google Maps.
Apple, Google và Microsoft đều đang quảng bá trình duyệt của riêng mình, điều này không thân thiện với người dùng.
Người dùng không muốn Google Maps hoặc trang web của Google nhắc mở Google Maps.
Apple cho phép cài đặt ứng dụng bản đồ mặc định ở Liên minh Châu Âu, nhưng không cho phép ở Hoa Kỳ.
Việc Apple quảng bá Apple Maps có thể là để tăng tính gắn bó của người dùng, khả năng kiếm tiền trong tương lai và làm suy yếu đối thủ cạnh tranh.
Apple Maps hiện tại không có quảng cáo, nhưng có thể sẽ có trong tương lai.
Apple cung cấp dịch vụ miễn phí thông qua iMessage, mặc dù không trực tiếp kiếm lợi nhuận từ iMessage, nhưng cũng không phải là vì mục đích từ thiện.
Người dùng mong muốn có một ứng dụng bản đồ không xâm phạm quyền riêng tư.
Một số người dùng đã giới thiệu Organic Maps dựa trên OpenStreetMap, chú trọng bảo vệ quyền riêng tư.
Apple cho phép các hành vi thù địch của người dùng trong ứng dụng, người dùng mong muốn Apple quản lý chặt chẽ hơn.
Việc ứng dụng tùy chỉnh menu chia sẻ có thể là để theo dõi dịch vụ mà người dùng chia sẻ.
Việc ứng dụng tùy chỉnh menu chia sẻ cũng có thể là để thêm hình mờ vào ảnh được chia sẻ.

OpenCut: Giải pháp thay thế CapCut mã nguồn mở #

OpenCut: The open-source CapCut alternative

https://github.com/OpenCut-app/OpenCut

OpenCut là một trình chỉnh sửa video mã nguồn mở, phù hợp cho web, máy tính để bàn và thiết bị di động. Nó được thiết kế như một sự thay thế cho CapCut, chú trọng bảo vệ quyền riêng tư, tất cả các tính năng đều miễn phí và dễ sử dụng.

Đặc điểm #

Chỉnh sửa dựa trên dòng thời gian
Hỗ trợ đa kênh
Xem trước thời gian thực
Không có hình mờ hoặc yêu cầu đăng ký
Phân tích được cung cấp bởi Databuddy, 100% ẩn danh và không xâm phạm.

Cấu trúc dự án #

apps/web/: Ứng dụng web Next.js chính
src/components/: Các thành phần UI và trình soạn thảo
src/hooks/: Các React hook tùy chỉnh
src/lib/: Các tiện ích và logic API
src/stores/: Quản lý trạng thái (ví dụ: Zustand, v.v.)
src/types/: Các kiểu TypeScript

Bắt đầu sử dụng #

Trước khi bắt đầu, hãy đảm bảo rằng hệ thống của bạn đã cài đặt Bun, Docker và Docker Compose cũng như Node.js (như một sự thay thế cho npm).

Fork kho lưu trữ và clone về máy cục bộ
Điều hướng đến thư mục ứng dụng web: cd apps/web
Cài đặt các dependency: bun install
Khởi động máy chủ phát triển: bun run dev

Yêu cầu Node.js 18+ và phiên bản Bun mới nhất cùng với Docker (dùng cho cơ sở dữ liệu cục bộ)

Khởi động dịch vụ cơ sở dữ liệu và Redis: docker-compose up -d
Điều hướng đến thư mục ứng dụng web: cd apps/web
Sao chép .env.example sang .env.local và cấu hình các biến môi trường cần thiết.

Đóng góp #

Dự án đang phát triển nhanh chóng, với các bản cập nhật và thay đổi lớn thường xuyên. Mặc dù đánh giá cao sự quan tâm, nhưng chúng tôi khuyên bạn nên đợi cho đến khi dự án ổn định hơn trước khi đóng góp, để tránh xung đột và lãng phí nỗ lực. Hướng dẫn đóng góp nằm trong CONTRIBUTING.md.

Nhà tài trợ #

Cảm ơn Vercel vì đã hỗ trợ phần mềm mã nguồn mở.

Giấy phép #

Giấy phép MIT.

Về #

OpenCut là một giải pháp thay thế mã nguồn mở cho CapCut, bạn có thể tìm thêm thông tin tại opencut.app. Các chủ đề liên quan đến dự án này bao gồm trình chỉnh sửa, phần mềm mã nguồn mở và trình chỉnh sửa video.

HN | Độ nóng: 429 điểm | 144 bình luận | Tác giả: nateb2022 #

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

Có người cho rằng hành vi xấu trên mạng không phải là trào lưu gần đây mà đã tồn tại từ lâu.
Có người chỉ ra rằng quy tắc ứng xử (Code of Conduct) chỉ là hình thức, nhiều dự án chỉ làm cho có để đáp ứng yêu cầu của GitHub.
Có người đề cập đến việc thực thi quy tắc ứng xử không nghiêm ngặt, thông tin liên hệ không được điền, dẫn đến không thể thực hiện trên thực tế.
Có người cho rằng, ngay cả khi có người vi phạm quy tắc ứng xử, người bảo trì dự án cũng nên xử lý càng sớm càng tốt.
Có người nghi ngờ về mục đích thực tế của quy tắc ứng xử, cho rằng chúng mang tính tín hiệu xã hội nhiều hơn.
Có người cho rằng quy tắc ứng xử chỉ dùng để đánh dấu một ô, tức là đáp ứng yêu cầu của GitHub.
Có người cho rằng quy tắc ứng xử bị sử dụng như một công cụ tấn công, thay vì công cụ bảo vệ.
Có người chỉ ra rằng, ngay cả khi có người vi phạm quy tắc ứng xử, các cuộc thảo luận trong dự án vẫn diễn ra bình thường và mang tính xây dựng.
Có người đề cập đến một người được cho là người đóng góp hàng đầu thực tế chỉ thực hiện một vài thay đổi mã nhỏ.
Có người cho rằng nên loại bỏ càng sớm càng tốt những “người đóng góp” vi phạm quy tắc ứng xử.
Có người không quan tâm đến cái tên Cluely, cho rằng tranh cãi và bắt nạt trên mạng đã tồn tại từ lâu.
Có người gọi tranh cãi trực tuyến là “flamewars” và cho rằng đó là điều bình thường trong tranh cãi trên mạng.
Có người coi vấn đề nhãn hiệu trong các dự án mã nguồn mở là hợp lý, ngay cả khi dự án được tạo ra vì sở thích.
Có người cho rằng nên có thái độ cứng rắn đối với các tuyên bố nhãn hiệu không hợp pháp.
Có người chỉ ra rằng, các dự án mã nguồn mở cũng chịu sự ràng buộc của luật nhãn hiệu và có thể bị yêu cầu gỡ xuống.
Có người đề cập rằng, nếu không bảo vệ nhãn hiệu, có thể mất quyền đối với nhãn hiệu.
Có người cho rằng, luật pháp là phương tiện duy nhất để bảo vệ các dự án mã nguồn mở khỏi bị các công ty đánh cắp.
Có người gợi ý rằng, nếu tuyên bố nhãn hiệu là vô lý, nên bỏ qua hoặc chỉ ra sự vô lý của nó.
Có người cho rằng, ngay cả khi tuyên bố nhãn hiệu là vô lý, cũng nên phản hồi một cách chín chắn.

GLP-1 đang phá vỡ bảo hiểm nhân thọ #

GLP-1s are breaking life insurance

https://www.glp1digest.com/p/how-glp-1s-are-breaking-life-insurance

Bài viết này nói về cách các loại thuốc GLP-1 đang phá vỡ ngành bảo hiểm nhân thọ. Tác giả Ashwin Sharma, sau khi tham gia sự kiện công nghệ sức khỏe HLTH ở Châu Âu, đã chia sẻ những quan sát và hiểu biết của mình. Dưới đây là bản tóm tắt tiếng Việt của bài viết:

Ảnh hưởng của thuốc GLP-1 đến bảo hiểm nhân thọ

Tác giả nhận thấy tại sự kiện HLTH, mặc dù trí tuệ nhân tạo là một chủ đề nóng, nhưng ông lại quan tâm hơn đến các loại thuốc GLP-1. Trong một cuộc thảo luận nhóm về vốn cổ phần tư nhân, ông đã nghe một bình luận về cách các công ty bảo hiểm đang đối phó với sự tăng trưởng bùng nổ của thuốc giảm cân, điều này đã khiến ông đi sâu vào vấn đề này. Các tác động hạ nguồn của thuốc GLP-1 đã bị bỏ qua hoàn toàn, nhưng lại rất hấp dẫn. Tác giả đã tìm kiếm những người từ các công ty bảo hiểm tại hội nghị, và tất cả họ đều hỏi cùng một câu hỏi: Chúng ta nên xử lý vấn đề này như thế nào?

Mối lo ngại của các công ty bảo hiểm

Các công ty bảo hiểm nhân thọ có thể dự đoán thời điểm bạn qua đời với độ chính xác khoảng 98%. Độ chính xác này đến từ hàng thập kỷ dữ liệu về tử vong, họ sử dụng dữ liệu này để tính toán số tiền họ nên thu của bạn hàng năm để đảm bảo rằng số tiền họ nhận được từ bạn (và số tiền kiếm được thông qua việc đầu tư phí bảo hiểm của bạn) có thể dễ dàng trang trải số tiền họ cần thanh toán sau này. Tất nhiên, không phải ai cũng nhận được giao dịch giống nhau. Thẩm định là một nghệ thuật đen tối, cho phép các công ty bảo hiểm đánh giá xem bạn là một canh bạc tốt hay một canh bạc rủi ro. Thông thường, các nhà thẩm định dựa vào một số chỉ số sức khỏe quan trọng, chẳng hạn như Hemoglobin A1c (HbA1c), cholesterol, huyết áp và chỉ số khối cơ thể (BMI) để tính toán nguy cơ bạn chết sớm (do đó gây tốn kém cho họ).

Tác động của thuốc GLP-1

Những độc giả tinh ý có lẽ đã nhận thấy một số điều thú vị. Bốn chỉ số này chính xác là những chỉ số mà thuốc GLP-1 cải thiện. Không chỉ một chút, mà là đủ để thay đổi hoàn toàn hồ sơ rủi ro của một người sau khi sử dụng ít nhất 6 tháng. Vì vậy, nếu một người 42 tuổi nộp đơn xin bảo hiểm nhân thọ, họ tự khai BMI là 25 (khỏe mạnh), không có dữ liệu yêu cầu bồi thường bệnh tật rõ ràng, không có hồ sơ kê đơn cho thấy Sema/Tirzepatide, các xét nghiệm trong phạm vi bình thường, công ty bảo hiểm sẽ thấy một “ảo ảnh” khỏe mạnh và phê duyệt nó là rủi ro thấp. Nhưng trên thực tế, một năm trước họ bị béo phì (BMI 32), đã giảm khoảng 14 kg thông qua thuốc GLP-1 từ nhà cung cấp D2C (không được nêu chi tiết trong hồ sơ sức khỏe điện tử của họ), và vẫn có hội chứng chuyển hóa tiềm ẩn.

Các biện pháp đối phó của các công ty bảo hiểm

Biện pháp đối phó đầu tiên của các công ty bảo hiểm là thay đổi cách họ đánh giá. Thay vì hỏi những câu hỏi mơ hồ như “Cân nặng của bạn đã thay đổi bao nhiêu trong 12 tháng qua?”, họ sử dụng một kỹ thuật khoa học hành vi gọi là neo để đơn giản hóa câu hỏi. Bây giờ, họ sẽ nói: “Trong 12 tháng qua, cân nặng của bạn có thay đổi hơn 10 kg do thuốc giảm cân không?” Bằng cách thêm một tham chiếu rõ ràng (“neo 10 kg”), các nhà thẩm định giúp mọi người dễ dàng và có nhiều khả năng trả lời trung thực hơn. Nếu bạn trả lời trung thực (nhiều người không làm như vậy), công ty bảo hiểm sẽ phản hồi theo một trong ba cách: từ chối hoàn toàn bảo hiểm, yêu cầu bằng chứng cho thấy bạn có thể duy trì việc giảm cân trên thuốc GLP-1 trong ít nhất một năm hoặc thêm 2-3 điểm BMI vào hồ sơ rủi ro của bạn như một vùng đệm an toàn.

Tiền thật

Hiện tại, các công ty bảo hiểm coi thuốc GLP-1 là công cụ giảm cân ngắn hạn, vì bệnh nhân đối xử với chúng như vậy. Nhưng chúng ta biết rằng có dữ liệu chắc chắn cho thấy việc sử dụng liên tục thuốc GLP-1 có thể làm giảm đáng kể bệnh béo phì, bệnh tim mạch và tỷ lệ tử vong nói chung (gián tiếp). Nói cách khác, việc tuân thủ tốt hơn sẽ dẫn đến bệnh nhân khỏe mạnh hơn, về lâu dài, chi phí của công ty bảo hiểm sẽ thấp hơn nhiều. Các công ty bảo hiểm đã bắt đầu tích cực tìm kiếm các quan hệ đối tác này, vì điều này ổn định dự báo tài chính của họ và giảm các yêu cầu bồi thường tốn kém. Các quan hệ đối tác này có thể dễ dàng trở thành các giao dịch trị giá hàng triệu đô la, một khi thuốc generic và những người tham gia thị trường thuốc GLP-1 mới thúc đẩy giá giảm, mở ra cánh cửa cho việc phục vụ hàng trăm nghìn khách hàng mỗi tháng, khiến đây trở thành một tình huống có lợi cho bệnh nhân, công ty bảo hiểm và các công ty tư nhân.

HN | Độ nóng: 416 điểm | 556 bình luận | Tác giả: alexslobodnik #

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

Những lý do khiến mọi người ngừng sử dụng chất chủ vận GLP1 bao gồm: muốn tận hưởng lại niềm vui ăn uống, rắc rối khi sử dụng thuốc, lo ngại về tác dụng lâu dài, vấn đề giá cả và các lý do cá nhân khác.
Sự nguy hiểm của việc thừa cân bị đánh giá thấp, đặc biệt là khi nguồn cung cấp thuốc dồi dào.
Những người phản ứng tốt với Ozempic và tiếp tục sử dụng thường ít gặp các vấn đề về tâm lý hơn, trong khi những người muốn ngừng thuốc một cách khẩn trương có thể có thành phần tâm lý trong chế độ ăn uống của họ.
Mọi người có thể ăn quá nhiều do các vấn đề điều chỉnh cảm xúc, điều này có thể liên quan đến tăng cân và giảm tuổi thọ.
Bệnh nhân ADHD thường có mối quan hệ không lành mạnh với thức ăn, họ có thể có xu hướng ăn quá nhiều hoặc ít chú ý đến thức ăn.
Chất chủ vận GLP1 có thể có tiềm năng trong điều trị ADHD và chứng nghiện, vì chúng ảnh hưởng đến hệ thống khen thưởng.
Có quan điểm cho rằng, một bộ phận những người có vấn đề về cân nặng có thể đồng thời mắc ADHD, điều này có thể làm trầm trọng thêm vấn đề ăn quá nhiều của họ.
Chất chủ vận GLP-1 làm giảm cảm giác thèm ăn bằng cách ảnh hưởng đến tín hiệu hormone no, làm chậm tốc độ thức ăn đi qua dạ dày và ảnh hưởng đến phản ứng của toàn bộ cơ thể đối với các tín hiệu trao đổi chất.
Thuốc ADHD nhắm trực tiếp vào hệ thống hoạt động định hướng mục tiêu, có thể làm giảm sự thèm ăn bằng cách tăng dopamine.
Có nghiên cứu chỉ ra rằng những người sử dụng Lisdexamfetamine (một loại thuốc ADHD) đã giảm lạm dụng amphetamine thực tế.
Lisdexamfetamine không phải là amphetamine, nó khác biệt về cấu trúc hóa học, thời gian bán hủy, trải nghiệm chủ quan và nghiên cứu về tác dụng lâu dài.
Các loại thuốc giống amphetamine do bác sĩ kê đơn không nhất thiết an toàn, cần phải đánh giá dựa trên từng trường hợp cụ thể.

Cùng Học Assembly x86-64 (2020) #

Let’s Learn x86-64 Assembly (2020)

https://gpfault.net/posts/asm-tut-0.txt.html

Bài viết này là phần đầu tiên của một loạt các hướng dẫn về học ngôn ngữ hợp ngữ x86-64, trong đó tác giả chia sẻ kinh nghiệm và động lực học hợp ngữ của mình, đồng thời giới thiệu các công cụ và khái niệm cơ bản cần thiết.

Mở đầu bài viết, tác giả đề cập rằng khi anh học ngôn ngữ hợp ngữ x86 ở trường đại học, nội dung được giảng dạy đã lỗi thời. Vào thời điểm đó, bộ xử lý 64-bit đã bắt đầu trở nên phổ biến, nhưng họ vẫn đang học các công nghệ cũ như DOS, real mode, phân đoạn bộ nhớ, v.v. Mặc dù vậy, tác giả đã có thể hiểu được nội dung mà trình biên dịch xuất ra thông qua các bài học trên lớp và những năm học sau đó, điều này đã giúp anh rất nhiều. Nhưng do lệnh phong tỏa vì đại dịch toàn cầu, anh quyết định bắt đầu tự viết một số mã hợp ngữ x86 không tầm thường.

Tác giả chọn tập trung vào kiến trúc x86-64 và hoàn toàn bỏ qua các công nghệ cũ không còn phù hợp. Anh quyết định xuất bản các ghi chú học tập của mình dưới dạng hướng dẫn trên blog, vì có vẻ như có người cần loại nội dung này. Các hướng dẫn này sẽ bao gồm kiến thức về viết ngôn ngữ hợp ngữ trong các chương trình Windows 64-bit, vì tất cả các máy không dùng cho công việc của tác giả đều chạy hệ điều hành Windows và ảnh hưởng của hệ điều hành ngày càng trở nên không thể bỏ qua khi viết ngôn ngữ hợp ngữ. Tác giả sẽ cố gắng bắt đầu từ con số không, không sử dụng bất kỳ thư viện nào, chỉ cho phép gọi hệ điều hành.

Trong phần giới thiệu, tác giả thảo luận về các công cụ cần thiết để viết các hướng dẫn này, bao gồm trình hợp ngữ và trình gỡ lỗi. Anh chọn Flat Assembler (gọi tắt là FASM) làm trình hợp ngữ, vì nó nhỏ gọn, dễ lấy và sử dụng, có hệ thống macro tốt và trình soạn thảo đi kèm. Đối với trình gỡ lỗi, tác giả chọn WinDbg, một phiên bản công cụ mới hơn với giao diện thân thiện hơn.

Tiếp theo, tác giả thảo luận về một số khái niệm cơ bản trong lập trình ngôn ngữ hợp ngữ. Anh giả định rằng người đọc có một số hiểu biết về các ngôn ngữ như C hoặc C++, nhưng hầu như không tiếp xúc với ngôn ngữ hợp ngữ. Bài viết giới thiệu tập lệnh của CPU, tức là tập hợp những việc mà CPU có thể làm, cũng như tính tham số hóa và đơn giản của các lệnh. Tác giả cung cấp một mô hình kiến trúc CPU đơn giản, nhấn mạnh tầm quan trọng của việc hiểu cách các khái niệm cấp cao ánh xạ tới mô hình cấp thấp.

Bài viết cũng trình bày chi tiết về các thanh ghi trong x86-64, đặc biệt là 16 thanh ghi đa năng, mỗi thanh ghi có chiều rộng 64 bit và có thể định địa chỉ riêng các byte, từ và từ kép có thứ tự thấp. Tác giả giải thích rằng một số thanh ghi có ý nghĩa đặc biệt đối với các lệnh cụ thể, chẳng hạn như thanh ghi rsp được sử dụng cho con trỏ ngăn xếp, rsi và rdi làm chỉ mục nguồn và đích cho các lệnh thao tác chuỗi. Ngoài ra, hai thanh ghi đặc biệt rip và rflags cũng được đề cập, rip lưu địa chỉ của lệnh tiếp theo và rflags lưu các cờ khác nhau về trạng thái chương trình.

Cuối cùng, tác giả thảo luận về các khái niệm bộ nhớ và địa chỉ, coi bộ nhớ như một mảng lớn các “ô” có kích thước byte, các ô này được đánh số, được gọi là “địa chỉ bộ nhớ”. Bài viết tóm tắt ngắn gọn cách bộ xử lý x86 cũ định địa chỉ bộ nhớ, đề cập đến vấn đề thanh ghi 16 bit và địa chỉ 20 bit, cũng như cách sử dụng các thanh ghi đoạn đặc biệt và độ lệch 16 bit để có được địa chỉ “tuyến tính” 20 bit cuối cùng. Tác giả chỉ ra rằng nội dung này không còn liên quan trong kiến trúc x86-64 hiện đại, nhưng việc hiểu những kiến thức nền này sẽ giúp hiểu rõ hơn về ngôn ngữ hợp ngữ.

HN | Độ nóng: 392 điểm | 97 bình luận | Tác giả: 90s_dev #

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

Có người chia sẻ một dự án mà họ đã phát triển trong nhiều năm, một IDE trực tuyến tương tác hỗ trợ nhiều ngôn ngữ assembly, bao gồm M68K, MIPS, RISC-V và X86.
Có người hỏi tại sao không hỗ trợ ngôn ngữ assembly Z80 hoặc 6502.
Có người đề cập rằng tên miền trang web của họ nên hỗ trợ Z80.
Có người chia sẻ phần giới thiệu cơ bản về X86 assembly mà họ đã viết.
Có người yêu cầu cung cấp phiên bản PDF hoặc làm cho trang web có thể in được.
Có người cho biết in rất tốt khi tắt JS trong Firefox.
Có người bày tỏ rất thích định dạng của bài viết.
Có người nhận ra rằng họ không có máy X86 ở nhà, cảm thấy hơi buồn.
Có người đề cập rằng sử dụng qemu để học ngôn ngữ assembly là một phương pháp đơn giản và tốt.
Có người gợi ý nếu muốn học ngôn ngữ assembly, có thể xem RISC-V.
Có người tò mò về việc liệu thanh ghi chỉ mục con trỏ trong X86_64 có truy cập trực tiếp byte thấp hay không.
Có người thảo luận về việc sử dụng 8 bit cao của thanh ghi dài hơn trong mã 64 bit hầu như không có lý do, nhưng có người phản bác rằng trong chế độ 64 bit, vẫn có lý do để sử dụng 8 bit cao của giá trị 16 bit, vì không có lệnh BSWAP r16.
Có người đề xuất sử dụng ROL r/m16, 8 để hoán đổi thứ tự byte của giá trị 16 bit, nhưng chỉ ra rằng điều này sẽ thay đổi thanh ghi cờ, không giống như BSWAP và XCHG.

Các nhà môi giới dữ liệu đang bán thông tin chuyến bay cho CBP và ICE #

Data brokers are selling flight information to CBP and ICE

https://www.eff.org/deeplinks/2025/07/data-brokers-are-selling-your-flight-information-cbp-and-ice

Các nhà môi giới dữ liệu đang bán thông tin chuyến bay của bạn cho CBP và ICE

Trong nhiều năm, các nhà môi giới dữ liệu đã hoạt động trong bóng tối, khai thác các lỗ hổng trong luật bảo mật để thu thập thông tin của chúng ta—tất cả vì lợi ích riêng của họ. Họ bán các hành động chính xác của chúng ta cho nhiều tác nhân tư nhân và quốc gia khác nhau, bao gồm cả các cơ quan thực thi pháp luật, mà không có kiến thức hoặc sự đồng ý có ý nghĩa của chúng ta. Và họ không có dấu hiệu dừng lại.

Điều này khuyến khích những kẻ xấu khác. Nếu một công ty thu thập bất kỳ loại dữ liệu cá nhân nào và muốn kiếm tiền nhanh chóng, luôn có một nhà môi giới dữ liệu sẵn sàng mua và bán cho người trả giá cao nhất—thường là các cơ quan thực thi pháp luật và tình báo.

Một cuộc điều tra gần đây của 404 Media đã tiết lộ Airlines Reporting Corp (ARC), một nhà môi giới dữ liệu thuộc sở hữu và điều hành của ít nhất tám hãng hàng không lớn của Hoa Kỳ, bao gồm United Airlines và American Airlines, thu thập hồ sơ chuyến bay nội địa của hành khách và bí mật bán quyền truy cập cho Cục Hải quan và Bảo vệ Biên giới Hoa Kỳ (CBP). Mặc dù bán tên hành khách, hành trình chuyến bay đầy đủ và chi tiết tài chính, nhưng nhà môi giới dữ liệu đã ngăn chặn lực lượng biên giới Hoa Kỳ tiết lộ vai trò của mình như một nguồn thông tin. Do đó, chính phủ không chỉ bỏ qua Tu chính án thứ tư để lấy thông tin mà lẽ ra họ cần lệnh khám xét—họ còn cố gắng che giấu cách họ biết những điều này về chúng ta.

Chương trình Tình báo Du lịch (TIP) của ARC tổng hợp dữ liệu hành khách, chứa hơn 1 tỷ hồ sơ, bao gồm 39 tháng du lịch trong quá khứ và tương lai, bao gồm cả công dân Hoa Kỳ và không phải công dân Hoa Kỳ. CBP, với tư cách là một phần của Bộ An ninh Nội địa Hoa Kỳ (DHS), tuyên bố cần dữ liệu này để hỗ trợ cảnh sát địa phương và tiểu bang theo dõi những người quan tâm. Nhưng vào thời điểm lo ngại ngày càng tăng về việc tăng cường thực thi luật nhập cư tại các cửa khẩu nhập cảnh Hoa Kỳ, bao gồm cả các cuộc khám xét vô lý, các quan chức thực thi pháp luật sẽ sử dụng công cụ giám sát bổ sung này để mở rộng mạng lưới nghi ngờ đối với nhiều du khách vô tội hơn.

Hơn 200 hãng hàng không thanh toán vé máy bay thông qua ARC, liên quan đến hơn 54% thông tin chuyến bay trên toàn thế giới. Hội đồng quản trị của ARC bao gồm đại diện từ các hãng hàng không Hoa Kỳ như JetBlue và Delta, cũng như các hãng hàng không quốc tế như Lufthansa, Air France và Air Canada.

Khi bán quyền truy cập hàng loạt vào thông tin nhạy cảm này cho các cơ quan thực thi pháp luật, các hãng hàng không này—thông qua nhà môi giới dữ liệu của họ—đặt lợi nhuận của họ lên trên quyền riêng tư của hành khách. Cơ quan Thực thi Hải quan và Nhập cư Hoa Kỳ (ICE) gần đây đã trình bày chi tiết về việc họ mua dữ liệu cá nhân từ ARC. Trong bối cảnh hiện tại, điều này có thể có tác động bất lợi đến cuộc sống của mọi người.

Hành động không bị hạn chế bởi chính phủ là dấu hiệu của một xã hội tự do. Vào thời điểm hiện tại, khi chính phủ liên bang đe dọa hậu quả pháp lý dựa trên quốc tịch, tôn giáo và mối liên hệ chính trị của mọi người, bất kỳ khách hàng nào của ARC theo dõi các chuyến đi hàng không đến và đi từ Hoa Kỳ đều là công thức cho sự trả thù của quốc gia.

Đáng buồn thay, các nhà môi giới dữ liệu gây ra tác hại rộng lớn hơn cho quyền riêng tư của chúng ta. Dữ liệu vị trí nhạy cảm được thu thập từ điện thoại thông minh và bán cho cảnh sát, dữ liệu xương sống Internet được bán cho các cơ quan phản gián liên bang và cơ sở dữ liệu tiện ích chứa hồ sơ điện thoại, nước và điện được chia sẻ với các quan chức ICE.

Vào thời điểm các nhà chức trách nhập cư đang xói mòn các quyền tự do cơ bản thông qua việc tăng cường và các hành động tùy tiện ở biên giới Hoa Kỳ-Mexico, tin tức này càng làm tăng thêm lo ngại về chủ nghĩa độc đoán ngày càng tăng có thể được thúc đẩy bằng cách trích xuất dữ liệu cá nhân nhất của chúng ta—tất cả đều không có kiến thức và sự đồng ý của chúng ta.

Những phát hiện mới về việc ARC bán dữ liệu cho CBP và ICE là một lời nhắc nhở mới rằng chúng ta cần luật “ưu tiên quyền riêng tư”, quy định các hạn chế về sự đồng ý và tối thiểu hóa đối với cách các công ty xử lý dữ liệu của chúng ta. Chúng ta cũng cần thông qua Đạo luật “Tu chính án thứ tư không được bán”, ngăn chặn cảnh sát bỏ qua việc xem xét tư pháp đối với việc thu giữ dữ liệu của họ bằng cách mua dữ liệu từ các nhà môi giới. Hãy thực thi luật đăng ký nhà môi giới dữ liệu.

HN | Độ nóng: 390 điểm | 189 bình luận | Tác giả: exiguus #

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

Ngay cả khi không có quyền truy cập dữ liệu trực tiếp đặc quyền, người ta vẫn có thể tái tạo lịch sử bay của hầu hết mọi người thông qua dữ liệu truyền thông xã hội và quảng cáo.
Bằng cách lọc các cạnh không gian-thời gian trong biểu đồ thực thể có tốc độ nhỏ hơn 300 km/h hoặc khoảng cách nhỏ hơn 200 km, có thể được sử dụng làm proxy cho “trên máy bay” và ngụ ý cung cấp điểm bắt đầu và điểm kết thúc.
Các cạnh này có thể được liên kết với dữ liệu chuyến bay công khai và dữ liệu IoT bảo trì động cơ phản lực, đặt thực thể trên một chuyến bay cụ thể.
Mọi người bỏ qua việc dữ liệu IoT công nghiệp có vẻ vô hại có thể hoạt động như một proxy cho các mối quan hệ trong các lĩnh vực không liên quan.
Trong một số ít trường hợp, có thể có nhiều chuyến bay thương mại hợp lý, thông qua lịch sử bay trong quá khứ, có thể giả định đó là hãng hàng không chính mà họ thường sử dụng trong quá khứ.
Phương pháp tái tạo lịch sử bay này rất hiệu quả và không yêu cầu dữ liệu trực tiếp từ hãng hàng không hoặc phân tích đặc biệt phức tạp.
Khả năng có được dữ liệu “không gian-thời gian” tự nó đã là một vấn đề lớn hơn, tương tự như việc biết bạn đã đến cửa hàng nào thông qua lịch sử giao dịch thẻ tín dụng.
Bộ xử lý thanh toán không chỉ được phép thu thập thông tin này và liên kết nó với tên của bạn, mà còn được yêu cầu làm như vậy.
Nếu những luật này được phép tồn tại, thì hậu quả sẽ không thể tưởng tượng được khi những kẻ phát xít thực sự có được dữ liệu này.
Ngay cả khi không được yêu cầu làm như vậy, bộ xử lý thanh toán vẫn sẽ làm như vậy vì nó là một phần quan trọng của việc phát hiện gian lận.
Chúng ta không nên không làm điều gì đó chỉ vì nó sẽ gây khó khăn hơn cho việc thực thi pháp luật, điều này nghe có vẻ như muốn biến mọi người thành tội phạm.
Trong một số trường hợp, việc hỗ trợ mọi người trở thành tội phạm là đúng, chẳng hạn như Rosa Parks ngồi ở phía trước xe buýt, cuộc tuần hành của Martin Luther King và những người sáng lập Hoa Kỳ phản đối thuế của Anh.
Sự tồn tại của luật pháp cần phải được sự đồng ý của những người bị cai trị, và khi phần lớn xã hội đồng ý với một luật nào đó, thì hiệu quả thực thi pháp luật không phải là điều cần thiết.
Việc phản đối luật “giúp đỡ tội phạm” khiến xã hội phải đối mặt với những thay đổi trong định nghĩa về tội phạm, và khi có luật chống lại một chủng tộc, tôn giáo hoặc ý thức hệ chính trị cụ thể, thì nên cho phép mọi người trở thành tội phạm.
Chính phủ có nên có khả năng đóng băng tài khoản ngân hàng của người biểu tình không? Nếu việc đóng băng được thực hiện như một hình phạt tập thể, thì câu trả lời là không.
Nếu bạn muốn thực hiện một hoạt động nào đó, bạn nên có được lệnh khám xét.
Tại thời điểm này trong lịch sử loài người, việc một cá nhân có phạm tội hay không còn quan trọng không? Điều quan trọng là họ có làm hại người khác hay không.
Ước tính mỗi người trưởng thành ở Mỹ phạm nhiều trọng tội liên bang mỗi ngày, luật liên bang chứa đầy những luật vô lý và số lượng luật liên bang là không thể đếm được đối với nhân viên của Cơ quan Nghiên cứu Quốc hội.
Liệu con số cụ thể của phân tích thống kê có thực sự là trọng tâm không? Ngay cả khi ba trọng tội được thực hiện mỗi năm, thì sự khác biệt là gì nếu mỗi trọng tội có thời gian giam giữ ít nhất là một năm? Vấn đề vẫn như cũ; các công tố viên có thể dễ dàng tống bất kỳ ai vào tù vì có quá nhiều luật và không ai có thể tuân thủ hoàn toàn hoặc nhận ra khi nào họ đã vi phạm luật.

Show HN: Refine – Một Giải Pháp Thay Thế Cục Bộ cho Grammarly #

Show HN: Refine – A Local Alternative to Grammarly

https://refine.sh

RefineOpen là một trợ lý viết văn được thiết kế đặc biệt cho Mac, nó sử dụng các mô hình AI cục bộ để xử lý văn bản trên máy Mac của bạn, đảm bảo rằng nội dung viết của bạn được bảo vệ quyền riêng tư. Công cụ này không phụ thuộc vào xử lý trên đám mây, vì vậy tài liệu của bạn không rời khỏi máy Mac, không có lưu trữ máy chủ, theo dõi hoặc các vấn đề về quyền riêng tư. RefineOpen cung cấp khả năng xử lý cục bộ nhanh chóng, có được kết quả ngay lập tức mà không cần kết nối Internet và có thể hoạt động ngoại tuyến ở mọi nơi.

RefineOpen có thể tích hợp liền mạch vào các ứng dụng Mac yêu thích của bạn, không cần thiết lập, chỉ cần bắt đầu viết để nhận được các đề xuất ngữ pháp. Nó hỗ trợ nhiều ứng dụng macOS bao gồm email, tin nhắn, Safari, Chrome, Pages, Word, Slack, Notion, v.v. Giá cả đơn giản và minh bạch, mua một lần để nhận các bản cập nhật và hỗ trợ phiên bản chính, không có phí đăng ký hoặc phí ẩn. Sau khi mua, bạn có thể sử dụng trên ba thiết bị.

RefineOpen cung cấp khả năng cải thiện văn bản được hỗ trợ bởi AI, khả năng xử lý cục bộ nhanh chóng và có thể hoạt động ngoại tuyến ở mọi nơi. Hiện đang trong tháng ra mắt, cung cấp ưu đãi giảm giá 50%, giá gốc 30 đô la, hiện tại là 15 đô la. Người dùng có thể tải xuống phiên bản dùng thử miễn phí, không cần thông tin thẻ tín dụng, để trải nghiệm tất cả các chức năng.

Về quyền riêng tư, RefineOpen nhấn mạnh rằng dữ liệu của người dùng hoàn toàn riêng tư, tài liệu, văn bản và nội dung viết sẽ không rời khỏi máy Mac của người dùng. Tất cả quá trình xử lý được thực hiện cục bộ, sử dụng các mô hình ngôn ngữ lớn (LLMs) ngoại tuyến chạy trực tiếp trên máy của người dùng. RefineOpen hỗ trợ macOS 14.0 trở lên, phù hợp với Apple Silicon (như M1, M2) và Mac dựa trên Intel.

RefineOpen cung cấp bản dùng thử miễn phí 7 ngày, không cần thông tin thẻ tín dụng, người dùng có thể tải xuống ứng dụng và bắt đầu sử dụng. Đối với sinh viên và nhà giáo dục, RefineOpen cung cấp giảm giá 50%, chỉ cần cung cấp email sinh viên/giáo viên/tổ chức hiện tại qua email để đăng ký.

Nói chung, RefineOpen là một trợ lý viết văn chú trọng đến bảo vệ quyền riêng tư, nó giúp người dùng cải thiện văn bản thông qua các mô hình AI cục bộ, đồng thời đảm bảo an toàn dữ liệu, không cần lo lắng về rò rỉ quyền riêng tư.

HN | Độ nóng: 375 điểm | 186 bình luận | Tác giả: runjuu #

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

Trong tiếng Anh Mỹ, “practice” là danh từ, “practise” là động từ, trong khi ở tiếng Anh Anh thì ngược lại.
Người dân các nước không thuộc Khối Thịnh vượng chung sử dụng cách viết kiểu Anh sẽ bị coi là kiêu ngạo.
Các tổ chức quốc tế thường sử dụng tiếng Anh Mỹ.
Người châu Âu chủ yếu học tiếng Anh thông qua Hollywood, MTV, âm nhạc, video, TV và trò chơi máy tính, những nội dung này hầu hết đều là tiếng Anh Mỹ.
Nếu không có lựa chọn rõ ràng, tiếng Anh Mỹ phổ biến hơn trên toàn cầu.
Các tổ chức quốc tế có thể cố ý chọn sử dụng tiếng Anh Anh làm ngôn ngữ làm việc.
Các thành viên không thuộc Khối Thịnh vượng chung trong các tổ chức quốc tế thường sử dụng tiếng Anh Anh với phát âm kiểu Mỹ.
Nhiều công ty và tổ chức châu Âu sử dụng cách viết kiểu Mỹ.
Sự khác biệt trong cách viết tiếng Anh Anh và tiếng Anh Mỹ không ảnh hưởng đến sự hiểu, vì sự khác biệt trong cách viết không ảnh hưởng đến sự hiểu.

Chúc mừng sinh nhật lần thứ 20, Django #

Happy 20th Birthday, Django

https://www.djangoproject.com/weblog/2025/jul/13/happy-20th-birthday-django/

Chúc mừng sinh nhật lần thứ 20 của Django!

Ngày 13 tháng 7 năm 2005, Jacob Kaplan-Moss đã gửi mã đầu tiên vào kho lưu trữ công khai mà sau này trở thành Django. 20 năm và hơn 400 bản phát hành sau đó, chúng ta ở đây để kỷ niệm sinh nhật lần thứ 20 của Django! 🎉

Kỷ niệm Chúng tôi muốn chia sẻ khoảnh khắc đặc biệt này với tất cả mọi người! Trang web mới của chúng tôi “20 năm của Django” giới thiệu các sự kiện trực tuyến và tại địa phương được tổ chức trên toàn cầu trong suốt năm 2025. Ngoài ra còn có các hoạt động kỷ niệm khác! Mong đợi bánh sinh nhật 🎂 và hát bài hát mừng sinh nhật Một bài kiểm tra đặc biệt để xem ai biết nhiều nhất về những điều nhỏ nhặt của Django Giới thiệu những thành tựu tuyệt vời của cộng đồng Xem trang web sinh nhật lần thứ 20 của chúng tôi

Hỗ trợ Django Như một món quà sinh nhật, hãy cân nhắc xem bạn hoặc chủ của bạn có thể hỗ trợ dự án bằng cách quyên góp cho Tổ chức Phần mềm Django phi lợi nhuận của chúng tôi hay không. Đối với sự kiện đặc biệt này, chúng tôi muốn đặt ra một mục tiêu đặc biệt! Trong 20 ngày tới, chúng tôi muốn thấy 200 nhà tài trợ mới, mỗi người hỗ trợ Django $20 trở lên, với ít nhất 20 nhà tài trợ hàng tháng. Hãy giúp chúng tôi đạt được mục tiêu này: Quyên góp trên trang web Django Quyên góp trên GitHub Sponsors Hoặc xem cách trở thành thành viên doanh nghiệp Sau khi bạn làm như vậy, hãy đăng với hashtag #DjangoBirthday và gắn thẻ chúng tôi trên Mastodon/Bluesky/X/LinkedIn để chúng tôi có thể bày tỏ lòng biết ơn!

Tiến độ mục tiêu năm 2025 Tính đến ngày 13 tháng 7 năm 2025, mục tiêu của chúng tôi là quyên góp được 300.000 đô la, hiện tại chúng tôi đã quyên góp được 25,6% số tiền, tương đương 76.707 đô la. Đóng góp để hỗ trợ Django.

20 năm tới 20 năm là một khoảng thời gian dài trong thế giới mã nguồn mở và chúng tôi hy vọng Django sẽ tiếp tục phát triển mạnh mẽ và vẫn là một Web framework cho những người theo đuổi chủ nghĩa hoàn hảo khi ngành phát triển. Chúng tôi không biết web sẽ thay đổi như thế nào trong 20 năm tới, nhưng từ Django, bạn có thể mong đợi: Nhiều phiên bản mới, mỗi phiên bản đều có nhiều năm hỗ trợ Thêm hàng nghìn gói nữa trong hệ sinh thái đang phát triển mạnh mẽ của chúng tôi Một cộng đồng hòa nhập và hỗ trợ với hàng trăm nghìn nhà phát triển

Chúc mừng sinh nhật Django!

HN | Độ nóng: 351 điểm | 95 bình luận | Tác giả: davepeck #

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

Django đã đặt nền móng cho sự nghiệp của rất nhiều người
Django đã nhận được sự giúp đỡ từ nhiều người lạ trên Internet trong cộng đồng ban đầu
Django không có lịch sử không ổn định hoặc không an toàn, chỉ là không có danh tiếng khi là một dự án mới
Một số nhà nghiên cứu trong phòng thí nghiệm nghiên cứu có thể không phải là những lập trình viên giỏi, họ có thể đưa ra một số phương án không thực tế
Django hỗ trợ database routing, có thể được sử dụng để tránh sử dụng data lake
Django là một framework “bao gồm mọi thứ”, đã khởi động nhiều dự án, công ty và sự nghiệp thành công
Tài liệu của Django thể hiện sự đồng cảm với người dùng
Khẩu hiệu của Django “Web framework cho những người theo chủ nghĩa hoàn hảo với thời hạn chót” rất tuyệt

Cách tôi xây dựng phần mềm nhanh chóng #

How I build software quickly

https://evanhahn.com/how-i-build-software-quickly/

Bài viết này được viết bởi Evan Hahn, thảo luận về cách xây dựng phần mềm nhanh chóng trong giới hạn về thời gian và chất lượng. Tác giả chia sẻ kinh nghiệm của bản thân khi là một nhà phát triển trong một nhóm nhỏ, duy trì phần mềm trong thời gian dài, và nhấn mạnh rằng đây không phải là hướng dẫn về tạo mẫu nhanh, mà là chia sẻ dựa trên kinh nghiệm cá nhân. “Phần mềm nên được xây dựng tốt đến mức nào?” Tác giả đã theo đuổi mã hoàn hảo trong giai đoạn đầu sự nghiệp, nhưng sau đó nhận ra rằng không có một cách phát triển phần mềm “đúng” duy nhất. Ví dụ, trong cuộc thi làm game 24 giờ, sự thanh lịch và không lỗi của mã không quan trọng, trong khi việc phát triển các thiết bị như máy tạo nhịp tim, lỗi có thể gây hại cho người, do đó yêu cầu chất lượng công việc cao hơn. Phần lớn công việc của tác giả nằm ở giữa, các dự án khác nhau có các yêu cầu về chất lượng và giới hạn thời gian khác nhau. Tác giả xác định nơi nên đầu tư thời gian, những lỗi nào có thể chấp nhận được và những chỗ nào có thể làm chưa hoàn hảo để hoàn thành nhiệm vụ nhanh hơn bằng cách hiểu định nghĩa “đủ tốt” của nhóm. Mục tiêu cá nhân của tác giả là giao mã đạt 8 điểm (trên thang điểm 10) đúng thời hạn, tức là mã đủ tốt để hoàn thành nhiệm vụ, có vấn đề nhỏ nhưng không có vấn đề lớn. Phần mềm bản nháp Tác giả ủng hộ việc phần mềm bắt đầu từ bản nháp giống như viết văn, đôi khi được gọi là “spike” hoặc “walking skeleton”. Tác giả thích triển khai bản nháp càng sớm càng tốt, sau đó định hình nó thành giải pháp cuối cùng. Mã bản nháp thường có nhiều vấn đề, chẳng hạn như nhiều lỗi, chú thích TODO, các trường hợp lỗi chưa được xử lý, câu lệnh print() rải rác, không xem xét hiệu năng, thông tin commit ngắn gọn, v.v. Tuy nhiên, mã bản nháp có một đặc điểm quan trọng: nó gần giống với một giải pháp tốt. Tác giả sẽ sửa những vấn đề này trước bản vá cuối cùng. Ưu điểm của phương pháp bản nháp Phương pháp bản nháp có thể tiết lộ “những điều chưa biết”, nguyên mẫu thường phát hiện ra những vấn đề mà tác giả không thể lường trước được, tốt nhất là nên phát hiện những vấn đề này càng sớm càng tốt, thay vì sau khi mã đã hoàn thiện. Nhiều vấn đề biến mất trong quá trình tạo bản nháp, tác giả không cần phải sửa chúng. Bản nháp giúp tác giả tập trung, tránh trừu tượng hóa quá sớm và dễ dàng giao tiếp tiến độ với người khác hơn. Những việc cụ thể cần làm khi xây dựng bản nháp Tác giả tập trung vào các quyết định ràng buộc, ghi lại các hack, xây dựng từ trên xuống dưới và trích xuất các thay đổi nhỏ hơn trong quá trình làm việc khi xây dựng bản nháp. Cố gắng thay đổi yêu cầu Tác giả khuyên rằng, thông thường làm ít việc hơn sẽ nhanh hơn và dễ dàng hơn. Tác giả sẽ đặt ra một số câu hỏi, chẳng hạn như liệu có thể hợp nhất nhiều màn hình thành một không, liệu có thể không xử lý các trường hợp đặc biệt khó khăn không, liệu có thể giảm số lượng đầu vào mà API hỗ trợ không, liệu có thể chỉ xây dựng nguyên mẫu thay vì phiên bản đầy đủ không, hoặc liệu có thể không làm việc này hoàn toàn không. Tránh đi lang thang trong code Tác giả đề cập đến việc thế giới hiện đại đầy rẫy những phiền nhiễu, chẳng hạn như thông báo trên điện thoại, tin nhắn của đồng nghiệp và các cuộc họp. Tác giả không có câu trả lời thông minh nào để xử lý những phiền nhiễu này, nhưng tác giả phát hiện ra một phiền nhiễu khác là bắt đầu đi lang thang trong code. Tác giả bắt đầu xử lý một việc, hai giờ sau, lại đang thay đổi những thứ hoàn toàn không liên quan. Tác giả đã tìm ra hai cách cụ thể để quản lý tình huống này: đặt hẹn giờ, khi bắt đầu xử lý một nhiệm vụ rời rạc, tác giả thường đặt hẹn giờ. Ước tính của tác giả thường sai, nhưng khi hẹn giờ reo, tác giả thường bị đánh thức khỏi một số phân tâm ngớ ngẩn. Tác giả cũng đề cập đến một số quan điểm và đề xuất liên quan khác, chẳng hạn như “vứt bỏ bản nháp code của bạn” và “hệ thống đơn giản tốt nhất hiện tại”.

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

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

Học cách sử dụng một công cụ còn tốt hơn là sử dụng một công cụ có vẻ phù hợp hơn với vấn đề, Django phù hợp với nhiều vấn đề thực tế.
Mô hình dữ liệu là cốt lõi của hầu hết các ứng dụng, ngay cả khi là một nguyên mẫu thô sơ, cũng không nên trì hoãn việc tái cấu trúc mô hình dữ liệu.
Phần lớn các ứng dụng không cần ứng dụng một trang (single-page application) hoặc các framework frontend nặng nề, các view Django truyền thống là đủ để xử lý 80% các trang.
Thông thường, tự xây dựng mọi thứ dễ dàng hơn, ví dụ như sử dụng Django để phát triển nhanh một ứng dụng CRM đơn giản.
Luôn chọn các công nghệ cực kỳ nhàm chán, sử dụng Python/Django/Postgres, quên Kubernetes, Redis, v.v. đi.
Kubernetes và Redis sẽ trở thành những công nghệ nhàm chán vào năm 2025, chúng rất ổn định và có mục đích sử dụng rõ ràng.
Việc thiết lập k3s trên máy ảo không phức tạp hơn việc thiết lập reverse proxy thông thường.
Đối với các trường hợp sử dụng đơn giản, Kubernetes có thể quá phức tạp, không bằng sử dụng các phương pháp đơn giản truyền thống.
Kubernetes ban đầu được thiết kế để điều phối khai báo các API/middleware không trạng thái, đối với các dự án API đơn giản, việc sử dụng YAML khai báo đơn giản của Kubernetes có thể đơn giản hơn.
Sự phức tạp của Kubernetes là không cần thiết đối với hầu hết các ứng dụng.
Đối với các thiết lập đơn giản, hai tài nguyên Pod và Service không phức tạp.