Home dizini yapılandırması için ipuçları (2023)

 (unixdigest.com)
2 puan yazan GN⁺ 2024-04-21 | 1 yorum | WhatsApp'ta paylaş

Home dizini yapılandırma ipuçları

  • Dizinleri yapılandırmak veya düzenlemek, başka şeyleri yapılandırıp düzenlemekten çok farklı değildir; önemli olan bunu sizin için en mantıklı şekilde yapmaktır
  • Organizasyon söz konusu olduğunda işler çok hızlı şekilde kontrolden çıkabilir
  • Düzenlemenin asıl amacı verimliliktir; aradığınız şeyi kolayca ve hızlıca bulabilmeli, kaydetmeniz gereken şeyi de kolayca ve hızlıca kaydedebilmelisiniz

Gizli varsayılan dosyalar ve dizinler

  • Home dizinimde .config, .aliases, .profile, .gnupg, .mozilla gibi modern Unix işletim sisteminin parçası olan tüm varsayılan gizli dosyalar bulunuyor
  • Tüm uygulamaların XDG_CONFIG_HOME'a uymasını tercih ederim, ancak bu konuda aşırı müdahaleci davranmıyor veya fazla kafa yormuyorum
  • Geçmişte $HOME'u Git ile tuttum; bu, dotfiles yönetmek için harika bir yöntemdir
  • Değişiklik geçmişini korumak için hâlâ tüm dotfiles dosyalarını Git'e koyuyorum, ancak yalnızca kullandığım farklı sistemlerde aynı şekilde çalışan dotfiles dosyalarını olduğu gibi bırakıyorum
  • Ayara özel dotfiles dosyalarını dotfiles dizininde tutuyor ve sembolik bağlantılar kullanıyorum

Genel dosya ve dizin düzeni

  • Genel dosyalar ve dizinler ağırlıklı olarak iki şekilde düzenleniyor: "kategori" ve "tarih"
  • Temel dizin yapısı:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • Desktop ve Downloads dizinlerini olduğu gibi bırakıyorum (çünkü çoğu uygulama bunu dayatıyor gibi görünüyor)
  • bin dizininde kabuk betikleri ve kişisel ikili çalıştırılabilir dosyaları tutuyorum (paket yöneticisi üzerinden kurulanlar hariç)
  • mnt dizinini SD kartlar, USB diskler, homelab'de kullanılan paylaşımlı depolama gibi çeşitli bağlama noktaları için kullanıyorum
  • Asla otomatik bağlama yapmıyorum; bunun yerine bağlama için kabuk betikleri kullanıyorum
  • usr/dotfiles dizini, .aliases gibi genel dotfiles dosyalarıyla birlikte Git ile yönetiliyor ve dotfiles dizinindeki ilgili dosyalara sembolik bağlantılar kullanıyor

Veri dizini düzeni

  • data ve edata dizinleri, tüm materyalleri sakladığım iki ana dizindir
  • Bu iki dizin, kök kurulumdan ayrı olarak disk yansılama havuzunda çalışan ZFS veri kümeleridir
  • ZFS'den yararlanarak snapshot'ları ve ZFS gönderme/alma işlemlerini düzenli olarak kullanıp ağ depolamaya kolayca yedek alıyorum
  • data ile edata arasındaki fark, edata'nın ZFS yerleşik şifrelemeli bir veri kümesi olmasıdır
  • Şifreleme gizlilik için iyidir, ancak zaten karmaşık olan dosya sistemi katmanının üstüne eklenen korkunç bir karmaşıklık katmanıdır ve ZFS şifrelemesinde hatalar vardır
  • Önemli verileri her zaman birden fazla farklı depolama çözümüne ve konuma yedeklemenizi şiddetle tavsiye ederim
  • Bulut depolamayı önemli şeyler için kullanmıyorum

Ek ipuçları

  • Dosya ve dizin adlandırmayla ilgili temel kural, yalnızca adına bakarak onun ne olduğunu kolayca anlayabilmenizdir
  • Bir dosyanın neyle ilgili olduğunu onu açmadan anlayamıyorsanız, hemen açıp bir dahaki sefere dosya adını gördüğünüzde daha anlamlı olacak şekilde yeniden adlandırmalısınız
  • Dosya ve dizinleri düzenlemeden kendi hâline bırakırsanız, bunları daha sonra düzeltmek çok zor hale gelir
  • Dosyayı açmadan da içeriği anlayabilmek için gerektiğinde uzun açıklamalar içeren dosya adları kullanıyorum

