Có phiên bản ngắn và phiên bản dài của câu trả lời của bạn ...
Phiên bản ngắn:
Như liên kết của bạn đã nói, /usr
là một nơi cho toàn hệ thống , chỉ đọc tập tin. Vì vậy, tất cả các phần mềm cài đặt của bạn đi đến đó. Nó không trùng lặp bất kỳ tên nào /
ngoại trừ /bin
và /lib
, nhưng, ban đầu, với một mục đích khác: /bin, /lib
chỉ dành cho nhị phân và thư viện cần thiết để khởi động , trong khi /usr/bin, /usr/lib
dành cho tất cả các thư viện và thư viện thực thi khác. (bây giờ hãy là một cậu bé ngoan và đừng hỏi về /sbin
, đây là phiên bản ngắn)
Ngày nay, sự khác biệt giữa "cần thiết để khởi động" và không bị giảm đi, vì hầu hết các bản phân phối hiện đại, bao gồm Ubuntu, không thể khởi động đúng cách mà không có nhiều tệp từ đó /usr
. Và đó là lý do tại sao có một phong trào mạnh mẽ đối với việc hợp nhất /usr/bin
và /bin
, vì vậy có lẽ trong tương lai gần (có lẽ Ubuntu 12.10?) /bin
Sẽ là một liên kết đến /usr/bin
.
Nhưng có lẽ bạn đang bối rối /usr
và /usr/local
? Bởi vì có, có (và nên) rất nhiều tên thư mục trùng lặp. Thêm vào đó sau ...
Phiên bản dài:
Trở lại những năm 70, trong Unix (vâng, Unix, trước Linux), các đĩa mềm có không gian nhỏ (không có HD, nhớ không?), Và tại một thời điểm nhất định, các nhị phân hệ thống đã tăng quá nhiều về số lượng và kích thước đến mức chúng sẽ không vừa với một đĩa và các nhà phát triển phải chia chúng trên một số phương tiện và do đó tạo ra các điểm gắn kết mới cho chúng. /bin
hệ thống tập tin đã đầy đủ, vì vậy họ cài đặt những chương trình mới tại ... /usr/bin
. Và /usr
tại thời điểm đó, ... thư mục người dùng của họ !
Sau khi sự chia rẽ (gần như xấu hổ và thường được nói là một trò đùa / truyền thuyết) xảy ra, họ bắt đầu tạo ra những biện minh "nhân tạo" (và tiêu chí) để quyết định điều gì sẽ xảy ra /bin
và điều gì sẽ xảy ra /usr/bin
. Quy tắc không chính thức là: "những thứ thiết yếu" được sử dụng /bin
, "phần còn lại" được sử dụng /usr/bin
. Tương tự với /lib
. Không lâu trước khi /usr
trở nên đông đúc với các thư mục liên quan đến hệ thống, trộn lẫn với các thư mục người dùng. Do đó /home
, ra đời, để giữ tất cả các thư mục liên quan đến người dùng và chỉ giữ /usr
sạch cho "công cụ" hệ thống.
Điều này đã rất lâu trước khi FHS tồn tại. Khi nó được tạo ra, nó chấp nhận (và chính thức hóa) truyền thống hiện tại và giữ nguyên tên /usr
, mặc dù tại thời điểm đó nó không còn liên quan gì đến "người dùng" nữa. Vì vậy, có, những cái tên lạ mắt " U NIX s ource r epository" hoặc " U NIX s ystem r esources" là tất cả các tên làm-up, và đó là quá muộn để đổi tên nó anyway. (nhưng không quá muộn để hợp nhất /bin
với nó)
"Ok, còn /usr/sbin
?" , bạn hỏi. Chết tiệt, tôi đã hy vọng bạn đã quên. Ok ... /usr/sbin
là cho các lệnh chỉ có thể (hoặc chỉ có ý nghĩa khi) được thực thi bởi root
người dùng, như mount
và fdisk
.
"Nhưng không phải nó gần giống như /bin
sao?" . Phải, chắc chắn, nhưng ...
"Đợi đã, vậy tại sao lại có một thứ /sbin
quá? Không có ý nghĩa gì cả!" . Chà, đó là vì ... err .. humm ..
Hãy nhìn xem, một con khỉ 3 đầu đằng sau bạn!
Ok, hy vọng, bạn đã đủ phân tâm. Tiếp tục ...
(nếu bạn nghĩ rằng tôi gian lận, vâng, bạn đã đúng. Nhưng các câu lệnh thiết yếu "chính thức" chỉ có thể được thực thi bằng root và phải có sẵn trước khi bạn gắn kết /
"). Sự thật là: dòng này thực sự mờ, và có rất nhiều tên di sản chỉ "bị mắc kẹt" và bây giờ khá khó để loại bỏ.
Thông tin thêm về Trường /usr
hợp hợp nhất , từ systemd
tài liệu:
Sự biện minh lịch sử cho a / bin, / sbin và / lib tách biệt với / usr không còn được áp dụng ngày hôm nay. Chúng được tách ra để có các công cụ được chọn trên một đĩa cứng nhanh hơn (nhỏ, vì nó đắt hơn) và để chứa tất cả các công cụ cần thiết để gắn kết phân vùng chậm / usr. Ngày nay, một phân vùng / usr riêng biệt đã được các initramfs gắn kết trong quá trình khởi động sớm, do đó đưa ra lời biện minh cho việc di chuyển tách rời. Ngoài ra, rất nhiều công cụ trong / bin và / sbin trong hiện trạng đã mất khả năng chạy mà không được gắn trước / usr. Không có lý do hợp lệ nữa để hệ điều hành trải rộng trên nhiều hệ thống phân cấp, nó mất mục đích.
Và một bài đọc tuyệt vời về sự /usr
chia rẽ và lý do của nó, bởi Rob Landley:
Hiểu về bin, sbin, usr / bin, usr / sbin split
Ngày nay
Hiện tại, liên quan đến các thư mục cài đặt, cách tốt nhất để hiểu là nghĩ theo cách này:
/usr
- tất cả các tệp trên toàn hệ thống, chỉ đọc được cài đặt bởi (hoặc được cung cấp bởi) HĐH
/usr/local
- các tệp toàn hệ thống, chỉ đọc được cài đặt bởi quản trị viên cục bộ (thông thường, bạn). Và đó là lý do tại sao hầu hết các tên thư mục /usr
được sao chép ở đây.
/opt
- một hành động tàn bạo dành cho phần mềm toàn hệ thống, chỉ đọc và độc lập . Đó là, phần mềm mà không chia nhỏ các file của họ trên bin
, lib
, share
, include
như well-behaved phần mềm cần.
~/.local
- đối tác trên mỗi người dùng của /usr/local
, đó là: phần mềm được cài đặt bởi (và cho) mỗi người dùng
~/.local/opt
- đối tác trên mỗi người dùng của /opt
Vậy cài đặt phần mềm ở đâu?
Danh sách trên đã là một nửa câu trả lời cho câu hỏi Oracle JDK của bạn, ít nhất là nó đưa ra một số manh mối. Danh sách kiểm tra "Tôi nên cài đặt phần mềm X ở đâu?" đi bằng:
Đây có phải là một phần mềm thư mục đơn hoàn toàn khép kín, như IDE Eclipse và các ứng dụng java đã tải xuống khác và bạn muốn nó có sẵn cho tất cả người dùng? Sau đó cài đặt vào/opt
Tương tự như trên, nhưng bạn không quan tâm đến người dùng khác và tôi muốn cài đặt cho người dùng của bạn một mình? Sau đó cài đặt vào~/.local/opt
Các tệp của nó phân chia trên nhiều thư mục, như bin
và share
, giống như phần mềm truyền thống được biên dịch và cài đặt cùng ./configure && make && sudo make install
, và có nên có sẵn cho tất cả người dùng không? Sau đó cài đặt vào/usr/local
Tương tự như trên, nhưng chỉ dành cho người dùng của bạn? Sau đó cài đặt vào~/.local
Phần mềm được cài đặt bởi HĐH hoặc thông qua các trình quản lý gói (như Trung tâm phần mềm) và quan trọng nhất là bất kỳ sửa đổi cục bộ nào có thể được ghi đè khi trình quản lý cập nhật nâng cấp lên phiên bản mới ? Nó đi đến/usr
Ghi chú:
Điều này giải thích tại sao tiền tố cài đặt mặc định cho phần mềm được biên dịch /usr/local
và tại sao bạn chỉ nên đổi nó thành ./configure --prefix=$HOME/.local
khi cài đặt phần mềm cho người dùng của riêng bạn
Bạn có thể nhận thấy rằng tất cả các thư mục ở trên là chỉ đọc (tất nhiên, ngoại trừ khi bạn cài đặt / gỡ bỏ phần mềm). Các tệp có thể ghi (như tệp cấu hình) thường chuyển đến /etc
(đối với phần mềm toàn hệ thống) và ~/.config
(đối với cài đặt theo người dùng). Mặc dù nhiều phần mềm cũ (và, thật không may, một số hiện đại cũng vậy) sử dụng ~/.<software-name>
, làm lộn xộn thư mục nhà của bạn với hàng tỷ thư mục và tệp.
~/.local
và ~/.config
không phải là một phần của đặc tả FHS. FHS không đối phó với thư mục nhà của người dùng. Chúng là một nỗ lực của XDG, một tổ chức tiêu chuẩn khác hướng đến Môi trường máy tính để bàn (như Gnome, KDE và Unity), để cố gắng thiết lập một số quy ước liên quan đến cấu trúc của nhà người dùng. Không phải tất cả các phần mềm đều tuân thủ nó (ví dụ, ~/.local/bin
không phải trong mặc định của người dùng $PATH
, trong khi theo logic thì nên) và không người dùng nào bị buộc phải tuân theo nó, nhưng cả hai đều đạt được nhiều lợi ích về khả năng tương tác nếu có.
Tôi hy vọng điều này sẽ giúp làm rõ mọi thứ một chút. Hãy hỏi bất cứ điều gì để tôi có thể cải thiện câu trả lời!
(và tôi cũng hy vọng những người theo chủ nghĩa thuần túy không giết tôi vì một ngôn ngữ và lời giải thích cực kỳ không chính thống như vậy. Đó là cố ý, và nó chắc chắn có nhiều điểm không chính xác, nhưng tôi tin rằng đó là một cách tốt để khiến người mới có hiểu biết tổng quan ngắn gọn về cài đặt thư mục hợp lý)