Mẹo cấu trúc thư mục home (2023)

 (unixdigest.com)
2 điểm bởi GN⁺ 2024-04-21 | 1 bình luận | Chia sẻ qua WhatsApp

Mẹo về cấu trúc thư mục home

  • Việc cấu trúc hoặc sắp xếp thư mục thực ra không khác nhiều so với việc cấu trúc hay sắp xếp những thứ khác; điều cốt lõi là làm theo cách hợp lý nhất với bản thân
  • Khi xử lý việc tổ chức, mọi thứ có thể rất nhanh chóng trở nên mất kiểm soát
  • Mục đích chính của việc sắp xếp là hiệu quả: phải có thể tìm thứ cần tìm một cách dễ dàng và nhanh chóng, đồng thời lưu thứ cần lưu cũng dễ dàng và nhanh chóng

Các tệp và thư mục mặc định bị ẩn

  • Trong thư mục home của tôi có đầy đủ các tệp ẩn mặc định vốn là một phần của các hệ điều hành Unix hiện đại như .config, .aliases, .profile, .gnupg, .mozilla
  • Tôi muốn mọi ứng dụng đều tôn trọng XDG_CONFIG_HOME, nhưng cũng không quá can thiệp hay bận tâm về việc đó
  • Trước đây tôi từng quản lý $HOME bằng Git, và đó là một cách rất tốt để tổ chức Dotfiles
  • Tôi vẫn đưa tất cả Dotfiles vào Git để giữ lịch sử thay đổi, nhưng chỉ giữ nguyên những Dotfiles hoạt động giống nhau trên các hệ thống khác nhau mà tôi sử dụng
  • Các Dotfiles theo từng cấu hình được lưu trong thư mục dotfiles và dùng symbolic link

Cấu trúc chung cho tệp và thư mục

  • Các tệp và thư mục thông thường chủ yếu được tổ chức theo hai cách: "danh mục" và "ngày tháng"
  • Cấu trúc thư mục cơ bản:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • Giữ nguyên các thư mục Desktop và Downloads (vì có vẻ hầu hết ứng dụng đều ép dùng chúng)
  • Thư mục bin dùng để lưu shell script và các tệp thực thi nhị phân cá nhân (không bao gồm những thứ được cài qua trình quản lý gói)
  • Thư mục mnt được dùng cho nhiều điểm mount khác nhau như thẻ SD, đĩa USB, bộ nhớ dùng chung trong homelab, v.v.
  • Tôi tuyệt đối không dùng tự động mount mà sử dụng shell script để mount
  • Thư mục usr/dotfiles được quản lý bằng Git cùng với các Dotfiles thông thường như .aliases, và sử dụng symbolic link tới các tệp liên quan trong thư mục dotfiles

Cấu trúc thư mục dữ liệu

  • Thư mục data và edata là hai thư mục chính dùng để lưu toàn bộ dữ liệu
  • Hai thư mục này là các ZFS dataset chạy trên một pool mirror đĩa, tách biệt với cài đặt hệ thống gốc
  • Tôi tận dụng ZFS để sao lưu dễ dàng lên bộ nhớ mạng bằng cách thường xuyên dùng snapshot cũng như ZFS send/receive
  • Điểm khác biệt giữa data và edata là edata là ZFS dataset dùng mã hóa gốc mặc định
  • Mã hóa tốt cho quyền riêng tư, nhưng cũng là một lớp phức tạp khủng khiếp đặt chồng lên một hệ thống phân cấp tệp vốn đã phức tạp, và ZFS encryption vẫn có lỗi
  • Tôi đặc biệt khuyến nghị luôn sao lưu dữ liệu quan trọng vào nhiều giải pháp lưu trữ và nhiều địa điểm khác nhau
  • Tôi không dùng lưu trữ đám mây cho những thứ quan trọng

Mẹo bổ sung

  • Quy tắc cơ bản khi đặt tên tệp và thư mục là chỉ nhìn tên cũng phải dễ dàng nhận ra đó là gì
  • Nếu không thể biết tệp nói về gì nếu chưa mở nó ra, thì bạn nên mở ngay và đổi sang một cái tên có ý nghĩa hơn cho lần sau khi nhìn thấy nó
  • Nếu để tệp và thư mục bừa bộn mà không sắp xếp, về sau sẽ rất khó chỉnh sửa lại
  • Tôi dùng tên tệp có mô tả dài khi cần, để có thể nắm được nội dung tệp mà không cần mở nó ra

