होम डायरेक्टरी को संरचित करने के टिप्स (2023)

 (unixdigest.com)
2 पॉइंट द्वारा GN⁺ 2024-04-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें

होम डायरेक्टरी संरचना के टिप्स

  • डायरेक्टरी को संरचित या व्यवस्थित करना, बाकी चीज़ों को संरचित या व्यवस्थित करने से बहुत अलग नहीं है; मुख्य बात यह है कि इसे उस तरीके से किया जाए जो आपको सबसे अधिक तार्किक लगे
  • संगठन को संभालते समय चीज़ें बहुत जल्दी नियंत्रण से बाहर हो सकती हैं
  • व्यवस्थित करने का मुख्य उद्देश्य दक्षता है; आप जो ढूंढना चाहते हैं उसे आसानी और तेजी से ढूंढ सकें, और जिसे सहेजना है उसे भी आसानी और तेजी से सहेज सकें

छिपी हुई डिफ़ॉल्ट फ़ाइलें और डायरेक्टरी

  • मेरी होम डायरेक्टरी में .config, .aliases, .profile, .gnupg, .mozilla आदि जैसे आधुनिक Unix operating system का हिस्सा बनने वाली सभी डिफ़ॉल्ट hidden files मौजूद हैं
  • मैं चाहता हूँ कि सभी applications XDG_CONFIG_HOME का सम्मान करें, लेकिन मैं इस बात को लेकर ज़्यादा दखल या चिंता नहीं करता
  • पहले मैं Git के साथ $HOME को बनाए रखता था, और यह Dotfiles को व्यवस्थित करने का एक शानदार तरीका है
  • बदलावों का इतिहास बनाए रखने के लिए मैं अब भी सभी Dotfiles को Git में रखता हूँ, लेकिन केवल वही Dotfiles जस का तस रखता हूँ जो मेरे द्वारा उपयोग किए जाने वाले विभिन्न systems पर एक जैसे काम करते हैं
  • प्रति-configuration Dotfiles को dotfiles डायरेक्टरी में रखा जाता है और symbolic links का उपयोग किया जाता है

सामान्य फ़ाइल और डायरेक्टरी संगठन

  • सामान्य फ़ाइलें और डायरेक्टरी मुख्य रूप से दो तरीकों से व्यवस्थित की जाती हैं: "category" और "date"
  • मूल डायरेक्टरी संरचना:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • Desktop और Downloads डायरेक्टरी को वैसे ही छोड़ देता हूँ (क्योंकि ज़्यादातर applications मानो यही मजबूर करती हैं)
  • bin डायरेक्टरी में shell scripts और personal binary executables रखता हूँ (package manager के जरिए install किए गए फ़ाइलों को छोड़कर)
  • mnt डायरेक्टरी का उपयोग SD card, USB disk, homelab में उपयोग होने वाले shared storage आदि जैसे विभिन्न mount points के लिए करता हूँ
  • मैं कभी auto-mount नहीं करता, और mounting के लिए shell scripts का उपयोग करता हूँ
  • usr/dotfiles डायरेक्टरी को .aliases जैसे सामान्य Dotfiles के साथ Git द्वारा प्रबंधित किया जाता है, और dotfiles डायरेक्टरी में संबंधित फ़ाइलों के लिए symbolic links का उपयोग किया जाता है

डेटा डायरेक्टरी संगठन

  • data और edata दो मुख्य डायरेक्टरी हैं जिनमें सारी सामग्री रखी जाती है
  • ये दोनों डायरेक्टरी root installation से अलग, disk mirroring pool पर चलने वाले ZFS datasets हैं
  • ZFS का उपयोग करके snapshots के साथ-साथ ZFS send और receive का नियमित रूप से उपयोग किया जाता है ताकि network storage पर आसानी से backup लिया जा सके
  • data और edata के बीच अंतर यह है कि edata एक ZFS native encryption dataset है
  • encryption privacy के लिए अच्छा है, लेकिन यह पहले से ही जटिल file system hierarchy के ऊपर एक डरावनी जटिलता की परत जोड़ देता है, और ZFS encryption में bugs भी हैं
  • दृढ़ता से सिफारिश की जाती है कि महत्वपूर्ण data का backup हमेशा कई अलग-अलग storage solutions और locations में रखा जाए
  • महत्वपूर्ण चीज़ों के लिए cloud storage का उपयोग नहीं करता

