Penjelasan awam untuk "Semuanya adalah file" - apa yang berbeda dari Windows?

Saya tahu bahwa "Semuanya adalah file" berarti bahwa perangkat bahkan memiliki nama file dan jalurnya di sistem mirip Unix dan Unix, dan ini memungkinkan alat umum digunakan pada berbagai sumber daya terlepas dari sifatnya. Tapi saya tidak bisa membandingkannya dengan Windows, satu-satunya OS yang pernah saya gunakan. Saya telah membaca beberapa artikel tentang konsep ini, tetapi saya pikir mereka agak tidak nyaman untuk dipahami oleh non-pengembang. Penjelasan orang awam adalah apa yang orang butuhkan!

Misalnya, ketika saya ingin menyalin file ke kartu CF yang dilampirkan ke pembaca kartu, saya akan menggunakan sesuatu seperti

zcat name_of_file > /dev/sdb

Di Windows, saya pikir pembaca kartu akan muncul sebagai driver, dan kami akan melakukan hal serupa, saya pikir. Jadi, bagaimana filosofi "Semuanya adalah file" membuat perbedaan di sini?

"Semuanya adalah file" sedikit glib. "Segala sesuatu muncul di suatu tempat di sistem file " lebih dekat dengan tanda, dan bahkan kemudian, itu lebih ideal daripada hukum desain sistem.

Sebagai contoh, soket domain Unix bukan file, tetapi mereka muncul di sistem file. Anda dapat ls -lsoket domain untuk menampilkan atributnya, catdata ke / dari satu, memodifikasi kontrol aksesnya melalui chmod, dll.

Tetapi, meskipun soket jaringan TCP / IP reguler dibuat dan dimanipulasi dengan panggilan sistem soket BSD yang sama dengan soket domain Unix, soket TCP / IP tidak muncul dalam sistem file, ¹ meskipun tidak ada alasan khusus yang kuat bahwa ini seharusnya benar.

Contoh lain dari benda-benda non-berkas yang muncul dalam filesystem adalah Linux /procfilesystem . Fitur ini memperlihatkan banyak detail tentang operasi run-time kernel ke ruang pengguna , sebagian besar sebagai file teks biasa virtual. Banyak /procentri yang hanya baca, tetapi banyak /procjuga yang dapat ditulisi, sehingga Anda dapat mengubah cara sistem berjalan menggunakan program apa pun yang dapat memodifikasi file. Sayangnya, di sini sekali lagi kita memiliki non-formalitas: tipe BSD Unix umumnya berjalan tanpa/proc , dan System V Unixes mengekspos jauh lebih sedikit /procdaripada Linux.

Saya tidak bisa membandingkannya dengan MS Windows

Pertama, sebagian besar sentimen yang dapat Anda temukan online dan di buku-buku tentang Unix tentang semua file I / O dan Windows yang "rusak" dalam hal ini sudah usang. Windows NT memperbaiki banyak hal ini.

Versi Windows modern memiliki sistem I / O terpadu, seperti halnya Unix, sehingga Anda dapat membaca data jaringan dari soket TCP / IP melalui ReadFile()API khusus dari Soket Windows WSARecv(), jika Anda mau. Ini persis dengan Paralel Unix Way , di mana Anda dapat membaca dari soket jaringan dengan read(2)panggilan sistem Unix umum atau panggilan khusus soket. recv(2)²

Namun demikian, Windows masih gagal untuk mengambil konsep ini ke tingkat yang sama dengan Unix, bahkan di sini pada tahun 2018. Ada banyak area arsitektur Windows yang tidak dapat diakses melalui sistem file, atau yang tidak dapat dilihat sebagai file-like. Beberapa contoh:

1. Driver.

   Subsistem driver Windows dengan mudah dan sekuat Unix, tetapi untuk menulis program untuk memanipulasi driver, Anda umumnya harus menggunakan Windows Driver Kit , yang berarti menulis kode C atau .NET.

   Pada tipe OS Unix, Anda dapat melakukan banyak hal untuk driver dari baris perintah. Anda hampir pasti sudah melakukan ini, jika hanya dengan mengarahkan output yang tidak diinginkan ke /dev/null.³

