Selama hampir tiga puluh tahun sekarang, Plan 9 telah mengujakan minda Unixoids. Sistem pengendalian, berdekad-dekad lebih awal daripada zamannya, tidak diperlukan dan telah dibuang ke pinggir dunia IT. Inferno, penggantinya, terbukti kurang popular dan akhirnya menemui ajalnya di tangan sesiapa pun. syarikat terkenal Vita Nuova. Walau bagaimanapun, kedua-dua sistem terus dikemas kini oleh pembangun individu sehingga hari ini malah digunakan untuk menyelesaikan pelbagai masalah yang sempit. Banyak garpu muncul, kebanyakannya mati, dan ada yang masih hidup hari ini. Mungkin yang paling menarik ialah Node9, simbiosis platform Inferno dan bahasa Lua, yang mampu bersaing dengan Erlang yang hebat dan dahsyat.

Bukannya memperkenalkan

Saya telah mengikuti perkembangan Inferno dan Plan 9 untuk masa yang lama, membaca senarai mel, menilai garpu yang muncul di GitHub dari semasa ke semasa dan sering menulis sesuatu yang mudah sendiri dalam Limbo, bahasa standard Inferno. Oleh itu, projek Node9, berdasarkan idea Inferno dan menggunakan salah satu kegemaran saya dan, seperti yang saya nampak, bahasa Lua yang sangat diremehkan, segera menarik perhatian saya. Dan ternyata, tidak sia-sia. Projek itu ternyata lebih serius dan lebih maju daripada semua "varian" sistem lain yang pernah saya lihat sebelum ini. Apakah Node9? Dalam istilah pembangun sendiri, ia adalah sistem pengendalian yang dihoskan, dan dalam rumusan yang lebih biasa, ia adalah persekitaran atau, lebih baik lagi, platform untuk menjalankan aplikasi yang diedarkan. Node9 adalah berdasarkan idea dan teknologi Inferno dan Plan 9, yang sepatutnya biasa kepada ramai pembaca. Walau bagaimanapun, beberapa penjelasan amat diperlukan.

Pada satu masa, Pelan 9 adalah berdasarkan idea mekanisme IPC tunggal yang akan membolehkan kedua-dua proses tempatan dan jauh untuk bertukar-tukar data. Diandaikan bahawa keseluruhan sistem akan dibina di sekitar mekanisme ini, jadi sudah pada peringkat awal pembangunan OS, protokol 9P telah direka (dalam Inferno ia dinamakan semula Styx), yang bertanggungjawab untuk pelaksanaannya. Dan semua komponen sistem lain, termasuk pemacu, tindanan grafik dan aplikasi biasa, menggunakannya untuk berinteraksi antara satu sama lain.

Ciri utama 9P ialah ia pada dasarnya adalah protokol untuk mengakses fail jauh (dan setempat). Oleh itu, dalam Pelan 9, secara literal semuanya diwakili oleh fail (sintetik), daripada penuding tetikus kepada susunan rangkaian. Banyak aplikasi yang agak biasa juga menyediakan akses kepada "fail mereka" untuk tujuan bertukar data dengan aplikasi lain. Malah penyediaan sistem dijalankan bukan melalui konfigurasi, tetapi menggunakan skrip yang menulis nilai tertentu pada fail. Dan yang paling penting, satu mesin Plan 9 boleh memasang semua atau sebahagian daripada sistem fail mesin lain melalui rangkaian dan menggunakan failnya untuk berinteraksi dengan aplikasi jauh, iaitu, pada dasarnya, melakukan panggilan prosedur jauh (RPC). Pendekatan ini memungkinkan untuk mengeluarkan banyak perkara menarik daripada kotak, termasuk desktop jauh (paparan, papan kekunci dan tetikus juga fail), akses jauh kepada peranti dan penskalaan sistem pengkomputeran yang mudah dan mudah. Contoh kegemaran saya ialah pelaksanaan NAT. Dalam Pelan 9 ia tidak diperlukan sama sekali, hanya lekapkan direktori /net (mengandungi fail susunan rangkaian) mesin jauh di atas mesin tempatan, dan semua aplikasi yang dilancarkan selepas ini akan menggunakan susunan rangkaian mesin ini.

Secara teorinya, helah ini tidak sepatutnya berfungsi, kerana untuk mengakses timbunan rangkaian mesin jauh, anda memerlukan timbunan rangkaian yang tempatan. Tetapi dalam Pelan 9 ia berfungsi, terima kasih kepada ruang nama yang dipanggil. Ini adalah satu lagi mekanisme utama Pelan 9 yang memastikan bahawa sebarang perubahan pada pepohon fail yang boleh dilihat oleh satu proses tidak akan menjejaskan pepohon fail yang boleh dilihat oleh proses lain. Kembali kepada contoh NAT, ini bermakna tindanan rangkaian yang dipasang pada mesin jauh akan kelihatan hanya kepada proses yang melekapkannya dan anak-anaknya, manakala semua proses lain akan terus berfungsi dengan tindanan rangkaian tempatan. Ini adalah mekanisme yang sangat berkuasa yang membolehkan anda mencipta persekitaran yang berbeza untuk proses, serta mengawal akses mereka kepada sumber (dengan cara ini, kotak pasir OpenVZ, LXC dan Docker di Linux menggunakan idea ruang nama yang sama).

Perkara terakhir yang penting kepada kami dalam konteks pengenalan kami kepada Node9 ialah saluran dan aliran. Bahasa Limbo, yang digunakan secara lalai dalam Inferno, dilengkapi dengan sistem multithreading yang sangat mudah dan berkesan, yang kemudiannya berhijrah ke bahasa Go. Intipatinya adalah mudah sehingga memalukan: pada bila-bila masa, sebarang fungsi boleh dihantar ke utas yang berasingan dengan memanggilnya menggunakan kata kunci spawn. Terdapat sesuatu yang serupa dalam Lua tulen dan beberapa bahasa lain, tetapi bukan itu yang penting. Perkara penting ialah apabila memanggil fungsi sedemikian, anda boleh menentukan dalam hujahnya saluran data (terdapat jenis data sedemikian dalam Limbo), yang melaluinya ia boleh berkomunikasi dengan benang kanak-kanak. Ini dipanggil model benang CSP, dan ia digunakan dalam Limbo dan Go untuk menyegerakkan benang dan bertukar data antara mereka. Tetapi apa yang paling menarik ialah saluran itu boleh diubah menjadi fail! Dan sudah tentu, fail ini (lebih tepat lagi, direktori yang mengandunginya) boleh dipasang dari mesin jauh. Seluar bertukar... menjadi aplikasi yang diedarkan.

Letakkan semua ini bersama-sama dan kami mempunyai platform yang menakjubkan untuk mencipta aplikasi yang diedarkan. Satu-satunya masalah ialah Pelan 9 itu sendiri adalah sistem yang agak kecil, dan tiada siapa yang akan melaksanakannya ke dalam pengeluaran. Inferno, sebaliknya, mampu berjalan di atas sistem lain, termasuk Linux, OS X dan Windows, tetapi menggunakan bahasa Limbo, yang, walaupun ia mempunyai halangan yang rendah untuk masuk, hampir tidak diketahui oleh semua orang dan tidak mempunyai asas perpustakaan siap pakai yang baik. Inilah sebab mengapa Node9 wujud.

Siapa yang menggunakan Inferno dan Plan 9 dan bagaimana

