Cevabınızın kısa versiyonu ve uzun versiyonu var ...
Kısa versiyon:
Bağlantınızın zaten söylediği gibi, sistem genelinde , salt okunur dosyalar /usriçin bir yer . Yani yüklü olan tüm yazılımlar oraya gider. Bu herhangi isimleri aynı olmayan haricinde ve farklı bir amaca hizmet, aslen, ama: sadece ikili ve kütüphaneler içindir önyükleme için gerekli iken , diğer tüm yürütülebilir ve kütüphaneler içindir. (şimdi iyi bir çocuk olun ve sormayın , bu sonuçta Kısa Versiyondur)//bin/lib/bin, /lib/usr/bin, /usr/lib/sbin
Günümüzde, Ubuntu da dahil olmak üzere çoğu modern dağıtım, birkaç dosya olmadan düzgün bir şekilde önyükleme yapamadığı için "önyükleme için gerekli" olan ve azalmayan arasındaki fark azalmadı /usr. Bu yüzden birleşme yönünde güçlü bir hareket var /usr/binve /binbu nedenle yakın bir gelecekte (belki de Ubuntu 12.10?) /binBir bağlantı olacaktır /usr/bin.
Ama belki kafa karıştırıyorsun /usrve /usr/local? Çünkü evet, birçok çoğaltılmış dizin adı vardır (ve olmalıdır) . Daha sonra ...
Uzun versiyon:
70'lerde, Unix'te (evet, Unix, Linux'tan çok önce), disketlerin çok az yeri vardı (HD yok, hatırladın mı?) Ve belirli bir noktada sistem ikilileri çok fazla büyüdüler ve değillerdi. tek bir diske sığacak ve geliştiriciler bunları birkaç medyaya bölmek zorunda kaldı ve böylece onlar için yeni montaj noktaları yarattı. /bindosya sistemi doluydu, bu yüzden ... 'da yeni ikili dosyaları kurdular /usr/bin. Ve /usro zaman, onların ... kullanıcı diziniydi!
(Neredeyse utanç verici ve sık sık şaka / irfan olarak söylendi) ayrılmasının gerçekleşmesinden sonra, neye gideceğine /binve neye gideceğine karar vermek için "yapay" gerekçeler (ve kriterler) yaratmaya başladılar /usr/bin. Gayri resmi kural şuydu: “temel” şeyler /bin, “geri kalanlar” ise gider /usr/bin. İle aynı /lib. /usrKullanıcı direkleri ile karıştırılmış sistem bağlantılı direklerle kalabalıklaşmak çok uzun sürmedi . Böylece /homekullanıcı ile ilgili tüm dir ve /usrsadece sistem "şeyler" için temiz tutmak için doğdu .
Bu, FHS'nin varlığından çok önceydi. Yaratıldığı zaman, mevcut geleneği benimsedi (ve resmileştirdi) ve ismini korudu /usr, ancak o zamanlar artık "kullanıcı" ile hiçbir ilgisi yoktu. Yani evet, fantezi isimler " u Nix ler aynak r epository" veya " u Nix ler istem r esources" Tüm uydurma isimler ve yine yeniden adlandırmak için çok geç. (ama birleştirmek /biniçin çok geç değil)
“Tamam, peki ya /usr/sbin?” , sen sor. Kahretsin, unuttuğunu umuyordum. Tamam ... /usr/sbinsadece olabilir komutlar için (veya yalnızca anlamlıdır) tarafından yürütülen rootgibi, kullanıcı mountve fdisk.
“Ama bu neredeyse aynı değil /binmi?” . Evet, elbette ama ...
“Bekle, o zaman neden bir /sbinde var? Hiç bir anlam ifade etmiyor!” . Şey, bunun nedeni ... hata ... humm ..
Bak, arkanda 3 başlı bir maymun!
Tamam, umarım yeterince dikkatin dağılmıştır. Hareketli...
(Hile yaptığımı düşünüyorsanız, evet, haklısınız. Ama "resmi" cevap "temel komutlar sadece root tarafından çalıştırılabilir ve hatta bağlamadan önce kullanılabilir olmalıdır /"). Gerçek şu ki: çizgi gerçekten bulanık ve sadece “sıkışmış” pek çok eski isim var ve şimdi kurtulmak oldukça zor.
Daha için Durumunda /usrbirleştirme gelen, systemddocs:
/ Usr / / sbin ve / lib 'in / usr' dan ayrı tarihsel gerekçesi artık geçerli değil. Araçları daha hızlı bir sabit diskte (küçüktü, çünkü daha pahalıydı) seçtiler ve daha yavaş / usr bölümünü monte etmek için gerekli tüm araçları içerdiler. Bugün, erken önyükleme sırasında initramfler tarafından zaten ayrı bir / usr bölmesi monte edilmeli ve böylelikle ayrılma güvesi için gerekçelendirilmelidir. Buna ek olarak, statükodaki / bin ve / sbin içindeki birçok araç, önceden monte edilmiş / usr olmadan çalışabilme özelliğini çoktan yitirdi. İşletim sisteminin birden fazla hiyerarşiye yayılması için artık geçerli bir neden yoktur, amacını kaybetmiştir.
Ve /usrRob Landley tarafından yapılan bölünme ve bunun mantığı ile ilgili şaşırtıcı bir okuma :
Bin, sbin, usr / bin, usr / sbin bölümlerini anlama
Şu günlerde
Şu anda, yükleme dizinleri ile ilgili olarak, anlamanın en iyi yolu şu şekilde düşünmektir:
/usr - işletim sistemi tarafından yüklenen (veya tarafından sağlanan) tüm sistem genelinde, salt okunur dosyalar
/usr/local- yerel yönetici tarafından yüklenen, sistem genelinde, salt okunur dosyalar (genellikle siz). İşte bu yüzden çoğu dizin ismi /usrburada çoğaltılıyor.
/opt- sistem genelinde, salt okunur ve kendi kendine yeten yazılım için yapılan bir vahşet . Yani üzerindeki dosyaları bölmek değil yazılım, bin, lib, share, includeyazılım gerekir uslu gibi.
~/.local- kullanıcı başına muadili /usr/local, yani: her kullanıcı tarafından yüklenen (ve için) yazılım
~/.local/opt - kullanıcı başına muadili /opt
Peki yazılımı nereye yükleyeceksiniz?
Yukarıdaki liste zaten Oracle JDK sorusunun cevabının yarısıdır, en azından birkaç ipucu verir. "X yazılımını nereye kurmalıyım?" Kontrol listesi gider:
Eclipse IDE ve diğer indirilmiş java uygulamaları gibi tamamen kendi kendine yeten, tek bir dizin yazılımı mı ve tüm kullanıcıların kullanımına açık olmasını mı istiyorsunuz? Sonra yükleyin/opt
Yukarıdakiyle aynı, ancak diğer kullanıcıları umursamıyorsunuz ve ben sadece kullanıcılarınız için kurmak istiyorum? Sonra yükleyin~/.local/opt
Dosyaları, derlenmiş ve yüklenmiş geleneksel yazılımlar gibi binve sharebenzerleri gibi birden fazla dizine bölünmüş ./configure && make && sudo make installve tüm kullanıcılar için erişilebilir olmalıdır? Sonra yükleyin/usr/local
Yukarıdakiyle aynı, ancak yalnızca kullanıcı için? Sonra yükleyin~/.local
OS tarafından yüklenen yazılım veya en önemlisi ve (Yazılım Merkezi gibi) paket yöneticileri aracılığıyla herhangi bir yerel değişiklik yeni bir sürüme ne zaman güncelleme yöneticisi yükseltmeleri bunun üzerine olabilir ? Gider/usr
Notlar:
Bu, derlenmiş yazılımlar için varsayılan yükleme önekinin /usr/localneden olduğunu ve ./configure --prefix=$HOME/.localyalnızca kendi kullanıcınıza yazılım yüklerken bunu neden değiştirmeniz gerektiğini açıklar.
Yukarıdaki tüm dizinlerin salt okunur olduğunu fark etmiş olabilirsiniz (elbette, yazılımı yüklediğinizde / kaldırdığınızda hariç). Yazılabilir dosyalar (config dosyaları gibi) genellikle /etc(sistem geneli yazılımlar için) ve ~/.config(kullanıcı başına ayarlar için ) gider . Birçok eski yazılım (ve ne yazık ki, bazıları da modern) kullansa da ~/.<software-name>, ana klasörünüzü milyarlarca dizin ve dosya ile karıştırın.
~/.localve ~/.configFHS spesifikasyonunun bir parçası değildir. FHS, kullanıcının ana klasörüyle ilgilenmez. Masaüstü Ortamlarına (Gnome, KDE ve Birlik gibi) yönelik bir başka standart organizasyon olan XDG'nin, kullanıcının evinin yapısına ilişkin bazı sözleşmeler koymaya çalışılması girişimidir. Tüm yazılımlar buna uymaz (örneğin, ~/.local/binkullanıcının varsayılan ayarlarında değildir $PATH, mantıkta olması gerektiği gibi) ve hiçbir kullanıcı bunu izlemeye zorlanmaz, ancak her ikisi de çalışırsa birçok birlikte çalışabilirlik avantajı elde eder.
Umarım bu işleri biraz netleştirmeye yardımcı olur. Bir şey sormaktan çekinmeyin, böylece cevabı geliştirebilirim!
(ve ayrıca umarız ki safhacılar böyle son derece gayriresmi bir dil ve açıklama için beni öldürmezler. Kasıtlıydı ve kesinlikle birçok yanlışlığı var, ancak yeni başlayanlar için kurulum hakkında kısa bir bakış açısına sahip olmanın iyi bir yol olduğuna inanıyorum. dizinler gerekçeleri)