2. Komunikasi antar program.

   Program Windows tidak berkomunikasi dengan mudah satu sama lain.

   Program baris perintah Unix berkomunikasi dengan mudah melalui aliran teks dan pipa. Program GUI sering dibangun di atas program baris perintah atau mengekspor antarmuka perintah teks, sehingga mekanisme komunikasi berbasis teks yang sama juga bekerja dengan program GUI.

3. Registri.

   Unix tidak memiliki padanan langsung dengan registri Windows. Informasi yang sama tersebar melalui sistem file, sebagian besar di dalamnya /etc, /procdan /sys.

Jika Anda tidak melihat bahwa driver, pipa, dan jawaban Unix untuk registri Windows ada hubungannya dengan "semuanya adalah file," baca terus.

Bagaimana filosofi "Semuanya adalah file" membuat perbedaan di sini?

Saya akan menjelaskan bahwa dengan memperluas tiga poin saya di atas, secara rinci.

Jawaban panjang, bagian 1: Drive vs File Perangkat

Katakanlah pembaca kartu CF Anda muncul di E:bawah Windows dan /dev/sdcdi Linux. Apa perbedaan praktis yang dihasilkannya?

Ini bukan hanya perbedaan sintaksis kecil.

Di Linux, saya bisa mengatakan dd if=/dev/zero of=/dev/sdcuntuk menimpa isi /dev/sdcdengan nol.

Pikirkan apa artinya itu sejenak. Di sini saya memiliki program ruang pengguna normal ( dd(1)) yang saya minta untuk membaca data dari perangkat virtual ( /dev/zero) dan menulis apa yang dibacanya ke perangkat fisik nyata ( /dev/sdc) melalui sistem file Unix yang disatukan. ddtidak tahu itu membaca dari dan menulis ke perangkat khusus. Ini akan bekerja pada file biasa juga, atau pada campuran perangkat dan file, seperti yang akan kita lihat di bawah ini.

Tidak ada cara mudah untuk mem-nolkan E:drive pada Windows, karena Windows membuat perbedaan antara file dan drive, jadi Anda tidak dapat menggunakan perintah yang sama untuk memanipulasi mereka. Cara terdekat yang bisa Anda dapatkan adalah melakukan format disk tanpa opsi Quick Format, yang memberikan nol pada sebagian besar konten drive, tetapi kemudian menulis sistem file baru di atasnya. Bagaimana jika saya tidak menginginkan sistem file baru? Bagaimana jika saya benar-benar ingin disk diisi dengan nol?

Mari kita bermurah hati dan katakan bahwa kita benar-benar menginginkan sistem file baru E:. Untuk melakukan itu dalam program di Windows, saya harus memanggil API pemformatan khusus. ⁴ Di Linux, Anda tidak perlu menulis program untuk mengakses fungsionalitas "format disk" OS. Anda hanya menjalankan program ruang pengguna yang sesuai untuk jenis filesystem yang ingin Anda buat: mkfs.ext4, mkfs.xfs, atau apa pun. Program-program ini akan menulis sistem file ke file atau /devnode apa pun yang Anda lewati.

Karena mkfsprogram jenis pada sistem Unixy bekerja pada file tanpa membuat perbedaan buatan antara perangkat dan file normal, itu berarti saya dapat membuat sistem file ext4 di dalam file normal pada kotak Linux saya:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

Itu benar-benar membuat gambar disk 1 MiB di direktori saat ini, disebut myfs. Saya kemudian dapat memasangnya seolah-olah itu adalah sistem file eksternal lainnya:

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

Sekarang saya memiliki image disk ext4 dengan file yang disebut my-passwd-entrydi dalamnya yang berisi /etc/passwdentri pengguna saya .

Jika saya mau, saya dapat meledakkan gambar itu ke kartu CF saya:

$ sudo dd if=myfs of=/dev/sdc1

Atau, saya dapat mengemas gambar disk tersebut, mengirimkannya kepada Anda, dan membiarkan Anda menulisnya ke media yang Anda pilih, seperti stik memori USB:

