Subyek: Sistem Operasi.
Pertanyaan: No.8

—————————————————————

Prinsip desain OS:

1.) Prinsip modularitas– dalam kasus umum, modul dipahami sebagai elemen sistem yang lengkap secara fungsional, dibuat sesuai dengan antarmuka antarmodul yang diterima. Berdasarkan definisinya, sebuah modul mengasumsikan kemampuan untuk dengan mudah menggantinya dengan yang lain jika antarmuka yang ditentukan tersedia. Sebagian besar, pembagian sistem menjadi modul-modul ditentukan oleh metode desain OS yang digunakan (bottom-up atau sebaliknya).

Yang paling penting ketika membangun sistem operasi adalah modul istimewa, masuk kembali, dan masuk kembali (masuk kembali - secara harfiah masuk kembali; istilah khusus untuk menunjukkan fungsionalitas program; properti program yang akan dieksekusi dengan benar selama panggilan rekursif (dikembalikan) dari interupsi).

Efek terbesar dari penggunaan prinsip ini dapat dicapai jika prinsip ini didistribusikan secara bersamaan ke OS, program aplikasi, dan perangkat keras.

2.) Prinsip selektivitas fungsional– OS mengalokasikan bagian tertentu dari modul penting yang harus selalu ada RAM untuk organisasi proses komputasi yang lebih efisien. Bagian OS ini disebut kernel karena merupakan basis sistem. Ketika membentuk komposisi inti, dua persyaratan yang saling bertentangan harus diperhitungkan. Di satu sisi, kernel harus menyertakan modul sistem yang paling sering digunakan, di sisi lain, jumlah modul harus sedemikian rupa sehingga jumlah memori yang digunakan oleh kernel tidak terlalu besar. Selain modul program yang merupakan bagian dari kernel dan ditempatkan secara permanen di RAM, mungkin masih banyak lagi modul lainnya program sistem modul akhir, yang disebut transit. Modul program transit dimuat ke dalam RAM hanya jika diperlukan dan, jika tidak ada ruang kosong, dapat diganti dengan modul transit lainnya.

3.) Prinsip pembuatan OS: Inti dari prinsipnya adalah mengatur (memilih) metode representasi awal dari program kontrol sistem pusat OS (kernel dan komponen utama yang terletak secara permanen di RAM), yang memungkinkan untuk mengkonfigurasi bagian pengawasan sistem ini berdasarkan konfigurasi spesifik dari kompleks komputasi tertentu dan rentang tugas yang diselesaikan. Prosedur ini jarang dilakukan sebelum jangka waktu pengoperasian OS yang cukup lama. Proses pembangkitan dilakukan menggunakan program generator khusus dan bahasa input yang sesuai untuk program ini, yang memungkinkan Anda menjelaskan kemampuan perangkat lunak sistem dan konfigurasi mesin. Hasil dari generasi adalah versi lengkap sistem operasi. Versi OS yang dihasilkan adalah kumpulan kumpulan modul dan data sistem.

4.) Prinsip redundansi fungsional: Prinsip ini memperhitungkan kemungkinan melakukan pekerjaan yang sama dengan cara yang berbeda. OS dapat mencakup beberapa jenis monitor (modul pengawas yang mengelola jenis sumber daya tertentu), berbagai cara untuk mengatur komunikasi antar proses komputasi. Kehadiran beberapa jenis monitor dan beberapa sistem manajemen file memungkinkan pengguna dengan cepat dan memadai mengadaptasi OS ke konfigurasi sistem komputer tertentu, memastikan pemuatan perangkat keras yang paling efisien saat memecahkan kelas masalah tertentu, dan memperoleh kinerja maksimal saat menyelesaikannya. suatu kelas masalah tertentu.

5.) Prinsip virtualisasi: pembangunan sumber daya virtual, distribusi dan penggunaannya saat ini digunakan di hampir semua OS. Prinsip ini memungkinkan kita untuk merepresentasikan struktur sistem dalam bentuk sekumpulan penjadwal proses dan pengalokasi sumber daya (monitor) tertentu dan menggunakan skema terpusat tunggal untuk distribusi sumber daya.

Manifestasi konsep virtualitas yang paling alami dan lengkap adalah konsep mesin virtual . Mesin virtual yang diberikan kepada pengguna mereproduksi arsitektur mesin sebenarnya, namun elemen arsitektur dalam representasi ini muncul dengan karakteristik baru atau lebih baik, biasanya menyederhanakan pekerjaan dengan sistem. Karakteristiknya bisa berubah-ubah, tetapi paling sering pengguna ingin memiliki mesin “ideal” sendiri dalam hal karakteristik arsitektural, yang terdiri dari berikut ini:

— memori virtual dengan kapasitas praktis tidak terbatas, seragam dalam logika pengoperasian.

— sejumlah prosesor virtual yang mampu bekerja secara paralel dan berinteraksi selama operasi.

— sejumlah perangkat virtual eksternal yang mampu bekerja dengan memori mesin virtual secara paralel atau berurutan, asinkron atau sinkron sehubungan dengan pengoperasian prosesor virtual tertentu yang memulai pengoperasian perangkat ini.

Salah satu aspek virtualisasi adalah pengorganisasian kemampuan menjalankan aplikasi pada OS tertentu yang dikembangkan untuk OS lain. Dengan kata lain, kita berbicara tentang pengorganisasian beberapa lingkungan operasi.

6.) Prinsip kemandirian program dari perangkat eksternal: Prinsip ini sekarang diterapkan di sebagian besar sistem operasi umum. Untuk pertama kalinya, prinsip ini paling konsisten diterapkan di OS UNIX. Ini juga diterapkan di sebagian besar sistem operasi PC modern. Prinsip ini adalah hubungan program dengan perangkat tertentu tidak dilakukan pada tataran penyiaran program, melainkan pada masa perencanaan pelaksanaannya. Akibatnya, kompilasi ulang tidak diperlukan saat menjalankan program pada perangkat baru tempat data berada.

7.) Prinsip kompatibilitas: Salah satu aspek kompatibilitas adalah kemampuan sistem operasi untuk menjalankan program yang ditulis untuk sistem operasi lain atau lebih versi sebelumnya OS ini, serta untuk platform perangkat keras lainnya. Penting untuk memisahkan pertanyaan kompatibilitas biner Dan kompatibilitas sumber aplikasi.

Kompatibilitas biner dicapai ketika Anda dapat mengambil program yang dapat dieksekusi dan menjalankannya di OS lain. Hal ini memerlukan kompatibilitas pada tingkat instruksi prosesor, dan kompatibilitas pada tingkat panggilan sistem, dan bahkan pada tingkat panggilan perpustakaan jika keduanya terhubung secara dinamis.

Kesesuaian pada tataran teks sumber memerlukan kehadiran penerjemah yang sesuai sebagai bagian dari sistem perangkat lunak, serta kompatibilitas di tingkat perpustakaan dan panggilan sistem. Dalam hal ini, perlu untuk mengkompilasi ulang teks sumber yang ada ke dalam modul baru yang dapat dieksekusi.

Jauh lebih sulit untuk mencapai kompatibilitas biner antar prosesor berdasarkan arsitektur yang berbeda. Agar satu komputer dapat menjalankan program komputer lain (misalnya, program untuk PC seperti PC IBM sebaiknya dijalankan pada PC seperti Apple Macintosh), komputer ini harus bekerja dengan instruksi mesin yang awalnya tidak dapat dipahami. untuk itu. Dalam hal ini, prosesor 680x0 (atau PowerPC) harus mengeksekusi kode biner yang dirancang untuk prosesor i80x86. Prosesor 80x86 memiliki dekoder instruksi, register, dan arsitektur internalnya sendiri. Prosesor 680x0 tidak memahami kode biner 80x86, sehingga harus mengambil setiap instruksi dan mendekodekannya untuk menentukan apa yang dimaksud.

