Tips Menata Struktur Home Directory (2023)

 (unixdigest.com)
2 poin oleh GN⁺ 2024-04-21 | 1 komentar | Bagikan ke WhatsApp

Tips Struktur Home Directory

  • Menata atau merapikan struktur direktori pada dasarnya tidak jauh berbeda dari menata atau merapikan hal lain; yang paling penting adalah melakukannya dengan cara yang paling masuk akal bagi diri sendiri
  • Saat berurusan dengan organisasi, kondisinya bisa sangat cepat menjadi di luar kendali
  • Tujuan utama kerapian adalah efisiensi: Anda harus bisa menemukan apa yang dicari dengan mudah dan cepat, serta menyimpan apa yang perlu disimpan dengan mudah dan cepat

File dan direktori bawaan tersembunyi

  • Di home directory saya ada semua file tersembunyi bawaan yang merupakan bagian dari sistem operasi Unix modern, seperti .config, .aliases, .profile, .gnupg, .mozilla, dan sebagainya
  • Saya lebih suka semua aplikasi menghormati XDG_CONFIG_HOME, tetapi saya tidak terlalu ikut campur atau terlalu memikirkannya
  • Dulu saya pernah mengelola $HOME dengan Git, dan itu adalah cara yang sangat baik untuk menyusun dotfiles
  • Saya masih menaruh semua dotfiles di Git untuk menjaga riwayat perubahan, tetapi hanya mempertahankan dotfiles yang bekerja sama di berbagai sistem yang saya gunakan
  • Dotfiles khusus konfigurasi disimpan di direktori "dotfiles" dan menggunakan symbolic link

Susunan file dan direktori umum

  • File dan direktori umum terutama disusun dengan dua cara: "kategori" dan "tanggal"
  • Struktur direktori dasar:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • Direktori Desktop dan Downloads dibiarkan apa adanya (karena tampaknya dipaksakan oleh sebagian besar aplikasi)
  • Direktori bin digunakan untuk menyimpan shell script dan file executable biner pribadi (tidak termasuk yang dipasang melalui package manager)
  • Direktori mnt digunakan untuk berbagai mount point seperti kartu SD, disk USB, dan shared storage yang dipakai di homelab
  • Saya tidak pernah melakukan auto-mount, dan menggunakan shell script untuk mounting
  • Direktori usr/dotfiles dikelola dengan Git bersama dotfiles umum seperti .aliases, dan menggunakan symbolic link ke file terkait di direktori dotfiles

Susunan direktori data

  • Direktori data dan edata adalah dua direktori utama tempat semua materi disimpan
  • Kedua direktori ini adalah dataset ZFS yang berjalan di pool mirroring disk, terpisah dari instalasi root
  • Dengan memanfaatkan ZFS, saya rutin menggunakan snapshot serta ZFS send dan receive untuk memudahkan backup ke network storage
  • Perbedaan antara data dan edata adalah bahwa edata merupakan dataset dengan enkripsi bawaan ZFS
  • Enkripsi baik untuk privasi, tetapi juga merupakan lapisan kompleksitas yang mengerikan di atas hierarki file system yang sudah rumit, dan enkripsi ZFS memiliki bug
  • Sangat disarankan agar data penting selalu dibackup ke beberapa solusi penyimpanan dan lokasi yang berbeda
  • Saya tidak menggunakan cloud storage untuk hal-hal yang penting

Tips tambahan

  • Aturan dasar untuk penamaan file dan direktori adalah nama itu sendiri harus membuat Anda bisa dengan mudah mengidentifikasi apa isinya
  • Jika Anda tidak bisa mengetahui isi file hanya dari namanya tanpa membukanya, segera buka file itu dan ubah namanya menjadi sesuatu yang lebih bermakna saat Anda melihat nama file itu lagi nanti
  • Jika file dan direktori dibiarkan tanpa dirapikan, akan menjadi sangat sulit untuk memperbaikinya nanti
  • Saya menggunakan nama file dengan deskripsi panjang saat diperlukan agar isi file bisa dipahami tanpa harus membukanya