$ gzip myfs
$ echo "Here's the disk image I promised to send you." | 
  mutt -a myfs.gz -s "Password file disk image" [email protected]

Semua ini dimungkinkan di Linux⁵ karena tidak ada perbedaan artifisial antara file, sistem file, dan perangkat. Banyak hal pada sistem Unix baik adalah file, atau diakses melalui filesystem sehingga mereka terlihat seperti file, atau dalam beberapa cara lain terlihat cukup file seperti itu mereka bisa diperlakukan seperti itu.

Konsep Windows dari sistem file adalah campur aduk; itu membuat perbedaan antara direktori, drive, dan sumber daya jaringan. Ada tiga sintaks yang berbeda, semuanya dicampur bersama di Windows: sistem ..\FOO\BARjalur mirip Unix , seperti huruf kandar C:, dan seperti jalur UNC \\SERVER\PATH\FILE.TXT. Ini karena ini merupakan pertambahan ide dari Unix, CP / M , MS-DOS , dan LAN Manager , daripada desain tunggal yang koheren. Itu sebabnya ada begitu banyak karakter ilegal dalam nama file Windows .

Unix memiliki sistem file terpadu, dengan semua yang diakses oleh satu skema umum. Untuk program yang berjalan pada sebuah kotak Linux, tidak ada perbedaan fungsional antara /etc/passwd, /media/CF_CARD/etc/passwd, dan /mnt/server/etc/passwd. File lokal, media eksternal, dan jaringan berbagi semua diperlakukan dengan cara yang sama.⁶

Windows dapat mencapai ujung yang serupa dengan contoh gambar disk saya di atas, tetapi Anda harus menggunakan program khusus yang ditulis oleh programmer yang tidak biasa. Inilah sebabnya mengapa ada begitu banyak program jenis "DVD virtual" pada Windows . Kurangnya fitur inti OS telah menciptakan pasar buatan untuk program untuk mengisi kesenjangan, yang berarti Anda memiliki banyak orang yang bersaing untuk membuat program jenis DVD virtual terbaik. Kami tidak memerlukan program seperti itu pada sistem * ix, karena kami hanya dapat memasang image disk ISO menggunakan perangkat loop .

Hal yang sama berlaku untuk alat-alat lain seperti program menghapus disk , yang kita juga tidak perlu pada sistem Unix. Ingin konten kartu CF Anda diacak bukan hanya memusatkan perhatian? Oke, gunakan /dev/randomsebagai sumber data alih-alih /dev/zero:

$ sudo dd if=/dev/random of=/dev/sdc

Di Linux, kami tidak terus menciptakan kembali roda seperti itu karena fitur inti OS tidak hanya bekerja cukup baik, mereka bekerja dengan sangat baik sehingga mereka digunakan secara luas. Skema khas untuk mem-boot kotak Linux melibatkan citra disk virtual, hanya untuk satu contoh, dibuat menggunakan teknik seperti yang saya perlihatkan di atas .⁷

Saya merasa itu hanya adil untuk menunjukkan bahwa jika Unix telah terintegrasi TCP / IP I / O ke filesystem dari awal, kita tidak akan memiliki netcatvs socatvs Ncatvs berantakan , penyebabnya dari yang kelemahan desain yang sama yang mengarah pada disk imaging dan proliferasi alat wiping pada Windows: kurangnya fasilitas OS yang dapat diterima.nc

Jawaban Panjang, bagian 2: Pipa sebagai File Virtual

Meskipun berakar pada DOS, Windows tidak pernah memiliki tradisi baris perintah yang kaya.

Ini bukan untuk mengatakan bahwa Windows tidak memiliki baris perintah, atau tidak memiliki banyak program baris perintah. Windows bahkan memiliki shell perintah yang sangat kuat hari ini, tepat disebut PowerShell .

