- Dù đã nhiều lần tăng dung lượng lưu trữ, mức sử dụng cũng tăng theo; trong một khảo sát Mastodon với 81 người tham gia, khoảng một nửa đang dùng hơn 75% dung lượng đĩa
- Điều này có thể được giải thích phần nào bằng lập luận entropy rằng có nhiều cách để đạt trạng thái đầy hơn là trạng thái trống, nhưng nó không giải thích hoàn toàn hành vi của người dùng
- Việc trì hoãn dọn dẹp cho đến khi chạm giới hạn rồi chỉ xóa vừa đủ cho nhu cầu trước mắt khiến ổ đĩa luôn ở trạng thái bão hòa thường trực
- Phần mềm chậm dần, nợ kỹ thuật tích tụ, đường sá ùn tắc và lịch trình dày đặc cũng cho thấy cùng một mô thức: chỉ phản ứng sau khi nỗi khó chịu đạt đến ngưỡng
- Nếu đặt ràng buộc nhân tạo nhỏ hơn tổng tài nguyên như một dạng ngân sách, ta có thể tránh tối ưu hóa quá sớm mà vẫn không bỏ mặc vấn đề cho đến sát giới hạn
Vì sao dung lượng lưu trữ cứ đầy mãi
- Ổ gốc chỉ còn 17GB trong tổng 0,47TB khả dụng, tức 3% dung lượng trống; ổ 12TB lắp thêm cũng chỉ còn 140GB, khoảng 1%
- Dung lượng lưu trữ đã nhiều lần tăng gấp đôi, từ khoảng 80MB vào thập niên 1990 lên tới hàng chục TB, nhưng phần lớn vẫn đang được dùng
- Việc phần mềm giúp tìm các tệp cần dọn dẹp đã tồn tại từ lâu cũng cho thấy vấn đề này vẫn kéo dài
- Trong 81 người trả lời khảo sát Mastodon, khoảng một nửa đang dùng hơn 75% ổ cứng, nên trường hợp dung lượng lưu trữ đầy phổ biến hơn là trống
- Vì có nhiều trạng thái tạo nên một ổ đĩa đầy hơn là một ổ đĩa trống, có thể diễn giải theo entropy rằng nếu thay đổi trạng thái ngẫu nhiên mà không xét đến dung lượng lưu trữ, hệ sẽ tiến về trạng thái bão hòa
- Tuy nhiên, ổ đĩa không được cảm nhận là vấn đề cho đến khi không thể lưu thêm nữa; đến lúc đó, nó đã quá lộn xộn để dễ quyết định tệp nào nên xóa
- Người dùng chỉ dọn vừa đủ để câu thêm thời gian rồi dừng lại, nên ổ đĩa nhanh chóng chạm giới hạn trở lại
- Ngay cả khi tăng dung lượng lưu trữ lên nhiều bậc độ lớn, hành vi này vẫn không thay đổi
Ngưỡng chịu đựng và ràng buộc nhân tạo
- Mô thức trì hoãn xử lý cho đến khi vấn đề đạt mức không thể chịu được lặp lại trong nhiều lĩnh vực
- Phần mềm thường không được tối ưu cho đến khi trở nên quá chậm, nên nhìn chung cứ duy trì ở trạng thái chậm
- Nợ kỹ thuật tích tụ cho đến khi làm việc với mã trở nên đau đớn và việc refactor là không thể tránh khỏi
- Lập trình viên ít kinh nghiệm đôi khi bắt đầu lại từ đầu, khiến phần lớn codebase trở nên bừa bộn
- Mạng lưới đường bộ chỉ được mở rộng sau khi ùn tắc đến mức khó kham nổi
- Chế độ ăn uống không được quản lý cho đến khi phải mua quần cỡ lớn hơn
- Ngay cả khi bỏ công việc toàn thời gian để tự kinh doanh, khi nghĩa vụ và chỉ thị biến mất, lịch trình vẫn được lấp đầy bận rộn như trước, đôi khi còn hơn
- Nếu chờ đến ngưỡng giới hạn, khối lượng việc phải xử lý sẽ lớn hơn nhiều so với giải quyết dần trong quá trình vận hành; nhưng ngược lại, tối ưu hóa quá sớm cũng không phải điều nên làm
- Để cân bằng hai vấn đề này, có thể vận dụng Jevons paradox bằng cách đặt một ràng buộc thực tế nhỏ hơn tổng tài nguyên sẵn có và tối ưu trong phạm vi đó
- Trong tài chính cá nhân, điều này được gọi là ngân sách, nhưng trong các lĩnh vực khác, cùng nguyên lý này lại thường xuyên bị bỏ qua
- Nếu triển khai phần mềm lên Raspberry Pi, tự dùng và tối ưu nó, phần mềm đó cũng sẽ chạy nhanh trên Threadripper
- Một codebase có thể điều hướng được trong Vim trên terminal 80×25 thì cũng có thể điều hướng được trong các IDE hiện đại mạnh mẽ
- Khi tài nguyên và tính năng tăng lên, ta tưởng như có thể làm được nhiều việc hơn, nhưng trên thực tế đôi khi chỉ khiến ta làm cùng một việc với chi phí lớn hơn
1 bình luận
Ý kiến trên Lobste.rs
Đó là một ràng buộc đau đớn, nhưng đã loại bỏ hẳn một nhóm yêu cầu hỗ trợ khách hàng. Các đối thủ thì либо chỉ hỗ trợ Mac và Linux, hoặc chỉ phát hành cho Windows rồi hứa sẽ hỗ trợ UNIX sau; nhìn họ vật lộn với những câu hỏi không dứt kiểu “Bao giờ có Linux?” khiến tôi thấy nhẹ nhõm. Tôi vẫn nhận câu hỏi “Bao giờ port sang BSD?”, nhưng vẫn ở mức chịu được
Các lệnh SIMD mới nhất cũng thú vị, nhưng chuẩn tối ưu của tôi luôn là Intel Haswell với AVX2 trên MacBook Pro 2015. Code chạy tốt trong môi trường đó thì đến giờ vẫn chạy tốt y như vậy
Mỗi lần tăng từ 256GB lên 512GB, lượng nội dung tôi lưu cũng tăng theo. Luôn có thêm repository để clone, nhạc để tải xuống, video YouTube và phim để lưu trữ, còn kích thước file thì cũng phình ra khi chuyển từ 720p lên 1080p rồi 4K. Game cũng ngày càng to đến mức phải xóa một game Steam để cài game Steam khác. Tôi tự hỏi liệu đây đơn giản chỉ là hiện tượng lấp đầy cái giỏ hiện có cho đến khi kiếm được cái giỏ lớn hơn hay không
Tôi thường gắn sao các repository mình thích trên GitHub hay Codeberg. Tôi hy vọng một ngày nào đó, giống như fediverse, có thể chia sẻ sao giữa các Git forge khác nhau để không phải giữ tài khoản ở GitHub, GitLab và Codeberg cùng lúc. Tôi muốn biết có phải bạn tự clone code để phòng trường hợp repository biến mất hoặc không còn truy cập được nữa không
/nixgần như lúc nào cũng trên 90% trừ ngay sau khi cài mới hoàn toàn. Nix cho thấy rất rõ góc nhìn của nhà phát triển rằng, tương tự quản lý bộ nhớ, nó chỉ thu hồi dung lượng đĩa bằng garbage collection khi thực sự cần chỗ. Nhiều phiên bản của các sản phẩm build trung gian cũng chiếm lượng lớn dung lượngMáy chủ media thì không đầy, vì tôi dùng RAID dị chủng tăng dần qua nhiều năm: mỗi khi một ổ cũ hỏng thì thay bằng ổ lớn hơn với mức giá tương tự. Tôi cũng đã bỏ cuộc với ý định số hóa toàn bộ CD và DVD trong nhà. CD audio dùng nén không mất dữ liệu và game Wii thì đáng giá, còn HD-DVD thì hoàn toàn không bõ công
Việc đảm bảo dữ liệu có giá trị không biến mất, thường bằng cách ghi vào Nix và lưu trong thư mục dự án dùng Git, khá phiền phức. Duy trì thiết bị kiểu cỗ máy thời gian này suốt nhiều năm đã tốn rất nhiều công sức, nhưng nó có vẻ là cách duy nhất để quản lý quy mô và độ phức tạp không ngừng tăng lên