• Coarid menggunakan Pelan 9 dan komponennya dalam penyelesaian NASnya.
• IBM menggunakan Pelan 9 dan beberapa komponen Inferno pada salah satu sistem superkomputer Blue Gene/Lnya, dibina pada 64,000 pemproses.
• Plan 9 OS telah digunakan untuk mengawal sistem lampu stadium di Sukan Olimpik Sydney pada tahun 2000.
• Untuk masa yang lama, sistem pengendalian Inferno telah digunakan dalam beberapa penyelesaian perkakasan Lucent (kemudian Alcatel-Lucent), seperti tembok api dan pintu masuk. Adalah diketahui dengan pasti bahawa OS Inferno tersembunyi di dalam Tembok Api Terurus Lucent, Portfolio Tembok Api VPN Lucent dan Pathstar Lucent.
• Beberapa model peranti telefon SIP, khususnya Philips IS2630 dan Alcatel Webtouch, adalah berdasarkan sistem pengendalian Inferno.
• Beberapa pusat penyelidikan dan universiti memilih Inferno sebagai platform pengkomputeran grid mereka: Cambridge Crystallography Data Center (CCDC), The University of York Department of Biology, Rutgers University Libraries, Evotec OAI AG (Deutsche Boerse EVT; TecDAX 30), Montclair State University .

Inferno, LuaJIT, libuv dan semua, semua, semua

Jadi, Node9 ialah simbiosis bahagian peringkat rendah versi dihoskan (berjalan di atas OS lain) Inferno, pengkompil JIT pantas LuaJIT dan perpustakaan pemprosesan acara tak segerak libuv, yang pada asalnya dibangunkan untuk Node.js, dan kini digunakan oleh projek lain. Apakah yang diberikan oleh semua ini kepada pembangun pihak ketiga? Pertama sekali, ini, sudah tentu, keseluruhan kompleks teknologi Inferno / Plan 9 proprietari dengan keupayaan untuk menulis perisian dalam bahasa Lua yang agak biasa dan sangat mudah dipelajari, dilengkapi dengan pengkompil JIT yang berkesan LuaJIT.

Kedua, ia adalah model berbilang benang mudah yang dilaksanakan dalam platform itu sendiri. Dalam Node9, semua proses dan utas berjalan dalam satu proses OS asas. Ini bermakna menukar antara urutan tidak memerlukan suis konteks, yang boleh menghasilkan manfaat prestasi yang ketara. Baik, ditambah segalanya, model CSP yang dibincangkan sebelum ini berdasarkan fungsi, saluran dan fail yang dikaitkan dengan saluran. CSP jauh lebih cekap daripada pelaksanaan multithreading tradisional dan, sebenarnya, menyelesaikan hampir semua masalah aplikasi selari. Benang di sini tidak berkongsi ruang alamat yang sama (skop benang = skop fungsi), mereka tidak mengakses data yang sama, tetapi sebaliknya menggunakan mesej segerak (tiada masalah penguncian), ia sangat mudah untuk disegerakkan.

Ketiga, sistem pemprosesan acara tak segerak yang berkesan (I/O, TCP, UDP, TTY), yang tidak menjerumuskan pengaturcara ke dalam neraka panggil balik, yang diketahui oleh mana-mana pembangun Node.js. Node9 bergantung pada libuv untuk semua pengendalian I/Onya. Oleh itu, walaupun panggilan sistem (jika ia boleh dipanggil dalam konteks "OS yang berjalan di atas OS") dilaksanakan di sini melalui "gelung peristiwa". Ia berfungsi seperti ini. Penjadual Node9 secara berurutan memindahkan kawalan ke setiap utas yang sedang berjalan sehingga salah seorang daripada mereka membuat panggilan sistem. Pada masa ini, kira-kira fungsi berikut dilancarkan (dalam dalam kes ini fungsi baca):

Fungsi S.read(vp, s_read, fd, buf, nbytes) s_read.fd = fd s_read.buf = buf s_read.nbytes = nbytes n9.sysreq(vp, n9.Sys_read) coroutine.yield() return s_read.ret end

Ia membuat baris gilir panggilan sistem ke libuv (fungsi n9.sysreq()), kemudian menggantung urutan semasa dan mengembalikan kawalan. Selepas ini, penjadual menghantar kawalan ke urutan seterusnya, dan apabila baris gilir benang habis, ia memulakan satu laluan gelung acara libuv (menyemak sama ada data yang diminta telah diterima, dalam kes ini dari cakera atau melalui rangkaian, Node9 tidak mendiskriminasi). Kemudian semuanya bermula semula. Jika semasa gelung libuv mengesan bahawa data telah diterima, kawalan dikembalikan kepada urutan yang membuat panggilan sistem. Pembaca yang bijak mungkin mengatakan bahawa semua ini sangat mengingatkan idea tentang apa yang dipanggil benang hijau, yang dilaksanakan dalam Smalltalk, Tcl, Erlang, dan dia akan benar. Seperti induknya Inferno, Node9 sepenuhnya berdasarkan model ini, tetapi menggunakan keupayaan libuv dan bahasa Lua dan bukannya Limbo. Pelaksanaan platform perisian berdasarkan "strim hijau" telah berulang kali membuktikan keberkesanannya, dan ia hampir sama baiknya dengan model berasaskan peristiwa yang digunakan dalam Node.js dan nginx. Walau bagaimanapun, tidak seperti yang terakhir, ia membolehkan anda "hanya menulis kod" dan tidak mengubah pemikiran anda memihak kepada pengaturcaraan berorientasikan panggilan balik, yang penuh dengan ralat dan kekeliruan kod yang teruk.

Oleh kerana Node9 dibina di sekitar protokol 9P, aplikasinya sangat mudah untuk dipautkan dengan aplikasi dalam mana-mana bahasa lain yang terdapat perpustakaan dengan pelaksanaan 9P. Dan terdapat banyak bahasa seperti itu, ini adalah C tulen, Go, Java dan banyak lagi. Dan ya, semuanya akan tersedia dari jauh.

Mari kita cuba

Node9 kini berada dalam pra-beta. Ia berfungsi, perisian membolehkan anda menjalankannya, penjadual merancangnya, libuv memprosesnya, tetapi banyak fungsi Inferno masih tidak direalisasikan. Sebagai contoh, masih belum mungkin untuk membuat pelayan fail (dalam terminologi Plan 9 / Inferno, ini adalah aplikasi yang mengeksport antara muka sendiri melalui fail), tidak mungkin untuk memasang struktur direktori mesin jauh, tetapi ia adalah mungkin untuk membukanya untuk pemasangan untuk mesin Plan 9. Namun begitu, masuk akal untuk membiasakan diri dengan platform, sekurang-kurangnya untuk menilai keupayaannya dalam keadaan sekarang(aplikasi web untuknya boleh ditulis sekarang).

Jadi, Node9 tersedia di GitHub dan pada masa ini hanya boleh berfungsi pada OS X dan Linux, dan selepas sistem dipindahkan sepenuhnya ke libuv, sokongan untuk banyak sistem lain diumumkan. Pasang git dan klon repositori:

$ git klon https://github.com/jvburnes/node9.git $ cd node9

Sistem ini dibina menggunakan aplikasi premake, dan untuk membina LuaJIT anda juga memerlukan automake. Semua alat binaan lain adalah standard, jadi memasang pakej binaan penting dalam Ubuntu dan analognya dalam pengedaran lain adalah mencukupi. Selepas itu, jalankan skrip pemasangan dan tunggu:

$ ./rebuild.sh

Selepas berjaya menyiapkan kompilasi, kami melancarkan sistem (pencinta epal putih menggantikan LD_LIBRARY_PATH dengan DYLD_LIBRARY_PATH):

$ eksport LD_LIBRARY_PATH=./lib $ bin/node9

Gesaan baris arahan akan muncul pada skrin. Ini adalah shell tempatan, ia mempunyai banyak kemungkinan: cd standard, ls, cat dan beberapa arahan yang anda akan dapati dalam direktori fs/appl. Sistem itu sendiri akan dikunci dalam kotak pasir, akarnya akan menjadi direktori fs di dalam direktori dengan Node9 dipasang. Mendahului arahan dengan ruang boleh mengubahnya menjadi ungkapan Lua. Belum ada paip UNIX standard dan ubah hala I/O, hanya tiga arahan, hanya tegar.