Namun, ada efek mengetuk dari kurangnya tradisi baris perintah ini. Anda mendapatkan alat seperti DISKPARTyang hampir tidak dikenal di dunia Windows, karena kebanyakan orang melakukan partisi disk dan semacamnya melalui snap-in MMC Manajemen Komputer. Kemudian ketika Anda perlu membuat skrip pembuatan partisi, Anda menemukan DISKPARTitu tidak benar-benar dibuat untuk didorong oleh program lain. Ya, Anda dapat menulis serangkaian perintah ke dalam file skrip dan menjalankannya melalui DISKPART /S scriptfile, tetapi semuanya atau tidak sama sekali. Apa yang benar - benar Anda inginkan dalam situasi seperti itu adalah sesuatu yang lebih seperti GNUparted , yang akan menerima perintah tunggal seperti parted /dev/sdb mklabel gpt. Itu memungkinkan skrip Anda untuk melakukan penanganan kesalahan secara bertahap.

Apa hubungannya semua ini dengan "semuanya adalah file"? Mudah: pipa membuat program baris perintah I / O menjadi "file," sejenis. Pipa adalah aliran searah , bukan akses acak seperti file disk biasa, tetapi dalam banyak kasus perbedaannya tidak ada konsekuensinya. Yang penting adalah Anda dapat melampirkan dua program yang dikembangkan secara independen dan membuatnya berkomunikasi melalui teks sederhana. Dalam pengertian itu, dua program apa pun yang dirancang dengan Unix Way dalam pikiran dapat berkomunikasi.

Dalam kasus-kasus di mana Anda benar-benar membutuhkan file, mudah untuk mengubah output program menjadi file:

$ some-program --some --args > myfile
$ vi myfile

Tetapi mengapa menulis output ke file sementara ketika filosofi "semuanya adalah file" memberi Anda cara yang lebih baik? Jika semua yang ingin Anda lakukan adalah membaca output dari perintah itu ke dalam vibuffer editor, vidapat melakukannya untuk Anda secara langsung. Dari vimode "normal", katakan:

:r !some-program --some --args

Itu memasukkan output program ke buffer editor aktif pada posisi kursor saat ini. Di bawah tenda, vimenggunakan pipa untuk menghubungkan output program ke sedikit kode yang menggunakan panggilan OS yang sama yang akan digunakan untuk membaca dari file sebagai gantinya. Saya tidak akan terkejut jika dua kasus :r- yaitu, dengan dan tanpa !- keduanya menggunakan loop pembacaan data generik yang sama di semua implementasi umum vi. Saya tidak bisa memikirkan alasan yang baik untuk tidak melakukannya.

Ini juga bukan fitur terbaru vi; itu jelas kembali ke ed(1)editor teks kuno.⁸

Ide yang kuat ini muncul berulang-ulang di Unix.

Untuk contoh kedua, ingat muttperintah email saya di atas. Satu-satunya alasan saya harus menulis itu sebagai dua perintah terpisah adalah bahwa saya ingin file sementara dinamai *.gz, sehingga lampiran email akan dinamai dengan benar. Jika saya tidak peduli dengan nama file, saya bisa menggunakan proses subtitusi untuk menghindari membuat file sementara:

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" [email protected]

Itu menghindari sementara dengan mengubah output gzip -cmenjadi FIFO (yang seperti file) atau /dev/fdobjek (yang seperti file). (Bash memilih metode berdasarkan kemampuan sistem, karena /dev/fdtidak tersedia di mana-mana.)

Untuk cara ketiga gagasan hebat ini muncul di Unix, pertimbangkan gdbsistem Linux. Ini adalah debugger yang digunakan untuk perangkat lunak apa pun yang ditulis dalam C dan C ++. Programmer yang datang ke Unix dari sistem lain melihat gdbdan hampir selalu mengeluh tentang itu, "Yuck, ini sangat primitif!" Kemudian mereka mencari debugger GUI, menemukan salah satu dari beberapa yang ada, dan dengan senang hati melanjutkan pekerjaan mereka ... sering kali tidak menyadari bahwa GUI hanya berjalan di gdbbawahnya, menyediakan cangkang yang cantik di atasnya. Tidak ada pesaing tingkat rendah yang bersaing pada sebagian besar sistem Unix karena tidak ada kebutuhan untuk program untuk bersaing di tingkat itu. Yang kita butuhkan adalah satu alat tingkat rendah yang baik yang bisa kita gunakan sebagai dasar alat tingkat tinggi, jika alat tingkat rendah itu berkomunikasi dengan mudah melalui pipa.

