'/ usr' dizininin mantığı nedir?

88

"unix sistem kaynaklarının" veya /usr dizininin, burada açıklandığı gibi, çoğunu çoğaltan mantığı nedir? kök dizini altındaki dizin adlarının / ?

Amacım: Oracle JDK'yı onüçüncü saat için yüklüyorum ve bu sefer /home/user 'in altına koymaya karar verdim ve sadece tek bir kullanıcı makinesinde kötü bir fikir olup olmadığını görmek için biraz okuyorum. .

    
sordu H2ONaCl 02.05.2012 18:46

1 cevap

135

Kısa versiyonunuz ve cevabınızın uzun versiyonu ...

Kısa versiyon:

Bağlantınız önceden belirtildiği gibi, /usr sistem çapında , salt okunur dosyaları için bir yer. Böylece tüm yüklü yazılımlarınız oraya gider. % Co_de% ve / hariç, ancak orijinal olarak, farklı bir amaçla /bin adının çoğunu çoğaltmaz: /lib , önyükleme sırasında için için gerekli olan ikili dosyalar ve kütüphaneler içindir. co_de% diğer tüm yürütülebilir dosyalar ve kütüphaneler içindir. (şimdi iyi bir çocuk ol ve /bin, /lib hakkında bir şey sorma, bu her şeyden önce Kısa Versiyon)

Günümüzde, Ubuntu da dahil olmak üzere çoğu modern dağıtımın /usr/bin, /usr/lib 'sinden birkaç dosya olmadan düzgün bir şekilde önyükleme yapamaması nedeniyle "önyükleme için gerekli" arasındaki ayrım azalmıştır. Bu nedenle, /sbin ve /usr 'sini birleştirme yönünde güçlü bir hareket var, bu yüzden muhtemelen yakın gelecekte (Ubuntu 12.10 belki?)% Co_de% /usr/bin ' sine bir link olacaktır.

Ancak, /bin ve /bin 'sini karıştırıyor musunuz? Çünkü evet, çoğaltılan dizin adlarının bir lotu var (ve olmalıdır). Daha fazlası için ...

Uzun versiyon:

70'lerde, Unix'te (evet, Unix, Linux'tan önce), disketler çok az yer kapladılar (HD yok, hatırlıyor musun?), ve belirli bir noktada sistem ikili sayıları bir sayıya ve büyüklükte çok fazla büyüdü Tek bir diske sığmazlardı ve geliştiriciler onları birkaç medyaya bölmek zorunda kaldılar ve bu yüzden onlar için yeni bağlama noktaları yarattılar. /usr/bin dosya sistemi doluydu, bu yüzden yeni ikili dosyaları% ...% co_de. Ve /usr , o anda ... kullanıcı dizini!

(neredeyse utanç verici ve sık sık bir şaka / lore olarak anlatılır) bölünme gerçekleştikten sonra, /usr/local 'ye ne gideceğine ve /bin ' ye ne gideceğine karar vermek için "yapay" gerekçeler (ve ölçütler) oluşturmaya başladılar. Resmi olmayan kural: "temel" öğeler /usr/bin , "geri kalan" ise /usr 'ya gider. % Co_de% ile aynı. % Co_de% 'si, sisteme bağlı direkler ile kullanıcı arayüzleri ile karışık hale gelmeden çok uzun sürmedi. Bu nedenle, /bin , kullanıcı ile ilgili tüm direkleri korumak ve /usr/bin 'yi yalnızca sistem "stuff" için temiz tutmak için doğdu.

Bu, FHS'nin varlığından çok önceydi. Oluşturulduğunda, mevcut geleneği benimsedi (ve resmileştirdi) ve adı /bin olarak tuttu, ancak o zaman zaten “kullanıcı” ile hiçbir ilgisi yoktu. Evet, süslü adlar " U NIX s buyruk r epository" veya " U NIX s ystem r esources "ifadelerinin tamamı hazırdır ve yine de yeniden adlandırmak için çok geç. (ancak /usr/bin değerini birleştirmek için çok geç değil)

"Tamam, peki /lib ?" , soruyorsunuz. Kahretsin, unuttuğunu umuyordum. Tamam ... /usr , /home kullanıcısı, /usr ve /usr gibi bir kullanıcı tarafından yürütülebilen (veya yalnızca anlamlı olduğunda) komutlar içindir.

"Fakat bu neredeyse /bin ile aynı değil" . Evet, tabi ama ...

"Bekle, o zaman neden /usr/sbin var? Neden bir anlam ifade etmiyor!" . Şey, çünkü bu ... err .. humm ..

Bak, arkanda 3 başlı bir maymun!

Tamam, umarım yeterince dikkatiniz dağılmıştır. Devam ediyor ...

(aldattığımı düşünüyorsan, evet, haklısın. Ama sadece "resmi" cevabı "sadece" root tarafından yürütülebilen ve hatta% co_de bile monte edilmeden önce mevcut olması gereken "zorunlu komutlar) % "). Gerçek şu ki: çizgi gerçekten bulanık ve sadece "sıkışmış" ve artık kurtulmak oldukça zor bir sürü eski isim var.

/usr/sbin dokümanından root birleştirme durumu için daha fazla bilgi / p>

  

/ usr'dan ayrı bir / bin, / sbin ve / lib için geçmişe yönelik gerekçe artık geçerli değil. Daha hızlı bir sabit diskte (ki bu daha küçüktü, çünkü daha pahalıydı) ve daha yavaş / usr bölümlerini monte etmek için gerekli olan tüm araçları içerecek şekilde araçlar seçtiler. Bugün, ayrı bir / usr bölümü zaten önyükleme sırasında initramfs tarafından monte edilmeli ve böylelikle ayrık bir tartışma için gerekçelendirilmelidir. Ayrıca, / bin ve / sbin içindeki bir çok araç, önceden yüklenmiş / usr olmadan çalışabilme özelliğini zaten kaybetmiştir. Artık işletim sisteminin birden çok hiyerarşiye yayılması için geçerli bir sebep yok, amacını kaybetti.

Ve Rob Landley tarafından mount split ve mantığı hakkında inanılmaz bir okuma:

Binayı anlama, sbin, usr / bin, usr / sbin ayırma

Günümüzde

Şu anda, yükleme dizinleriyle ilgili olarak, anlamanız için en iyi yol bu şekilde düşünmektir:

  • fdisk - OS tarafından kurulan (veya sağlanan) tüm sistem genelinde, salt okunur dosyaları

  • /bin - sistem yöneticisi, yerel yönetici tarafından yüklenen salt okunur dosyalar (genellikle siz). Ve işte bu yüzden /sbin dizin adının çoğunun burada çoğaltılması.

  • / - sistem genelinde, salt okunur ve kendi kendine yeten yazılımı için bir acımasızlık. Yani, dosyalarını /usr , systemd , /usr , /usr gibi iyi davranmayan yazılımlar arasında bölmeyen bir yazılım olmalıdır.

  • /usr/local - kullanıcı başına /usr karşılığı, yani: her kullanıcı tarafından yüklenen yazılım (ve)

  • /opt - kullanıcı başına bin karşılığı

Peki yazılımı nereye kurabilirim?

Yukarıdaki liste, 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 şöyle gider:

  • Eclipse IDE ve diğer indirilen java uygulamaları gibi tamamen kendi kendine yeten, tek bir dizin yazılımı ve tüm kullanıcılar tarafından kullanılabilir olmasını ister misiniz? Ardından lib

  • 'de yükleyin
  • Yukarıdakilerle aynıdır, ancak diğer kullanıcıları umursamıyorsunuz ve sadece kullanıcınız için yüklemek istiyorum. Ardından share

  • 'de yükleyin
  • Dosyaları, include ve ~/.local gibi, birden çok direme bölünür; geleneksel yazılımlar gibi /usr/local ile derlenmiş ve yüklenmiştir ve tüm kullanıcılar tarafından kullanılabilir olmalıdır? Ardından ~/.local/opt

  • 'de yükleyin
  • Yukarıdakilerle aynı, ancak yalnızca kullanıcınız için mi? Ardından /opt

  • 'de yükleyin
  • İşletim sistemi tarafından yüklenen yazılımlar veya paket yöneticileri (Yazılım Merkezi gibi) ve en önemlisi, güncelleme yöneticisi yeni bir sürüme yükselttiğinde herhangi bir yerel değişikliğin üzerine yazılabildiği ? % Co_de%

  • konumuna gider

Notlar:

  • Bu, derlenmiş yazılım için varsayılan yükleme önekinin /opt neden olduğunu ve neden yalnızca kendi kullanıcınız için yazılım yüklerken ~/.local/opt olarak değiştirmeniz gerektiğini açıklar

  • Yukarıdaki tüm dizinlerin salt okunur olduğunu fark etmiş olabilirsiniz (tabii ki, yazılımı yüklediğinizde / kaldırdığınızda). Yazılabilir dosyalar (yapılandırma dosyaları gibi) genellikle bin (sistem genelinde yazılım için) ve share (kullanıcı başına ayarlar için) seçeneğine gider. Birçok eski yazılım (ve ne yazık ki, bazı modern) de ./configure && make && sudo make install kullanmaktadır, bu da ev dizininizi milyarlarca yönlendirici ve dosyayla karıştırmaktadır.

  • /usr/local ve ~/.local , FHS belirtiminin bir parçası değildir. FHS, kullanıcının ana klasörüyle ilgilenmez. Bunlar, kullanıcının evinin bir yapısına ilişkin bazı kurallar belirlemeye çalışmak için, Masaüstü Ortamlarına (Gnome, KDE ve Unity gibi) yönelik bir başka standart organizasyon olan XDG'nin bir girişimidir. Tüm yazılımlar buna uymuyor (örneğin, /usr kullanıcının varsayılan% co_de değerinde değil, mantığa göre olmalıdır) ve hiçbir kullanıcı onu takip etmeye zorlanmıyor, ancak her ikisi de çok kazanıyor eğer birlikte çalışırlarsa faydalar.

Umarım bu, bazı şeyleri açıklığa kavuşturmaya yardımcı olur. Herhangi bir şey sormaktan çekinmeyin, böylece cevabı iyileştirebilirim!

(ve ben de püristlerin bu tür gayri resmi bir dil ve açıklama için beni öldürmediklerini umuyorum. Bu kasıtlıydı ve kuşkusuz pek çok yanlışlık var, ama bunun iyi bir yol olduğuna inanıyorum. yeni gelenler, yükleme dizinleri gerekçeleriyle ilgili kısa bir genel bakışa sahiptir)

    
verilen cevap MestreLion 11.05.2012 22:49

Etiketlerdeki diğer soruları oku