Untuk menjalankan skrip Lua anda, hanya masukkannya ke dalam fs/appl, dan kemudian jalankannya sebagai arahan biasa, meninggalkan sambungan (.lua). API di sini berbeza daripada Lua standard. "Panggilan sistem" asas disertakan dalam modul sys. Untuk berkenalan dengan mereka, anda boleh membaca kod sumber appl/syscall.lua. Tiada modul untuk interaksi rangkaian sama sekali; sebaliknya, seperti yang dijangkakan, terdapat fail, dalam kes ini direktori /net. Untuk mengetahui cara bekerja dengannya, anda boleh membaca sumber dalam direktori fs/appl. Turut disertakan ialah perpustakaan Penlight Lua dengan set fungsi untuk memanipulasi jenis data yang berbeza. Jika tidak, tiada yang luar biasa. Projek biasa dalam peringkat pembangunan selepas permulaan. Bingkai sudah siap, yang tinggal hanyalah menyelesaikannya dan membungkusnya dalam bungkusan yang cantik.

kesimpulan

Node9 adalah projek yang lebih menarik. Pembangunnya memutuskan untuk membetulkan apa yang Inferno selalu takutkan pengaturcara. Saya amat meragui bahawa sistem ini akan menjadi lebih terkenal, jika hanya kerana ramai pengaturcara tidak mengaitkan Lua dengan sesuatu yang serius (walaupun ia). Tetapi ia cukup mampu untuk menduduki nichenya, kerana kebanyakan kerja untuk membangunkan platform telah pun selesai.

Sebagai demonstrasi, Inferno juga dijalankan sebagai pemalam di bawah Internet Explorer versi 4.

Setiap sistem Inferno membentangkan persekitaran yang sama kepada aplikasi, tanpa mengira OS atau seni bina hos yang mendasari, membolehkan pembangun bekerja dengan persekitaran yang benar-benar homogen merentas pelbagai platform yang berbeza.

Aplikasi Mudah Alih
Aplikasi Inferno ditulis dalam Limbo®, bahasa pengaturcaraan serentak yang moden, selamat, modular dan serentak dengan sintaks seperti C. Ia lebih berkuasa daripada C tetapi jauh lebih mudah untuk difahami dan nyahpepijat daripada C++ atau Java. Mudah untuk menyatakan konkurensi dalam dunia fizikal secara terus dalam sintaks Limbo. Mana-mana aplikasi Inferno akan berjalan secara sama pada semua platform Inferno.

Kod Mudah Alih
Kod Limbo disusun menjadi kod bebas seni bina untuk Mesin Maya Dis®, dengan perwakilan padat. Dis boleh ditafsirkan secara langsung (menjimatkan ruang), atau disusun dengan cepat untuk pemproses sasaran tertentu (menjimatkan masa). Pilihan boleh dibuat semasa run-time, setiap modul. Seni bina Dis direka bentuk dengan teliti untuk menjadikan penjanaan kod dengan cepat dengan mudah. Arahannya mudah dilaksanakan.

Sumber Telus
Inferno menawarkan ketelusan lengkap sumber dan data menggunakan sistem "ruang nama" yang ringkas tetapi berkuasa. Dengan sumber yang mewakili sebagai fail dan mempunyai satu protokol komunikasi standard - 9P (Styx®) - sumber seperti stor data, perkhidmatan dan peranti luaran boleh dikongsi dengan mudah antara sistem Inferno. Antara muka sumber boleh diimport ke sistem tempatan dan digunakan oleh aplikasi tanpa mereka ketahui, atau perlu tahu, sama ada ia tempatan atau jauh.

Keselamatan
Keselamatan tahap tinggi adalah bahagian penting dalam sistem Inferno. Dengan menggunakan satu protokol standard untuk semua komunikasi rangkaian, keselamatan boleh difokuskan pada satu titik dan disediakan pada peringkat sistem. Inferno menawarkan sokongan penuh untuk sambungan yang disahkan dan disulitkan menggunakan skim pengenalan pengguna berasaskan sijil dan pelbagai algoritma termasuk:

• IDEA, 56 bit DES, 40, 128 dan 256 bit algoritma penyulitan RC4
• Algoritma cincang selamat MD4, MD5 dan SHA

Penyelesaian Lengkap
Inferno bukan sahaja sistem pengendalian, ia juga merupakan persekitaran pembangunan yang lengkap, menyediakan semua alatan yang diperlukan untuk mencipta, menguji dan menyahpepijat aplikasi yang dijalankan di dalamnya.

• Acme IDE: termasuk editor, shell, alat padanan corak lanjutan & banyak lagi
• Penyusun Cepat: dengan sintaks penuh dan pemeriksaan jenis masa menyusun
• Penyahpepijat Grafik: dengan surih tindanan penuh untuk melaksanakan utas pada masa ini
• Shell Berkuasa: dengan keupayaan skrip yang canggih
• Perintah seperti UNIX: termasuk bind, grep, gzip, mount, ps, tar, yacc...

Untuk melihat bagaimana Vita Nuova dan Inferno boleh memberikan penyelesaian untuk anda, hubungi kami atau pilih salah satu pautan di bawah.

