Windows – Penjelasan Orang Awam Untuk “Semuanya Adalah File” — Apa Bedanya dengan Windows?

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

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?

Jawaban yang Diterima:

"Semuanya adalah file" agak fasih. "Semuanya muncul di suatu tempat di sistem file" lebih dekat dengan sasaran, dan bahkan kemudian, itu lebih ideal daripada hukum desain sistem.

Misalnya, soket domain Unix bukanlah file, tetapi soket tersebut muncul di sistem file. Anda dapat ls -l soket domain untuk menampilkan atributnya, ubah kontrol aksesnya melalui chmod , dan pada beberapa sistem tipe Unix (mis. macOS tetapi bukan Linux), Anda bahkan dapat cat data ke/dari satu.

Namun, meskipun soket jaringan TCP/IP biasa dibuat dan dimanipulasi dengan panggilan sistem soket BSD yang sama seperti soket domain Unix, soket TCP/IP tidak muncul di sistem file,¹ meskipun tidak ada alasan yang tepat bahwa ini benar.

Contoh lain dari objek non-file yang muncul di sistem file adalah /proc Linux berkas sistem. Fitur ini memaparkan sejumlah besar detail tentang operasi run-time kernel ke ruang pengguna, sebagian besar sebagai file teks biasa virtual. Banyak /proc entri hanya-baca, tetapi banyak /proc juga dapat ditulisi, sehingga Anda dapat mengubah cara sistem berjalan menggunakan program apa pun yang dapat memodifikasi file. Sayangnya, di sini lagi kita memiliki ketidakidealan:Unix tipe BSD umumnya berjalan tanpa /proc , dan Unix Sistem V jauh lebih sedikit terekspos melalui /proc daripada Linux.

Saya tidak bisa membedakannya dengan MS Windows

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

Versi modern Windows memiliki sistem I/O terpadu, sama seperti Unix, sehingga Anda dapat membaca data jaringan dari soket TCP/IP melalui ReadFile() daripada API khusus Windows Sockets WSARecv() , jika Anda menghendaki. Ini persis sejajar dengan Unix Way, di mana Anda dapat membaca dari soket jaringan dengan read(2) generik. Panggilan sistem Unix atau recv(2) khusus soket telepon.²

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

1. Pengemudi.

Subsistem driver Windows sama kaya dan kuatnya dengan Unix, tetapi untuk menulis program untuk memanipulasi driver, Anda biasanya harus menggunakan Windows Driver Kit, yang berarti menulis kode C atau .NET.

Pada OS tipe 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 antarprogram.

Program Windows tidak mudah berkomunikasi satu sama lain.

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

3. Pendaftaran.

Unix tidak memiliki padanan langsung dari registri Windows. Informasi yang sama tersebar melalui sistem file, sebagian besar di /etc , /proc dan /sys .

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

Bagaimana filosofi “Semuanya adalah file” membuat perbedaan di sini?

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

Jawaban panjang, bagian 1:Drive vs File Perangkat

Katakanlah pembaca kartu CF Anda muncul sebagai E: di bawah Windows dan /dev/sdc di bawah Linux. Apa perbedaan praktisnya?

Ini bukan hanya perbedaan sintaksis kecil.

Di Linux, saya dapat mengatakan dd if=/dev/zero of=/dev/sdc untuk menimpa konten /dev/sdc dengan nol.

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

Tidak ada cara mudah untuk menghilangkan E: drive di Windows, karena Windows membuat perbedaan antara file dan drive, jadi Anda tidak dapat menggunakan perintah yang sama untuk memanipulasinya. Cara terdekat yang bisa Anda dapatkan adalah melakukan format disk tanpa opsi Quick Format, yang paling banyak zero nol isi drive, tetapi kemudian menulis sistem file baru di atasnya. Bagaimana jika saya tidak mau sistem file baru? Bagaimana jika saya benar-benar ingin disk diisi dengan nol?

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

Karena mkfs ketik program 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 di 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, yang 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 gambar disk ext4 dengan file bernama my-passwd-entry di dalamnya yang berisi /etc/passwd pengguna saya entri.

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

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