Ý kiến của GN⁺

  • Bài viết này đưa ra các mẹo thực tế về cách sắp xếp và tổ chức cấu trúc thư mục. Đặc biệt, cách tận dụng ZFS dataset để chia tách và quản lý thư mục được mã hóa và không mã hóa khá thú vị.

  • Cá nhân tôi nghĩ rằng nên lưu trữ dữ liệu quan trọng dưới dạng mã hóa. Tuy nhiên, vì cũng có những nhược điểm như suy giảm hiệu năng hoặc tăng độ phức tạp do mã hóa gây ra, nên có vẻ tốt hơn nếu sử dụng có chọn lọc tùy theo tình huống.

  • Ngoài ra, tôi cho rằng việc chia sẻ trước cách truy cập dữ liệu đã mã hóa với người thân trong gia đình cũng là một điểm quan trọng. Điều này cần thiết để không làm mất dữ liệu ngay cả khi bản thân không thể truy cập được nữa do tai nạn hay sự cố.

  • Đối với quản lý dữ liệu cá nhân, việc xây dựng một chiến lược sao lưu có hệ thống như tác giả là rất quan trọng. Có thể tuân theo quy tắc sao lưu 3-2-1, nhưng thay vì lưu trữ đám mây thì tận dụng các kho lưu trữ cục bộ phân tán về mặt vật lý cũng có vẻ là một cách hay.

  • Các công cụ mã nguồn mở hữu ích cho việc quản lý dữ liệu cá nhân gồm có Syncthing hoặc Nextcloud. Nếu tận dụng tốt các công cụ này, có thể đạt được việc quản lý dữ liệu cá nhân một cách có hệ thống và an toàn.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-21
