Làn sóng Linux rồi sẽ đến..!
Tôi đã dùng PC Linux khoảng 20 năm rồi, từ hồi còn là học sinh cấp 3.
Khoảng 5 năm trước, tôi đã chuyển hẳn laptop chính sang Fedora và dùng ổn định đến giờ.
Tôi vẫn có desktop Windows, nhưng ngoài một vài game nhất định ra thì hầu như chẳng bật lên làm gì.
Ngay cả những trang của cơ quan công quyền, thay vì dùng desktop Windows thì thà chạy môi trường ảo trong Bottle còn hơn, vì có thể dồn hết đám chương trình bảo mật vô dụng chỉ vào môi trường ảo, nên ngược lại còn tiện hơn nữa~
Rails tiện vì nó ép buộc convention và làm nhiều "phép thuật" bên dưới lớp trừu tượng, dù có đánh đổi là hiệu năng giảm, nhưng cái này không khiến tiền đội lên ngay lập tức.
Ngược lại, nếu framework tự ý chọn model thì ai sẽ chịu trách nhiệm khi mức tiêu thụ token bùng nổ đây...?
Theo tôi, bất kể quy mô thế nào thì rủi ro cũng không thể được thay thế bằng AI. Là nhân viên hay CEO cũng vậy. Nếu thay thế một nhân viên đang gánh rủi ro bằng AI thì người khác sẽ phải gánh phần đó. CEO cũng tương tự. Nếu thay bằng AI thì sẽ có người khác phải gánh rủi ro đó. Và rốt cuộc người đó sẽ đảm nhận vai trò CEO.
Tôi cho rằng chỉ có “con người” mới là bên gánh chịu rủi ro.
Nhưng việc người ta nói rằng có thể thay thế điều này bằng AI, thậm chí còn nói sẽ thay thế người có mục đích tồn tại lớn nhất là đưa ra “những quyết định có mức độ rủi ro rất cao” như CEO, khiến tôi thấy nghi vấn. Tôi không nói CEO là không thể thay thế còn nhân viên thì có thể.
Tuy nhiên, tôi nghĩ trong tương lai gần, công nghệ sẽ có thể phân tán/điều tiết/hedge cả rủi ro đó. Hướng phát triển của công nghệ từ trước đến nay vẫn luôn như vậy.
Bộ gõ tiếng Hàn quá bất tiện nên trước đây tôi không dùng nổi, dạo này đã cải thiện nhiều chưa? Trước đây các vấn đề như trên Chrome bị nuốt ký tự khi gõ hoặc chữ cuối cùng bị xóa xảy ra khá nghiêm trọng.
Đây là cách tôi từng làm bằng mã debug hồi còn làm ở một công ty game cách đây 25 năm, chứ đâu chỉ riêng mỗi strcpy. Khi phát hành thì lại mở hết ra để tăng tốc độ rồi đem đi phục vụ. Thực ra phía game là nơi nhạy cảm nhất với xung đột bộ nhớ, nên khi làm cũng phải cực kỳ tỉnh táo và cẩn trọng, đến mức còn tự làm cả memory debugger để dùng. Nhưng nhìn lại ngày nay thì hóa ra khi đó mình đang tạo ra garbage collection. Đúng là một ký ức mơ hồ.
Ồ, tôi đã đọc rất hay. Anh/chị có nói rằng việc có tiến hành kiểm chứng bổ sung hay không được quyết định dựa trên độ tin cậy, nên tôi cũng tò mò giá trị độ tin cậy này được đo lường như thế nào.
Đây là một bài viết giải quyết vấn đề rất tốt bằng VLM, tôi đọc rất thú vị.
Có một điều tôi thắc mắc sau khi đọc bài,
Phát hiện bằng YOLO – crop chỉ đối tượng chính để thu hẹp phạm vi phân tích
Tôi muốn hỏi là anh/chị đã đưa bước này vào như thế nào.
Khi đọc bài, tôi nghĩ rằng VLM có lẽ sẽ cho hiệu năng tốt hơn YOLO, nên ngược lại nếu crop thì có thể xảy ra vấn đề mô hình YOLO phán đoán sai, làm mất thông tin quan trọng trước cả khi chuyển sang cho VLM xử lý.
Tôi tò mò không biết việc crop được nghĩ ra từ vấn đề nào, và anh/chị đã kiểm chứng độ chính xác rồi đưa nó vào như thế nào.
Trên một số MCU cao cấp, đúng như bạn nói, có thể dùng MPU để thiết lập theo từng vùng không chỉ quyền truy cập mà cả các thuộc tính liên quan đến cache. Tài liệu sau của ST sẽ là một tài liệu tham khảo rất tốt: https://community.st.com/t5/stm32-mcus/…
Tuy nhiên, trên ESP32-S3 được sử dụng trong bài viết này, không có cơ chế cho phép thiết lập thuộc tính cacheable / non-cacheable theo từng vùng nhớ bằng MPU hay cơ chế tương tự như trên CPU đa dụng hoặc một số MCU khác.
Với ESP32-S3, bộ nhớ ngoài (Flash/PSRAM) được thiết kế để truy cập thông qua cache/MMU (TRM 4.3.3 External Memory), và việc kiểm soát quyền truy cập được thực hiện qua PMS (Permission Management System) (TRM Chương 15), nhưng thành phần này dùng cho bảo vệ truy cập chứ không có vai trò thay đổi việc có đi qua cache hay không, hoặc bản thân đường truy cập.
Năm ngoái đã có rất nhiều cải thiện về HiDPI và HDR, giờ có vẻ như mức độ hỗ trợ còn tốt hơn cả Windows.
Tôi thật sự thắc mắc không hiểu vì sao giá của 4o mini lại như vậy, tôi nhớ là bản 4o thường còn rẻ hơn mà haha
Hóa ra tôi đã nhầm khi đương nhiên cho rằng đó sẽ là lõi ARM.
Cảm ơn bạn đã trả lời rất nhiệt tình
Làn sóng Linux rồi sẽ đến..! Tôi đã dùng PC Linux khoảng 20 năm rồi, từ hồi còn là học sinh cấp 3.
Khoảng 5 năm trước, tôi đã chuyển hẳn laptop chính sang Fedora và dùng ổn định đến giờ.
Tôi vẫn có desktop Windows, nhưng ngoài một vài game nhất định ra thì hầu như chẳng bật lên làm gì.
Ngay cả những trang của cơ quan công quyền, thay vì dùng desktop Windows thì thà chạy môi trường ảo trong Bottle còn hơn, vì có thể dồn hết đám chương trình bảo mật vô dụng chỉ vào môi trường ảo, nên ngược lại còn tiện hơn nữa~
Dạo này các vấn đề với Wayland cũng đã giảm đi nhiều.
Đến năm 2026 liệu sẽ có một công cụ mới nào đó xuất hiện không? Có lẽ sẽ khác với Rails, nhưng được trừu tượng hóa hơn một chút... Tôi rất mong chờ.
Không hiểu sao bỗng nhiên tôi lại nhớ đến Aaron Swartz, đồng sáng lập Reddit. Chắc hẳn đây là một thay đổi mà anh ấy đã luôn mong mỏi..
Framework tác nhân... nghe tên thì hoành tráng nhưng rốt cuộc cũng chỉ là công cụ để giao cho
llm. Chỉ là cái vỏ rỗng.Nên dùng
snprintfthay chostrcpy. Nếu trong code cóstrcpythì phải tìm ra địa chỉ của lập trình viên đã tạo ra nó.Rails tiện vì nó ép buộc convention và làm nhiều "phép thuật" bên dưới lớp trừu tượng, dù có đánh đổi là hiệu năng giảm, nhưng cái này không khiến tiền đội lên ngay lập tức.
Ngược lại, nếu framework tự ý chọn model thì ai sẽ chịu trách nhiệm khi mức tiêu thụ token bùng nổ đây...?
Theo tôi, bất kể quy mô thế nào thì rủi ro cũng không thể được thay thế bằng AI. Là nhân viên hay CEO cũng vậy. Nếu thay thế một nhân viên đang gánh rủi ro bằng AI thì người khác sẽ phải gánh phần đó. CEO cũng tương tự. Nếu thay bằng AI thì sẽ có người khác phải gánh rủi ro đó. Và rốt cuộc người đó sẽ đảm nhận vai trò CEO.
Tôi cho rằng chỉ có “con người” mới là bên gánh chịu rủi ro.
Nhưng việc người ta nói rằng có thể thay thế điều này bằng AI, thậm chí còn nói sẽ thay thế người có mục đích tồn tại lớn nhất là đưa ra “những quyết định có mức độ rủi ro rất cao” như CEO, khiến tôi thấy nghi vấn. Tôi không nói CEO là không thể thay thế còn nhân viên thì có thể.
Tuy nhiên, tôi nghĩ trong tương lai gần, công nghệ sẽ có thể phân tán/điều tiết/hedge cả rủi ro đó. Hướng phát triển của công nghệ từ trước đến nay vẫn luôn như vậy.
Khuyên dùng bộ gõ kime
Bộ gõ tiếng Hàn quá bất tiện nên trước đây tôi không dùng nổi, dạo này đã cải thiện nhiều chưa? Trước đây các vấn đề như trên Chrome bị nuốt ký tự khi gõ hoặc chữ cuối cùng bị xóa xảy ra khá nghiêm trọng.
Nhận định rất sắc bén. Tỷ lệ mắc lỗi của con người còn cao hơn nữa..
Đây là cách tôi từng làm bằng mã debug hồi còn làm ở một công ty game cách đây 25 năm, chứ đâu chỉ riêng mỗi
strcpy. Khi phát hành thì lại mở hết ra để tăng tốc độ rồi đem đi phục vụ. Thực ra phía game là nơi nhạy cảm nhất với xung đột bộ nhớ, nên khi làm cũng phải cực kỳ tỉnh táo và cẩn trọng, đến mức còn tự làm cả memory debugger để dùng. Nhưng nhìn lại ngày nay thì hóa ra khi đó mình đang tạo ra garbage collection. Đúng là một ký ức mơ hồ.Ồ, tôi đã đọc rất hay. Anh/chị có nói rằng việc có tiến hành kiểm chứng bổ sung hay không được quyết định dựa trên độ tin cậy, nên tôi cũng tò mò giá trị độ tin cậy này được đo lường như thế nào.
Ngoài ra, xin lưu ý rằng mô hình gpt-4o-mini có chi phí token đầu vào khi nhận ảnh khá đắt, nên tôi khuyên anh/chị cũng hãy cân nhắc các mô hình nhẹ khác!
Đây là một bài viết giải quyết vấn đề rất tốt bằng VLM, tôi đọc rất thú vị.
Có một điều tôi thắc mắc sau khi đọc bài,
Tôi muốn hỏi là anh/chị đã đưa bước này vào như thế nào.
Khi đọc bài, tôi nghĩ rằng VLM có lẽ sẽ cho hiệu năng tốt hơn YOLO, nên ngược lại nếu crop thì có thể xảy ra vấn đề mô hình YOLO phán đoán sai, làm mất thông tin quan trọng trước cả khi chuyển sang cho VLM xử lý.
Tôi tò mò không biết việc crop được nghĩ ra từ vấn đề nào, và anh/chị đã kiểm chứng độ chính xác rồi đưa nó vào như thế nào.
Ồ, trông đẹp đấy. Sẽ tuyệt hơn nếu nó được port sang nhiều ngôn ngữ khác nhau!
Có vẻ không hẳn là giải quyết bằng cách chuyển sang bài toán có cấu trúc, mà là đã tạo ra một mô hình mới thì đúng hơn.
Trên một số MCU cao cấp, đúng như bạn nói, có thể dùng MPU để thiết lập theo từng vùng không chỉ quyền truy cập mà cả các thuộc tính liên quan đến cache. Tài liệu sau của ST sẽ là một tài liệu tham khảo rất tốt: https://community.st.com/t5/stm32-mcus/…
Tuy nhiên, trên ESP32-S3 được sử dụng trong bài viết này, không có cơ chế cho phép thiết lập thuộc tính cacheable / non-cacheable theo từng vùng nhớ bằng MPU hay cơ chế tương tự như trên CPU đa dụng hoặc một số MCU khác.
Với ESP32-S3, bộ nhớ ngoài (Flash/PSRAM) được thiết kế để truy cập thông qua cache/MMU (TRM 4.3.3 External Memory), và việc kiểm soát quyền truy cập được thực hiện qua PMS (Permission Management System) (TRM Chương 15), nhưng thành phần này dùng cho bảo vệ truy cập chứ không có vai trò thay đổi việc có đi qua cache hay không, hoặc bản thân đường truy cập.
Liên kết TRM (Technical Reference Manual): https://documentation.espressif.com/esp32-s3_technical_reference_manua….