apa yang ingin dilakukannya, lalu jalankan rutinitas setara yang ditulis untuk 680x0.

Salah satu cara untuk memastikan kompatibilitas antara perangkat lunak dan antarmuka pengguna adalah kepatuhan terhadap standar POSIX, yang penggunaannya memungkinkan Anda membuat program bergaya UNIX yang dapat dengan mudah ditransfer dari satu sistem ke sistem lainnya.

8.) Prinsip keterbukaan dan skalabilitas: Sistem operasi terbuka tersedia untuk dianalisis oleh pengguna dan spesialis sistem yang memelihara sistem komputer. OS yang dapat diperluas (dimodifikasi, dikembangkan) memungkinkan Anda tidak hanya menggunakan kemampuan pembangkitan, tetapi juga memperkenalkan modul baru ke dalam komposisinya, meningkatkan yang sudah ada, dll. Dengan kata lain, penambahan dan perubahan harus dapat dilakukan dengan mudah bila diperlukan tanpa mengurangi integritas sistem. Peluang besar untuk ekspansi disediakan oleh pendekatan client-server untuk penataan OS menggunakan teknologi mikro-kernel. Sesuai dengan pendekatan ini, OS dibangun sebagai sekumpulan program kontrol dengan hak istimewa dan sekumpulan layanan (server) yang tidak memiliki hak istimewa. Bagian utama dari OS tetap tidak berubah, dan pada saat yang sama server baru dapat ditambahkan atau server lama dapat ditingkatkan. Prinsip ini terkadang diartikan sebagai perluasan sistem.

9.) Prinsip mobilitas: sistem operasi harus relatif mudah untuk di-porting

transfer dari prosesor dari satu jenis ke prosesor dari jenis lain dan dari platform perangkat keras dari satu jenis, yang mencakup, bersama dengan jenis prosesor, metode pengorganisasian semua perangkat keras komputer (arsitektur sistem komputer), ke platform perangkat keras dari tipe lain. Perlu diperhatikan bahwa prinsip portabilitas sangat mirip dengan prinsip kompatibilitas, meskipun keduanya tidak sama. Membuat OS portabel mirip dengan menulis kode portabel apa pun, tetapi Anda perlu mengikuti beberapa hal aturan:

— sebagian besar OS harus dijalankan dalam bahasa yang tersedia di semua sistem yang rencananya akan ditransfer di masa mendatang. Ini, pertama-tama, berarti bahwa OS harus ditulis dalam bahasa tersebut tingkat tinggi, sebaiknya distandarisasi, misalnya dalam bahasa C. Sebuah program yang ditulis dalam bahasa assembly umumnya tidak portabel.

- Penting untuk meminimalkan atau, jika mungkin, menghilangkan bagian-bagian kode yang berinteraksi langsung dengan perangkat keras. Ketergantungan pada perangkat keras dapat terjadi dalam berbagai bentuk. Beberapa bentuk ketergantungan yang jelas termasuk manipulasi langsung terhadap register dan perangkat keras lainnya. Terakhir, jika kode yang bergantung pada perangkat keras tidak dapat sepenuhnya dihilangkan, maka kode tersebut harus diisolasi dalam beberapa modul yang terlokalisasi dengan baik. Kode yang bergantung pada perangkat keras tidak boleh didistribusikan ke seluruh sistem. Misalnya, Anda bisa menyembunyikan struktur yang bergantung pada perangkat dalam data yang ditentukan program dari tipe abstrak.

Pengenalan standar POSIX dimaksudkan untuk memastikan portabilitas perangkat lunak yang dibuat.

10.) Prinsip keamanan komputasi: memastikan keamanan saat melakukan penghitungan adalah properti yang diinginkan untuk sistem multi-pengguna mana pun. Aturan keamanan menentukan properti seperti melindungi sumber daya satu pengguna dari pengguna lain dan menetapkan kuota sumber daya untuk mencegah satu pengguna mengambil alih semua sumber daya sistem, seperti memori.

Memastikan perlindungan informasi dari akses tidak sah adalah fungsi wajib sistem operasi jaringan.

—————————————————————

Apa yang terjadiPOSIX: antarmuka sistem platform-independen untuk lingkungan komputer POSIX (Portable Operating System Interface for Computer Environments) adalah standar IEEE (Institute of Electrical and Electronics Engineers) yang menjelaskan antarmuka sistem untuk sistem operasi terbuka, termasuk shell, utilitas, dan toolkit. Selain itu, menurut POSIX, tugas keamanan, tugas waktu nyata, proses administrasi, fungsi jaringan, dan pemrosesan transaksi distandarisasi. Standar ini didasarkan pada sistem UNIX, tetapi juga dapat diterapkan pada sistem operasi lain. POSIX muncul sebagai upaya IEEE yang terkenal di dunia untuk mempromosikan portabilitas aplikasi di lingkungan UNIX dengan mengembangkan standar abstrak dan tidak bergantung pada platform. Misalnya, OS real-time QNX yang terkenal mematuhi spesifikasi standar ini.

Standar ini menjelaskan sistem secara rinci memori maya VMS (Virtual Memory System), MPE (Multi-Process Executing) multitasking dan teknologi CTOS (Sistem Operasi yang menghasilkan Teknologi Konvergen...) untuk mentransfer sistem operasi. Jadi POSIX sebenarnya adalah seperangkat standar yang disebut POSIX.I hingga POSIX.12. Perlu juga dicatat secara khusus bahwa POSIX.1 mengasumsikan C sebagai bahasa utama

bahasa untuk mendeskripsikan fungsi API sistem.

Dengan demikian, program yang ditulis dengan standar ini akan berjalan sama di semua sistem yang mendukung POSIX. Namun, dalam beberapa kasus, standar ini hanya bersifat nasihat. Beberapa standar dijelaskan dengan sangat ketat, sementara standar lainnya hanya mengungkapkan persyaratan dasar secara dangkal.

Implementasi API POSIX di level sistem operasi berbeda. Meskipun sebagian besar sistem UNIX pada awalnya mematuhi spesifikasi IEEE Standard 1003.1-1990, WinAPI tidak kompatibel dengan POSIX. Namun, untuk mendukung standar ini, sistem operasi MS Windows NT memperkenalkan modul dukungan API POSIX khusus yang beroperasi pada tingkat hak istimewa proses pengguna.

Modul ini menyediakan konversi dan transmisi panggilan dari program pengguna ke kernel sistem dan sebaliknya, bekerja dengan kernel melalui Win API. Aplikasi lain yang dibangun menggunakan WinAPI dapat meneruskan informasi ke aplikasi POSIX melalui mekanisme aliran I/O standar (stdin, stdout).

Tidak ada postingan serupa...

POSIX (Portable Operating System Interface for Computer Environments) adalah standar IEEE (Institute of Electrical and Electronics Engineers) yang menjelaskan antarmuka sistem.

"Dalam konteks ini, perintah sistem harus dipahami sebagai serangkaian program tertentu yang memungkinkan Anda mengontrol proses komputasi, misalnya pstat, kill, dir, dll.

Antarmuka POSIX____________________________________________ 305

wajah untuk sistem operasi terbuka, termasuk shell, utilitas, dan alat. Selain itu, menurut POSIX, tugas keamanan, tugas waktu nyata, proses administrasi, fungsi jaringan, dan pemrosesan transaksi distandarisasi. Standar ini didasarkan pada sistem UNIX, tetapi juga dapat diterapkan pada sistem operasi lain.