;
3. Memasang sistem dan aplikasi (Anda sedang membaca bahagian ini).
Dari teori kepada amalan. Sistem pengendalian Inferno datang sebagai teks sumber, yang boleh dimuat turun dari tapak web rasmi (http://www.vitanuova.com/inferno/downloads.html) atau diperoleh melalui sistem kawalan versi Mercurial (dalam hal ini anda akan menerima versi yang lebih baharu dan mungkin kurang stabil sistem).

Arahan pemasangan ringkas terdapat dalam fail INSTALL, dan untuk lebih banyak lagi Penerangan terperinci Anda boleh merujuk artikel bahasa Rusia: http://inferno.execbit.ru/wiki.wsgi/Installation. Dengan cara ini, satu lagi bahan dalam talian (http://habrahabr.ru/blogs/os inferno/42998) menerangkan bukan sahaja proses pemasangan dari kod sumber, tetapi juga beberapa tetapan utama, dan tapak web pengilang menawarkan dokumentasi terperinci (http://www.vitanuova.com/inferno/docs.html) sudah dihidupkan Bahasa Inggeris: panduan lengkap pengguna, gambaran keseluruhan protokol Styx, penerangan tentang proses membangunkan aplikasi untuk OS, dokumentasi untuk Limbo, dsb.

Ketersediaan kod sumber telah membolehkan peminat menyusun dan menjalankan Inferno pada platform yang tidak disokong secara rasmi - contohnya, Android dan Nintendo DS (lihat rajah di bawah).

Melancarkan Inferno pada Nintendo DS

Masih terdapat beberapa aplikasi siap sedia untuk Inferno - sistem telah menduduki niche tertentu. Ia bertindak sebagai platform untuk mencipta aplikasi teragih yang sangat disasarkan untuk menyelesaikan masalah tertentu. Set perisian sedia ada adalah mencukupi untuk pembangunan aplikasi yang selesa dan interaksi dengan rangkaian.

Dicipta untuk Inferno penyunting teks, beberapa pelayan, klien e-mel, penyemak imbas, pakej lengkap alat pembangunan perisian, termasuk penyusun bahasa Limbo dan perpustakaan untuknya, pemasang dan pembongkar kod untuk mesin maya Dis, penyahpepijat, profiler, penjana parser , dan lain-lain. Malah terdapat beberapa permainan mudah seperti Minesweeper, Tetris dan Snake.
Senarai yang agak terperinci bagi perisian sedia ada untuk Inferno (kedua-dua sistem dan aplikasi) boleh didapati di Wikipedia: http://en.wikipedia.org/wiki/List of Inferno applications.

Tidak ada repositori program terpusat untuk Inferno, dan secara umum saya perhatikan itu aplikasi pihak ketiga untuk Inferno ini adalah kejadian yang jarang berlaku. Walau bagaimanapun, dengan menggali sumber tematik, anda boleh menemui sesuatu.

Sebagai contoh, saya berjaya mencari pemapar VNC, pengurus alternatif tingkap, pelanggan untuk DBMS MySQL, klien dan pelayan NFS, modul untuk menyokong sistem fail, penyusun dan jurubahasa yang berbeza perbezaan bahasa pengaturcaraan.

Sesetengah pembangun telah mencipta pelayan dengan perisian mereka sendiri untuk Inferno, contohnya ialah sumber www.ueber.net/code (pengarang - Mechiel Lukkien).

kesimpulan

Sistem pengendalian Inferno melaksanakan banyak idea menarik. Walaupun hari ini setiap daripada mereka tidak lagi unik, tidak ada produk lain yang menyatukan semua konsep ini.

Walaupun popularitinya rendah, dari segi teknikal semata-mata, Inferno mungkin salah satu platform yang paling "betul" dilaksanakan. Sebab kelaziman rendah adalah remeh: dasar pemasaran yang pada mulanya tidak ditujukan kepada orang ramai, pemilihan perisian yang sedikit (dan kesukaran mengalihkan perisian yang wujud pada platform lain), sokongan perkakasan yang terhad dan banyak faktor lain. Bagaimanapun, semua ini tidak menghalang Vita Nuova daripada menjual penyelesaian berasaskan Inferno kepada pengeluar elektronik, kluster dan pembangun aplikasi perniagaan.

Secara umum, Inferno sememangnya projek menarik yang menunjukkan pandangannya tentang banyak perkara yang kelihatan biasa. Namun, sedia ada perisian membolehkan anda melihat Inferno lebih sebagai platform untuk melaksanakan beberapa program tertentu atau sebagai persekitaran pembangunan, tetapi bukan sebagai OS untuk kegunaan harian.

Oleh itu, hari ini Inferno hanya menarik minat peminat komputer, pengaturcara dan syarikat yang jarang ditemui. Di samping itu, Inferno ialah sumber idea berharga yang boleh dipinjam untuk digunakan dalam projek berskala lebih besar dan "gunaan".

Penerangan tentang Inferno

Tulis ulasan tentang artikel "Inferno (sistem pengendalian)"

Nota

lihat juga

Pautan

• (Bahasa Inggeris)
• dengan sumber rasmi (Bahasa Inggeris)
• (Bahasa Rusia)
• (Bahasa Rusia)
• (Bahasa Rusia)
• (Bahasa Rusia)
• - artikel yang mengandungi senarai pautan ke sumber lain di Inferno (Rusia)
• (Bahasa Inggeris)
• (Bahasa Rusia)
• (Bahasa Rusia)

Untuk pelayan atau stesen kerja Tidak seperti Unix terbina dalam Lain-lain

Petikan yang mencirikan Inferno (sistem pengendalian)

"Ini Metampsic," kata Sonya, yang sentiasa belajar dengan baik dan mengingati segala-galanya. – Orang Mesir percaya bahawa jiwa kita berada dalam haiwan dan akan kembali kepada haiwan.
"Tidak, anda tahu, saya tidak percaya, bahawa kita adalah haiwan," kata Natasha dalam bisikan yang sama, walaupun muzik telah berakhir, "tetapi saya tahu pasti bahawa kita adalah malaikat di sana sini di suatu tempat, dan itulah sebabnya. kami ingat segala-galanya.”...
-Boleh saya sertai awak? - kata Dimmler, yang menghampiri secara senyap dan duduk di sebelah mereka.
- Jika kita adalah malaikat, maka mengapa kita jatuh lebih rendah? - kata Nikolai. - Tidak, ini tidak boleh!
"Bukan lebih rendah, siapa yang memberitahu anda lebih rendah?... Kenapa saya tahu apa yang saya sebelum ini," Natasha membantah dengan yakin. - Lagipun, jiwa adalah abadi... oleh itu, jika saya hidup selama-lamanya, itulah cara saya hidup sebelum ini, hidup selama-lamanya.
"Ya, tetapi sukar bagi kami untuk membayangkan keabadian," kata Dimmler, yang mendekati orang muda dengan senyuman yang lemah lembut dan menghina, tetapi kini bercakap dengan senyap dan serius seperti yang mereka lakukan.
– Mengapa sukar untuk membayangkan keabadian? - kata Natasha. - Hari ini ia akan menjadi, esok ia akan menjadi, ia akan sentiasa dan semalam ia dan semalam ia adalah...
- Natasha! sekarang giliran awak. "Nyanyikan sesuatu untuk saya," suara countess kedengaran. - Bahawa anda duduk seperti konspirator.
- Ibu! "Saya tidak mahu berbuat demikian," kata Natasha, tetapi pada masa yang sama dia berdiri.
Kesemua mereka, walaupun Dimmler pertengahan umur, tidak mahu mengganggu perbualan dan meninggalkan sudut sofa, tetapi Natasha berdiri, dan Nikolai duduk di clavichord. Seperti biasa, berdiri di tengah dewan dan memilih lokasi utama Untuk resonans, Natasha mula menyanyikan lagu kegemaran ibunya.
Dia berkata bahawa dia tidak mahu menyanyi, tetapi dia sudah lama tidak menyanyi sebelum ini, dan sudah lama sejak itu, cara dia menyanyi petang itu. Count Ilya Andreich, dari pejabat di mana dia bercakap dengan Mitinka, mendengarnya menyanyi, dan seperti seorang pelajar, tergesa-gesa untuk pergi bermain, menyelesaikan pelajaran, dia menjadi keliru dalam kata-katanya, memberi arahan kepada pengurus dan akhirnya diam. , dan Mitinka, juga mendengar, secara senyap sambil tersenyum, berdiri di hadapan kiraan. Nikolai tidak mengalihkan pandangannya dari kakaknya, dan menarik nafas bersamanya. Sonya, mendengar, berfikir tentang betapa besar perbezaan yang ada antara dia dan rakannya dan betapa mustahil baginya untuk menjadi lebih menawan seperti sepupunya. Countess tua itu duduk dengan senyuman sedih yang gembira dan air mata di matanya, sesekali menggelengkan kepalanya. Dia berfikir tentang Natasha, dan tentang masa mudanya, dan tentang bagaimana ada sesuatu yang tidak wajar dan mengerikan dalam perkahwinan Natasha yang akan datang ini dengan Putera Andrei.
Dimmler duduk di sebelah countess dan menutup matanya, mendengar.
"Tidak, Countess," katanya akhirnya, "ini adalah bakat Eropah, dia tidak perlu belajar apa-apa, kelembutan, kelembutan, kekuatan ini..."
- Ah! "Betapa saya takut kepadanya, betapa takutnya saya," kata countess itu, tidak ingat dengan siapa dia bercakap. Naluri keibuannya memberitahunya bahawa terdapat terlalu banyak perkara dalam diri Natasha, dan ini tidak akan menggembirakannya. Natasha masih belum selesai menyanyi apabila Petya berumur empat belas tahun yang bersemangat berlari ke dalam bilik dengan berita bahawa mummers telah tiba.
Natasha tiba-tiba berhenti.
- Bodoh! - dia menjerit kepada abangnya, berlari ke kerusi, jatuh di atasnya dan menangis teresak-esak sehingga dia tidak dapat berhenti untuk masa yang lama.
“Tak ada apa-apa, Mama, betul-betul tak ada, cuma begini: Petya takutkan saya,” katanya, cuba tersenyum, tetapi air matanya terus mengalir dan esak tangisnya mencekik tekaknya.
Berpakaian hamba, beruang, Turki, pemilik penginapan, wanita, menakutkan dan lucu, membawa bersama mereka kesejukan dan keseronokan, pada mulanya dengan malu-malu berhimpit di lorong; kemudian, bersembunyi di belakang yang lain, mereka dipaksa masuk ke dalam dewan; dan pada mulanya dengan malu-malu, dan kemudian semakin ceria dan mesra, lagu, tarian, paduan suara dan permainan Krismas bermula. Countess, yang mengenali wajah dan mentertawakan mereka yang berpakaian, pergi ke ruang tamu. Count Ilya Andreich duduk di dalam dewan dengan senyuman yang cerah, menyetujui pemain. Pemuda itu hilang entah ke mana.

Siri Kandungan:

pengenalan

Semua peminat UNIX tahu nama Ken Tompson, Rob Pike, dan Dennis Ritchie. Mereka tahu tentang sumbangan mereka kepada industri IT, mereka tahu bahawa mereka adalah pencipta sistem pengendalian UNIX, bahasa pengaturcaraan C, dan mereka adalah orang yang menghasilkan idea untuk peranti fail, pemprosesan data saluran paip dan arahan. penterjemah yang beroperasi di luar kernel OS. Tetapi beberapa orang tahu bahawa pada akhir 1980-an, orang-orang ini memulakan projek yang paling bercita-cita tinggi dan berskala besar untuk memusnahkan UNIX dan bahasa C ibundanya, bahawa pada masa itu mereka mula bekerja pada sistem pengendalian yang direka untuk memusnahkan UNIX dan menggantikannya.

Penurunan UNIX

Masalah utama UNIX, dari sudut pandangan pengarangnya, ialah, disebabkan oleh seni binanya, OS tidak dapat menyesuaikan diri secara telus dengan dunia IT yang telah berubah dengan ketara sejak pembangunannya. Ringkasnya, UNIX sedang mati masalah sendiri, dan semua percubaan untuk menyesuaikannya dengan keadaan moden membawa kepada komplikasi OS, pengenalan banyak API kompleks yang berbeza, lapisan baharu, protokol rangkaian, format data, yang menjadikan OS yang dahulunya mudah, bertimbang rasa, elegan berat, kekok dan sukar untuk dikekalkan dengan segumpal kod.

Ingat bagaimana UNIX pada awal kelahirannya. OS ringkas yang direka untuk dijalankan pada kerangka utama, dengan set panggilan sistem yang sangat kecil dan dengan cara yang unik menyediakan akses kepada peralatan menggunakan set fail sintetik. Ia telah dipasang pada kerangka utama yang besar, dan pengguna yang ingin menerima kuasa pengkomputeran, disambungkan ke OS menggunakan terminal. Ini adalah era UNIX sebenar, bekerja dalam keadaan yang ia direka bentuk.

Lama kelamaan, terminal teks digantikan dengan terminal dengan paparan, raster pertama dan kemudian grafik, tetapi kod OS yang bertanggungjawab untuk output ke terminal kekal tidak berubah. Dengan kelahiran ARPANET dan protokol TCP/IP, kod tindanan rangkaian telah ditambahkan pada edisi BSD UNIX, tetapi bukannya fail sintetik (fail peranti), ia terikat pada panggilan sistem yang melaksanakan model soket. Dengan kedatangan paparan grafik dan model persekitaran windowing Xerox, sistem grafik X Window telah ditambahkan pada UNIX, tetapi sekali lagi, daripada mengikat APInya kepada fail sintetik, protokol khas telah dibangunkan. Perkongsian fail rangkaian juga telah dibuat sistem NFS dan protokol rangkaian dengan nama yang sama, pelbagai sistem panggilan prosedur jauh, Kerberos dan banyak lagi. Akhirnya, idea kerangka utama perkongsian masa tidak berlaku, dan UNIX dialihkan ke stesen kerja peribadi dan pemproses keluarga i386.

Seni bina PC yang dicadangkan oleh IBM termasuk kemungkinan memasang papan tambahan yang mengembangkan fungsi stesen kerja. Pada mulanya, pengguna mempunyai akses kepada bilangan terhad kad pengembangan mudah, tetapi kemudiannya kedua-dua bilangan dan kepelbagaian mereka, serta kerumitannya, meningkat. Semua ini membawa kepada fakta bahawa kernel UNIX monolitik yang dahulunya mudah (dan kini BSD dan Linux) dibahagikan kepada modul, setiap satunya melaksanakan lapisan keserasian dengan kad pengembangan (pemandu), dan fail peranti sintetik yang mudah digunakan yang berfungsi sebagai pusat akses kepada Perkakasan ini telah berkembang menjadi antara muka kompleks yang menyokong bukan sahaja menulis dan membaca, tetapi juga pelbagai panggilan ioctl yang dipanggil, kadangkala dengan nama yang kompleks dan tidak jelas sepenuhnya.

Masa bermakna bahawa sistem pengendalian ringkas yang dahulunya direka untuk dijalankan pada komputer kerangka utama yang dikawal oleh terminal teks kini berjalan pada PC rumah yang berdiri sendiri dan pelayan rangkaian. Kami telah lama menyingkirkan terminal teks, tetapi kami sentiasa bekerja dengan emulator mereka, kami terbiasa dengan akaun root, yang diperlukan pada zaman kerangka utama, tetapi kini hanya mewujudkan jurang keselamatan, kami menggunakan antara muka grafik yang tidak sama sekali tidak sesuai dengan ideologi UNIX dan wujud seolah-olah bebas daripadanya, kami mempunyai pelbagai jenis cara untuk berkomunikasi dengan PC lain, tiada satu pun yang standard, kami menggunakan protokol khas untuk mengakses dan mengawal mesin lain, kami terpaksa menggunakan mekanisme RPC yang sangat kompleks untuk mencipta aplikasi yang diedarkan, kami terkejut bilangan panggilan sistem dalam kernel Linux, malah idea fail peranti telah pun kehilangan kepelbagaian dan kesederhanaannya.

Pelan nombor 9

Jelas sekali, UNIX tidak boleh diperbaiki; seni binanya sendiri membunuhnya. Oleh itu, penyelidik dari Bell Labs memutuskan untuk bermula dari awal dan membangunkan OS baharu, tidak berkaitan dan tidak serasi dengan UNIX, dengan nama sipi Pelan 9.

Idea utama Pelan 9 adalah untuk membawa konsep "semuanya adalah fail" kepada kejayaan logiknya dan membina keseluruhan OS daripada fail sintetik (atau, lebih khusus, untuk mewakili semua sumber sistem pengendalian sebagai fail). Dan lakukan ini dengan cara yang bukan sahaja aplikasi dan pengguna tempatan, tetapi juga mana-mana pelanggan jauh boleh mengakses fail. Akibatnya, protokol fail 9P muncul, yang melaluinya akses kepada mana-mana fail (setempat dan jauh), pelayan fail yang mengeksport sumber OS tertentu atau aplikasi khusus dalam bentuk fail, dan ruang nama yang direka untuk menggabungkan semua fail yang tersedia menjadi satu pokok yang boleh diakses oleh aplikasi atau pengguna untuk mencari dan memanipulasi fail.

Tidak seperti UNIX, yang membezakan dengan jelas antara fail "biasa" dan fail peranti, Pelan 9 tidak mempunyai konsep ini sama sekali. Semua fail, tidak kira sama ada ia disimpan pada cakera atau dicipta oleh sesetengah pelayan fail, tertakluk kepada peraturan yang sama dan boleh diakses oleh mesin lain pada rangkaian. Dan jika anda menggali lebih dalam, ternyata tidak ada fail "biasa" yang disimpan pada cakera, kerana ia juga dieksport oleh pelayan fail yang melaksanakan pemacu sistem fail.

Semuanya adalah fail

Untuk memahami ideologi Pelan 9, bayangkan bahawa ruang nama ialah sistem fail UNIX (secara luaran ia kelihatan seperti ini), bermula pada akar, yang menempatkan direktori dan fail yang menyimpan aplikasi, perpustakaan, data pengguna, dll. Anda boleh menyambung ke mana-mana direktori sistem fail ini (menggunakan lekapkan arahan dan mengikat) lain pokok fail, tetapi dieksport bukan oleh pemacu sistem fail, seperti yang dilakukan dalam UNIX, tetapi oleh program bertulis khas yang dipanggil pelayan fail.

Pelayan fail boleh menjadi aplikasi peringkat pengguna atau komponen kernel. Pada dasarnya, ia hanyalah satu program yang melayani permintaan pelanggan yang diterima melalui protokol 9P. Oleh kerana 9P ialah protokol fail, maka program mesti mengekalkan senarai fail yang dieksport kepadanya (pada asasnya, titik masuk ke dalam program) dan menyampaikan sebarang permintaan untuk membuka/menutup, membaca/menulis mana-mana fail ini. Sebaik sahaja pelayan fail disambungkan ke ruang nama, semua fail yang dieksportnya tersedia untuk aplikasi lain, yang boleh menggunakan panggilan sistem kernel standard (seperti buka, baca, cari, dll.) untuk memanggil fungsi pelayan fail tertentu.

Ini semua sangat serupa dengan interaksi antara program dan perpustakaan fungsi, kecuali 9P menjadikan interaksi ini lebih fleksibel. Untuk menunjukkan fleksibiliti ini, mari ambil pelayan fail timbunan protokol TCP/IP, yang dilaksanakan dalam kernel dan dinamakan "#I". Dengan menyambungkannya ke direktori /net dan menjalankan arahan "ls /net" kita akan melihat sesuatu seperti ini:

% mengikat -a #I /net % ls /net /net/dns /net/ether /net/il /net/tcp /net/udp

Untuk menyambung ke mesin jauh menggunakan protokol TCP, kita mesti membuka fail /net/tcp/clone. Kemudian direktori kawalan sambungan akan muncul dalam direktori /net/tcp, dalam fail ctl yang mana kita boleh menulis arahan "sambungkan alamat IP", tulis permintaan ke fail data, dan kemudian, selepas membacanya, terima respons . Dalam bahasa penterjemah arahan Plan 9 semuanya kelihatan seperti ini:

<>/net/tcp/clone ( dir=/net/tcp/^`(cat<} echo connect 74.125.77.99!80 >$dir/ctl && ( echo "GET /search?q=Plan9&btnI=I""m+Feeling+Lucky HTTP/1.1" && echo "connection: close" && echo "host: www.google.com" && echo "" )>$dir/data kucing $dir/data )

Pada tahap yang rendah, semua kerja dengan fail dalam direktori /net akan dikurangkan kepada panggilan ke fungsi pelayan fail "#I", jadi buat masa ini kami tidak melihat apa-apa kelebihan di sini selain daripada kejelasan dan keupayaan untuk membuat sambungan secara langsung daripada baris arahan. Walau bagaimanapun, jika anda ingat bahawa semua akses fail dalam Pelan 9 berlaku melalui protokol 9P, peluang baharu akan terbuka. Jika kita mengimport direktori /net dari mesin jauh, kita pada dasarnya berakhir dengan NAT:

% import -a remote/net

Semua akses kepada fail dalam direktori /net akan dipindahkan ke mesin jauh, jadi ia akan bertanggungjawab untuk memulakan sambungan. Dan semua ini tanpa satu baris kod tambahan.

Tetapi bukan itu sahaja. Ruang nama yang digunakan untuk mengakses mana-mana fail OS adalah individu untuk setiap proses, tetapi boleh diwarisi daripada proses induk. Oleh itu, kami boleh mengawal akses aplikasi yang dipilih kepada fungsi rangkaian dengan hanya tidak menyambungkan pelayan fail "#I" ke ruang namanya. Kami boleh pergi lebih jauh dan memastikan bahawa aplikasi hanya mempunyai akses kepada yang kami tentukan protokol rangkaian dengan menetapkan kebenaran yang sesuai pada subdirektori direktori /net. Dengan menukar ruang nama, kami boleh mengawal sama ada direktori /net boleh diakses oleh mesin jauh atau tidak.

Tetapi dalam Pelan 9, pelayan fail ada di mana-mana. Ini bukan sahaja timbunan TCP/IP, tetapi juga sebarang pemacu, sistem fail, antara muka grafik tetingkap, pelayan mel dan banyak lagi. Mana-mana sumber Rancangan 9 diwakili oleh pelayan fail, manakala API teras hanya memperkenalkan fungsi untuk mencipta benang, bekerja dengan fail dan mengubah suai ruang nama. Dan setiap pelayan fail tertakluk kepada semua peraturan yang diterangkan di atas. Oleh itu, sistem fail /proc, yang menyediakan akses kepada proses sifat dan sumber, boleh digunakan untuk menyahpepijat proses, manakala mesin jauh mempunyai hak untuk menyambungkannya ke ruang namanya untuk penyahpepijatan jauh. Sesuatu proses boleh dikotak pasir dengan hanya mengubah suai ruang namanya dan teks yang diletakkan dalam tetingkap grafik menggunakan arahan kucing.

Protokol dan ruang nama 9P menjadikan Pelan 9 sebagai persekitaran yang ideal untuk mengatur sistem teragih. Mana-mana sumber OS, sama ada fail biasa, disimpan pada cakera, cakera itu sendiri, tetikus, papan kekunci, paparan, tetingkap grafik, sebarang peranti boleh diakses dari mesin jauh. Untuk mesin yang menjalankan Pelan 9, tidak kira di mana sumbernya berada: direktori /bin boleh ditempatkan secara fizikal pada satu mesin, yang lain boleh digunakan untuk menyimpan fail dan antara muka grafik boleh dijalankan pada yang ketiga. Pelan 9 membolehkan anda mencipta metakomputer yang besar, berkuasa dan tahan kerosakan daripada segelintir stesen kerja berprestasi rendah.

Keselamatan

Keselamatan Plan 9 juga berpunca daripada sifat pengedarannya. Walaupun pengguna tempatan mesin yang boleh log masuk hanya dari terminal mempunyai kebenaran penuh dan tidak terhad, semua pengguna lain yang cuba mengakses sumber OS dari mesin jauh dikehendaki mengesahkan diri mereka sendiri dengan mengemukakan sijil yang ditandatangani oleh pelayan sijil. Selepas ini, sambungan akan diwujudkan, dan semua mesej yang dihantar di dalamnya akan disulitkan.

Dengan menguruskan ruang nama, pemilik mesin boleh mengehadkan akses pengguna jauh kepada hanya julat fail dan direktori tertentu, dan, akibatnya, set sumber dan perkhidmatan yang diberikan kepadanya. Dalam kes ini, kebenaran pengguna sebenarnya dijalankan menggunakan pengurusan hak akses fail, dan tembok api tidak diperlukan pada dasarnya, kerana dalam rangkaian Pelan 9 semua sambungan berlaku menggunakan protokol 9P.

Pengaturcaraan

Konsep "semuanya adalah fail" sangat memudahkan sistem pengendalian dan menjadikan pengaturcaraan aplikasi lebih jelas dan lebih serba boleh.

Pelan 9 tidak membezakan antara sumber tempatan dan jauh, menghapuskan keperluan untuk pengaturcara menulis kod tambahan yang bertanggungjawab untuk kefungsian rangkaian. Apa yang perlu dilakukan oleh programnya ialah menulis dan membaca fail dan menyemak nilai pulangan. Pada masa yang sama, beliau mempunyai banyak perpustakaan khas yang berfungsi sebagai pembungkus antara muka fail banyak pelayan fail.

Antara muka pengaturcaraan Plan 9 terdiri daripada satu set kecil panggilan sistem kernel dan sejumlah besar fail berbeza yang dieksport oleh pelayan fail. Kebanyakan fail ini boleh digunakan tanpa sebarang pembalut, melalui panggilan terus ke fungsi seperti buka, tutup, baca, tulis dan cari. Ini menjadikan API mudah dan mudah diingati dan digunakan.

Antara muka fail boleh digunakan dari mana-mana bahasa pengaturcaraan tanpa perlu menulis kod gam tambahan. Oleh itu, menggunakan bahasa shell, seorang pengaturcara boleh mencipta analog yang setara dari segi fungsi bagi hampir mana-mana aplikasi yang tersedia dalam Pelan 9. Perkara yang sama boleh dikatakan untuk mana-mana bahasa lain.

Nota khusus ialah hakikat bahawa Pelan 9 tidak membezakan antara proses dan benang. Panggilan sistem rfork, yang direka untuk menghentikan proses, mengambil hujah yang boleh digunakan oleh pengaturcara untuk menentukan sumber proses induk yang boleh dikongsi dengan kanak-kanak, disalin atau dicipta semula. Ia membolehkan anda mengawal "berat" kanak-kanak dengan baik, yang boleh menjadi benang ringan yang berkongsi kebanyakan sumber dengan ibu bapa, atau proses lengkap yang set sumbernya berasingan. Panggilan sistem pertemuan memastikan penyegerakan proses, membolehkan anda mengatur saluran komunikasi, jenis lain kunci dan mekanisme untuk bertukar kepada keadaan siap sedia dan pengaktifan.

Inferno

Pada tahun 1995, Lucent Technologies, pemilik baharu makmal penyelidikan Bell Labs, memindahkan banyak pembangun Plan 9 kepada pasukan lain, yang mula mencipta sistem pengendalian Inferno, dibina berdasarkan Pelan 9. Pengurusan syarikat, bukan tanpa sebab, percaya bahawa Pelan 9, mampu telus dan mudah dijalankan pada komputer yang dianjurkan dalam rangkaian pengkomputeran yang diedarkan, ia akan berfungsi dengan baik pada peranti mudah alih dan terminal berkuasa rendah, yang pada masa itu hanya diwajibkan untuk memunggah bahagian terbesar fungsi mereka untuk mesin lain untuk memastikan prestasi optimum dan kemudahan penggunaan.

Hasilnya ialah Inferno, sistem pengendalian yang mengambil semua manfaat Pelan 9 dan mempunyai beberapa ciri unik. OS baharu adalah berdasarkan kernel Plan 9 yang dilucutkan dengan reka bentuk semula subsistem grafik, di atas ialah mesin maya Dis berprestasi tinggi yang direka untuk melaksanakan kod bait bebas pemproses mudah alih, dan bahasa pengaturcaraan aplikasi ialah Limbo, bahasa modular peringkat tinggi dengan sokongan terbina dalam pengaturcaraan berbilang benang. Di samping itu, Inferno mempunyai keupayaan untuk dijalankan bukan sahaja pada banyak seni bina pemproses, tetapi juga untuk menjadi aplikasi dalam sistem pengendalian sedia ada seperti Windows, Linux, Solaris, AIX dan lain-lain.

Ciri-ciri ini menjadikan Inferno sebagai platform yang ideal untuk mengatur pelbagai jenis sistem yang diedarkan. Inferno benar-benar bekerja pada segala-galanya, membolehkan aplikasi dipindahkan antara platform bukan sahaja tanpa pengubahsuaian, tetapi juga tanpa penyusunan semula. Protokol 9P (dinamakan semula Styx) menyediakan cara yang mudah dan bersatu untuk mengakses sumber. Bahasa Limbo menjadikan pembangunan aplikasi selari menyeronokkan.

Mesin maya

Walaupun penggunaan mesin maya (VM), yang secara teori sepatutnya menyebabkan penurunan mendadak dalam kelajuan pelaksanaan aplikasi, sistem pengendalian menunjukkan prestasi yang mengagumkan. Dan terdapat penjelasan mudah untuk ini: Inferno ialah produk komersial, jadi apabila mereka bentuk Dis, penyelidik dari Bell Labs menentang prinsip dan melakukan segala-galanya untuk menjadikan VM lebih menarik, dari sudut pandangan komersial, teknologi. Akibatnya, Dis memperoleh ciri-ciri berikut:

1. Dis ialah mesin maya memori-ke-memori. Tidak seperti Java VM dan banyak mesin maya bertindan lain, Dis mempunyai seni bina JIT yang paling optimum untuk pelaksanaan. Walaupun prestasi Dis dalam mod tafsiran adalah lebih rendah daripada mesin maya bertindan, pengkompil JITnya dengan mudah mengatasi prestasi rakan sejawatannya dalam mesin maya bertindan, dan tahap penggunaan memori kekal minimum. Seni bina memori-ke-ingatan menambah kerumitan kepada pengkompil, tetapi membolehkan pengkompil JIT yang lebih ringkas dan lebih pantas.
2. Set arahan mesin maya adalah sedekat mungkin dengan set arahan pemproses moden. Ini bermakna untuk mentafsirkan bilangan arahan yang cukup besar, mesin maya hanya perlu melaksanakan 1-2 arahan daripada pemproses sasaran (bukannya 10-20 dalam VM lain).
3. Dis melaksanakan set arahan tahap tinggi yang berlebihan (mesin CISC) dan bukannya yang minimum dan hanya perlu (mesin RISC, yang merangkumi kebanyakan VM lain). Bersama-sama dengan arahan peringkat rendah seperti penambahan, penolakan, pendaraban, anjakan, lompatan, dsb., kamus Dis terdiri daripada arahan untuk bekerja dengan saluran, senarai, tatasusunan, arahan untuk membangkitkan benang, memuatkan modul, dsb. Kesemuanya membantu mempercepatkan pelaksanaan aplikasi yang ditulis dalam Limbo, tetapi tidak sama sekali mengikat mesin maya kepada satu bahasa.
4. Dis menggunakan pengumpul sampah hibrid. Kebanyakan sampah dikumpul menggunakan pengiraan rujukan, manakala pengumpul bendera mengumpul data dalam masa nyata. Tidak seperti Java VM dan lain-lain, set arahan Dis tidak menimbulkan kesukaran dalam menjejaki rujukan kepada objek yang disalin, yang bermaksud bahawa memori boleh dibebaskan tanpa berlengah-lengah dan panggilan kepada pengumpul penanda ditangguhkan.
5. Komponen sistem pengendalian Inferno yang paling memerlukan sumber dilaksanakan dalam bahasa C. Inferno mempunyai tujuh modul terbina dalam, termasuk sys (panggilan sistem dan fungsi yang kerap digunakan), lukis (bekerja dengan penyesuai video dan primitif grafik), Tk (perpustakaan widget grafik di mana antara muka kebanyakan aplikasi dibina), freetype (font rasterizer) dan keyring (penyulitan algoritma, bekerja dengan sijil, dsb.). Setiap daripada mereka dilaksanakan dalam bahasa C dan oleh itu dilaksanakan pada kelajuan maksimum yang mungkin.

Limbo

Selain kemudahalihan dan prestasi, Inferno mempunyai satu lagi ciri yang sangat penting: kehadiran bahasa pengaturcaraan aplikasi Limbo, yang dibangunkan dari awal khusus untuk Inferno dan hanya wujud dalam OS ini. Sintaksnya sebahagian besarnya mengulangi sintaks C, tetapi mempunyai kemasukan daripada banyak bahasa lain. Ciri-ciri bahasa ini agak luar biasa, tetapi lebih daripada munasabah.

1. Kuat menaip. Limbo ialah bahasa yang ditaip kuat, yang bermaksud bahawa ia tidak mempunyai penunjuk seperti C (terdapat pautan, tetapi anda tidak boleh menulis alamat sewenang-wenangnya di dalamnya), tiada penukaran jenis tersirat (manakala yang eksplisit sentiasa memberikan hasil yang diharapkan) . Pemeriksaan jenis dilakukan pada masa penyusunan dan pada masa jalan. Semua ini menyumbang kepada peningkatan keselamatan dan tingkah laku aplikasi yang lebih dijangka, dan juga membolehkan anda meninggalkan penggunaan unit pemproses MMU untuk mengasingkan proses/benang ini dan dengan itu meningkatkan prestasi OS (Inferno, pada dasarnya, tidak membenarkan kod pihak ketiga untuk dilaksanakan di bawah mesin maya).
2. Modul Limbo ialah bahasa modular, yang, ditambah dengan gaya pengisytiharan/permulaan berubah-ubah, menjadikannya serupa dengan bahasa Modula. Semasa anda mula belajar Inferno, anda akan perasan bahawa tiada konsep fail boleh laku dan perpustakaan. Semua kod bait Dis yang disusun disimpan dalam modul, setiap satunya boleh dilancarkan dari baris arahan atau digunakan oleh modul lain sebagai perpustakaan fungsi. Dalam kes ini, kod modul dilaksanakan dalam benang yang berasingan, tidak diduplikasi dalam ingatan dan boleh dimuatkan beberapa kali. Jika anda telah bekerja dengan sistem operasi Oberon dan AOS, maka anda akan faham apa yang saya maksudkan.
3. Sokongan pengaturcaraan selari. Limbo mengesan asal-usulnya ke Newsqueak, yang nenek moyangnya ialah Squeak, bahasa pengaturcaraan selari eksperimen Rob Pike. Bahasa ini menggalakkan penciptaan aplikasi berbilang benang, memudahkan ini dalam setiap cara yang mungkin. Oleh itu, Limbo (dan, sewajarnya, Dis) mempunyai sokongan terbina dalam untuk saluran dwiarah (buffered dan unbuffered), operator untuk mencipta benang baru dan operator pemilihan saluran alt, yang serupa dengan tujuan panggilan sistem epoll di Linux, kqueue dalam FreeBSD dan /dev/ tinjauan pendapat dalam Solaris.
4. Reka bentuk tahap tinggi. Limbo menyokong jenis data seperti rentetan, senarai, tupel dan jenis data abstrak (semacam struktur yang boleh merangkum bukan sahaja data tetapi juga berfungsi), serta binaan khas untuk bekerja dengannya. Oleh itu, rentetan boleh ditambah, dibandingkan, dipangkas, ditukar menjadi tatasusunan, senarai boleh diproses menggunakan binaan bahasa untuk mendapatkan kepala dan ekornya, tupel boleh ditukar menjadi tatasusunan, dsb.

Kod berikut, yang disiarkan di tapak web Vita Nuova (pemilik semasa Inferno, http://www.vitanuova.com), menunjukkan cara Limbo berfungsi dengan strim dan saluran:

melaksanakan Pemasa2; sertakan "sys.m"; sys: Sys; sertakan "draw.m"; Pemasa2: modul ( init: fn (nil: ref Draw->Context, argv: list of string); ); init(nil: ref Draw->Context, argv: list of string) ( sys = muat Sys->PATH; sync:= chan of int; n:= len argv; spawn timer(sync, n); sys-> print("Parameter Baris Perintah\n"); untuk (i:= 0; i< n; i++) { <-sync; sys->print("%d: %s\n", i, hd argv); argv = tl argv; ) ) pemasa(segerak: chan of int, n: int) ( untuk (i:= 0; i< n; i++) { sys->tidur(1000); penyegerakan<-= 1; } }

Pelaksanaan aplikasi bermula dengan fungsi init(). Baris "sync:= chan of int;" mencipta saluran untuk menghantar mesej jenis int. Menggunakan operator spawn, benang baharu dihasilkan, melaksanakan fungsi pemasa, yang menghantar mesej "1" ke saluran setiap saat. Dalam kes ini, proses induk memasuki gelung yang menyekat sehingga mesej muncul dalam saluran (<-sync;) , а после этого печатает аргумент командной строки. Количество проходов цикла равно количеству аргументов командной строки, а результатом программы будет печать всех аргументов с интервалом в одну секунду.

Keserasian

Mempunyai mesin maya dan bahasa baharu, Inferno tidak kehilangan keserasian dengan aplikasi sedia ada. Berjalan di atas OS lain, Inferno membolehkan anda memanggil aplikasi lain OS itu menggunakan antara muka khas, jadi dalam kes di mana Inferno digunakan sebagai platform untuk mencipta aplikasi yang diedarkan, aplikasi sedia ada boleh dilancarkan tanpa sebarang perubahan dalam persekitaran Inferno. Antara muka modul terbina dalam membolehkan anda membenamkan sebarang kod C ke dalam teras Inferno, mencipta antara muka untuk mengakses kod ini daripada Limbo, dan dengan itu mengembangkan kefungsian persekitaran masa jalan. Kit ini termasuk pelaksanaan protokol 9P/Styx yang ditulis dalam C untuk platform yang mematuhi POSIX. Tugasnya: untuk menyambungkan Inferno dengan mana-mana aplikasi luaran, kedua-duanya dalam satu OS dan dari jauh.

Kesimpulan

Pelan 9 ialah sistem pengendalian yang sangat fleksibel, tetapi ia memerlukan pemikiran semula prinsip membina sistem perisian. Hari ini ia digunakan oleh ramai peminat di seluruh dunia sebagai OS yang diedarkan. IBM menjalankan Pelan 9 dan beberapa komponen Inferno pada salah satu sistem superkomputer Blue Gene/Lnya, dibina dengan 64,000 pemproses. Pelan 9 digunakan untuk mengawal sistem lampu stadium di Sukan Olimpik Sydney 2000. Ia adalah OS hidup yang mungkin menjadi masa depan jika nichenya tidak diduduki oleh UNIX, yang, menurut Eric Steven Raymond, "berderit, berderit, dan mempunyai kesan karat yang jelas, tetapi ia berfungsi dengan cukup baik untuk mengekalkan kedudukan kami. ."

Pada masa yang sama, Pelan 9 meninggalkan tandanya pada UNIX. Panggilan sistem rfork dalam FreeBSD dan klon dalam Linux dimodelkan selepas rakan sejawatannya Pelan 9, sistem fail /proc dalam Linux dan FreeBSD dipinjam daripada Pelan 9, sistem fail /sys dalam Linux mengikuti rapat model pelayan fail Plan 9, menyediakan cara mendapatkan maklumat perkakasan tanpa menggunakan panggilan ioctl. UTF-8, yang digunakan hari ini dalam segala-galanya daripada sistem pengendalian UNIX kepada aplikasi Web, telah dicipta untuk digunakan dalam Pelan 9.

Inferno, sebaliknya, boleh menjadi platform yang sangat baik, produktif, difikirkan dengan baik dan mesra pengaturcara yang boleh mengatasi Java dan C# digabungkan. Ia boleh bersaing dengan erlang dan akan menjadi OS yang sangat baik untuk peranti terbenam. Tetapi semua ini tidak berlaku kerana pengiklanan yang tidak seberapa, harga yang melambung tinggi, kebodohan syarikat pemilik dan nama yang menjijikkan dari sudut pemasaran.

Inferno mempunyai banyak kelebihan berbanding platform lain, tetapi memahami falsafahnya, apatah lagi menukar, memerlukan perubahan perspektif yang sangat drastik, yang dalam kebanyakan kes tidak ada masa atau wang untuknya. Jika anda ingin mencari idea Inferno dalam dunia moden, kemudian lihat Android, yang mempunyai mesin maya yang serupa dengan Dis, menggunakan komponen C untuk meningkatkan prestasi, malah mempunyai mekanisme penghantaran mesej untuk komunikasi proses.