Phản biện thường gặp đối với đề xuất thu nhập cơ bản là vấn đề đảm bảo nguồn thu thuế, và có vẻ như đến nay vẫn chưa có giải pháp thực sự sắc bén cho chuyện này.
Tôi nghĩ việc quản lý một dự án bằng một ngôn ngữ duy nhất là tốt, nhưng ngoài chuyện đó ra thì cách thuyết phục đồng nghiệp về điều này đúng là tệ nhất.
Thực tế thì người ta nói cái này cũng làm được, cái kia cũng làm được, nhưng lại chẳng có gì là làm cho ra hồn cả. Ngoài việc có vẻ đã cải thiện về mặt hiệu suất, thì vẫn chưa có benchmark nào thật sự đáng tin, nên khó mà chỉ tin vào những lời kiểu mọi thứ đã tốt hơn vài phần trăm, nhất là vì khi dùng thực tế thì nhiều trường hợp lại không được như vậy. Cái gọi là tập kiểm thử gần như vô nghĩa, vì rốt cuộc vẫn là học và kiểm thử trên những dữ liệu đã có sẵn rồi, nên có lẽ mấu chốt là nó có thể ứng phó được đến mức nào với những phần chưa được học và các vấn đề phát sinh bất ngờ.
Tôi đã từng thấy tin rằng ở Cheonan, sau khi đổi bãi đỗ xe của tòa thị chính từ miễn phí hoàn toàn sang miễn phí 2 giờ, mọi thứ trở nên thông thoáng hơn.
K8s là công cụ điều phối container, vậy liệu vì wasm mà tính hiệu quả của nó sẽ giảm đi không? Nếu là Docker thì chắc chắn sẽ bị lấn sân ở một mức độ nào đó...
Có vẻ đây không phải là PR sửa phần triển khai DMA, cũng không phải trực tiếp đụng vào DMA API, mà là PR viết FFI binding để có thể truy cập DMA API từ Rust.
Thế mà PR như vậy lại bị từ chối bằng một câu cụt lủn: "No rust code in kernel/dma, please." và đây là link: https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Khi được hỏi vậy thì nên làm thế nào, người đó trả lời: "Keep the wrappers in your code instead of making life painful for others." https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(Thực ra đúng là đã làm theo như vậy. PR này không sửa kernel/dma mà sửa subtree bên dưới rust/kernel.)
Dĩ nhiên, nếu thêm FFI binding thì khi DMA API thay đổi, phía Rust FFI binding cũng sẽ phải sửa theo, nên đúng là có thêm gánh nặng như vậy,
nhưng dù bên đụng tới Rust đã nói rằng họ sẽ tự lo phần đó, tôi vẫn không rõ việc một người không phụ trách tree đó lại phản đối với thái độ như vậy có đúng hay không.
(Christoph Hellwig là maintainer của kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)
Nhưng điều thú vị là ngay ở thread trước đó có một ý như thế này,
nếu API có breaking change mà đội Rust không phản ứng đủ nhanh thì bản build sẽ vỡ và Linus sẽ không nhận PR.
Dù sao, nếu nghĩ đây là vấn đề giữa module tạo ra breaking change và một module khác, thì cá nhân tôi lại thấy phía có Rust tốt hơn.
Giả sử module x tạo ra breaking change, còn module y không kịp phản ứng, thì:
module y viết bằng Rust: compile lỗi nên Linus sẽ không merge
module y viết bằng C: vẫn compile được(??) nên Linus sẽ merge (????)
Các ví dụ ứng dụng thực tế ở phần dưới đây còn thú vị hơn.
Nó có thể tạo ra avatar cho mục đích marketing, hoặc tạo các đoạn video clip từ hình ảnh sản phẩm.
Sau đó còn dùng chính thứ đó để ghép con người và sản phẩm thành một, rồi tạo hẳn video giới thiệu sản phẩm.
Vì vậy các video như ăn đồ ăn, mặc quần áo đi lại, trang điểm hay gội đầu đều được làm rất trơn tru.
Có lẽ đây là những ví dụ được tối ưu cho social commerce ở Trung Quốc.
Ngay cả chiếc máy chủ Mac mini M1 ở nhà tôi, vốn đang chạy rất ổn với điện năng thấp, im lặng và hầu như không tỏa nhiệt, cũng có thể được dựng lên nhờ chuyện này, hu hu. Buồn thật.
PR này không phải là port. Đây là PR thêm các ràng buộc FFI ở phía Rust để có thể dùng API DMA hiện có cả trong các mô-đun viết mới dựa trên Rust. Và người phụ trách DMA đã chặn việc đó.
Mới biết thêm điều này. Cảm ơn bạn. 😁
Phản biện thường gặp đối với đề xuất thu nhập cơ bản là vấn đề đảm bảo nguồn thu thuế, và có vẻ như đến nay vẫn chưa có giải pháp thực sự sắc bén cho chuyện này.
Có nhất thiết phải tách bạch giữa những vấn đề xã hội và thay đổi thể chế kinh tế không...?
Bản tóm tắt chỉ nhắc đến những sự việc đã xảy ra, nhưng ở cuối bài gốc (bằng tiếng Hàn) còn có thêm 2 thông tin nền bổ sung để hiểu rõ hơn về sự việc.
Vốn dĩ trang này không có chức năng chỉnh sửa. Chỉ có quản trị viên mới có thể sửa.
Ép người khác phải khuất phục bằng quyền lực là điều phi lý.
Tôi nghĩ việc quản lý một dự án bằng một ngôn ngữ duy nhất là tốt, nhưng ngoài chuyện đó ra thì cách thuyết phục đồng nghiệp về điều này đúng là tệ nhất.
Thực tế thì người ta nói cái này cũng làm được, cái kia cũng làm được, nhưng lại chẳng có gì là làm cho ra hồn cả. Ngoài việc có vẻ đã cải thiện về mặt hiệu suất, thì vẫn chưa có benchmark nào thật sự đáng tin, nên khó mà chỉ tin vào những lời kiểu mọi thứ đã tốt hơn vài phần trăm, nhất là vì khi dùng thực tế thì nhiều trường hợp lại không được như vậy. Cái gọi là tập kiểm thử gần như vô nghĩa, vì rốt cuộc vẫn là học và kiểm thử trên những dữ liệu đã có sẵn rồi, nên có lẽ mấu chốt là nó có thể ứng phó được đến mức nào với những phần chưa được học và các vấn đề phát sinh bất ngờ.
Gần đây ByteDance công bố rất nhiều bài báo kỹ thuật liên quan... tôi nghĩ chẳng bao lâu nữa nó cũng sẽ được áp dụng lên TikTok.
Đây là một bình luận rất hay.
http://www.icj.kr/bbs/board.php?bo_table=news&wr_id=47621
Tôi đã từng thấy tin rằng ở Cheonan, sau khi đổi bãi đỗ xe của tòa thị chính từ miễn phí hoàn toàn sang miễn phí 2 giờ, mọi thứ trở nên thông thoáng hơn.
Cảm ơn bạn đã xử lý.
K8s là công cụ điều phối container, vậy liệu vì wasm mà tính hiệu quả của nó sẽ giảm đi không? Nếu là Docker thì chắc chắn sẽ bị lấn sân ở một mức độ nào đó...
Tiếc là không có tiếng Hàn...
Đây là thread mail của PR đó:
https://lwn.net/ml/all/…
Có vẻ đây không phải là PR sửa phần triển khai DMA, cũng không phải trực tiếp đụng vào DMA API, mà là PR viết FFI binding để có thể truy cập DMA API từ Rust.
Thế mà PR như vậy lại bị từ chối bằng một câu cụt lủn: "No rust code in kernel/dma, please." và đây là link: https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Khi được hỏi vậy thì nên làm thế nào, người đó trả lời: "Keep the wrappers in your code instead of making life painful for others." https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(Thực ra đúng là đã làm theo như vậy. PR này không sửa kernel/dma mà sửa subtree bên dưới rust/kernel.)
Dĩ nhiên, nếu thêm FFI binding thì khi DMA API thay đổi, phía Rust FFI binding cũng sẽ phải sửa theo, nên đúng là có thêm gánh nặng như vậy,
nhưng dù bên đụng tới Rust đã nói rằng họ sẽ tự lo phần đó, tôi vẫn không rõ việc một người không phụ trách tree đó lại phản đối với thái độ như vậy có đúng hay không.
(Christoph Hellwig là maintainer của kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)
Vì thế có lẽ Hector Martin đã kéo Linus vào thread này:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Nhưng điều thú vị là ngay ở thread trước đó có một ý như thế này,
nếu API có breaking change mà đội Rust không phản ứng đủ nhanh thì bản build sẽ vỡ và Linus sẽ không nhận PR.
Dù sao, nếu nghĩ đây là vấn đề giữa module tạo ra breaking change và một module khác, thì cá nhân tôi lại thấy phía có Rust tốt hơn.
Giả sử module x tạo ra breaking change, còn module y không kịp phản ứng, thì:
Goku+: Video Ads Foundation Models
Các ví dụ ứng dụng thực tế ở phần dưới đây còn thú vị hơn.
Nó có thể tạo ra avatar cho mục đích marketing, hoặc tạo các đoạn video clip từ hình ảnh sản phẩm.
Sau đó còn dùng chính thứ đó để ghép con người và sản phẩm thành một, rồi tạo hẳn video giới thiệu sản phẩm.
Vì vậy các video như ăn đồ ăn, mặc quần áo đi lại, trang điểm hay gội đầu đều được làm rất trơn tru.
Có lẽ đây là những ví dụ được tối ưu cho social commerce ở Trung Quốc.
Ngay cả chiếc máy chủ Mac mini M1 ở nhà tôi, vốn đang chạy rất ổn với điện năng thấp, im lặng và hầu như không tỏa nhiệt, cũng có thể được dựng lên nhờ chuyện này, hu hu. Buồn thật.
PR này không phải là port. Đây là PR thêm các ràng buộc FFI ở phía Rust để có thể dùng API DMA hiện có cả trong các mô-đun viết mới dựa trên Rust. Và người phụ trách DMA đã chặn việc đó.
2021-01-07 Asahi Linux: dự án Linux cho Apple Silicon
2022-03-21 Asahi Linux alpha release - Linux cho chip Apple M1
2024-02-17 Hỗ trợ OpenGL trên Apple Silicon của Asahi Linux, chính thức vượt qua Apple
2024-10-11 Chơi game AAA trên Asahi Linux
2024-11-02 Triển khai Linux trên Apple Silicon, phỏng vấn Alyssa Rosenzweig
Đã nỗ lực suốt 4 năm, cuối cùng mọi chuyện lại thành ra như thế này.
Khi một dự án tồn tại lâu, ngày càng hay xảy ra tình huống mọi người đòi hỏi đủ thứ như thể họ đã giao phó gì đó cho dự án, dù thực tế không phải vậy.
Và về phần xung đột với cộng đồng Linux kernel ở giữa chừng, hãy tham khảo thêm tranh cãi Rust trong Linux kernel lại bùng lên.
Hay đấy