Atau, saya dapat mengemas disk image itu, mengirimkannya kepada Anda, dan membiarkan Anda menulisnya ke media Anda memilih, 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 buatan antara file, sistem file, dan perangkat. Banyak hal di sistem Unix baik adalah file, atau diakses melalui sistem file sehingga terlihat seperti file, atau dengan cara lain terlihat cukup mirip file sehingga dapat diperlakukan seperti itu.

Konsep sistem file Windows adalah gado-gado; itu membuat perbedaan antara direktori, drive, dan sumber daya jaringan. Ada tiga sintaks yang berbeda, semuanya digabungkan bersama di Windows:..FOOBAR mirip Unix sistem jalur, huruf drive seperti C: , dan jalur UNC seperti \SERVERPATHFILE.TXT . Ini karena ini adalah kumpulan ide dari Unix, CP/M, MS-DOS, dan LAN Manager, daripada satu desain yang koheren. Itulah mengapa 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 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 semuanya diperlakukan dengan cara yang sama.⁶

Windows dapat mencapai tujuan yang serupa dengan contoh gambar disk saya di atas, tetapi Anda harus menggunakan program khusus yang ditulis oleh pemrogram yang luar biasa berbakat. Inilah sebabnya mengapa ada begitu banyak program jenis "DVD virtual" di 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.

Terkait:Bagaimana mencegah RealVNC menskalakan tampilan berdasarkan opsi penskalaan windows?

Hal yang sama berlaku untuk alat lain seperti program penghapusan disk, yang juga tidak kami perlukan di sistem Unix. Ingin konten kartu CF Anda diacak tanpa bisa diperbaiki alih-alih hanya dinolkan? Oke, gunakan /dev/random sebagai sumber data, bukan /dev/zero :

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

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

Saya merasa adil untuk menunjukkan bahwa jika Unix telah mengintegrasikan TCP/IP I/O ke dalam sistem file sejak awal, kami tidak akan memiliki netcat vs socat vs Ncat vs nc kekacauan, yang penyebabnya adalah kelemahan desain yang sama yang mengarah pada pencitraan disk dan proliferasi alat penghapusan pada Windows:kurangnya fasilitas OS yang dapat diterima.

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 akhir-akhir ini, yang disebut PowerShell.

Namun, ada efek langsung dari kurangnya tradisi baris perintah ini. Anda mendapatkan alat seperti DISKPART yang 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 bahwa DISKPART 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 , tapi itu semua-atau-tidak sama sekali. Apa yang Anda benar-benar inginkan dalam situasi seperti itu adalah sesuatu yang lebih seperti GNU parted , yang akan menerima perintah tunggal seperti parted /dev/sdb mklabel gpt . Itu memungkinkan skrip Anda melakukan penanganan kesalahan selangkah demi selangkah.

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

Dalam 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 vi penyangga editor, vi dapat melakukannya untuk Anda secara langsung. Dari vi mode “normal”, katakan:

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

Itu memasukkan output program itu ke buffer editor aktif pada posisi kursor saat ini. Di bawah tenda, vi menggunakan 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 umum yang sama di semua implementasi umum vi . Saya tidak bisa memikirkan alasan bagus untuk tidak melakukannya.

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

Ide hebat ini muncul berulang kali di Unix.

Untuk contoh kedua, ingat mutt saya perintah email di atas. Satu-satunya alasan saya harus menulisnya sebagai dua perintah terpisah adalah karena saya ingin file sementara diberi nama *.gz , sehingga lampiran email akan diberi nama dengan benar. Jika saya tidak peduli dengan nama file, saya dapat menggunakan proses substitusi untuk menghindari pembuatan 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 memutar output gzip -c menjadi FIFO (yang seperti file) atau /dev/fd objek (yang seperti file). (Bash memilih metode berdasarkan kemampuan sistem, karena /dev/fd tidak tersedia di mana-mana.)

Untuk cara ketiga ide hebat ini muncul di Unix, pertimbangkan gdb pada sistem Linux. Ini adalah debugger yang digunakan untuk perangkat lunak apa pun yang ditulis dalam C dan C++. Pemrogram yang datang ke Unix dari sistem lain melihat gdb dan hampir selalu mengeluh tentang hal itu, "Yuck, ini sangat primitif!" Kemudian mereka pergi mencari debugger GUI, menemukan salah satu dari beberapa yang ada, dan dengan senang hati melanjutkan pekerjaan mereka…seringkali tidak pernah menyadari bahwa GUI hanya menjalankan gdb di bawahnya, menyediakan cangkang cantik di atasnya. Tidak ada debugger tingkat rendah yang bersaing di sebagian besar sistem Unix karena program tidak perlu bersaing di tingkat itu. Yang kita butuhkan hanyalah satu alat tingkat rendah yang baik yang dapat kita gunakan untuk mendasarkan alat tingkat tinggi kita, jika alat tingkat rendah itu berkomunikasi dengan mudah melalui pipa.

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