अतिरिक्त टिप्स

  • फ़ाइल और डायरेक्टरी naming का मूल नियम यह है कि केवल नाम देखकर आसानी से समझ आ जाना चाहिए कि वह क्या है
  • अगर बिना फ़ाइल खोले यह पता नहीं चलता कि फ़ाइल किस बारे में है, तो उसे तुरंत खोलकर देखना चाहिए और अगली बार उसका नाम दिखने पर उसे अधिक अर्थपूर्ण नाम में बदल देना चाहिए
  • यदि फ़ाइलों और डायरेक्टरी को व्यवस्थित किए बिना छोड़ दिया जाए, तो बाद में उन्हें ठीक करना बहुत मुश्किल हो जाता है
  • जब भी ज़रूरत हो, ऐसे लंबे और वर्णनात्मक फ़ाइल नामों का उपयोग करता हूँ ताकि फ़ाइल खोले बिना भी उसकी सामग्री समझी जा सके

GN⁺ की राय

  • यह लेख डायरेक्टरी संरचना को व्यवस्थित और संगठित करने के तरीकों पर व्यावहारिक टिप्स देता है। खासकर ZFS datasets का उपयोग करके encrypted और unencrypted डायरेक्टरी को अलग-अलग प्रबंधित करने का तरीका दिलचस्प है.

  • व्यक्तिगत रूप से मेरा मानना है कि महत्वपूर्ण data को encrypt करके रखना अच्छा है। लेकिन encryption के कारण performance में गिरावट या complexity बढ़ने जैसी कमियाँ भी हैं, इसलिए स्थिति के अनुसार इसे चुनिंदा रूप से इस्तेमाल करना बेहतर लगता है.

  • साथ ही, encrypted data तक पहुँचने का तरीका परिवार के लोगों के साथ साझा करके रखना भी एक महत्वपूर्ण बिंदु है। ताकि दुर्घटना आदि की स्थिति में यदि आप स्वयं access न कर सकें, तब भी data खो न जाए.

  • व्यक्तिगत data management के लिए लेखक की तरह एक व्यवस्थित backup strategy बनाना बहुत महत्वपूर्ण है। 321 backup rule का पालन करते हुए cloud storage की बजाय भौतिक रूप से वितरित local storage का उपयोग करना भी अच्छा तरीका लगता है.

  • व्यक्तिगत data को व्यवस्थित करने के लिए उपयोगी open source tools में Syncthing या Nextcloud जैसे विकल्प शामिल हैं। इन tools का सही उपयोग किया जाए तो सुव्यवस्थित और सुरक्षित personal data management संभव हो सकता है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-21