GN⁺ görüşü

  • Bu yazı, dizin yapısını düzenleme ve organize etme konusunda pratik ipuçları sunuyor. Özellikle ZFS veri kümelerini kullanarak şifreli ve şifresiz dizinleri ayrı yönetme yaklaşımı ilgi çekici.

  • Kişisel olarak önemli verileri şifreleyerek saklamanın iyi olduğunu düşünüyorum. Ancak şifrelemenin performans düşüşü veya artan karmaşıklık gibi dezavantajları da olduğundan, duruma göre seçici biçimde kullanmak mantıklı görünüyor.

  • Ayrıca şifreli verilere erişim yöntemini aile üyeleriyle paylaşmak da önemli bir nokta gibi görünüyor. Kaza gibi durumlarda kişinin kendisi erişemese bile verilerin kaybolmaması gerekir.

  • Kişisel veri yönetimi için yazarın yaptığı gibi sistemli bir yedekleme stratejisi kurmak çok önemlidir. 3-2-1 yedekleme kuralını izlerken, bulut depolama yerine fiziksel olarak dağıtılmış yerel depolamayı kullanmak da iyi bir yöntem gibi görünüyor.

  • Kişisel veri düzeni için yararlı açık kaynak araçlar arasında Syncthing veya Nextcloud bulunuyor. Bu araçlar doğru kullanılırsa sistemli ve güvenli kişisel veri yönetimi mümkün olabilir.

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-21
Hacker News yorumları

  • Home dizininin dağınık olmasından nefret ediyorum; özellikle de uygulamalar home altında gizli bile olmayan dizinler oluşturması gerektiğini düşündüğünde bu gerçekten sinir bozucu
    En çok sinir bozan şey, Go modülleri için varsayılan dizin olan ~/go. Bundan o kadar nefret ettim ki yıllarca Go uygulaması kurmaktan ya da Go ile geliştirme yapmaktan kaçındım, ama sonunda kullanmak zorunda kaldım; GOPATH ayarıyla değiştirilebiliyor olsa da varsayılan olarak berbat

    • En kötüsü, Mac'te yapılmış CLI araçlarının XDG'yi yok sayması. Orada bu yaygın bir kavram değil, bu yüzden her araç .rustup, .mix, .npm, .yarn gibi kendine ait dizinlerle dotfile düzenini kirletiyor
      Yine de ~/go gibi home dizinini onu bile gizleme nezaketini göstermeden kirletmek gerçekten kabalık
    • GOPATH'ın başlı başına kötü bir tasarım olduğunu düşünüyorum. Diğer dillerde olduğu gibi proje başına bağımsız bir dizin yapısı olmak yerine, birbiriyle alakasız projelerin öğelerini aynı dizin yapısında karıştırmaya zorluyor
      Projelerimi düzenleme biçimimle o kadar ters düşüyor ki Go'ya ilgi duymamamın başlıca sebebi bu. Birbiriyle ilgisiz birçok projeyi tek bir monorepo içinde toplamayı sevenler için daha uygun olabilir ama benim zevkim bu değil
    • İpucu: Kendi dosyalarınızı $HOME içine koymayın. $HOME, uygulamaların kirlettiği yerdir; benim dosyalarım ise kelimenin tam anlamıyla başka herhangi bir yerde olabilir
    • Temiz bir home dizini fikrinden uzun zaman önce vazgeçtim. Önemli her şeyi home içindeki pCloud, Dropbox gibi senkronizasyon dizinlerinde tutuyorum ve onların içini kusursuz biçimde düzenliyorum
      .vimrc ve .gitconfig dosyalarını bir Git deposuna sembolik bağlantıyla bağladım. Böylece home dizininin geri kalanı tamamen çöp olsa da umurumda olmuyor ve makine bozulsa bile birkaç dakika içinde başka bir makinede geri dönebiliyorum
    • Keşke Unix en başından itibaren “uygulamaların istediği her şeyi koyduğu home dizini” ile “kullanıcının kendi dosyalarını koyduğu home dizini”ni standart olarak ayırmış olsaydı

  • Çoğu uygulamanın home dizinine dosya yağdırması sorununu azaltmada xdg-ninja yardımcı oldu
    Kısacası kurulu programları tarıyor ve XDG standardına uymaları için yapılandırılıp yapılandırılamayacaklarını söylüyor. Her şeyde işe yaramıyor ama birçok uygulamada böyle bir seçenek var
    https://github.com/b3nj5m1n/xdg-ninja

  • Sadece düzen değil, makineler arasında yalın biçimde yedeklemek ve taşımak da istiyorum
    .config klasörü, uygulamaların içine birkaç gigabaytlık oturum verisi doldurması yüzünden stratejik yedekleme yaparken büyük bir baş belası
    “Oturum verisi”, “ayar” değildir. Bir uygulamanın “ayarları” birkaç gigabayt olamaz

    • Bir programdan kalıcı ayar değişikliği istemediğiniz sürece, .config salt okunur olsa bile çalışabilmeli
    • Kesinlikle katılıyorum. Uygulamaların neden .config'i uygulama veri deposu gibi kullandığını anlamıyorum. Bunun için .local ve .cache var

  • Bu konu o kadar kişisel ki, yazarın çözümü benim için işe yaramaz; benim çözümüm de muhtemelen başkalarına pek yardımcı olmaz
    Benim home dizinim neredeyse boş. Çalışma dosyalarımın tamamı OwnCloud'da ve asıl soru, OwnCloud içindeki dizin yapısının ne olduğu. Yerel Git depolarını tamamen ayrı bir bölümde tutuyorum
    Artık KeepassXC SSH anahtarlarını da yönettiği için .ssh içindeki anahtarlar da OwnCloud'daki Keepass dosyasının içine taşındı. Her şey çok basitleşti ve artık home dizininde gerçekten ilgilenmeye değer neredeyse hiçbir şey kalmadı

    • Benim için önemli olan sadece sistem değiştirirken taşınabilirlik ve iş/kişisel ortam ayrımı
      Giriş yaptıktan sonra tek bir komutla, bulunduğum ortamın Linux mu, iş için mi, kişisel mi, masaüstü mü, sunucu mu olduğuna göre doğru dosya setini eşitleyebilmeliyim
      Örneğin home vault endpoint'i ya da belirli token'lar gibi ortam değişkenlerini iş sistemlerine asla aktarmak istemem
      Yakın zamanda NixOS projesinin home-manager aracına geçtim ve oldukça umut verici görünüyor. Nix dili karmaşık ama farklı ortamları tanımlamak için gereken soyutlamalar tam da buydu; ayrıca Git branch'leriyle iş/kişisel dosya içeriklerini ayırabiliyorum
    • Yine de .vimrc ile .bashrc/.zshrc home'da duruyor

  • Fikir iyi ama medyayı aile gibi bir yapıya göre bölme yöntemi hoşuma gitmiyor. Sonradan bir sürü yinelenen dosya ve düzenlenmiş kopya oluşuyor, kolayca karışıyorlar ve düzenlenmiş sürümü kaybetmek mümkün görünüyor
    Fotoğrafları EXIF anahtar kelimeleriyle düzenlemenin daha iyi olduğunu düşünüyorum. Metaveriyi fotoğrafın kendisinde, belki MIME türünün içinde tutup aileyle ilgiliyse #family ya da #personx gibi etiketler ekleyebilirsiniz. Böylece fotoğrafları tarih bazlı klasörlerde tutar, geri kalanını da Adobe Bridge gibi bir programla anahtar kelimeleri düzenleyerek yönetirsiniz
    Belge dosya adı yapısı olarak hem Date then Description.txt hem de Keyword Title or Description and then Date.txt kullandım. Tarih için sıralama amacıyla YYYY-MM-DD-hhmm biçiminde ISO tarih kullanıyorum; -hhmm isteğe bağlı
    Bazen konuya, yani anahtar kelimeye ya da başlığa göre sıralamak istersiniz ama günlük benzeri kayıtlarda ne zaman yazıldığının daha önemli olduğu durumlarda tarihi başa koymak daha iyidir
    Tarih sistemde de tutulduğu için gereksiz görünebilir ama dosyaları taşıdıkça tarih eninde sonunda değişir, hatta hata yaparsanız daha da kolay değişir. Buna karşılık dosya adının içindeki tarih değişmez ve liste sıralamasına da yardımcı olur

    • Medya başına içerik adreslemeli depo bu sorun için doğru yön gibi görünüyor. İdeal olarak, mevcut dizin yapısını ya da dosya düzenini değiştirmeden yalnızca ona başvuran bir overlay biçiminde olması iyi olur
      photoprism ve photostructure dizin yapısı ya da düzen konusunda çok takıntılı görünmüyor ama paperless (paperless-ngx gibi güncel türevleri dahil) düzen konusunda oldukça dayatmacı ve mevcut yapıya saygı göstermemesiyle kötü üne sahip
      Bir süre fotoğraflar için camlistore/perkeep kullandım ama Google Photos, tüm fotoğraflarda kimlerin olduğunu, hatta yaş farkını bile hesaba katarak belirleme konusunda ezici derecede iyi bir yeteneğe sahip. Aralarında 8 yaş fark olan iki oğlum benzer yaşlardayken gerçekten çok benziyorlardı ama sistem hangisinin kim olduğunu doğru biçimde ayırt ediyor. Yüz analizi mi kullanıyor, fotoğraf metaverisini mi kullanıyor bilmiyorum ama bir kez bile karıştırmadı. Yine de bu etiket bilgisini Google Photos dışına makul bir şekilde çıkarmanın bir yolu yok ve üstelik bunun için para ödüyor olsam bile durum böyle
      Sanırım tekrar bakmanın zamanı geldi. photostructure ya da photoprism yüz tanımayı deniyor mu hatırlamıyorum ama henüz yapmıyor olsalar bile yakında Google Photos düzeyine yaklaşacaklarını ya da en azından Google bağımlılığını bırakacak kadar iyi olacaklarını düşünüyorum
      Belgeler ve fotoğraf/video tamam da, müzik ne olacak? İyi ya da kötü, müzik koleksiyonumu dosya olarak doğrudan yönetmeyeli en az 10 yıl olmuştur. Bugünlerde paperless ya da photoprism gibi yalnızca “disk üzerindeki dosyalar” yaklaşımından daha derin biçimde içerikle bütünleşen bir müzik kütüphane sistemi var mı?
    • Rastgele dosya etiketlerini yönetmek için TagSpaces https://www.tagspaces.org/ ya da TMSU https://tmsu.org/ denenebilir. Yalnızca EXIF ya da ID3 dosyalarıyla sınırlı değiller

  • Benim yöntemim şöyle
    GUI ile ilgili öğeleri büyük harfle, CLI ile ilgili olanları küçük harfle tutuyorum. ~/documents tarafını tercih ederim ama GUI tarafındaki insanlar büyük harfte ısrar ediyor, ben de kabulleniyorum. İkisini karıştırmak zorunda kaldığım durum çok az olduğu için büyük bir sorun olmuyor
    ~/dotfiles, Git ile yönettiğim nokta dosyaları dizinim. ~/.zshrc -> dotfiles/zshrc gibi sembolik bağlantılar oluşturuyorum. Ayrı bir yönetim yazılımı kullanmıyorum, sadece bağlantı kuruyorum. Eskiden ~/.dotfiles kullanıyordum ama görünür bırakmanın daha mantıklı olduğunu düşünüyorum
    ~/projects proje dizinim. ~/projects/test doğrulama amaçlı tek seferlik test projeleri için, ~/projects/my kişisel projelerim için, ~/projects/company ise şu anda çalıştığım şirketin projeleri için. Bazen serbest çalışana benzer şekilde birden fazla şirketle çalıştığım için bu ayrım gerekli oluyor
    ~/tmp, tüm tek seferlik işler için kullandığım dizin. mkcdtmp adlı bir shell fonksiyonum var; ~/tmp/240419 gibi bugünün tarihine sahip bir dizin oluşturup içine geçiyor. Gerçekten çok iyi bir yöntem. Büyük bir disk alıp çöpleri bir ölçüde düzenli bırakmayı tercih ettiğim için neredeyse hiç temizlik yapmıyorum. Dünden ya da geçen aydan bir şeye ihtiyaç duyarsam nerede olduğunu biliyorum ve geçici işleri toparlamada bana en çok yardımcı olan şey bu oldu. Gerekirse ~/tmp/whatever da oluşturabiliyorum, nasıl olsa hepsi atılacak şeyler
    ~/Desktop kullanmıyorum. ~/Documents da neredeyse hiç kullanmıyorum ve onu nasıl düzenleyeceğimi hâlâ bulmam gerek. Kısa notlar gibi şeyleri kişisel web sitemi derlediğim GitHub deposuna atıyorum. Birçok not uygulamasını denedim ama Markdown ile yazılmış sıradan bir web sitesi bana en iyi uyan çözüm oldu
    İşleri çok yapısal biçimde düzenlemeyi hiç başaramadım. Etrafta hep çöp yığınları dolaşıp sonunda işe yarar bir şeye dönüştüğü için, kendimle savaşmak yerine o çöpleri düzenli çöplere dönüştürmeye karar verdim
    Esasen bilgisayarım sarf malzemesi gibi. ~/projects içindeki her şey Git’te, ~/tmp ise önemsiz cache’ler ya da atılacak işler gibi. Temiz bir durumdan geri yüklemenin uzun sürmemesi için buna göre düzenlemeye çalışıyorum. İşletim sistemini sık sık baştan kuruyor, işletim sistemiyle dizüstü bilgisayarımı da sık değiştiriyorum; bu yöntem bana en iyi bu yüzden uyuyor

    • Herhangi bir şeyi büyük harfle yazmaktan gerçekten nefret ediyorum. Sadece bir tuşa daha basmak olduğunu biliyorum ama inanılmaz derecede sinir bozucu

  • Dosya sisteminde beni en çok rahatsız eden şeylerden biri, çok fazla dizinin D harfiyle başlaması
    Desktop, Dev, Downloads, Documents, Dropbox, vb.
    Bir şeyleri değiştirmeyi düşündüm ama yazarın dediği gibi birçok uygulama bu konuda oldukça inatçı

    • Bu sorundan kaçınmak için /src kullanıyorum

  • Oldukça basit ama bana çok uyan bir yapı kullanıyorum
    projects/ altında 2023/, 2024/ gibi yıl klasörleri oluşturuyorum ve her projeye 0000-something/, 0312-other-project/, 0419-hn-comment/ gibi ay+gün öneki veriyorum
    Her yıl o yılın klasörünü oluşturuyorum; uzun soluklu projeleri üste çıkarmak istediğimde başına 0000 koyuyor ya da tarihte sadece 00 kullanıyorum
    Basit ve her OS'te çalışıyor. Linux'ta biraz yardımcı script kullanıyorum
    İndirilenler klasöründen dosya taşıyacağım dizini hızlıca oluşturmak da kolay oluyor ve iç içe yapıyı tek seviyede tutunca bulması kolay oluyor. YYYY/MM/DD düzenindeki gibi bir ay seviyesi daha ekleyen yöntemden daha iyi olduğunu düşünüyorum

    • İlgili klasörleri kronolojik sıraya koyarken benzer bir yöntem kullanıyorum
      En üst dizinde genelde şu anda üzerinde çalıştığım şeyler duruyor. Bir nevi “bugün” ya da “bu hafta” kavramı
      O zaman penceresinin dışına arşivlerken, örneğin bugün için 041924 gibi bir klasör oluşturup o gün oluşturduğum tüm dosyaları onun içine taşıyorum
      İnsan ömrü açısından bakınca genelde 2024 gibi bir dize kullanmaya gerek olmadığını düşünüyorum. 2100'e kadar yaşayacağımı sanmıyorum, 2000'den öncesi de zaten ilgili değil; o yüzden 24 yeterli
      Zaman akmaya devam ettiği için arşiv klasörlerinin sayısı artıyor ama küçük ve bulunması kolay kalıyorlar. Özellikle her gün çok da ayırt edici olmayan standart dosyalar üretiyorsanız çok iyi uyuyor
    • Klasörlerin değiştirilme tarihi kullanılamaz mı? Sıralama yapılabilirdi
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • Ben de bu yönteme daha çok “işleme süreci” niteliğinde bir klasör yapısı eklenmiş hâline geçtim. Yinelenen veri artıyor ama akıl sağlığını koruyor

  • Yedekleme konusunda, yeni bir Mac'i Time Machine yedeğinden kurmaya çalıştım ama Mac, Time Machine yedeğinin içindeki hiçbir şeyi göremedi
    Apple destekle görüştüğümde, kurulum sürecinin bazen yedekten kurmak yerine Time Machine yedeğini sıfırladığı nadir bir bug olduğunu söylediler
    Neyse ki Backblaze kurulu olduğu için kurtuldum ama yüzlerce gigabaytı geri yüklemek çok uzun sürdü
    Şimdi Time Machine, Backblaze ve iCloud yedeklerinin hepsini kullanıyorum; ara sıra her şeyi .tgz olarak paketleyip S3'e yüklüyorum

  • Dosya ve dizin adlarında tire ile alt çizgi arasında tireyi tamamen destekliyorum
    Terminalde gezinirken tire kullanmak o kadar pratik ki standart olması gerektiğini düşünüyorum. Alt çizgili dosya adını seçmek için her seferinde ekstra giriş yapmak ya da boşluklarla uğraşmak zorunda kalmaktan çok daha iyi

    • Lisp'te sevdiğim küçük şeylerden biri de bu. Değişken adlarını foo-bar-baz gibi verebiliyorsunuz ve yazarken Shift'e basmak gerekmiyor