Antarmuka POSIX dimulai sebagai upaya IEEE untuk mempromosikan portabilitas aplikasi di lingkungan UNIX dengan mengembangkan standar abstrak dan tidak bergantung pada platform. Namun, POSIX tidak terbatas pada sistem UNIX; Ada berbagai implementasi standar ini dalam sistem yang memenuhi persyaratan IEEE Standard 1003.1-1990 (POSIX.1). Misalnya, OS real-time QNX yang terkenal mematuhi spesifikasi standar ini, yang membuatnya lebih mudah untuk mem-porting aplikasi ke sistem ini, tetapi ini bukan sistem UNIX dalam bentuk apa pun, karena arsitekturnya menggunakan prinsip yang sama sekali berbeda.

Standar ini merinci teknologi Virtual Memory System (VMS), Multiprocess Executing (MPE), dan Portable Operating System (CTOS). Jadi POSIX sebenarnya adalah banyak standar POSIX. 1-POSIKS. 12. Dalam tabel. 9.1 mencantumkan bidang-bidang utama yang dijelaskan oleh standar-standar ini. Perlu juga diperhatikan secara khusus bahwa di POSIX. 1 Bahasa utama untuk mendeskripsikan fungsi API sistem diasumsikan C.

Tabel 9.1. Kelompok standar POSIX

Deskripsi Singkat Standar ISO Standar

POSIX.0 No Pengenalan standar sistem terbuka. Dokumen ini

bukanlah standar dalam bentuknya yang murni, tetapi mewakili rekomendasi dan gambaran singkat teknologi

POSIX.1 Ya Sistem API (bahasa C)

POSIX.2 Tanpa Shell dan utilitas (disetujui IEEE)

POSIX.3 Tidak Ada Pengujian dan verifikasi

POSIX.4 Tidak ada tugas dan rangkaian eksekusi waktu nyata

POSIX.5 Ya Penggunaan bahasa ADA berlaku

dengan standar POSIX. 1

POSIX.6 Tidak ada keamanan sistem

POSIX.7 Tidak ada Administrasi sistem

POSIX.8 Tanpa Jaringan, akses file transparan, abstrak

antarmuka jaringan, tidak bergantung pada protokol fisik, panggilan RPC, komunikasi sistem dengan aplikasi yang bergantung pada protokol

POSIX.9 Ya Penggunaan bahasa Fortran, berlaku

dengan standar POSIX. 1

POSIX. 10 Tidak Ada Profil Lingkungan Aplikasi Komputasi Super (AEP)

POSIX. 11 Tidak Ada Pemrosesan Transaksi AEP

POSIX. 12 Tidak ada antarmuka pengguna grafis (GUI)

306______________________________ Bab 9. Arsitektur sistem operasi

Dengan demikian, program yang ditulis dengan standar ini akan berjalan sama di semua sistem yang mendukung POSIX. Namun, standar tersebut sebagian hanya bersifat nasihat. Beberapa standar dijelaskan dengan sangat ketat, sementara standar lainnya hanya mengungkapkan persyaratan dasar secara dangkal. Seringkali sistem perangkat lunak dinyatakan sesuai dengan POSIX, meskipun tidak dapat disebut demikian. Alasannya terletak pada pendekatan formal untuk mengimplementasikan antarmuka POSIX di berbagai sistem operasi. Pada Gambar. Gambar 9.1 menunjukkan diagram implementasi tipikal untuk aplikasi yang sesuai dengan POSIX.

Beras. 9.1. Diagram implementasi aplikasi secara ketat sesuai dengan standar POSIX

Gambar tersebut menunjukkan bahwa program hanya menggunakan perpustakaan POSIX untuk berinteraksi dengan sistem operasi. 1 dan pustaka C RTL standar, yang hanya dapat menggunakan 110 fungsi berbeda, juga dijelaskan oleh standar POSIX. 1.

Sayangnya, sering kali, untuk meningkatkan kinerja subsistem tertentu atau untuk memperkenalkan teknologi eksklusif yang membatasi cakupan aplikasi pada lingkungan operasi yang sesuai, fungsi lain yang tidak memenuhi standar POSIX digunakan selama pemrograman.

Implementasi standar POSIX pada tingkat sistem operasi berbeda-beda. Meskipun sebagian besar sistem UNIX pada awalnya mematuhi spesifikasi IEEE Standard 1003.1-1990, WinAPI tidak kompatibel dengan POSIX. Namun untuk mendukungnya di ruang operasi sistem jendela NT memperkenalkan modul API khusus untuk mendukung standar POSIX, yang beroperasi pada tingkat hak istimewa proses pengguna. Modul ini menyediakan konversi dan transmisi panggilan dari program pengguna ke kernel sistem dan sebaliknya, bekerja dengan kernel melalui WinAPI. Aplikasi lain yang ditulis menggunakan WinAPI dapat meneruskan informasi POSIX ke aplikasi melalui mekanisme aliran stdin dan stdout I/O standar.

Contoh pemrograman untuk API yang berbeda________ 307

Contoh pemrograman untuk API yang berbeda

Untuk menunjukkan dengan jelas perbedaan mendasar antara antarmuka API dari sistem operasi modern paling populer untuk komputer pribadi, mari kita lihat contoh paling sederhana, di mana Anda perlu menghitung jumlah spasi di dalamnya file teks, yang namanya harus ditentukan pada baris perintah. Mari kita pertimbangkan dua versi program: untuk Windows (menggunakan WinAPI) dan untuk Linux (POSIX API).

Karena kita tertarik untuk bekerja dengan tugas paralel, mari kita asumsikan bahwa ketika program dijalankan, untuk setiap file yang terdaftar di baris perintah, prosesnya sendiri atau thread eksekusi (tugas) dibuat, yang paralel dengan proses lainnya. (utas), melakukan pekerjaan menghitung spasi di file "nya". Hasil dari program ini adalah daftar file dengan jumlah spasi yang dihitung untuk masing-masing file.

Perhatian khusus harus diberikan pada kenyataan bahwa implementasi program untuk memecahkan masalah yang diberikan di bawah ini bukanlah satu-satunya kemungkinan yang bisa dilakukan. Kedua sistem operasi tersebut memiliki metode berbeda dalam bekerja dengan sistem file dan mengelola proses. DI DALAM dalam hal ini Hanya satu opsi yang dipertimbangkan, namun ini adalah opsi yang paling umum untuk antarmuka API terkait.

Agar lebih mudah untuk membandingkan program ini (Listing 9.1) dan program berikutnya (Listing 9.2), dan juga memperhitungkan bahwa tugas tersebut tidak memerlukan antarmuka jendela untuk penyelesaiannya, hanya panggilan API yang tidak mempengaruhi antarmuka grafis digunakan dalam teks. Tentu saja, saat ini jarang ada aplikasi yang tidak menggunakan kemampuan GUI, namun dalam kasus kami, Anda dapat langsung melihat perbedaan dalam organisasi operasi paralel dari perhitungan yang diluncurkan.

Alexei Fedorchuk
2005

Salah satu ciri khas struktur logis sistem file sistem operasi keluarga POSIX adalah organisasinya yang hierarkis, atau seperti pohon (meskipun, seperti yang telah saya katakan, pohon tersebut terlihat agak aneh). Artinya, tidak ada sebutan (misalnya, alfabet atau lainnya) untuk masing-masing media dan bagiannya, seperti di DOS atau Windows apa pun: semuanya dimasukkan dalam satu struktur sebagai subdirektori dari direktori utama. disebut akar. Proses koneksi sistem file pada media fisik independen (dan partisinya) ke akar pohon file disebut mount, dan subdirektori yang isinya disebut mount point.

Secara historis, Unix telah mengembangkan struktur direktori tertentu, sangat mirip secara umum di antara anggota keluarga ini, tetapi sedikit berbeda secara detail. Secara khusus, hierarki file di sistem BSD hampir sama, berbeda dengan di Linux. Dan yang terakhir, ditemukan perbedaan signifikan antara distribusi yang berbeda. Sampai-sampai struktur hierarki file menjadi salah satu fitur khusus distribusi.