Tetap saja, setidaknya mungkin bahwa beberapa gdb future di masa depan penggantian akan masuk secara transparan hanya dengan mengkloning antarmuka baris perintahnya. Untuk melakukan hal yang sama pada kotak Windows, pembuat alat yang dapat diganti harus menentukan semacam plugin formal atau API otomatisasi. Artinya, hal itu tidak terjadi kecuali untuk program yang paling populer, karena membangun antarmuka pengguna baris perintah normal dan API pemrograman lengkap memerlukan banyak pekerjaan.

Keajaiban ini terjadi melalui anugerah IPC berbasis teks yang meresap.

Meskipun kernel Windows memiliki pipa anonim gaya Unix, jarang terlihat program pengguna normal menggunakannya untuk IPC di luar shell perintah, karena Windows tidak memiliki tradisi membuat semua layanan inti dalam versi baris perintah terlebih dahulu, kemudian membangun GUI di atasnya 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, adalah 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 tty semu di /dev/pty* (yang seperti file). Sekarang sistem jarak jauh Anda terhubung ke sistem lokal Anda melalui koneksi yang sangat cocok dengan Unix Way sehingga Anda dapat menyalurkan data melalui koneksi SSH, jika perlu.

Apakah Anda mendapatkan gambaran seberapa kuat konsep ini sekarang?

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

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

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

Jawaban Panjang, bagian 3:File Registri vs Konfigurasi

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

Terkait:Mencegah hotspot Wifi Windows 10 mati secara otomatis pada 1809?

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 yang sama. Untuk sebagian besar, file konfigurasi ini hanyalah file teks biasa, yang berarti saya dapat menggunakan alat apa pun di Unix untuk memanipulasinya agar dapat bekerja dengan file teks biasa.

Membuat skrip registri hampir tidak mudah di Windows.

Metode termudah adalah membuat perubahan Anda melalui GUI Registry Editor pada satu mesin, kemudian menerapkan perubahan tersebut secara membabi buta ke mesin lain dengan regedit melalui *.reg file. Itu sebenarnya bukan "scripting", karena tidak memungkinkan Anda melakukan apa pun secara kondisional:semuanya atau tidak sama sekali.

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

Catatan Kaki:

1. Rencana 9 memperbaiki kesalahan langkah desain ini, memperlihatkan I/O jaringan melalui /net sistem file virtual.

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, dengan contoh tandingan, mengapa merupakan ide yang bagus untuk membuat semua sumber daya data terlihat melalui sistem file.

2. Yang saya maksud dengan “Windows modern” adalah Windows NT dan semua turunan langsungnya, yang mencakup Windows 2000, semua versi Windows Server, dan semua versi Windows berorientasi desktop mulai dari XP dan seterusnya. Saya menggunakan istilah tersebut untuk mengecualikan versi Windows berbasis DOS, menjadi Windows 95 dan turunan langsungnya, Windows 98 dan Windows ME, ditambah pendahulunya 16-bit.

Anda dapat melihat perbedaannya dengan tidak adanya sistem I/O terpadu di OS yang terakhir. Anda tidak dapat meneruskan soket TCP/IP ke ReadFile() pada Windows 95; Anda hanya dapat meneruskan soket ke Windows Sockets APIs. Lihat artikel mani Andrew Schulman, Windows 95:What It's Not untuk mempelajari topik ini lebih dalam.

3. Jangan salah, /dev/null adalah perangkat kernel nyata pada sistem tipe Unix, bukan hanya nama file dengan casing khusus, seperti halnya NUL yang setara secara dangkal di Windows.