Ý kiến trên Hacker News

  • Tôi ghét việc thư mục home trở nên bừa bộn, đặc biệt là khi ứng dụng cho rằng chúng phải tạo các thư mục thậm chí không bị ẩn ngay trong home
    Điều khiến tôi tức nhất là ~/go, thư mục mặc định của Go modules. Tôi ghét đến mức đã tránh cài ứng dụng Go hay phát triển bằng Go trong nhiều năm, nhưng cuối cùng vẫn phải dùng; dù có thể đổi bằng cách đặt GOPATH, giá trị mặc định vẫn quá tệ

    • Tệ nhất là các công cụ CLI viết trên Mac thường phớt lờ XDG. Vì bên đó khái niệm này không phổ biến, mỗi công cụ lại làm bẩn dotfiles bằng thư mục riêng như .rustup, .mix, .npm, .yarn
      Dù vậy, việc làm ô nhiễm thư mục home như ~/go mà thậm chí không lịch sự ẩn đi thì thật sự rất vô duyên
    • Tôi cho rằng bản thân GOPATH là một thiết kế tệ. Thay vì để mỗi dự án có cấu trúc thư mục độc lập như các ngôn ngữ khác, nó khiến những thứ của các dự án không liên quan bị trộn vào cùng một cấu trúc thư mục
      Nó quá trái với cách tôi tổ chức dự án, và đó là lý do chính khiến tôi không còn hứng thú với Go. Có thể hợp hơn với những ai thích gom nhiều dự án không liên quan vào một monorepo, nhưng không phải gu của tôi
    • Mẹo: đừng để file của bạn trong $HOME. $HOME là nơi các ứng dụng làm bẩn, còn file của mình thì có thể để ở đúng nghĩa là bất kỳ chỗ nào khác
    • Tôi đã từ bỏ ý tưởng về một thư mục home sạch từ lâu. Mọi thứ quan trọng tôi để trong thư mục đồng bộ bên trong home như pCloud, Dropbox, và bên trong đó thì được sắp xếp hoàn hảo
      .vimrc và .gitconfig được symlink tới một kho Git. Như vậy phần còn lại của thư mục home có hoàn toàn là rác cũng không sao, và nếu máy chết thì có thể khôi phục trên máy khác trong vài phút
    • Giá mà ngay từ đầu Unix đã tách chuẩn giữa “thư mục home nơi ứng dụng nhét mọi thứ chúng muốn” và “thư mục home nơi người dùng để file của mình” thì tốt biết mấy

  • xdg-ninja đã giúp giảm vấn đề hầu hết ứng dụng xả file vào thư mục home
    Tóm lại, nó quét các chương trình đã cài và cho biết có thể cấu hình chúng tuân theo chuẩn XDG hay không. Không hiệu quả với mọi thứ, nhưng nhiều ứng dụng có tùy chọn như vậy
    https://github.com/b3nj5m1n/xdg-ninja

  • Tôi muốn không chỉ sắp xếp, mà còn sao lưu và di chuyển giữa các máy một cách gọn nhẹ
    Thư mục .config là một vấn đề lớn khi sao lưu có chiến lược, vì các ứng dụng nhét dữ liệu phiên làm việc vài gigabyte vào đó
    “Dữ liệu phiên” không phải là “cấu hình”. “Cấu hình” của một ứng dụng làm sao có thể lên đến vài gigabyte được

    • Trừ khi tôi yêu cầu chương trình thay đổi cấu hình lâu dài, .config phải có thể hoạt động ngay cả khi ở chế độ chỉ đọc
    • Rất đồng cảm. Không hiểu vì sao các ứng dụng lại dùng .config như kho dữ liệu ứng dụng. Đã có .local và .cache cho mục đích đó rồi

  • Chuyện này quá cá nhân, nên giải pháp của tác giả không hữu ích với tôi, và giải pháp của tôi chắc cũng chẳng giúp được mấy cho người khác
    Thư mục home của tôi gần như trống. Tất cả file công việc nằm trong OwnCloud, và câu hỏi thật sự là cấu trúc thư mục bên trong OwnCloud như thế nào. Các kho Git cục bộ thì nằm trên một phân vùng hoàn toàn riêng
    Giờ KeepassXC xử lý khóa SSH, nên các khóa trong .ssh cũng đã nằm trong file Keepass trên OwnCloud. Mọi thứ đơn giản hơn rất nhiều, và giờ trong thư mục home thật sự hầu như chẳng còn gì đáng để bận tâm

    • Điều quan trọng chỉ là tính di động khi đổi hệ thống và việc tách biệt môi trường công việc/cá nhân
      Sau khi đăng nhập, tôi phải có thể dùng một lệnh để đồng bộ bộ file phù hợp tùy theo môi trường hiện tại là Linux hay không, dùng cho công việc hay cá nhân, desktop hay server
      Ví dụ, tôi tuyệt đối không muốn xuất các biến môi trường như endpoint vault ở nhà hoặc một token cụ thể nào đó sang hệ thống công việc
      Gần đây tôi đã chuyển sang home-manager của dự án NixOS, và nó trông khá hứa hẹn. Ngôn ngữ Nix phức tạp, nhưng lớp trừu tượng để định nghĩa nhiều môi trường khác nhau chính xác là thứ tôi cần, và có thể tách nội dung file công việc/cá nhân bằng các nhánh Git
    • Dù vậy, tôi vẫn để .vimrc và .bashrc/.zshrc trong home

  • Ý tưởng thì ổn, nhưng tôi không thích cách chia media theo cấu trúc kiểu gia đình. Về sau có vẻ sẽ sinh ra cả đống tệp trùng lặp và các bản trùng đã chỉnh sửa, rồi chúng dễ bị lẫn vào nhau khiến bạn có thể làm mất bản đã chỉnh sửa
    Tôi nghĩ ảnh nên được sắp xếp bằng từ khóa EXIF thì hơn. Lưu metadata trong chính bức ảnh, có thể là trong MIME type, rồi nếu liên quan đến gia đình thì gắn tag như #family hoặc #personx. Vì vậy ảnh cứ để trong các thư mục kiểu theo ngày, còn phần còn lại thì dùng chương trình như Adobe Bridge để chỉnh sửa từ khóa
    Với cấu trúc tên tệp tài liệu, tôi đã thử cả Date then Description.txt lẫn Keyword Title or Description and then Date.txt. Ngày thì dùng ngày ISO theo định dạng YYYY-MM-DD-hhmm để tiện sắp xếp, trong đó -hhmm là tùy chọn
    Có lúc tôi muốn sắp xếp theo chủ đề, tức từ khóa hoặc tiêu đề, nhưng khi thời điểm ghi lại quan trọng hơn, như log chẳng hạn, thì nên đặt ngày ở đầu
    Có thể trông như không cần thiết vì ngày cũng được lưu trong hệ thống, nhưng khi di chuyển tệp thì ngày cuối cùng cũng sẽ thay đổi, và nếu sơ suất thì càng dễ bị đổi hơn. Còn ngày trong tên tệp thì không đổi, và cũng giúp sắp xếp danh sách

    • Với vấn đề này, kho lưu trữ dựa trên địa chỉ nội dung theo từng loại media có vẻ là hướng đúng. Lý tưởng nhất là một lớp overlay chỉ tham chiếu, không thay đổi cấu trúc thư mục hay cách sắp xếp tệp hiện có
      photoprism và photostructure có vẻ không quá quan tâm đến cấu trúc thư mục hay cách sắp xếp, nhưng paperless (và các biến thể mới như paperless-ngx) thì nổi tiếng là rất cố chấp về cách sắp xếp và không muốn tôn trọng cấu trúc hiện có
      Có một thời gian tôi dùng camlistore/perkeep cho ảnh, nhưng Google Photos có một năng lực áp đảo: nhận ra ai có mặt trong mọi bức ảnh, thậm chí còn tính đến cả chênh lệch tuổi. Hai con trai của tôi cách nhau 8 tuổi, ở cùng tầm tuổi thì trông thật sự rất giống nhau, vậy mà nó vẫn phân biệt chính xác ai là ai. Tôi không biết nó dùng phân tích khuôn mặt hay metadata của ảnh, nhưng chưa lần nào nhầm. Có điều không có cách hợp lý nào để lấy thông tin tag đó ra khỏi Google Photos, dù tôi đang trả tiền
      Có lẽ đã đến lúc xem lại. Tôi không nhớ photostructure hay photoprism có thử nhận diện khuôn mặt hay không, nhưng dù hiện chưa làm thì có lẽ chúng sẽ sớm đạt mức gần giống Google Photos, hoặc ít nhất đủ tốt để cắt phụ thuộc vào Google
      Tài liệu và ảnh/video thì tạm vậy, còn âm nhạc thì sao? Dù tốt hay xấu, đã ít nhất khoảng 10 năm tôi không trực tiếp quản lý bộ sưu tập nhạc dưới dạng tệp nữa. Dạo này có hệ thống thư viện nào dành cho nhạc được tích hợp sâu hơn với nội dung, thay vì chỉ là “tệp trên đĩa” đơn giản như paperless hay photoprism không?
    • Nếu muốn quản lý tag tùy ý cho tệp, có thể thử TagSpaces https://www.tagspaces.org/ hoặc TMSU https://tmsu.org/. Không chỉ giới hạn ở các tệp EXIF hay ID3

  • Cách của tôi là thế này
    Các mục liên quan đến GUI thì để chữ hoa, còn các mục liên quan đến CLI thì để chữ thường. Tôi thích kiểu ~/documents hơn, nhưng vì người dùng GUI cứ khăng khăng dùng chữ hoa nên tôi chấp nhận. Hầu như không có việc gì phải trộn hai bên, nên cũng không thành vấn đề lớn
    ~/dotfiles là thư mục dotfile do Git quản lý. Tôi tạo liên kết tượng trưng kiểu ~/.zshrc -> dotfiles/zshrc. Không dùng phần mềm quản lý riêng, chỉ tạo link thôi. Trước đây tôi dùng ~/.dotfiles, nhưng tôi nghĩ để nó hiện ra thì hợp lý hơn
    ~/projects là thư mục dự án. ~/projects/test là dự án thử nghiệm dùng một lần để kiểm tra, ~/projects/my là dự án cá nhân, ~/projects/company là dự án của công ty hiện tại tôi đang làm. Có lúc tôi làm với nhiều công ty kiểu gần như freelance, nên cần tách riêng
    ~/tmp là thư mục cho mọi việc dùng một lần. Tôi có một shell function tên mkcdtmp, nó tạo thư mục theo ngày hiện tại như ~/tmp/240419 rồi chuyển vào đó. Cách này thật sự rất tốt. Tôi thích mua ổ đĩa lớn và để rác lại ở trạng thái có tổ chức phần nào, nên gần như không dọn. Nếu cần thứ gì đó của hôm qua hay tháng trước, tôi biết nó ở đâu; đây là việc giúp ích nhiều nhất cho việc sắp xếp công việc tạm. Nếu cần thì cũng có thể tạo ~/tmp/whatever, dù sao tất cả đều là đồ bỏ đi
    Tôi không dùng ~/Desktop. ~/Documents cũng gần như không dùng và vẫn cần tìm cách sắp xếp. Những thứ như ghi chú ngắn thì tôi ném vào repo GitHub dùng để build website cá nhân. Tôi đã thử nhiều ứng dụng ghi chú, nhưng một website bình thường viết bằng Markdown là hợp nhất với tôi
    Tôi chưa từng thành công trong việc sắp xếp công việc thật có cấu trúc. Lúc nào cũng có đống rác lăn lóc rồi cuối cùng thành thứ gì đó dùng được, nên thay vì chiến đấu với bản thân, tôi quyết định biến đống rác đó thành rác có tổ chức
    Về bản chất, máy tính của tôi là vật tiêu hao. Mọi thứ trong ~/projects đều nằm trên Git, còn ~/tmp gần như là cache không mấy quan trọng hoặc công việc bỏ đi. Tôi cố sắp xếp sao cho việc khôi phục từ trạng thái sạch không mất nhiều thời gian. Tôi thường xuyên cài lại OS từ đầu, cũng hay đổi hệ điều hành và laptop; cách này hợp với tôi nhất

    • Tôi thật sự ghét việc viết hoa bất cứ thứ gì. Tôi biết chỉ là nhấn thêm một phím thôi, nhưng phiền khủng khiếp

  • Một trong những điều tôi rất không hài lòng ở hệ thống tệp là có quá nhiều thư mục bắt đầu bằng D
    Desktop, Dev, Downloads, Documents, Dropbox, v.v.
    Tôi từng nghĩ có nên đổi gì đó không, nhưng như tác giả nói, nhiều ứng dụng khá cố chấp về vấn đề này

    • Để tránh vấn đề này, tôi dùng /src

  • Tôi dùng một cấu trúc khá đơn giản nhưng hợp với mình
    Bên dưới projects/, tôi tạo các thư mục theo năm như 2023/, 2024/, và mỗi dự án được thêm tiền tố tháng+ngày như 0000-something/, 0312-other-project/, 0419-hn-comment/
    Mỗi năm tạo một thư mục năm, và khi muốn đẩy các dự án dài hạn lên trên thì thêm 0000 hoặc chỉ để phần ngày là 00
    Đơn giản và chạy được trên mọi OS. Trên Linux thì tôi có dùng thêm một chút script phụ trợ
    Việc nhanh chóng tạo thư mục để chuyển file từ thư mục Downloads sang cũng dễ, và nếu giữ mức lồng nhau chỉ một cấp thì dễ tìm. Tôi thấy cách này tốt hơn kiểu có thêm một cấp tháng như mẫu YYYY/MM/DD

    • Tôi dùng một cách tương tự khi sắp xếp các thư mục liên quan theo thứ tự thời gian
      Ở thư mục cấp cao nhất, tôi thường để những thứ đang làm hiện tại. Kiểu như khái niệm “hôm nay” hoặc “tuần này”
      Khi lưu trữ ra ngoài khung thời gian đó, chẳng hạn nếu là hôm nay thì tôi tạo một thư mục theo dạng 041924, rồi chuyển tất cả file tạo trong ngày đó vào đó
      Thường thì xét theo tuổi thọ con người, tôi không thấy cần dùng chuỗi như 2024. Chắc tôi cũng không sống đến năm 2100, còn trước năm 2000 thì không liên quan, nên 24 là đủ
      Thời gian cứ trôi nên số thư mục lưu trữ sẽ tăng lên, nhưng chúng nhỏ và dễ tìm. Cách này đặc biệt hợp nếu mỗi ngày bạn tạo ra những file tiêu chuẩn không mấy độc nhất
    • Không dùng ngày sửa đổi của thư mục được sao? Như vậy có thể sắp xếp mà
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • Tôi cũng đã chuyển sang hướng thêm vào cách này một cấu trúc thư mục mang tính “quy trình xử lý”. Dữ liệu trùng lặp sẽ tăng, nhưng nó giữ được sức khỏe tinh thần

  • Về sao lưu, từng có lần tôi định cài một máy Mac mới từ bản sao lưu Time Machine, nhưng máy Mac lại không nhìn thấy bất cứ thứ gì trong bản sao lưu Time Machine
    Khi liên hệ hỗ trợ Apple, tôi được nghe rằng có một lỗi hiếm gặp: trong quá trình cài đặt, đôi khi thay vì cài từ bản sao lưu, nó lại khởi tạo lại bản sao lưu Time Machine
    May là tôi đã thiết lập Backblaze nên thoát nạn, nhưng việc khôi phục hàng trăm gigabyte mất cực kỳ lâu
    Giờ tôi dùng cả Time Machine, Backblaze và sao lưu iCloud, thỉnh thoảng còn đóng gói toàn bộ thành .tgz rồi tải lên S3

  • Về chuyện dùng dấu gạch nối hay dấu gạch dưới trong tên file và tên thư mục, tôi hoàn toàn đồng ý với dấu gạch nối
    Dùng dấu gạch nối khi di chuyển trong terminal quá thực dụng, đến mức tôi nghĩ nó nên trở thành chuẩn. Tốt hơn nhiều so với việc lần nào cũng phải nhập thêm để chọn tên file có dấu gạch dưới, hoặc phải xử lý khoảng trắng

    • Đây là một điểm nhỏ tôi thích ở Lisp. Có thể đặt tên biến kiểu foo-bar-baz, và khi gõ không cần nhấn Shift