Keadaan ini menyulitkan penulisan aplikasi lintas platform. Oleh karena itu, ada dan secara aktif mengembangkan proyek standardisasi hierarki file - FHS (Filesystem Hierarchy Standard).

Proyek FHS pada awalnya bertujuan untuk menyederhanakan struktur direktori berbagai distribusi Linux. Kemudian diadaptasi untuk sistem mirip Unix lainnya (termasuk klan BSD). Dan sekarang terdapat upaya aktif (tetapi tidak terlalu berhasil) untuk menjadikannya standar untuk sistem POSIX, tidak hanya dalam nama, tetapi pada kenyataannya.

Standar FHS bertumpu pada dua prinsip dasar - pemisahan yang jelas dalam hierarki file direktori bersama dan tidak bersama, di satu sisi, dan tidak dapat diubah dan diubah, di sisi lain.

Perbedaan antara direktori bersama dan non-berbagi disebabkan oleh sifat jaringan Unix yang melekat. Artinya, data yang terkait dengan mesin lokal (misalnya, file konfigurasi untuk perangkatnya) harus ditempatkan di direktori yang terpisah dari direktori yang isinya dapat diakses dari mesin lain di jaringan, lokal atau global (contohnya bukan hanya pengguna data, tetapi juga program).

Inti dari perbedaan antara direktori yang tidak dapat diubah dan direktori yang dapat diubah dapat dengan mudah dijelaskan dengan sebuah contoh. Dengan demikian, program pengguna umum yang sama harus bersifat kekal (atau lebih tepatnya, tersedia untuk modifikasi hanya untuk administrator sistem, tetapi tidak untuk pengguna itu sendiri yang menggunakannya dalam pekerjaannya). Pada saat yang sama, program-program ini, selama pengoperasiannya, tidak hanya menghasilkan file data, katakanlah, teks atau gambar (sifat variabelnya jelas tanpa komentar), tetapi semua jenis informasi layanan, seperti file log, file sementara, dan file menyukai). Yang harus dikelompokkan ke dalam direktori yang dipisahkan dari file program, perpustakaan, file konfigurasi, dll. yang sebenarnya dapat dieksekusi, yang diperlukan untuk peluncurannya.

Namun, meskipun ada promosi aktif di banyak distribusi Linux yang paling umum, FHS belum mencapai status standar yang sebenarnya. Masih banyak distro Linux yang tidak menggunakan beberapa ketentuannya. Dan itu hanya berkorelasi sebagian dengan hierarki file tradisional sistem BSD.

Dan alasannya adalah FHS mengabaikan kontras lain yang sangat penting bagi pengguna: kontras antara bagian sistem file yang mudah dipulihkan dan komponennya yang sulit dipulihkan atau tidak dapat dipulihkan sama sekali.

Yang pertama, anehnya, mencakup sistem dasar itu sendiri: lagipula, menginstal ulang dari media distribusi jika terjadi kerusakan fatal tidaklah begitu sulit. Bagian sistem file yang sulit dipulihkan jelas mencakup data pengguna: meskipun data tersebut dicadangkan secara teratur (dan berapa banyak pengguna yang sangat berhati-hati?), membuka gulungannya dari arsip akan memerlukan banyak waktu (dan hampir pasti memerlukan waktu beberapa kerugian).

Selain itu, dalam sistem BSD dan distribusi Linux Berbasis Sumber, saya akan mengklasifikasikan segala sesuatu yang berhubungan dengan manajemen paket ke dalam direktori yang sulit dipulihkan - pohon port FreeBSD atau pkgsrc di NetBSD (dan sistem yang meminjamnya), analognya dalam distribusi Linux, sumber sebenarnya dari program porting, dan juga kode sumber sistem. Karena, meskipun semua ini tersedia dalam kit distribusi, komponen sistem file ini, sebagai suatu peraturan, tetap diperbarui oleh pengguna dengan melakukan sinkronisasi melalui Jaringan dengan server proyek (jika tidak, penggunaannya tidak masuk akal). Dan kerugiannya akan menyebabkan kerugian sementara (terutama dengan koneksi modem) dan kerugian finansial (hanya sedikit orang yang bahagia memiliki akses Internet gratis).

Ketaatan yang ketat terhadap konsep pemisahan direktori bersama dan tidak dibagikan, tidak dapat diubah dan tidak dapat diubah, dapat dipulihkan dan tidak dapat dipulihkan satu sama lain memungkinkan, dalam satu hierarki file seperti pohon, untuk mengisolasi masing-masing cabang secara fisik - yaitu, dalam bentuk sistem file independen yang terletak di perangkat yang terisolasi (disk, bagian disk, irisan, partisi, dll.). Ada banyak alasan untuk hal ini - peningkatan kecepatan, peningkatan keandalan, dan sekadar pertimbangan kenyamanan - tetapi kami tidak akan membicarakannya sekarang. Karena di saat ini Yang penting bagi kami adalah bahwa cabang-cabang pohon file ini harus dimasukkan ke dalam sistem file secara keseluruhan.

Satu set direktori sistem POSIX yang khas

Faktanya, untuk pengoperasiannya, mutlak diperlukan hanya satu sistem file - sistem yang dipasang di direktori root pohon file (semacam analog dari pohon dunia Yggdrassil). Direktori root dan cabang-cabang pentingnya harus membentuk sistem file tunggal yang terletak pada satu media - disk, partisi disk, array RAID perangkat lunak atau perangkat keras, atau volume logis dalam pengertian LVM. Dan itu harus berisi semua komponen yang diperlukan untuk memulai sistem dan, idealnya, tidak lebih.

Anda dapat melihat komposisi direktori root dengan perintah

$ls -1/

yang pada sistem POSIX mana pun akan menampilkan kumpulan direktori minimum tertentu:

Tempat sampah/ boot/ dll/ root/ sbin/

Mereka berisi semua file yang tanpanya sistem tidak akan ada. Direktori lain kira-kira seperti ini:

Beranda/ mnt/ pilih/ tmp/ usr/ var/

Hal-hal tersebut a) tidak diperlukan (setidaknya secara teoritis - dalam praktiknya sulit dilakukan tanpanya), b) tidak masing-masing ada di semua sistem dan distribusi, dan c) masing-masing dapat (dan sering kali ada - jika Anda melakukan semuanya dengan bijak) ) titik mount dari cabang pohon filenya sendiri.

Selain itu, dalam banyak kasus, di root sistem file sistem operasi yang kompatibel dengan POSIX terdapat dua subdirektori lagi:

Pengembangan/proses/