Ini berarti kami sekarang memiliki antarmuka debugger yang terdokumentasi yang akan memungkinkan penggantian drop-in gdb, tetapi sayangnya, pesaing utama gdb tidak mengambil jalur gesekan rendah .

Namun, paling tidak mungkin bahwa beberapa gdbpenggantian di masa depan akan turun secara transparan hanya dengan mengkloning antarmuka baris perintahnya. Untuk melakukan hal yang sama pada kotak Windows, pencipta alat yang dapat diganti harus mendefinisikan beberapa jenis plugin formal atau API otomatisasi. Itu berarti itu tidak terjadi kecuali untuk program yang paling populer, karena banyak pekerjaan untuk membangun antarmuka pengguna baris perintah normal dan API pemrograman lengkap.

Keajaiban ini terjadi melalui rahmat IPC berbasis teks meresap .

Meskipun kernel Windows memiliki pipa anonim gaya Unix , sangat jarang melihat program pengguna biasa menggunakannya untuk IPC di luar shell perintah, karena Windows tidak memiliki tradisi menciptakan semua layanan inti dalam versi baris perintah terlebih dahulu, kemudian membangun GUI di secara terpisah. Hal ini menyebabkan tidak dapat melakukan beberapa hal tanpa GUI, yang merupakan salah satu alasan mengapa ada begitu banyak sistem desktop jarak jauh untuk Windows, dibandingkan dengan Linux: Windows sangat sulit digunakan tanpa GUI.

Sebaliknya, sangat umum untuk mengelola kotak Unix, BSD, OS X, dan Linux dari jarak jauh melalui SSH. Dan bagaimana cara kerjanya, Anda bertanya? SSH menghubungkan soket jaringan (yang seperti file) ke pseudo tty at /dev/pty*(yang seperti file). Sekarang sistem jarak jauh Anda terhubung ke jaringan lokal Anda melalui koneksi yang sangat cocok dengan Unix Way sehingga Anda dapat menyalurkan data melalui koneksi SSH , jika perlu.

Apakah Anda mendapatkan gagasan seberapa kuat konsep ini sekarang?

Aliran teks pipa tidak dapat dibedakan dari file dari perspektif program, kecuali bahwa itu searah. Sebuah program membaca dari sebuah pipa dengan cara yang sama seperti membaca dari suatu file: melalui deskriptor file . FD benar-benar inti untuk Unix; fakta bahwa file dan pipa menggunakan abstraksi yang sama untuk I / O pada keduanya harus memberi tahu Anda sesuatu .⁹

Dunia Windows, yang tidak memiliki tradisi komunikasi teks sederhana ini, cocok dengan antarmuka OOP kelas berat melalui COM atau .NET . Jika Anda perlu mengotomatisasi program semacam itu, Anda juga harus menulis program COM atau .NET. Ini sedikit lebih sulit daripada memasang pipa pada kotak Unix.

Program Windows yang tidak memiliki API pemrograman yang rumit ini hanya dapat berkomunikasi melalui antarmuka miskin seperti clipboard atau File / Save diikuti oleh File / Open.

Jawaban Panjang, bagian 3: Registri vs File Konfigurasi

Perbedaan praktis antara registri Windows dan Unix Way dari konfigurasi sistem juga menggambarkan manfaat filosofi "semuanya adalah file".

Pada sistem tipe Unix, saya dapat melihat informasi konfigurasi sistem dari baris perintah hanya dengan memeriksa file. Saya dapat mengubah perilaku sistem dengan memodifikasi file-file yang sama. Sebagian besar, file konfigurasi ini hanyalah file teks biasa, yang berarti saya dapat menggunakan alat apa pun di Unix untuk memanipulasi mereka yang dapat bekerja dengan file teks biasa.

Membuat skrip registri hampir tidak mudah di Windows.

