Tên gọi kỹ thuật này khá dễ gây nhầm lẫn. zram là một tính năng của kernel, tạo ra một thiết bị khối có chức năng nén tự động, tức là một dạng lưu trữ. Và nếu tạo rồi sử dụng một file swap thông thường như chúng ta vẫn biết trên phần lưu trữ đó, thì nó sẽ có kiểu chức năng swap dựa trên RAM + nén. Có vẻ như dịch vụ zramswap đảm nhiệm vai trò đó. Tuy nhiên, về sau người ta thấy trường hợp sử dụng này hữu ích, nên zram + swap được tích hợp trọn vẹn thành một tính năng của kernel. Đó là zswap. zswap có thể được kích hoạt trên đa số bản phân phối Linux chỉ bằng lệnh, không cần cài đặt riêng. (Tham khảo https://wiki.archlinux.org/title/Zswap)
zram và zswap có khác nhau không? sudo apt install zram-tools systemctl enable zramswap
Tôi đang dùng như thế này, nhưng không rõ cái gọi là zswap có phải là cái này không..
zswap khá đáng dùng. Trên macOS, một tính năng tương tự cũng là tùy chọn được bật mặc định. Nó hoạt động tốt khi mở trình duyệt hoặc chạy nhiều ứng dụng trong môi trường tài nguyên hạn chế như laptop. Tuy nhiên, như bạn đã đề cập, có sự đánh đổi về CPU nên có lẽ sẽ ảnh hưởng đến pin.
Việc cải tiến từng bước và tách dần microservice thực sự rất quan trọng... Đọc những bài như thế này mới thấy PM dẫn dắt dự án đó đúng là cực kỳ quan trọng và đáng nể. Quản lý từng này thứ đúng là ghê thật.
Trường hợp zram thì đây là lần đầu tôi biết đến, nên tôi đã hỏi qwq:32b xem nó có nhược điểm gì.
Vì sao các bản phân phối Linux không bật zram theo mặc định?
Vì vấn đề thiếu bộ nhớ trên các hệ thống hiện đại đã giảm đi: hiện nay đa số PC mặc định đều được trang bị từ 4GB RAM trở lên. Trong môi trường ít gặp vấn đề thiếu bộ nhớ, nhu cầu dùng zram sẽ thấp hơn.
Rủi ro tăng tải CPU: zram có thể làm tăng mức sử dụng CPU, nên không an toàn cho mọi loại phần cứng.
Vì các bản phân phối ưu tiên “môi trường phổ thông”, họ có thể cho rằng không đáng để chấp nhận phần overhead CPU của zram.
Thay đổi trong cách dùng swap mặc định: sự phổ biến của SSD đã cải thiện đáng kể tốc độ của swap trên đĩa truyền thống.
Ưu thế về tốc độ của zram vì thế cũng kém nổi bật hơn so với trước đây.
Sự đa dạng của môi trường người dùng: zram chỉ thực sự hiệu quả trong một số môi trường nhất định (ví dụ: thiết bị cấu hình thấp), còn với người dùng phổ thông thì hầu như không mang lại lợi ích rõ rệt.
Các bản phân phối theo đuổi mục tiêu “tương thích tối đa với cấu hình tối thiểu”, nên không bật zram theo mặc định.
Độ phức tạp trong cấu hình: để tối ưu, cần phải tự điều chỉnh kích thước zram, thuật toán nén, v.v., và điều này khá khó để người dùng phổ thông hiểu và áp dụng.
Ngôn ngữ lập trình nào phù hợp nhất với coding agent?
Là một lập trình viên backend trước giờ chủ yếu dùng Java & Kotlin, Spring, nên khi dùng Cursor tôi thường thấy khá bí bách..
Hiện tôi đang refactor một ứng dụng React cũ sang Astro.
Trong bài viết, tác giả nhấn mạnh "ngữ cảnh tích hợp". Cần hiểu rằng "ngữ cảnh tích hợp" giúp xây dựng dịch vụ nhanh hơn, nhưng rồi đến lúc nào đó có thể trở thành nợ kỹ thuật.
Từ góc độ bảo trì dài hạn của dịch vụ, "liên kết lỏng giữa các mô-đun độc lập" tốt hơn "liên kết chặt tích hợp".
Và Astro chính là framework linh hoạt nhất cho điều đó.
Trải nghiệm "trò chuyện" với LLM giống như đang sử dụng terminal máy tính của thập niên 80. GUI (giao diện người dùng đồ họa) vẫn chưa được phát minh ra, nhưng tôi nghĩ một số đặc tính của nó đã có thể dự đoán được.
Nó sẽ mang tính trực quan hơn (giống GUI trước đây). Bởi vì thông tin thị giác (ảnh, biểu đồ, hoạt ảnh, v.v. — nhìn luôn nhanh hơn đọc) giống như một đường cao tốc 10 làn đi thẳng vào não. Thị giác có băng thông đầu vào thông tin cao nhất, và khoảng 1/3 năng lực xử lý của não được dành cho việc xử lý hình ảnh.
Nó sẽ mang tính tạo sinh và thay đổi theo điều kiện đầu vào. Tức là GUI sẽ được tạo theo thời gian thực để phù hợp với prompt của người dùng, và mọi yếu tố sẽ tồn tại và được cấu thành cho mục đích tức thời đó.
Một câu hỏi mở hơn một chút là mức độ mang tính "thủ tục" (procedural) của nó. Ở một cực, ta có thể hình dung một diffusion model khổng lồ tạo ra toàn bộ canvas đầu ra trong một lần; ở cực còn lại là một trang đầy các React component được tạo theo thủ tục (ví dụ: hình ảnh, biểu đồ, hoạt ảnh, sơ đồ, v.v.). Tôi nghĩ nó sẽ là sự pha trộn của cả hai, nhưng vế sau sẽ là bộ khung mặc định.
Tuy vậy, điều tôi có thể khẳng định ngay lúc này là khi năng lực tiến gần đến vô hạn, một GUI canvas 2D tương tác được, linh hoạt, kỳ ảo và mang tính tạm thời (ephemeral) sẽ trở thành hình thái cuối cùng. Và tôi cho rằng điều đó đã bắt đầu diễn ra một cách chậm rãi rồi (ví dụ: code block/highlighting, khối LaTeX, in đậm/in nghiêng/danh sách/bảng trong Markdown, emoji, tham vọng hơn nữa là tab Artifacts, biểu đồ Mermaid hay các ứng dụng hoàn chỉnh hơn). Dĩ nhiên hiện tại tất cả vẫn còn ở mức rất sơ khai và nguyên thủy.
Iron Man, và ở một mức độ nào đó là Star Trek/Minority Report, có thể xem là những ví dụ tiêu biểu trong văn hóa đại chúng về AI/UI theo hướng phát triển này.
Nếu ngay cả system prompt cũng có thể được chính LLM tự thay đổi, thì có lẽ con người vẫn sẽ phải đặt ra cả các quy tắc về chính sách đó; rốt cuộc có khi chỉ còn lại những thứ như Ba định luật robot.
Cá nhân tôi thấy dùng kiểu self-hosted như Ghost cũng khá ổn.
Tên gọi kỹ thuật này khá dễ gây nhầm lẫn.
zramlà một tính năng của kernel, tạo ra một thiết bị khối có chức năng nén tự động, tức là một dạng lưu trữ. Và nếu tạo rồi sử dụng một file swap thông thường như chúng ta vẫn biết trên phần lưu trữ đó, thì nó sẽ có kiểu chức năng swap dựa trên RAM + nén. Có vẻ như dịch vụzramswapđảm nhiệm vai trò đó. Tuy nhiên, về sau người ta thấy trường hợp sử dụng này hữu ích, nênzram+swapđược tích hợp trọn vẹn thành một tính năng của kernel. Đó làzswap.zswapcó thể được kích hoạt trên đa số bản phân phối Linux chỉ bằng lệnh, không cần cài đặt riêng. (Tham khảo https://wiki.archlinux.org/title/Zswap)zramvàzswapcó khác nhau không?sudo apt install zram-toolssystemctl enable zramswapTôi đang dùng như thế này, nhưng không rõ cái gọi là
zswapcó phải là cái này không..Có vẻ như Cursor có nhiều extension hơn...
zswapkhá đáng dùng. Trên macOS, một tính năng tương tự cũng là tùy chọn được bật mặc định. Nó hoạt động tốt khi mở trình duyệt hoặc chạy nhiều ứng dụng trong môi trường tài nguyên hạn chế như laptop. Tuy nhiên, như bạn đã đề cập, có sự đánh đổi về CPU nên có lẽ sẽ ảnh hưởng đến pin.Có phải là JavaScript không nhỉ, dù đây chỉ là phỏng đoán không có căn cứ?
Vì số lượng nhiều nhất nên có lẽ nó cũng được học tốt nhất chăng...
Việc cải tiến từng bước và tách dần microservice thực sự rất quan trọng... Đọc những bài như thế này mới thấy PM dẫn dắt dự án đó đúng là cực kỳ quan trọng và đáng nể. Quản lý từng này thứ đúng là ghê thật.
Trường hợp zram thì đây là lần đầu tôi biết đến, nên tôi đã hỏi qwq:32b xem nó có nhược điểm gì.
Vì sao các bản phân phối Linux không bật zram theo mặc định?
Vì vấn đề thiếu bộ nhớ trên các hệ thống hiện đại đã giảm đi: hiện nay đa số PC mặc định đều được trang bị từ 4GB RAM trở lên. Trong môi trường ít gặp vấn đề thiếu bộ nhớ, nhu cầu dùng zram sẽ thấp hơn.
Rủi ro tăng tải CPU: zram có thể làm tăng mức sử dụng CPU, nên không an toàn cho mọi loại phần cứng.
Vì các bản phân phối ưu tiên “môi trường phổ thông”, họ có thể cho rằng không đáng để chấp nhận phần overhead CPU của zram.
Thay đổi trong cách dùng swap mặc định: sự phổ biến của SSD đã cải thiện đáng kể tốc độ của swap trên đĩa truyền thống.
Ưu thế về tốc độ của zram vì thế cũng kém nổi bật hơn so với trước đây.
Sự đa dạng của môi trường người dùng: zram chỉ thực sự hiệu quả trong một số môi trường nhất định (ví dụ: thiết bị cấu hình thấp), còn với người dùng phổ thông thì hầu như không mang lại lợi ích rõ rệt.
Các bản phân phối theo đuổi mục tiêu “tương thích tối đa với cấu hình tối thiểu”, nên không bật zram theo mặc định.
Độ phức tạp trong cấu hình: để tối ưu, cần phải tự điều chỉnh kích thước zram, thuật toán nén, v.v., và điều này khá khó để người dùng phổ thông hiểu và áp dụng.
Vì OpenAI đã mua lại Windsurf nên có lẽ mọi người sẽ chuyển sang phía Windsurf thôi.
Có lẽ để cục diện UI/UX thực sự thay đổi, nền tảng cũng cần những nỗ lực thoát khỏi form factor như điện thoại hay màn hình.
Ngôn ngữ lập trình nào phù hợp nhất với coding agent?
Là một lập trình viên backend trước giờ chủ yếu dùng Java & Kotlin, Spring, nên khi dùng Cursor tôi thường thấy khá bí bách..
Hiện tôi đang refactor một ứng dụng React cũ sang Astro.
Trong bài viết, tác giả nhấn mạnh "ngữ cảnh tích hợp". Cần hiểu rằng "ngữ cảnh tích hợp" giúp xây dựng dịch vụ nhanh hơn, nhưng rồi đến lúc nào đó có thể trở thành nợ kỹ thuật.
Từ góc độ bảo trì dài hạn của dịch vụ, "liên kết lỏng giữa các mô-đun độc lập" tốt hơn "liên kết chặt tích hợp".
Và Astro chính là framework linh hoạt nhất cho điều đó.
Đúng vậy mà haha
https://x.com/karpathy/status/1917920257257459899
Có lẽ cũng đáng để so sánh thêm với quan điểm của Andrej Karpathy.
Trải nghiệm "trò chuyện" với LLM giống như đang sử dụng terminal máy tính của thập niên 80. GUI (giao diện người dùng đồ họa) vẫn chưa được phát minh ra, nhưng tôi nghĩ một số đặc tính của nó đã có thể dự đoán được.
Nó sẽ mang tính trực quan hơn (giống GUI trước đây). Bởi vì thông tin thị giác (ảnh, biểu đồ, hoạt ảnh, v.v. — nhìn luôn nhanh hơn đọc) giống như một đường cao tốc 10 làn đi thẳng vào não. Thị giác có băng thông đầu vào thông tin cao nhất, và khoảng 1/3 năng lực xử lý của não được dành cho việc xử lý hình ảnh.
Nó sẽ mang tính tạo sinh và thay đổi theo điều kiện đầu vào. Tức là GUI sẽ được tạo theo thời gian thực để phù hợp với prompt của người dùng, và mọi yếu tố sẽ tồn tại và được cấu thành cho mục đích tức thời đó.
Một câu hỏi mở hơn một chút là mức độ mang tính "thủ tục" (procedural) của nó. Ở một cực, ta có thể hình dung một diffusion model khổng lồ tạo ra toàn bộ canvas đầu ra trong một lần; ở cực còn lại là một trang đầy các React component được tạo theo thủ tục (ví dụ: hình ảnh, biểu đồ, hoạt ảnh, sơ đồ, v.v.). Tôi nghĩ nó sẽ là sự pha trộn của cả hai, nhưng vế sau sẽ là bộ khung mặc định.
Tuy vậy, điều tôi có thể khẳng định ngay lúc này là khi năng lực tiến gần đến vô hạn, một GUI canvas 2D tương tác được, linh hoạt, kỳ ảo và mang tính tạm thời (ephemeral) sẽ trở thành hình thái cuối cùng. Và tôi cho rằng điều đó đã bắt đầu diễn ra một cách chậm rãi rồi (ví dụ: code block/highlighting, khối LaTeX, in đậm/in nghiêng/danh sách/bảng trong Markdown, emoji, tham vọng hơn nữa là tab Artifacts, biểu đồ Mermaid hay các ứng dụng hoàn chỉnh hơn). Dĩ nhiên hiện tại tất cả vẫn còn ở mức rất sơ khai và nguyên thủy.
Iron Man, và ở một mức độ nào đó là Star Trek/Minority Report, có thể xem là những ví dụ tiêu biểu trong văn hóa đại chúng về AI/UI theo hướng phát triển này.
Cline có mất phí không? Chẳng phải là miễn phí sao?
Xe được định nghĩa bằng phần mềm lấy phần cứng làm trung tâm
Chuẩn
Dù sao thì học MBA cũng chỉ toàn làm nghiên cứu tình huống thôi
Cái gì làm trên bàn giấy thì cũng có giới hạn mà
Botox haha, tôi phải đọc một lúc mới hiểu là nói gì haha
Thú vị đấy
Mong thời đại không biên giới sớm đến
Nếu ngay cả system prompt cũng có thể được chính LLM tự thay đổi, thì có lẽ con người vẫn sẽ phải đặt ra cả các quy tắc về chính sách đó; rốt cuộc có khi chỉ còn lại những thứ như Ba định luật robot.
Anthropic công bố "system prompt" vận hành Claude
System prompt được công bố trực tiếp có dung lượng nhỏ. Có vẻ như phần liên quan đến công cụ đã bị lược bỏ.