Ini biasanya merupakan titik mount untuk sistem file virtual - masing-masing perangkat dan proses (walaupun jika sistem file perangkat tidak digunakan, direktori /dev harus menjadi komponen sistem file root. Terakhir, pada sistem Linux, sebagai aturan , akar dari pohon file juga terdapat direktori /lib, yang ditujukan untuk perpustakaan sistem utama. Dan ketika menggunakan mekanisme udev, direktori /sys juga tidak dapat dihindari, di mana sistem file virtual sysfs dipasang.

Sistem file akar

Sistem file root tidak dibagikan (artinya, tidak dimaksudkan untuk membagikan mesin yang berbeda di jaringan) dan tidak dapat diubah (yaitu, perubahan hanya dapat dilakukan oleh administrator sistem, tetapi tidak oleh program pengguna dan, terlebih lagi, bukan oleh pengguna). Selain itu, sangat tidak disarankan untuk membuat subdirektori di luar yang disediakan oleh standar (dan tercantum di atas).

Konten sistem file root dipilih sedemikian rupa sehingga mesin dapat memulai dan mempertahankan fungsionalitas minimal bahkan selama boot darurat (atau dalam mode pengguna tunggal), ketika semua sistem file lainnya tidak dipasang (dan, karenanya, sistem file root) cabang seperti /usr atau /var mungkin tidak tersedia.

Sesuai dengan ini, permulaan mesin dipastikan oleh file direktori /boot dan /etc. Yang pertama berisi kernel sistem - file yang dapat dieksekusi "tujuan khusus" - dan segala sesuatu yang diperlukan untuk memuatnya: di Linux, misalnya, ini adalah peta sistem (file /etc/System.map), dan di FreeBSD - dapat dimuat modul kernel. Namun, terkadang kernel terletak langsung di root sistem file, dan kemudian direktori /boot mungkin tidak ada sama sekali, dan direktori /modules mungkin dialokasikan untuk modul kernel.

Direktori /etc ditujukan untuk file konfigurasi seluruh sistem yang menentukan kondisi boot. Kontennya sangat bergantung pada sistem (dan di Linux, juga pada distribusinya), dan oleh karena itu saya tidak akan mempertimbangkannya di sini - saya harus kembali ke topik ini lebih dari sekali.

Fungsionalitas minimum yang diperlukan disediakan oleh konten direktori /bin dan /sbin - direktori tersebut berisi file yang dapat dieksekusi dari program pengguna dan sistem yang paling penting, masing-masing, yang memungkinkan Anda melakukan serangkaian tindakan perbaikan dan penyelamatan dan membawa mesin kembali ke bentuk manusia setelah kegagalan.

Distribusi program sistem dan pengguna ke dalam subdirektori root cukup sewenang-wenang. Tak satu pun dari perintah ini yang benar-benar dimaksudkan untuk menyelesaikan masalah pengguna. Hanya saja direktori /bin berisi perintah-perintah administrasi yang diakses (atau dapat diakses) oleh pengguna biasa dari waktu ke waktu, dan direktori sbin ditujukan untuk perintah-perintah yang tidak seharusnya diketahui oleh pengguna. Dan yang, dalam banyak kasus, masih tidak dapat dia gunakan karena kurangnya izin yang sesuai (misalnya, hak akses yang diperlukan ke file perangkat).

Untuk menjalankan program POSIX (termasuk yang dikumpulkan di direktori /bin dan sbin), sebagai aturan, Anda memerlukan akses ke fungsi perpustakaan seluruh sistem (terutama perpustakaan glibc utama). Dan oleh karena itu (hampir) komponen yang sangat diperlukan dari direktori root adalah subdirektori /lib, tempat mereka dikumpulkan.

Di Linux, direktori /lib memiliki tujuan penting lainnya - subdirektorinya (/lib/modules) berisi modul kernel yang dapat dimuat (di FreeBSD tempatnya adalah direktori /boot/kernel).

Di FreeBSD, direktori /lib tidak ditemukan di sistem file root - komponen terkait terletak di sini di /usr/lib (lihat di bawah). Hal ini karena, secara historis, FreeBSD membangun program-program penting di seluruh sistem sehingga fungsi-fungsi perpustakaan yang diperlukan dibangun ke dalam executable-nya (dikenal sebagai tautan statis, dibahas di Bab 14). Di FreeBSD cabang 5, program dari direktori /bin dan /sbin dihubungkan secara dinamis, yaitu, jika tidak ada direktori /usr (dan di Free ini hampir selalu merupakan cabang terpisah dari sistem file), program tersebut tidak berfungsi . Untuk mengimbangi hal ini, direktori /restore non-standar disediakan, berisi program yang sama, tetapi terhubung secara statis (sesuai dengan nama direktori, satu-satunya tujuan isinya adalah pekerjaan penyelamatan darurat).

Dan akhirnya /root . Ini adalah direktori home biasa dari pengguna dengan nama yang sama, yaitu administrator sistem. Karena tidak kerja praktek tidak (atau setidaknya tidak seharusnya), isinya hanyalah file konfigurasi pengguna super itu sendiri (shell perintah pengguna, editor favorit, dll.).

Cabang /usr

Secara historis, direktori /usr ditujukan untuk program dan data pengguna. Fungsi-fungsi ini sekarang terbagi antara direktori /usr/local dan /home (walaupun direktori /home masih berupa symlink ke /usr/home secara default di FreeBSD). Direktori /usr tidak dapat diubah, tetapi dibagikan, dan berfungsi sebagai tempat penyimpanan untuk bagian utama program aplikasi dan segala sesuatu yang berhubungan dengannya - kode sumber, file konfigurasi, perpustakaan bersama, dokumentasi dan sejenisnya.

Komposisi direktori /usr berbeda secara signifikan antara sistem BSD dan Linux. Yang pertama hanya menampung bagian-bagian integral dari sistem operasi (yang di FreeBSD disatukan oleh konsep Distribusi). Aplikasi yang diinstal dari port atau paket terdaftar di subdirektori /usr/local, yang dapat mewakili cabang terpisah dari pohon file.

Di Linux, direktori /usr berfungsi sebagai tempat penyimpanan semua program (dan komponennya) yang secara standar disertakan dalam distribusi. Dan subdirektori /usr/local biasanya ditujukan untuk program yang dikompilasi secara independen dari sumbernya.

Bagaimanapun, komposisi direktori /usr yang biasa adalah sebagai berikut (sebagai output dari perintah ls -1):

X11R6/ bin/ dll/ sertakan/ lib/ libexec/ lokal/ sbin/ bagikan/ src/

Seperti telah disebutkan, subdirektori /usr/local adalah cabang terpisah dari pohon file, dan oleh karena itu akan dipertimbangkan secara terpisah. Tujuan dari direktori lain adalah sebagai berikut:

• /usr/bin dan /usr/sbin ditujukan untuk file yang dapat dieksekusi dari program pengguna dan sistem (di sini batas di antara keduanya bahkan lebih sewenang-wenang daripada dalam kasus direktori root), yang tujuannya lebih dari sekadar memastikan fungsi dasar dari sistem;
• /usr/etc untuk file konfigurasi aplikasi individual;
• /usr/include berisi apa yang disebut file header yang diperlukan untuk menghubungkan file yang dapat dieksekusi dengan komponen perpustakaan;
• /usr/lib dan /usr/libexec adalah direktori untuk perpustakaan bersama yang menjadi tempat bergantungnya aplikasi pengguna;
• /usr/share - wadah untuk berbagai macam hal yang disebut. komponen yang independen secara arsitektur: di sini Anda dapat melihat dokumentasi dalam berbagai format, contoh file konfigurasi, data yang digunakan oleh program manajemen konsol (font, tata letak keyboard), dan deskripsi zona waktu;
• /usr/src - direktori untuk kode sumber; di Linux, biasanya hanya kode sumber kernel sistem yang ditempatkan di sini, sedangkan di klon BSD - set lengkap kode sumber kompleks, yang di FreeBSD disebut Distribusi; Sebagai aturan, tidak disarankan untuk menempatkan kode sumber program yang dirakit sendiri di sini;
• /usr/X11R6 - direktori untuk komponen sistem X window - file yang dapat dieksekusi (/usr/X11R6/bin), perpustakaan (/usr/X11R6/lib), header (/usr/X11R6/include), dokumentasi (/usr/ X11R6/ laki-laki); File aplikasi X tidak boleh ditempatkan di sini (dengan kemungkinan pengecualian pengelola jendela) - tempatnya di /usr, /usr/local atau /opt, tergantung pada sistemnya.

Selain itu, direktori /usr mungkin berisi subdirektori /usr/var dan /usr/tmp - biasanya tautan simbolik ke cabang terkait dari direktori root. Dan di beberapa distribusi Linux, dokumentasi utama seluruh sistem - halaman manual (di subdirektori /usr/man) ditempatkan langsung di /usr.

Terakhir, pada sistem BSD dan beberapa distribusi Linux Berbasis Sumber (misalnya, Gentoo), direktori /usr berisi subdirektori untuk sistem manajemen paket - port FreeBSD dan OpenBSD (/usr/ports), analognya pada sistem lain (/usr /portage di Gentoo). Meskipun dari sudut pandang mengikuti isi dan semangat standar FHS (standar itu sendiri tidak menyebutkan sepatah kata pun tentang port dan sistem serupa), tempat yang lebih logis untuk penempatannya adalah direktori /var (lihat di bawah) - dan inilah yang dilakukan di distribusi seperti CRUX dan Archlinux.

Cabang /usr/local

Seperti yang telah disebutkan, cabang /usr/local di Linux ditujukan untuk program yang dikompilasi secara independen dari kode sumber (tidak termasuk dalam distribusi ini). Dan di FreeBSD, ini berfungsi sebagai wadah untuk sebagian besar aplikasi pengguna - hampir semua yang melampaui Distribusi dan diinstal dari paket atau port. Oleh karena itu, struktur direktori secara keseluruhan mengikuti struktur cabang /usr (dengan pengecualian yang jelas):

Bin/ dll/ sertakan/ lib/ man/ sbin/ bagikan/

Isi subdirektori juga serupa: file program yang dapat dieksekusi (/usr/local/bin dan /usr/local/sbin), konfigurasinya (/usr/local/etc), perpustakaan yang terhubung dengannya, dan file headernya (/usr/ local/lib dan /usr/local/include , masing-masing), halaman manual (/usr/local/man) dan segala macam hal yang tidak bergantung pada arsitektur (/usr/local/share), termasuk dokumentasi dalam format lain .

Cabang / pilih

Direktori /opt disediakan oleh standar FHS, namun sebenarnya tidak digunakan di semua distribusi Linux, dan sama sekali tidak ada di sistem BSD. Namun, semakin banyak program yang ditulis dengan mempertimbangkan instalasi default.

Secara historis, direktori /opt ditujukan di Linux untuk aplikasi komersial dan semua jenis program yang tidak sepenuhnya gratis. Saat ini, tujuannya adalah untuk menampung kompleks perangkat lunak mandiri yang besar, seperti perpustakaan Qt, KDE dengan semua komponen dan aplikasinya, OpenOffice.org dan sejenisnya. Struktur direktori harus seperti ini: /opt/pkg_name. Ini adalah tampilannya di sistem saya (Archlinux):

$ ls -1 /memilih gnome/ kde/ OpenOffice.org1.1.2/ qt/

Masing-masing subdirektori memiliki struktur internalnya sendiri:

$ ls -1 /opt/* /opt/gnome: bin/ lib/ man/ share/ /opt/kde: bin/ dll/ sertakan/ lib/ share/ /opt/OpenOffice.org1.1.2: bantuan/ LISENSI LISENSI. program html/ README README.html setup@ share/ spadmin@ THIRDPARTYLICENSEREADME.html pengguna/ /opt/qt: bin/ doc/ include/ lib/ mkspecs/ buku frasa/ plugin/ templat/ terjemahan/

Tujuan dari subdirektori di dalam /opt/pkg_name mudah ditebak dengan analogi dengan /usr dan /usr/local. Misalnya, /opt/kde/bin untuk file executable sistem KDE dan aplikasinya, /opt/kde/etc untuk file konfigurasinya, /opt/kde/include untuk file header, /opt/kde/lib adalah untuk perpustakaan dan /opt/kde/share - untuk file bersama, termasuk dokumentasi. KDE tidak memiliki dokumentasi dalam format man, tetapi jika memang ada, maka (seperti dalam kasus Gnome - saya tidak menginstalnya, inilah yang ditarik oleh Gimp dan aplikasi Gtk serupa) Anda dapat melihat subdirektori /opt/pkg_name/ pria .

Anda dapat melihat bahwa struktur direktori /opt menyimpang dari tradisi POSIX historis (dan dibenarkan secara internal dalam menggabungkan komponen serupa ke dalam direktori - file yang dapat dieksekusi, perpustakaan, dll. Dan dengan sejumlah besar program yang diinstal di dalamnya, itu menciptakan tertentu kesulitan: Anda harus membebani variabel dengan nilai $PATH , yang menyediakan akses cepat ke perintah (yang akan dibahas di Bab 12), atau membuat direktori /opt/bin khusus dan menempatkan tautan simbolik ke biner program yang dapat dieksekusi di dalamnya. Oleh karena itu, di sejumlah distribusi Linux (misalnya, di CRUX), direktori /.opt pada prinsipnya tidak digunakan, seperti halnya di semua sistem BSD, sangat mungkin lebih baik...

/var cabang

Sesuai dengan namanya, direktori /var dimaksudkan untuk menyimpan file yang dapat diubah yang dihasilkan selama operasi normal berbagai program - cache perangkat lunak (misalnya, browser), file log, spooling cetak dan sistem email, kotak surat, deskripsi proses yang berjalan, dan sebagainya. Secara khusus, di direktori /var lah apa yang disebut dump ditempatkan - cuplikan status RAM, yang dihasilkan selama pematian tidak normal untuk mengidentifikasi penyebabnya. Ciri khas dari semua komponen ini adalah sifatnya yang dapat diubah selama sesi kerja dan fakta bahwa komponen tersebut, bagaimanapun, harus dipertahankan ketika sistem di-boot ulang.

Struktur internal /var sangat bervariasi dari satu sistem ke sistem lainnya, dan oleh karena itu saya tidak akan membahas detail strukturnya. Saya hanya akan mencatat bahwa direktori ini adalah tempat yang logis untuk menempatkan komponen dari semua jenis sistem manajemen paket mirip port, seperti yang dilakukan, misalnya, dalam distribusi Archlinux, di mana subdirektori /var/abs dicadangkan untuknya (abs - Sistem Bangunan Archlinux).

Direktori / mnt

Direktori /mnt dimaksudkan untuk memasang sistem file yang digunakan sementara, biasanya terletak pada media yang dapat dipindahkan. Dalam sistem yang terinstal penuh, biasanya kosong, dan strukturnya tidak diatur dengan cara apa pun. Pengguna bebas membuat subdirektori di dalamnya untuk masing-masing jenis media. Misalnya, di sistem saya ini adalah /mnt/cd, /mnt/dvd, /mnt/usb dan /mnt/hd - untuk CD, DVD, flash drive, dan hard drive yang dapat dilepas.

Di FreeBSD, direktori default untuk pemasangan CD dan floppy disk adalah /cdrom dan /floppy langsung di direktori root. Yang tidak sepenuhnya konsisten dengan standar, tetapi logis dengan caranya sendiri - root berisi titik pemasangan perangkat yang ada (seperti CD ROM) atau yang sampai saat ini ada (floppy drive) di mesin mana pun.

Cabang / rumah

Direktori /home dimaksudkan untuk memuat direktori home pengguna. Kontennya tidak diatur dengan cara apa pun, tetapi biasanya terlihat seperti /home/(username1,...,username#) . Meskipun pada sistem besar dengan banyak pengguna, direktori home mereka dapat dikelompokkan bersama.

Direktori /home dapat berisi direktori home tidak hanya pengguna nyata, tetapi juga beberapa pengguna virtual. Jadi, jika mesin digunakan sebagai server web atau ftp, Anda dapat melihat subdirektori seperti /home/www atau /home/ftp.

Cabang /tmp

Satu-satunya hal yang perlu dibicarakan adalah direktori untuk menyimpan file-file sementara - /tmp. Seperti komponen /var, komponen tersebut dihasilkan berbagai program dalam menjalankan aktivitas kehidupan normalnya. Namun, tidak seperti /var , komponen /tmp tidak diharapkan disimpan di luar sesi saat ini. Apalagi semua manual administrasi sistem Disarankan untuk membersihkan direktori ini secara berkala (misalnya saat mesin dihidupkan ulang) atau secara berkala. Oleh karena itu, sebagai /tmp, disarankan untuk memasang sistem file di RAM - tmpfs (di Linux) atau mfs (di FreeBSD). Selain memastikan bahwa isinya dibersihkan saat reboot, ini juga meningkatkan kinerja, misalnya kompilasi program yang produk sementaranya tidak ditulis ke disk, tetapi ditempatkan di direktori virtual seperti /tmp/obj.

Pada banyak sistem Anda akan melihat direktori seperti /usr/tmp dan /var/tmp. Ini biasanya berupa tautan simbolik ke /tmp.

Strategi partisi sistem file

Sebagai penutup percakapan tentang hierarki file, perlu ditekankan bahwa dijamin hanya direktori yang tercantum dalam paragraf yang boleh ditempatkan pada satu sistem file (secara kiasan, pada satu partisi disk, meskipun ini tidak sepenuhnya akurat) Sistem file akar. Semua direktori lain - /usr, /opt, /var, /tmp dan, tentu saja, /home dapat mewakili titik mount untuk sistem file independen pada media fisik terpisah atau partisinya.

Apalagi di jaringan lokal Direktori ini mungkin terletak bahkan pada mesin yang berbeda. Jadi, satu komputer yang bertindak sebagai server aplikasi dapat berisi direktori /usr dan /opt yang dibagikan di jaringan, komputer lain - server file - dapat berisi semua direktori home pengguna, dan seterusnya.

Yang tersisa hanyalah memutuskan sistem file mana yang sesuai untuk diisolasi dari pohon file umum, dan mengapa melakukan hal ini. Jawaban atas pertanyaan-pertanyaan ini sangat bergantung pada OS yang digunakan, dan dalam kasus Linux, juga pada distribusinya. Namun demikian, prinsip-prinsip umum untuk memisahkan sistem file dapat diuraikan. Oleh karena itu, kita harus mengingat perbedaan antara, di satu sisi, direktori yang tidak dapat diubah dan dapat diubah, dan di sisi lain, data yang mudah dipulihkan, sulit dipulihkan, dan praktis tidak dapat dipulihkan. Mari kita lakukan upaya ini sehubungan dengan desktop pengguna - dalam kasus server, penghitungannya akan sangat berbeda.

Jelasnya, sistem file root, yang terdiri dari direktori /bin, /boot, /etc, /root, /sbin, berisi data yang dapat dengan mudah dipulihkan dari media distribusi dan praktis tidak dapat diubah, harus ditempatkan pada partisi disk yang terisolasi. . Di Linux, ini juga harus menyertakan direktori /lib. Di sisi lain, ketika menggunakan GRUB sebagai bootloader (apa pun sistem operasinya), disarankan untuk menempatkan direktori /boot pada partisi terpisah.

Di sumber-sumber lama tentang Linux, Anda dapat membaca tentang alasan lain untuk mengalokasikan partisi untuk direktori /boot, dan di awal disk: karena ketidakmungkinan memuat kernel oleh program Lilo dari nomor silinder yang lebih tinggi dari 1023 . Dalam bootloader versi modern tidak ada batasan seperti itu. Namun, jika partisi untuk /boot sudah dibuat, masuk akal untuk menjadikannya yang pertama pada disk, dan menempatkan partisi swap tepat di belakangnya: ini akan menambah lima sen kinerja saat melakukan swapping.

Dan satu hal lagi dari bidang sejarah: persyaratan bahwa partisi root dan boot harus menjadi yang utama juga telah dihapus sejak lama. Dan sistem file ini mungkin cocok dengan partisi logis di dalam Partisi Diperluas.

Jelas juga bahwa cabang sistem file yang dapat dimodifikasi - direktori /var dan /tmp - harus dipindahkan ke luar partisi root. Selain itu, yang terakhir, seperti yang telah dikatakan berkali-kali sebelumnya, umumnya disarankan untuk menempatkannya pada sistem file dalam RAM (tmpfs atau mfs). Jika direktori /var berisi subdirektori untuk sistem manajemen paket mirip port, seperti /var/abs , /var/cache/pacman/src dan /var/cache/pacman/pkg di Archlinux, ini juga harus membentuk sistem file terpisah

Sekarang - direktori /usr, berisi komponen sistem dasar (seperti di BSD), atau sebagian besar aplikasi pengguna (seperti di sebagian besar distribusi Linux). Ini berisi data yang mudah dipulihkan dan, sejujurnya, secara praktis tidak dapat diubah, dan oleh karena itu, tentu saja, layak untuk disorot dalam bagian terpisah. Selain itu, dari komposisinya disarankan untuk mengisolasi, di satu sisi, subdirektori /usr/X11R6 dan /usr/local, di sisi lain - subdirektori untuk sistem manajemen paket mirip port: /usr/ports, /usr/pkgsrc dan /usr/pkg di sistem BSD, /usr/portages di Gentoo Linux, dan seterusnya. Selain itu, yang terakhir harus dipisahkan menjadi subdirektori untuk menempatkan sumber yang diunduh dari jaringan saat membangun port - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles dan sejenisnya.

Selain itu, dalam sistem BSD, dari direktori /usr masuk akal untuk memilih subdirektori /usr/src dan /usr/obj yang berisi kode sumber komponen dasar (termasuk kernel) dan produk antara kompilasinya, dibentuk sebagai hasil dari make buildworld dan prosedur make buildkernel.

Dan terakhir, direktori /home, yang berisi data yang dapat diubah dan seringkali tidak dapat dipulihkan, harus dihapus dari akar hierarki file. Selain itu, saya selalu mencoba meletakkannya di bagian terpisah (di BSD) atau di partisi primer (di Linux).

Skema yang diusulkan untuk memisahkan sistem file mungkin tampak terlalu rumit. Namun, ini menjamin isolasi data yang mudah dipulihkan, sulit dipulihkan, dan tidak dapat dipulihkan, yang akan memfasilitasi instalasi ulang sistem jika terjadi keadaan darurat, dan bahkan migrasi dari satu sistem ke sistem lainnya.

Keuntungan tambahannya adalah untuk masing-masing cabang pohon file, tergantung pada sifat data yang ada di dalamnya, di Linux Anda dapat memilih sistem file yang optimal secara fisik. Misalnya, untuk partisi /boot tidak ada gunanya menggunakan apa pun selain Ext2fs. Biasanya disarankan untuk memformat partisi root dalam Ext3fs yang andal dan paling kompatibel. Untuk direktori dengan banyak file kecil, seperti /var/abs di Archlinux, /usr/portages di Gentoo, disarankan untuk menggunakan ReiserFS: lagipula, penanganan file kecil yang terampil adalah profilnya. Dan di direktori /home, di mana file multimedia berukuran besar dapat muncul (dan biasanya berukuran sangat besar), XFS mungkin berguna (walaupun, seperti yang ditunjukkan oleh pengukuran, ReiserFS terlihat cukup baik di sini). Langkah-langkah tersebut dapat membantu meningkatkan keandalan penyimpanan data dan kecepatan pengoperasian file.

Pengguna sistem operasi BSD terikat pada sistem file FFS tanpa alternatif. Namun, mereka juga punya ruang untuk bermanuver. Pertama, dengan memvariasikan ukuran blok dan fragmen sistem file individual, yang berkontribusi terhadap kinerja operasi disk atau menghemat ruang disk. Dan kedua, beberapa cabang pohon file (seperti /tmp atau /usr/obj, bertentangan dengan rekomendasi, dapat dipasang dengan aman dalam mode asinkron murni, sehingga memperoleh kinerja satu atau dua persentase.

- (IPAEng|ˈpɒzɪks) atau Antarmuka Sistem Operasi Portabel mengutip web | judul = POSIX | url = http://standards.ieee.org/regauth/posix/ | pekerjaan = Standar | penerbit = IEEE] adalah nama kolektif dari keluarga standar terkait yang ditentukan oleh IEEE ... Wikipedia

POSIX- ini adalah nama keluarga standar yang ditetapkan pada tahun 1988 oleh Institut Insinyur Listrik dan Elektronika dan formulir yang dirancang IEEE 1003. Standar ini muncul dalam proyek standardisasi API logika yang ditakdirkan à… … Wikipédia en Français

posix- ini adalah nama keluarga standar definie depuis 1988 par l IEEE et formellement désignée IEEE 1003. Standar ini muncul dalam proyek standardisasi API logika yang dirancang untuk berfungsi pada varian sistem… … Wikipédia en Français

POSIX- adalah akronim dari Antarmuka Sistem Operasi Portabel; X viene de UNIX sama seperti identitas API. Terminal ini dikontrol oleh Richard Stallman sebagai respons atas permintaan IEEE, yang menghasilkan sejumlah rekaman yang mudah. Sebuah perdagangan… Wikipedia bahasa Spanyol

POSIX- , 1986 dalam Standar 1003.1 dari IEEE yang tidak terdaftar Spesifikasinya untuk Zugriffe dan Fungsi Sistem di Unix. Sowohl Unix Sy…Universal-Lexikon

POSIX- status standar dari T sritis informatika apibrėžtis Standartų grupė, apibrėžianti operacinės sistemos sąsajas tarp joje veikiančių programų bei tarnybų. Pirmuosius standart sukūrė Elektros ir elektronikos inžinierių institutas (IEEE) Linux… … Enciklopedinis kompiuterijos žodynas

POSIX- adalah singkatan dari Portable Operating System Interface, yang mewakili X de UNIX dengan arti penting dari API (Jika diterjemahkan sebagai Sistem Operasi Portabel berbasis UNIX). Ini adalah familia de standares de llamadas al sistema… … Ensiklopedia Universal

POSIX- (Antarmuka Sistem Operasi Portabel berbasis unix) n. kumpulan standar sistem operasi yang berbasis Unix (Komputer) ... kamus bahasa inggris kontemporer

POSIX

posix- Antarmuka Sistem Operasi Portabel (POSIX [ˈpɒsɪks]) merupakan salah satu standar dari IEEE dan Open Group untuk Unix yang memiliki standar Antarmuka Pemrograman Aplikasi, yang merupakan dasar dari Aplikasi dan mereka… … Wikipedia bahasa Jerman

Buku

• , Stephen A.Rago, W.Richard Stevens. "UNIX. Pemrograman Profesional" adalah panduan referensi terperinci yang selama 20 tahun telah membantu programmer C profesional menulis secara eksklusif...
• UNIX. Pemrograman Profesional oleh Stevens W. Richard, Rago Steven A. Buku ini sangat populer di kalangan programmer serius di seluruh dunia karena berisi informasi paling penting dan praktis tentang pengelolaan kernel UNIX dan Linux. Tanpa ini...

Kursus ini mencakup standar antarmuka sistem operasi seluler (POSIX), serta teknik dan metode pemrograman aplikasi berdasarkan standar ini, dijelaskan dengan banyak contoh. Masalah pemrograman sistem multiproses dan interaksi aplikasi dalam konfigurasi terdistribusi telah diatasi. Memastikan mobilitas (portabilitas) perangkat lunak adalah tugas yang sangat penting dan rumit; di zaman kita, keadaan ini hampir tidak memerlukan pembenaran yang panjang. Salah satu cara yang diterima secara umum untuk meningkatkan portabilitas perangkat lunak adalah dengan menstandarisasi lingkungan aplikasi: antarmuka perangkat lunak yang disediakan, utilitas, dll. Pada tingkat layanan sistem, lingkungan seperti itu dijelaskan oleh standar POSIX (Portable Operating System Interface - antarmuka sistem operasi seluler); Nama tersebut disarankan oleh spesialis terkenal, pendiri Free Software Foundation, Richard Stallman.

Kursus ini mengkaji versi paling modern, sebagaimana diubah pada tahun 2003, yang dapat disebut sebagai “standar rangkap tiga”, yaitu: standar IEEE Std 1003.1, Standar Teknis Grup Terbuka dan, yang paling penting bagi kami, standar internasional ISO/IEC 9945 . Tugas pokok Mata kuliah ini adalah memahami teknik dan metode penggunaan utilitas dan fungsi yang terstandarisasi. Tujuannya bukan untuk menceritakan kembali standar, menyoroti semua seluk-beluk implementasi OS, semua kemungkinan kode kesalahan, dll. Hal utama, menurut kami, adalah merasakan semangat standar dan belajar menggunakan kemampuan yang melekat di dalamnya secara mobile. Dengan asumsi bahwa pembaca berbicara bahasa C, kami tidak mempertimbangkan sintaksis atau fungsi perpustakaan buku teksnya. Adapun bahasa perintah standar dan penerjemahnya, topik ini disajikan secara rinci, meskipun banyak pemrogram yang berlatih lebih suka menggunakan penerjemah lain. Tempat penting - baik dalam volume maupun peran - dikhususkan untuk contoh program. Banyak ketentuan standar (terkait, misalnya, dengan penanganan situasi kesalahan) tidak ditetapkan dalam teks utama, tetapi dalam contoh terkait, bila memungkinkan, dikompilasi dan dijalankan pada beberapa platform perangkat keras dan perangkat lunak yang, menjadi satu derajat atau lainnya, mengklaim mematuhi standar POSIX. Namun, kekeliruan tentu saja mungkin terjadi. Kami akan berterima kasih atas semua komentar dan saran terkait kursus secara keseluruhan dan contoh program individual.

Sejarah pembuatan dan status standar POSIX saat ini.

Memastikan mobilitas (portabilitas) perangkat lunak adalah tugas yang sangat penting dan rumit; di zaman kita, keadaan ini hampir tidak memerlukan pembenaran yang luas. Salah satu cara yang diterima secara umum untuk meningkatkan portabilitas perangkat lunak adalah dengan menstandarisasi lingkungan aplikasi: menyediakan antarmuka perangkat lunak, utilitas, dll. Pada tingkat layanan sistem, lingkungan seperti itu dijelaskan oleh standar POSIX (Portable Operating System Interface - antarmuka sistem operasi seluler); Nama tersebut diusulkan oleh spesialis terkenal, pendiri Free Software Foundation, Richard Stallman.

Halaman judul.
Data keluaran.
Kuliah 1. Konsep dasar dan ide standar POSIX.
Kuliah 2. Bahasa shell.
Kuliah 3. Utilitas dan fungsi yang melayani konsep "pengguna".
Kuliah 4. Organisasi sistem file.
Kuliah 5. Input/output file.
Kuliah 6. Alat untuk mengolah data terstruktur.
Kuliah 7. Proses.
Kuliah 8. Alat komunikasi antarproses.
Kuliah 9. Antarmuka terminal umum.
Kuliah 10. Survei karakteristik host dan penggunaannya dalam aplikasi.
Kuliah 11. Alat jaringan.
Kuliah 12. Waktu dan cara mengatasinya.
Kuliah 13. Lingkungan linguistik dan budaya.
Kuliah 14. Kesimpulan.
Referensi.

Unduhan gratis buku elektronik dalam format yang nyaman, tonton dan baca:
Unduh buku Pemrograman dalam standar POSIX, bagian 1, Galatenko V.A., 2016 - fileskachat.com, unduh cepat dan gratis.