Meskipun Windows mencoba mencegah Anda membuat NUL file, adalah mungkin untuk melewati perlindungan ini dengan tipuan belaka, membodohi logika penguraian nama file Windows. Jika Anda mencoba mengakses file itu dengan cmd.exe atau Explorer, Windows akan menolak untuk membukanya, tetapi Anda dapat menulisnya melalui Cygwin, karena ia membuka file menggunakan metode yang mirip dengan program contoh, dan Anda dapat menghapusnya melalui tipu daya serupa.

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

Anda bahkan dapat membuat node dev perangkat null tambahan di tempat lain:tidak masalah jika Anda menyebutnya /home/grandma/Recycle Bin , selama itu adalah dev node untuk perangkat null, itu akan bekerja persis sama dengan /dev/null .

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

Ada dua untuk yang sangat…yah…Windows semacam alasan. Yang pertama meminta Windows Explorer untuk menampilkan kotak dialog "Format Disk" normalnya, yang berarti ia berfungsi pada semua versi Windows modern, tetapi hanya saat pengguna masuk secara interaktif. Yang lain, Anda dapat menelepon di latar belakang tanpa masukan pengguna, tetapi tidak ditambahkan ke Windows hingga Windows Server 2003. Benar, perilaku inti OS tersembunyi di balik GUI hingga 2003, di dunia di mana Unix mengirimkan mkfs dari hari 1.

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

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

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

Sekarang, Anda mungkin berpikir, “Tidak bisakah saya menelepon format.com ? Bukankah itu sama di Windows dengan memanggil mkfs di Unix?” Sayangnya, tidak, itu tidak sama, karena banyak alasan:

- First, `format.com` wasn't designed to be scripted. It prompts you to "press ENTER when ready", which means you need to send an Enter key to its input, or it'll just hang.

- Then, if you want anything more than a success/failure status code, you have to open its standard output for reading, which is [far more complicated on Windows than it has to be](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx). (On Unix, everything in that linked article can be accomplished with a simple [`popen(3)`](http://linux.die.net/man/3/popen) call.)

- Having gone through all this complication, the output of `format.com` is harder to parse for computer programs than the output of `mkfs`, being intended primarily for human consumption.

- If you trace what `format.com` does, you find that it does a bunch of complicated calls to [`DeviceIoControl()`](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363216%28v=vs.85%29.aspx), `ufat.dll`, and such. It is not simply opening a device file and writing a new filesystem onto that device. This is the sort of design you get from [a company that employs 126000 people](https://news.microsoft.com/facts-about-microsoft/#EmploymentInfo), and needs to *keep* employing them.

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 sintaksnya agak berbeda.

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

Kontras Windows, di mana disk jarak jauh biasanya dipetakan ke huruf drive atau harus diakses melalui jalur UNC, daripada terintegrasi 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" di server cermin perangkat lunak? Jalur UNC berarti Anda harus mengingat server tempat file jarak jauh Anda berada, yang menjadi sulit di organisasi besar dengan ratusan atau ribuan server file.

Windows tidak mendapatkan symlink sampai Windows Vista, dirilis pada 2007, yang memperkenalkan tautan simbolik NTFS. Tautan simbolis Windows sedikit lebih kuat daripada tautan simbolik Unix — fitur Unix sejak 1977 — karena tautan tersebut juga dapat menunjuk ke berbagi file jarak jauh, tidak hanya ke jalur lokal. Unix melakukannya secara berbeda, melalui NFS pada tahun 1984, yang dibangun di atas fitur titik pemasangan Unix yang sudah ada sejak awal.

Terkait:XML tanpa LF ingin membuatnya cantik menggunakan perintah sed di shell?

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

Meski begitu, tautan simbolik bukanlah bagian normal dari pengalaman pengguna Windows, karena beberapa alasan.

Pertama, Anda hanya dapat membuatnya dengan program baris perintah mundur MKLINK . Anda tidak dapat membuatnya dari Windows Explorer, sedangkan Unix setara dengan Windows Explorer biasanya melakukan memungkinkan Anda membuat symlink.

Kedua, konfigurasi Windows default mencegah pengguna normal membuat tautan simbolik, yang 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 pengguna rata-rata Anda, apalagi yang tahu Cara Penggunaan. (Dan tidak seperti kebanyakan masalah hak istimewa Admin di Windows, UAC tidak membantu dalam kasus ini.)

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

8. man ed

9. Omong-omong, deskriptor soket jaringan adalah FD di bawahnya.