Pendapat GN⁺

  • Artikel ini memberikan tips praktis tentang cara merapikan dan menyusun struktur direktori. Secara khusus, cara memanfaatkan dataset ZFS untuk membagi dan mengelola direktori terenkripsi dan yang tidak terenkripsi terasa menarik.

  • Secara pribadi, saya merasa menyimpan data penting dalam keadaan terenkripsi adalah pilihan yang baik. Namun, karena ada juga kekurangan seperti penurunan performa atau bertambahnya kompleksitas akibat enkripsi, tampaknya lebih baik digunakan secara selektif sesuai situasi.

  • Selain itu, menurut saya poin penting lainnya adalah membagikan cara mengakses data terenkripsi kepada anggota keluarga. Dengan begitu, meskipun terjadi kecelakaan atau hal lain yang membuat diri kita tidak bisa mengaksesnya, data tetap tidak hilang.

  • Untuk pengelolaan data pribadi, sangat penting memiliki strategi backup yang sistematis seperti penulis. Mengikuti aturan backup 3-2-1, sambil memanfaatkan penyimpanan lokal yang tersebar secara fisik alih-alih cloud storage, juga tampak sebagai pendekatan yang baik.

  • Beberapa alat open source yang berguna untuk pengelolaan data pribadi antara lain Syncthing dan Nextcloud. Jika alat-alat ini dimanfaatkan dengan baik, pengelolaan data pribadi yang sistematis dan aman tampaknya bisa diwujudkan.

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-21
Pendapat di Hacker News

  • Saya tidak suka direktori home jadi berantakan, dan terutama sangat menjengkelkan ketika aplikasi merasa perlu membuat direktori yang bahkan tidak tersembunyi di home
    Yang paling membuat marah adalah ~/go, direktori default untuk modul Go. Saya begitu membencinya sampai selama bertahun-tahun menghindari memasang atau mengembangkan aplikasi Go, tetapi akhirnya harus memakainya; meski bisa diubah dengan pengaturan GOPATH, sebagai default itu buruk sekali

    • Yang terburuk adalah tool CLI yang dibuat di Mac sering mengabaikan XDG. Karena konsep itu tidak umum di sana, tiap tool mengotori dotfile dengan direktorinya sendiri seperti .rustup, .mix, .npm, .yarn
      Meski begitu, mencemari direktori home tanpa sopan santun untuk sekadar menyembunyikannya seperti ~/go benar-benar tidak sopan
    • Menurut saya GOPATH sendiri adalah desain yang buruk. Alih-alih memiliki struktur direktori independen per proyek seperti bahasa lain, ia membuat hal-hal dari proyek yang tidak saling terkait bercampur dalam struktur direktori yang sama
      Ini sangat bertentangan dengan cara saya mengorganisasi proyek, dan menjadi alasan utama saya tidak tertarik pada Go. Mungkin lebih cocok bagi orang yang suka mengumpulkan banyak proyek tidak terkait dalam satu monorepo, tetapi itu bukan selera saya
    • Tip: jangan taruh file Anda di $HOME. $HOME adalah tempat yang dikotori aplikasi, dan file saya bisa diletakkan secara harfiah di tempat lain mana pun
    • Saya sudah lama menyerah pada gagasan direktori home yang bersih. Semua yang penting saya taruh di direktori sinkronisasi seperti pCloud atau Dropbox di dalam home, dan bagian dalamnya saya tata dengan sempurna
      .vimrc dan .gitconfig saya jadikan symbolic link ke repositori Git. Dengan begitu, sisa direktori home boleh benar-benar jadi sampah, dan bahkan jika mesin mati, bisa dipulihkan di mesin lain dalam beberapa menit
    • Seandainya sejak awal Unix secara standar memisahkan “direktori home tempat aplikasi menaruh semua yang mereka mau” dan “direktori home tempat pengguna menaruh file mereka sendiri”

  • xdg-ninja membantu mengurangi masalah kebanyakan aplikasi yang menumpahkan file ke direktori home
    Singkatnya, tool ini memindai program yang terpasang dan memberi tahu apakah program tersebut bisa dikonfigurasi agar mengikuti standar XDG. Tidak berlaku untuk semuanya, tetapi banyak aplikasi punya opsi seperti itu
    https://github.com/b3nj5m1n/xdg-ninja

  • Selain rapi, saya juga ingin bisa mencadangkan dan memindahkannya secara ringkas antar mesin
    Folder .config menjadi masalah besar untuk strategi backup karena aplikasi menaruh data sesi berukuran beberapa gigabyte di sana
    “Data sesi” bukan “konfigurasi”. Tidak mungkin “konfigurasi” aplikasi berukuran beberapa gigabyte

    • Kecuali kita meminta program melakukan perubahan konfigurasi permanen, .config seharusnya tetap bisa berjalan meski read-only
    • Sangat setuju. Saya tidak tahu mengapa aplikasi memakai .config seperti penyimpanan data aplikasi. Untuk penggunaan seperti itu sudah ada .local dan .cache

  • Ini terlalu personal, jadi solusi penulis tidak berguna bagi saya, dan solusi saya juga mungkin tidak banyak membantu orang lain
    Direktori home saya hampir kosong. Semua file kerja ada di OwnCloud, dan pertanyaan sebenarnya adalah seperti apa struktur direktori di dalam OwnCloud. Repositori Git lokal saya taruh di partisi yang sepenuhnya terpisah
    Sekarang KeepassXC menangani kunci SSH, kunci-kunci di .ssh juga masuk ke dalam file Keepass yang ada di OwnCloud. Jadi sangat sederhana, dan sekarang hampir tidak ada lagi yang perlu saya pedulikan di direktori home

    • Yang penting hanyalah portabilitas saat berganti sistem dan pemisahan lingkungan kerja/pribadi
      Setelah login, dengan satu perintah saya harus bisa menyinkronkan set file yang sesuai dengan apakah lingkungan saat ini Linux, untuk kerja, pribadi, desktop, atau server
      Misalnya, saya sama sekali tidak ingin mengekspor variabel lingkungan seperti endpoint vault rumah atau token tertentu ke sistem kerja
      Belakangan saya pindah ke home-manager dari proyek NixOS, dan terlihat cukup menjanjikan. Bahasa Nix memang rumit, tetapi abstraksi untuk mendefinisikan berbagai lingkungan memang tepat seperti yang saya butuhkan, dan isi file kerja/pribadi bisa dipisahkan dengan branch Git
    • Meski begitu, .vimrc dan .bashrc/.zshrc tetap saya taruh di home

  • Idenya lumayan, tetapi saya tidak suka cara membagi media ke dalam struktur seperti keluarga. Nantinya tampak akan muncul banyak file duplikat dan salinan duplikat yang sudah diedit, lalu mudah tercampur sehingga versi editannya bisa hilang
    Menurut saya foto lebih baik diatur dengan kata kunci EXIF. Simpan metadata di dalam foto itu sendiri, mungkin di dalam tipe MIME, lalu jika terkait keluarga beri tag seperti #family atau #personx. Jadi foto diletakkan di folder seperti berdasarkan tanggal, sementara sisanya memakai program seperti Adobe Bridge untuk mengedit kata kunci
    Untuk struktur nama file dokumen, saya pernah memakai baik Date then Description.txt maupun Keyword Title or Description and then Date.txt. Untuk tanggal, gunakan tanggal ISO dalam format YYYY-MM-DD-hhmm agar bisa diurutkan, dan -hhmm bersifat opsional
    Kadang kita ingin mengurutkan berdasarkan topik, yaitu kata kunci atau judul, tetapi ketika waktu pencatatan lebih penting, seperti pada log, lebih baik menaruh tanggal di depan
    Tanggal memang juga disimpan oleh sistem sehingga mungkin terlihat tidak perlu, tetapi saat file dipindahkan, tanggal pada akhirnya berubah, dan lebih mudah berubah lagi jika kita melakukan kesalahan. Sebaliknya, tanggal di dalam nama file tidak berubah dan juga membantu pengurutan daftar

    • Penyimpanan berbasis alamat konten per jenis media tampaknya merupakan arah yang tepat untuk masalah ini. Idealnya berupa overlay yang hanya merujuk tanpa mengubah struktur direktori atau penataan file yang sudah ada
      photoprism dan photostructure tampaknya tidak terlalu peduli pada struktur atau penataan direktori, tetapi paperless (termasuk varian modern seperti -ngx) terkenal sangat ngotot soal penataan dan enggan menghormati struktur yang sudah ada
      Dulu saya sempat memakai camlistore/perkeep untuk foto, tetapi Google Photos punya kemampuan luar biasa untuk mengenali siapa yang ada di setiap foto, bahkan dengan memperhitungkan perbedaan usia. Dua putra saya yang terpaut 8 tahun benar-benar mirip pada usia yang berdekatan, tetapi Google Photos tetap bisa membedakan siapa yang siapa dengan tepat. Saya tidak tahu apakah mereka memakai analisis wajah atau metadata foto, tetapi belum pernah sekali pun tertukar. Sayangnya, tidak ada cara yang masuk akal untuk mengeluarkan informasi tag itu dari Google Photos, meski saya membayar
      Sepertinya sekarang saatnya meninjau lagi. Saya tidak ingat apakah photostructure atau photoprism mencoba pengenalan wajah, tetapi meski belum, rasanya mereka akan segera mencapai tingkat yang mirip Google Photos, atau setidaknya cukup baik untuk lepas dari ketergantungan pada Google
      Untuk dokumen dan foto/video, baiklah; lalu bagaimana dengan musik? Baik atau buruk, sudah kira-kira setidaknya 10 tahun sejak terakhir kali saya mengelola koleksi musik langsung sebagai file. Apakah sekarang ada sistem pustaka untuk musik yang, seperti paperless atau photoprism, terintegrasi lebih dalam dengan konten daripada sekadar “file di disk”?
    • Untuk mengelola tag file arbitrer, TagSpaces https://www.tagspaces.org/ atau TMSU https://tmsu.org/ layak dicoba. Tidak terbatas hanya pada file EXIF atau ID3

  • Cara saya seperti ini
    Item yang terkait GUI saya tulis dengan huruf besar, sedangkan yang terkait CLI dengan huruf kecil. Saya lebih suka yang seperti ~/documents, tetapi karena orang-orang GUI bersikeras memakai huruf besar, saya menerimanya saja. Hampir tidak pernah ada kebutuhan untuk mencampur keduanya, jadi bukan masalah besar
    ~/dotfiles adalah direktori dotfile yang dikelola dengan Git. Saya membuat symbolic link seperti ~/.zshrc -> dotfiles/zshrc. Saya tidak memakai perangkat lunak manajemen terpisah, hanya membuat link. Dulu saya memakai ~/.dotfiles, tetapi menurut saya lebih masuk akal jika dibuat terlihat
    ~/projects adalah direktori proyek. ~/projects/test untuk proyek uji sekali pakai sekadar mengecek sesuatu, ~/projects/my untuk proyek pribadi, dan ~/projects/company untuk proyek perusahaan tempat saya bekerja saat ini. Ada kalanya saya bekerja dengan beberapa perusahaan seperti pekerja lepas, jadi perlu dipisahkan
    ~/tmp adalah direktori untuk semua pekerjaan sekali pakai. Saya punya fungsi shell bernama mkcdtmp yang membuat direktori bertanggal hari ini seperti ~/tmp/240419, lalu pindah ke dalamnya. Ini benar-benar cara yang bagus. Saya lebih suka membeli disk besar dan membiarkan sampah tetap tersisa dalam keadaan agak teratur, jadi hampir tidak pernah membersihkannya. Jika saya butuh sesuatu dari kemarin atau bulan lalu, saya tahu di mana mencarinya, dan ini adalah hal yang paling membantu dalam merapikan pekerjaan sementara. Jika perlu, saya juga bisa membuat ~/tmp/whatever, dan toh semuanya barang buangan
    Saya tidak memakai ~/Desktop. ~/Documents juga hampir tidak saya pakai dan saya masih perlu mencari cara merapikannya. Catatan singkat dan semacamnya saya lempar ke repositori GitHub yang membangun situs web pribadi saya. Saya sudah mencoba berbagai aplikasi catatan, tetapi situs web biasa berbasis Markdown paling cocok untuk saya
    Saya tidak pernah berhasil menata pekerjaan dengan sangat terstruktur. Selalu ada tumpukan sampah yang berkeliaran dan pada akhirnya menjadi sesuatu yang berguna, jadi alih-alih melawan diri sendiri, saya memutuskan untuk membuat sampah itu menjadi sampah yang tertata
    Pada dasarnya komputer saya adalah barang habis pakai. Semua yang ada di ~/projects ada di Git, dan ~/tmp lebih mirip cache atau pekerjaan buangan yang tidak terlalu penting. Saya berusaha menatanya agar tidak butuh waktu lama untuk memulihkan dari keadaan bersih. Saya sering memasang ulang OS dari nol dan juga sering berganti sistem operasi serta laptop, dan cara ini paling cocok untuk saya

    • Saya benar-benar tidak suka menulis apa pun dengan huruf besar. Saya tahu itu cuma menekan satu tombol lagi, tetapi rasanya sangat merepotkan

  • Salah satu keluhan besar saya terhadap sistem file adalah terlalu banyak direktori yang diawali dengan D
    Desktop, Dev, Downloads, Documents, Dropbox, dan seterusnya
    Saya sempat berpikir untuk mengubah sesuatu, tetapi seperti yang dikatakan penulis, banyak aplikasi cukup ngotot soal hal ini

    • Untuk menghindari masalah ini, saya memakai /src

  • Saya memakai struktur yang cukup sederhana, tetapi cocok untuk saya
    Di bawah projects/, saya membuat folder tahun seperti 2023/, 2024/, dan setiap proyek diberi prefiks bulan+tanggal seperti 0000-something/, 0312-other-project/, 0419-hn-comment/
    Setiap tahun saya membuat folder tahun, dan kalau ingin menonjolkan proyek jangka panjang di bagian atas, saya menambahkan 0000 atau membiarkan tanggalnya sebagai 00 saja
    Sederhana dan berjalan di OS mana pun. Di Linux memang saya memakai sedikit skrip pembantu
    Ini juga memudahkan membuat direktori dengan cepat untuk memindahkan file dari folder Downloads, dan kalau nesting dipertahankan hanya satu tingkat, file mudah ditemukan. Menurut saya ini lebih baik daripada pola YYYY/MM/DD yang menambah satu tingkat lagi untuk bulan

    • Saya memakai pendekatan serupa saat mengatur folder terkait secara kronologis
      Di direktori teratas biasanya saya menaruh hal yang sedang dikerjakan sekarang. Konsepnya seperti “hari ini” atau “minggu ini”
      Saat mengarsipkan sesuatu yang sudah keluar dari jendela waktu itu, misalnya kalau hari ini, saya membuat folder dengan format seperti 041924, lalu memindahkan semua file yang dibuat hari itu ke dalamnya
      Menurut saya, untuk rentang hidup manusia biasanya tidak perlu memakai string seperti 2024. Rasanya saya tidak akan hidup sampai 2100, dan sebelum 2000 juga tidak relevan, jadi 24 sudah cukup
      Waktu terus berjalan, jadi jumlah folder arsip akan bertambah, tetapi ukurannya kecil dan mudah dicari. Ini terutama cocok jika setiap hari membuat file standar yang tidak terlalu unik
    • Tidak bisakah memakai tanggal modifikasi folder? Seharusnya bisa diurutkan
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • Saya juga sudah beralih ke pendekatan ini dengan menambahkan struktur folder yang sifatnya seperti “alur pemrosesan”. Data duplikat memang akan bertambah, tetapi ini menjaga kesehatan mental

  • Terkait backup, pernah saya mencoba memasang Mac baru dari backup Time Machine, tetapi Mac tidak bisa melihat apa pun di dalam backup Time Machine itu
    Setelah menghubungi dukungan Apple, saya diberi tahu bahwa ada bug langka yang kadang membuat proses instalasi menginisialisasi ulang backup Time Machine alih-alih memasang dari backup
    Untungnya saya sudah menyiapkan Backblaze, jadi selamat, tetapi memulihkan ratusan gigabyte memakan waktu sangat lama
    Sekarang saya memakai Time Machine, Backblaze, dan backup iCloud semuanya, dan sesekali mengemas semuanya sebagai .tgz lalu mengunggahnya ke S3

  • Untuk nama file dan direktori, antara tanda hubung dan garis bawah, saya sepenuhnya setuju dengan tanda hubung
    Saat berpindah di terminal, memakai tanda hubung sangat praktis sampai menurut saya seharusnya menjadi standar. Jauh lebih baik daripada harus mengetik tambahan setiap kali memilih nama file dengan garis bawah, atau menangani spasi

    • Ini salah satu hal kecil yang saya suka dari Lisp. Nama variabel bisa dibuat seperti foo-bar-baz, dan tidak perlu menekan Shift saat mengetiknya