Metode termudah adalah membuat perubahan Anda melalui Registry Editor GUI pada satu mesin, lalu menerapkan perubahanregedit*.reg itu secara membabi buta ke komputer lain dengan melalui file . Itu tidak benar-benar "scripting," karena tidak membiarkan Anda melakukan sesuatu dengan syarat: itu semua atau tidak sama sekali.

Jika perubahan registri Anda memerlukan jumlah logika apa pun, opsi termudah berikutnya adalah mempelajari PowerShell , yang pada dasarnya sama dengan belajar pemrograman sistem .NET. Akan seperti jika Unix hanya memiliki Perl, dan Anda harus melakukan semua administrasi sistem ad hoc melaluinya. Sekarang, saya penggemar Perl, tetapi tidak semua orang. Unix memungkinkan Anda menggunakan alat apa pun yang Anda sukai, asalkan dapat memanipulasi file teks biasa.

Catatan kaki:

1. Plan 9 tetap salah langkah desain ini, mengekspos jaringan I / O melalui para /netvirtual filesystem .

   Bash memiliki fitur yang disebut/dev/tcp yang memungkinkan I / O jaringan melalui fungsi sistem file biasa. Karena ini adalah fitur Bash, bukan fitur kernel, itu tidak terlihat di luar Bash atau pada sistem yang tidak menggunakan Bash sama sekali . Ini menunjukkan, oleh contoh tandingan, mengapa itu adalah ide yang bagus untuk membuat semua sumber data terlihat melalui sistem file.

2. Dengan "Windows modern," maksud saya Windows NT dan semua turunan langsungnya, yang meliputi Windows 2000, semua versi Windows Server, dan semua versi Windows yang berorientasi desktop mulai dari XP dan seterusnya. Saya menggunakan istilah ini untuk mengecualikan versi Windows berbasis DOS, menjadi Windows 95 dan turunan langsungnya, Windows 98 dan Windows ME, plus pendahulunya 16-bit.

   Anda dapat melihat perbedaannya dengan kurangnya sistem I / O terpadu dalam OS-OS terakhir tersebut. Anda tidak dapat melewatkan soket TCP / IP ke ReadFile()Windows 95; Anda hanya dapat meneruskan soket ke Soket Soket Windows. Lihat artikel mani Andrew Schulman, Windows 95: Apa Itu Bukan untuk menyelam lebih dalam ke topik ini.

3. Jangan salah, /dev/nulladalah perangkat kernel nyata pada sistem tipe Unix, bukan hanya nama file yang khusus, seperti yang dangkal setara NULdi Windows.

   Meskipun Windows mencoba untuk mencegah Anda membuat NULfile, dimungkinkan untuk memotong perlindungan ini hanya dengan tipuan , membodohi logika parsing nama file Windows. Jika Anda mencoba mengakses file itu dengan cmd.exeatau Explorer, Windows akan menolak untuk membukanya, tetapi Anda dapat menulis ke sana melalui Cygwin, karena itu membuka file menggunakan metode yang mirip dengan contoh program, dan Anda dapat menghapusnya melalui tipu daya serupa .

   Sebaliknya, Unix akan dengan senang hati membiarkan Anda rm /dev/null, selama Anda memiliki akses tulis /dev, dan membiarkan Anda membuat ulang file baru di tempatnya, semua tanpa tipu daya, karena simpul dev itu hanyalah file lain. Sementara simpul dev itu hilang, perangkat null kernel masih ada; itu hanya tidak dapat diakses sampai Anda membuat ulang dev melalui mknod.

   Anda bahkan dapat membuat simpul dev perangkat nol tambahan di tempat lain: tidak masalah jika Anda memanggilnya /home/grandma/Recycle Bin, asalkan simpul dev untuk perangkat null itu akan berfungsi sama persis dengan /dev/null.