Hacker News की राय

  • मुझे home directory का बिखर जाना पसंद नहीं है, और खासकर तब बहुत झुंझलाहट होती है जब कोई app मानता है कि उसे home में hidden भी नहीं, ऐसी directory बनानी ही चाहिए
    सबसे ज्यादा गुस्सा Go modules की default directory ~/go पर आता है। इतनी नापसंद थी कि कई साल तक Go apps install करने या Go development से बचता रहा, लेकिन आखिरकार इस्तेमाल करना पड़ा। GOPATH setting से इसे बदला जा सकता है, फिर भी default के तौर पर यह बहुत खराब है

    • सबसे बुरा तब होता है जब Mac पर बने CLI tools XDG को ignore करते हैं। वहाँ यह आम concept नहीं है, इसलिए हर tool .rustup, .mix, .npm, .yarn जैसी अपनी-अपनी directories बनाकर dotfiles को गंदा कर देता है
      फिर भी ~/go की तरह home directory को hidden रखने की शिष्टता तक न दिखाते हुए प्रदूषित करना वाकई बदतमीजी है
    • मुझे लगता है GOPATH अपने-आप में खराब design है। दूसरी languages की तरह हर project के लिए independent directory structure रखने के बजाय, यह आपस में unrelated projects की चीजों को एक ही directory structure में मिला देता है
      यह मेरे projects organize करने के तरीके से इतना उलटा है कि Go में रुचि न लेने का यह मुख्य कारण रहा। जिन्हें कई unrelated projects को एक monorepo में साथ रखना पसंद है, उनके लिए यह ज्यादा ठीक हो सकता है, लेकिन मेरी पसंद नहीं है
    • टिप: अपनी files $HOME में न रखें। $HOME वह जगह है जिसे apps गंदा करती हैं, और अपनी files सचमुच कहीं भी और रखी जा सकती हैं
    • साफ-सुथरी home directory का विचार मैंने बहुत पहले छोड़ दिया। जरूरी चीजें home के अंदर pCloud, Dropbox जैसी sync directories में रखता हूँ, और उनके अंदर सब कुछ पूरी तरह organized रहता है
      .vimrc और .gitconfig को Git repository से symbolic link कर रखा है। इससे home directory का बाकी हिस्सा पूरी तरह कचरा भी हो तो फर्क नहीं पड़ता, और machine मर भी जाए तो दूसरी machine पर कुछ ही मिनटों में restore हो सकता है
    • अच्छा होता अगर Unix शुरू से ही “apps अपनी मनचाही चीजें यहाँ डालें वाली home directory” और “users अपनी files रखने वाली home directory” को standard के रूप में अलग करता

  • ज्यादातर apps द्वारा home directory में files उड़ेल देने की समस्या कम करने में xdg-ninja मददगार रहा
    संक्षेप में, यह installed programs को scan करके बताता है कि उन्हें XDG standard follow करने के लिए configure किया जा सकता है या नहीं। यह हर चीज पर काम नहीं करता, लेकिन कई apps में ऐसे options होते हैं
    https://github.com/b3nj5m1n/xdg-ninja

  • सिर्फ organization नहीं, मैं machines के बीच सरलता से backup और portability भी चाहता हूँ
    .config folder strategic backup के समय बड़ा सिरदर्द है, क्योंकि apps उसमें कई gigabytes का session data डाल देती हैं
    “session data” “settings” नहीं है। किसी app की “settings” कई gigabytes की हो ही नहीं सकतीं

    • जब तक program से permanent settings change करने को न कहा जाए, .config को read-only होने पर भी काम करना चाहिए
    • बिल्कुल सहमत। समझ नहीं आता apps .config को app data store की तरह क्यों इस्तेमाल करती हैं। ऐसे काम के लिए .local और .cache हैं

  • यह मामला इतना व्यक्तिगत है कि लेखक का समाधान मेरे लिए बेकार है, और मेरा समाधान भी शायद दूसरों के लिए ज्यादा मददगार नहीं होगा
    मेरी home directory लगभग खाली है। सारी work files OwnCloud में हैं, और असली सवाल यह है कि OwnCloud के अंदर directory structure कैसा है। Local Git repositories पूरी तरह अलग partition पर रखता हूँ
    अब KeepassXC SSH keys संभालता है, इसलिए .ssh की keys भी OwnCloud में मौजूद Keepass file के अंदर चली गई हैं। सब बहुत सरल हो गया है, और अब home directory में सचमुच ध्यान देने लायक लगभग कुछ नहीं है

    • system बदलते समय portability और work/personal environments का अलगाव ही महत्वपूर्ण है
      login करने के बाद एक command से इस हिसाब से सही file set sync हो जाना चाहिए कि मौजूदा environment Linux है या नहीं, work का है या personal, desktop है या server
      उदाहरण के लिए home vault endpoint या कुछ खास tokens जैसे environment variables को मैं work system पर कभी export नहीं करना चाहता
      हाल ही में NixOS project के home-manager पर shift किया है, और यह काफी promising लगता है। Nix language जटिल है, लेकिन अलग-अलग environments define करने के लिए जो abstraction चाहिए था, वह ठीक यही है, और Git branches से work/personal files की सामग्री अलग रखी जा सकती है
    • फिर भी .vimrc और .bashrc/.zshrc home में ही रखता हूँ

  • आइडिया ठीक है, लेकिन मीडिया को परिवार जैसी संरचना में बांटने का तरीका पसंद नहीं आया। बाद में duplicate files और edited duplicates ढेरों बनते दिखते हैं, जो आसानी से मिल-जुल सकते हैं और आप edited version खो सकते हैं
    मेरे हिसाब से photos को EXIF keywords से organize करना बेहतर है। metadata को photo में ही, शायद MIME type के अंदर, store करें और अगर family-related है तो #family या #personx जैसे tags लगा दें। इसलिए photos को date-wise जैसे folders में रखें और बाकी keywords Adobe Bridge जैसे program से edit करें
    document filenames के लिए मैंने Date then Description.txt और Keyword Title or Description and then Date.txt दोनों structures इस्तेमाल किए हैं। sorting के लिए date में YYYY-MM-DD-hhmm format वाली ISO date इस्तेमाल करता हूँ, और -hhmm optional है
    कभी-कभी subject, यानी keyword या title के आधार पर sort करना चाहता हूँ, लेकिन logs जैसी चीज़ों में कब record किया गया यह ज़्यादा important होता है, तब date को आगे रखना बेहतर है
    date system में भी store होती है, इसलिए यह unnecessary लग सकता है, लेकिन files move करते-करते date आखिर बदल ही जाती है, और गलती हो तो और आसानी से बदल जाती है। जबकि filename में date नहीं बदलती और list sorting में भी मदद करती है

    • media-wise content-addressed storage इस problem के लिए सही दिशा लगती है। Ideally यह existing directory structure या file organization को बदले बिना सिर्फ references करने वाला overlay हो तो अच्छा होगा
      photoprism और photostructure directory structure या organization की बहुत परवाह नहीं करते लगते, लेकिन paperless(-ngx जैसे newer variants) organization को लेकर काफी rigid होने और existing structure का सम्मान न करने के लिए बदनाम है
      कुछ समय तक मैंने photos के लिए camlistore/perkeep इस्तेमाल किया, लेकिन Google Photos में हर photo में कौन है, उम्र के अंतर तक को ध्यान में रखकर पहचान लेने की जबरदस्त capability है। मेरे दो बेटे, जिनमें 8 साल का gap है, similar age range में सचमुच बहुत मिलते-जुलते दिखते हैं, फिर भी यह सही-सही पहचान लेता है कि कौन कौन है। यह face analysis इस्तेमाल करता है या photo metadata, पता नहीं, लेकिन इसने कभी confuse नहीं किया। बस उन tag information को Google Photos के बाहर reasonable तरीके से निकालने का कोई तरीका नहीं है, जबकि मैं पैसे भी दे रहा हूँ
      लगता है अब फिर से देखना चाहिए। याद नहीं कि photostructure या photoprism face recognition की कोशिश करते हैं या नहीं, लेकिन अगर अभी नहीं भी करते, तो भी जल्द Google Photos के level के करीब पहुँच जाएंगे, या कम-से-कम Google dependency छोड़ने लायक अच्छे हो जाएंगे
      documents और photos/videos तो ठीक, लेकिन music का क्या? अच्छा हो या बुरा, music collection को files के रूप में सीधे manage किए मुझे कम-से-कम 10 साल हो गए। आजकल music के लिए ऐसा library system है क्या जो paperless या photoprism की तरह simple “files on disk” से ज़्यादा content के साथ deeply integrated हो?
    • arbitrary file tags manage करने हों तो TagSpaces https://www.tagspaces.org/ या TMSU https://tmsu.org/ आज़माने लायक हैं। यह सिर्फ EXIF या ID3 files तक सीमित नहीं है

  • मेरा तरीका यह है
    GUI-related items uppercase में, CLI-related items lowercase में रखता हूँ। ~/documents जैसी चीज़ों को prefer करता हूँ, लेकिन GUI वाले लोग uppercase पर अड़े रहते हैं, इसलिए मान लेता हूँ। दोनों को mix करने की ज़रूरत बहुत कम पड़ती है, इसलिए बड़ा issue नहीं है
    ~/dotfiles Git से manage की गई dotfiles directory है। ~/.zshrc -> dotfiles/zshrc की तरह symbolic links बनाता हूँ। कोई separate management software नहीं इस्तेमाल करता, बस links बनाता हूँ। पहले ~/.dotfiles इस्तेमाल करता था, लेकिन visible रखना ज़्यादा logical लगता है
    ~/projects projects directory है। ~/projects/test quick check के लिए one-off test project, ~/projects/my personal projects, और ~/projects/company current employer के projects हैं। freelancer जैसा होकर कई companies के साथ काम करने के मौके आते हैं, इसलिए separation ज़रूरी है
    ~/tmp सभी one-off work के लिए directory है। mkcdtmp नाम का shell function रखा है, जो ~/tmp/240419 जैसा current date directory बनाता है और उसमें चला जाता है। यह सच में बहुत अच्छा तरीका है। बड़ी disk खरीदकर कचरे को कुछ हद तक organized छोड़े रखना prefer करता हूँ, इसलिए शायद ही कभी clean करता हूँ। अगर कल या पिछले महीने की कोई चीज़ चाहिए, तो पता होता है कहाँ है, और temporary work organize करने में यह सबसे मददगार चीज़ रही है। ज़रूरत हो तो ~/tmp/whatever भी बना सकता हूँ, और वैसे भी यह सब फेंकने लायक सामान है
    ~/Desktop इस्तेमाल नहीं करता। ~/Documents भी लगभग इस्तेमाल नहीं करता और अभी organize करने का तरीका ढूँढना है। short notes जैसी चीज़ें अपने personal website build करने वाले GitHub repository में डाल देता हूँ। कई notes apps try किए, लेकिन Markdown वाली plain website मेरे लिए सबसे अच्छा काम करती है
    काम को बहुत structured तरीके से organize करने में कभी सफल नहीं हुआ। हमेशा कचरे के ढेर इधर-उधर घूमते रहते हैं और आखिरकार कोई काम की चीज़ बन जाते हैं, इसलिए खुद से लड़ने के बजाय मैंने उस कचरे को organized कचरा बनाने का फैसला किया
    मूल रूप से मेरा computer consumable है। ~/projects की हर चीज़ Git में है, और ~/tmp खास important नहीं, cache या discarded work जैसा है। मैं इसे ऐसे organize करने की कोशिश करता हूँ कि clean state से restore करने में ज्यादा समय न लगे। मैं OS को शुरू से अक्सर reinstall करता हूँ और operating system तथा laptop भी अक्सर बदलता हूँ, और यह तरीका मेरे लिए सबसे अच्छा fit बैठता है

    • मुझे किसी भी चीज़ को uppercase में लिखना सचमुच नापसंद है। पता है यह बस एक extra key press है, लेकिन बेहद झंझट लगता है

  • file system में मेरी बड़ी complaints में से एक यह है कि बहुत सारी directories D से शुरू होती हैं
    Desktop, Dev, Downloads, Documents, Dropbox वगैरह
    कुछ बदलने का सोचा था, लेकिन author के कहे अनुसार कई applications इस मामले में काफी stubborn हैं

    • इस problem से बचने के लिए /src इस्तेमाल करता हूँ

  • मैं एक काफ़ी सरल, लेकिन मेरे लिए अच्छी तरह काम करने वाला स्ट्रक्चर इस्तेमाल करता/करती हूं
    projects/ के अंदर 2023/, 2024/ जैसे साल वाले फ़ोल्डर बनाता/बनाती हूं, और हर प्रोजेक्ट के आगे महीने+दिन का prefix लगाता/लगाती हूं, जैसे 0000-something/, 0312-other-project/, 0419-hn-comment/
    हर साल साल वाला फ़ोल्डर बनाता/बनाती हूं, और जब किसी लंबे चलने वाले प्रोजेक्ट को ऊपर दिखाना हो तो 0000 लगा देता/देती हूं या तारीख़ में दिन को सिर्फ़ 00 रखता/रखती हूं
    यह सरल है और किसी भी OS पर चलता है. Linux पर मैं थोड़ी-बहुत helper scripts ज़रूर इस्तेमाल करता/करती हूं
    Downloads फ़ोल्डर से फ़ाइलें हटाने के लिए directory जल्दी बनाना भी आसान है, और nesting को सिर्फ़ एक level तक रखने पर चीज़ें ढूंढना आसान रहता है. मुझे यह YYYY/MM/DD pattern जैसे तरीके से बेहतर लगता है, जिसमें month का एक अतिरिक्त level जुड़ जाता है

    • संबंधित फ़ोल्डरों को chronological order में व्यवस्थित करते समय मैं मिलता-जुलता तरीका इस्तेमाल करता/करती हूं
      top-level directory में आम तौर पर वही रखता/रखती हूं जिस पर अभी काम चल रहा है. यह “आज” या “इस हफ़्ते” जैसी अवधारणा है
      उस time window से बाहर निकलकर archive करते समय, उदाहरण के लिए अगर आज है तो 041924 जैसे format का फ़ोल्डर बनाता/बनाती हूं और उस दिन बनी सारी फ़ाइलें उसमें डाल देता/देती हूं
      आम तौर पर इंसानी उम्र के हिसाब से 2024 जैसी string लिखने की ज़रूरत नहीं लगती. 2100 तक जीने वाला/वाली तो लगता नहीं, और 2000 से पहले की चीज़ें relevant नहीं हैं, इसलिए 24 काफ़ी है
      समय चलता रहता है, इसलिए archive फ़ोल्डरों की संख्या बढ़ती है, लेकिन वे छोटे होते हैं और ढूंढने में आसान. अगर आप रोज़ बहुत ज़्यादा unique न होने वाली standard files बनाते हैं, तो यह खास तौर पर अच्छा बैठता है
    • फ़ोल्डर की modified date इस्तेमाल नहीं कर सकते? sort तो किया जा सकेगा
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • मैं भी इसी तरीके में “process” प्रकृति वाला folder structure जोड़ने की दिशा में आ गया/गई हूं. duplicate data तो बढ़ेगा, लेकिन mental health बची रहती है

  • backup के बारे में, एक बार मैंने Time Machine backup से नया Mac install करने की कोशिश की, लेकिन Mac को Time Machine backup के अंदर कुछ भी नहीं दिखा
    Apple Support से संपर्क किया तो पता चला कि install process में कभी-कभी एक rare bug होता है जो backup से install करने के बजाय Time Machine backup को initialize कर देता है
    सौभाग्य से Backblaze set up किया हुआ था, इसलिए बच गया/गई, लेकिन सैकड़ों gigabytes restore करने में बहुत लंबा समय लगा
    अब मैं Time Machine, Backblaze और iCloud backup तीनों इस्तेमाल करता/करती हूं, और कभी-कभी सबको .tgz में bundle करके S3 पर upload कर देता/देती हूं

  • filenames और directory names में hyphen और underscore के बीच मैं hyphen से पूरी तरह सहमत हूं
    terminal में navigate करते समय hyphen इस्तेमाल करना इतना practical है कि मुझे लगता है इसे standard होना चाहिए. underscore वाले filename को select करने के लिए हर बार extra input करने या spaces handle करने से यह कहीं बेहतर है

    • Lisp में मुझे पसंद आने वाली छोटी-सी बात यही है. variable names foo-bar-baz जैसे रख सकते हैं, और type करते समय Shift दबाने की ज़रूरत नहीं पड़ती