4. Sebenarnya ada dua API "format disk" tingkat tinggi di Windows: SHFormatDrive()dan Win32_Volume.Format().

   Ada dua alasan yang sangat ... baik ... Windows . Yang pertama meminta Windows Explorer untuk menampilkan kotak dialog "Format Disk" yang normal, yang berarti ia bekerja pada versi Windows modern, tetapi hanya ketika pengguna login secara interaktif. Yang lain Anda dapat memanggil di latar belakang tanpa input pengguna, tetapi itu tidak ditambahkan ke Windows sampai Windows Server 2003. Itu benar, perilaku inti OS tersembunyi di balik GUI sampai 2003, di dunia di mana Unix dikirim mkfs dari hari 1 .

   Salinan saya Unix V5 dari tahun 1974 termasuk /etc/mkfs, sebuah 4136 byte yang terhubung secara statis PDP-11 yang dapat dieksekusi. (Unix tidak mendapatkan hubungan dinamis sampai akhir 1980-an , jadi tidak seperti ada perpustakaan besar di tempat lain melakukan semua pekerjaan nyata.) Kode sumbernya - termasuk dalam gambar sistem V5 sebagai /usr/source/s2/mkfs.c- adalah sepenuhnya mandiri 457- program jalur C. Bahkan tidak ada #includepernyataan!

   Ini berarti Anda tidak hanya dapat memeriksa apa yang mkfsdilakukan pada tingkat tinggi, Anda dapat bereksperimen dengannya menggunakan alat yang sama dengan Unix dibuat, sama seperti Anda Ken Thompson , empat dekade lalu. Coba itu dengan Windows. Yang terdekat dengan Anda hari ini adalah mengunduh kode sumber DOS , pertama kali dirilis pada tahun 2014 , yang Anda temukan jumlahnya hanya setumpuk sumber perakitan . Itu hanya akan dibangun dengan alat-alat usang yang mungkin tidak akan Anda miliki, dan pada akhirnya Anda mendapatkan salinan DOS 2.0 Anda sendiri, sebuah OS yang jauh lebih kuat daripada Unix V5 1974 , meskipun dirilis hampir satu dekade kemudian.

   (Mengapa berbicara tentang Unix V5? Karena itu adalah sistem Unix lengkap paling awal masih tersedia. Versi sebelumnya tampaknya hilang waktu . Ada proyek yang menyatukan era V1 / V2 Unix, tetapi tampaknya hilang mkfs, meskipun ada keberadaannya. halaman manual V1 yang ditautkan di atas membuktikannya pasti ada di suatu tempat, entah kapan. Baik mereka yang menyusun proyek ini tidak dapat menemukan salinan yang masih ada mkfsuntuk disertakan, atau saya payah menemukan file tanpa find(1), yang juga tidak ada dalam sistem itu . :))

   Sekarang, Anda mungkin berpikir, "Tidak bisakah saya menelepon format.com? Bukankah itu sama dengan Windows ketika memanggil mkfsUnix?" Sayangnya, tidak, itu tidak sama, karena banyak alasan:

   • Pertama, format.comtidak dirancang untuk dituliskan. Ini meminta Anda untuk "tekan ENTER saat siap", yang berarti Anda perlu mengirim kunci Enter ke inputnya, atau itu hanya akan hang.

   • Kemudian, jika Anda menginginkan sesuatu lebih dari kode status keberhasilan / kegagalan, Anda harus membuka output standar untuk membaca, yang jauh lebih rumit pada Windows daripada yang seharusnya . (Di Unix, semua yang ada di artikel tertaut itu dapat diselesaikan dengan popen(3)panggilan sederhana .)

   • Setelah melalui semua kerumitan ini, output dari format.comlebih sulit untuk diurai untuk program komputer daripada output mkfs, yang dimaksudkan terutama untuk konsumsi manusia.

   • Jika Anda melacak apa yang format.comdilakukannya, Anda menemukan bahwa hal itu sekelompok panggilan rumit untuk DeviceIoControl(), ufat.dll, dan semacamnya. Itu tidak hanya membuka file perangkat dan menulis filesystem baru ke perangkat itu. Ini adalah jenis desain yang Anda dapatkan dari perusahaan yang mempekerjakan 126.000 orang , dan perlu terus mempekerjakan mereka.

5. Ketika berbicara tentang perangkat loop, saya hanya berbicara tentang Linux daripada Unix secara umum karena perangkat loop tidak portabel antara sistem tipe Unix. Ada mekanisme serupa di OS X, BSD, dll., Tetapi sintaks agak bervariasi .

6. Kembali pada hari-hari ketika disk drive adalah ukuran mesin cuci dan harganya lebih mahal dari mobil mewah kepala departemen, laboratorium komputer besar akan berbagi proporsi lebih besar dari ruang disk kolektif mereka dibandingkan dengan lingkungan komputasi modern. Kemampuan untuk secara transparan mencangkokkan cakram jarak jauh ke dalam sistem berkas lokal membuat sistem terdistribusi jauh lebih mudah digunakan. Di sinilah kita dapatkan /usr/share, misalnya.

   Bandingkan Windows, tempat disk jarak jauh biasanya dipetakan ke huruf drive atau harus diakses melalui jalur UNC, daripada diintegrasikan secara transparan ke sistem file lokal. Huruf drive menawarkan beberapa pilihan untuk ekspresi simbolis; apakah P:merujuk ke ruang "publik" di BigServer, atau ke direktori "paket" pada server mirror software? Jalur UNC berarti Anda harus mengingat server mana file jarak jauh Anda berada, yang menjadi sulit di organisasi besar dengan ratusan atau ribuan server file.

   Windows tidak mendapatkan symlinks sampai Windows Vista, dirilis pada 2007, yang memperkenalkan tautan simbolik NTFS . Tautan simbolis Windows sedikit lebih kuat daripada tautan simbolis Unix - fitur Unix sejak tahun 1977 - karena mereka juga dapat menunjuk ke berbagi file jarak jauh, bukan hanya ke jalur lokal. Unix melakukannya secara berbeda, melalui NFS pada tahun 1984 , yang dibangun di atas fitur mount point Unix yang sudah ada sebelumnya , yang telah dimilikinya sejak awal.

   Jadi, tergantung pada bagaimana Anda melihatnya, Windows membuntuti Unix sekitar 2 atau 3 dekade.

   Bahkan saat itu, tautan simbolik bukan bagian normal dari pengalaman pengguna Windows, karena beberapa alasan.

   Pertama, Anda hanya dapat membuatnya dengan program baris perintah mundurMKLINK . Anda tidak dapat membuat mereka dari Windows Explorer, sedangkan Unix setara dengan Windows Explorer biasanya jangan membiarkan Anda membuat symlink.

   Kedua, konfigurasi Windows default mencegah pengguna normal membuat tautan simbolik, mengharuskan Anda menjalankan shell perintah sebagai Administrator atau memberikan izin kepada pengguna untuk membuatnya melalui jalur yang tidak jelas dalam alat yang belum pernah dilihat oleh pengguna biasa, apalagi yang tahu bagaimana cara menggunakan. (Dan tidak seperti kebanyakan masalah hak istimewa Admin di Windows, UAC tidak membantu dalam hal ini.)

7. Kotak Linux tidak selalu menggunakan gambar disk virtual dalam urutan boot. Ada banyak cara berbeda untuk melakukannya .

8. man ed

9. Deskriptor soket jaringan adalah FD di bawahnya juga.

Jika Anda menganggap Linuxsebagai Bahasa Inggris , itu file systemsadalah abjad yang pada dasarnya adalah dasar pondasi untuk bahasa Inggris .

Dari halaman wiki sistem File,

Dalam komputasi, sistem file (atau sistem file) digunakan untuk mengontrol bagaimana data disimpan dan diambil. Tanpa sistem file, informasi yang ditempatkan di area penyimpanan akan menjadi satu kumpulan besar data tanpa cara untuk mengetahui di mana satu informasi berhenti dan selanjutnya dimulai.

Jadi dalam istilah awam tanpa struktur bahasa yang tepat untuk bahasa Inggris (yang dibuat dari huruf), interaksi manusia tidak akan menghasilkan makna apa pun. Demikian pula, tanpa sistem file data apa pun yang kita miliki di perangkat penyimpanan yang mendasarinya tidak akan memiliki arti yang nyata.