MINIX

Minix 3

Sejarah MINIX

Banyak profesor-propesor universitas menyesali UNIX tidak bisa lagi digunakan dalam pembelajaran sistem operasi, akan tetapi ia tetap digunakan dikarenakan tidak ada pilihan pembelajaran sistem operasi. Salah satu propesor, Andrew Tanenbaum, di Vrije Universiteit di Amsterdam, Netherlands, mencari dan membeli sebuah IBM PC, dan seperti halnya Ken Thompson pada satu dekade sebelumnya, membuat sistem operasi baru berdasarkan penelitian. Sama seperti Thompson yang diilhami oleh MULTICS, tetapi sepenuhnya membuat sistem operasi yang yang lebih kecil dan baru, Tanenbaum diilhami oleh UNIX, tetapi juga sepenuhnya membuat sistem operasi yang baru dan lebih kecil – MINIX – dimana mewakili Mini-UNIX.

Sejak MINIX tidak berisi kode AT&T , menyerah pada batasan – batasan lisensi AT&T. Sumber kode dibuat secara luas tersedia untuk universitas untuk pembelajaran dan lainnya. Seperti halnya UNIX,  MINIX dengann cepat mendapatkan respon yang bagus dan mulai menguasai pasar UNIX – sistem operasi yang kecil tersedia dengan semua sumber kode yang dapat digunakan untuk pembelajaran dan dapat diubah sesuai yang diinginkan.

Sejak satu bulan setelah dipasarkannya minix pada januari 1987, menjadi topik yang menarik untuk diperbincangkan di seluruh dunia sehingga suatu kelompok berita yang bernama (comp.os.minix) mempersiapkan USENET sebagai  suatu jaringan komputer yang dapat diakses oleh sebagian besar universitas dan perusahaan komputer yang berada di  Amerika Utara, Eropa, Jepang, Australia, dan di negara – negara lainnya. setelah beberapa bulan kemudian,  kelompok  berita tersebut memiliki 10,000 orang member yang mendukung keberadaan minix sebagai suatu pembelajaran OS. 

Awal pelepasan MINIX hanya untuk IBM PC dan PC/AT saja. Keadaan ini tidak berlangsung lama sebelum orang – orang dengan komputer yang bermacam jenis mulai memikirkan untuk menggunakannya dalam PC mereka. Port yang pertama 68000 mesin dasar, Atari ST, menyelesaikan yang utamannya oleh Johan Stevenson, dengan bantuan Jost Muller bagian keras dari MINIX, dimana, seperti UNIX, melakukan berbagai macam proses untuk melakukannya secara serempak, menjalankannya di 68000, tanpa adanya manajemen memori atau penampungan perangkat keras. Pada saat masalah ini telah dipecahkan dan sarana I/O yang baru membuat keyboard Atari, layar, disk, dll.MINIX-ST menjadi kenyataan. Atari versi 1.5 disiapkan oleh Frans Meulenbroeks.

Port Commodore Amiga dibuat oleh Raymond Michiels dan Steven Reiz sedangkan port Macintosh dibuat oleh Yusuf Pickert. Tidak seperti halnya port yang lain, port versi Macintosh tidak melakuakn penggantian sistem operasi pabrikan itu dandapat dijialankan tanpa menggunakan SO. Sebagai gantinya, pada port Macintosh sistem operasi digunakan pada akhir proses, memberikan fasilitas untuk bisa menggunakan sistem secara bersamaan. keadaan itu semua tentu saja ada sesuatu yang harus dibayar untuk menperolehnya dalam kaitan dengan menggunakan persamaan ukuran kinerja.

Peranan yang diberikan USENET tidak bisa diremehkan dalam pengembangan MINIX. Ratusan individu sudah menyumbangkan gagasan-gagasan, bug fixes, dan perangkat lunak, banyak darinya sudah termasukdidalamnya. Seseorang yang menonjol di atas semua, Bruce Evans, yang sudah menghasilkan kemajuan juga yang terlalu banyak untuk dihitung, dan dengan cara yang sangat profesional. Pengarang-pengarang itu dihargai karena gagasan – gagasan mereka, di mana yang secara teknis mungkin.

MINIX merupakan system operasi yang masih terus dikembangkan secara periodic, dengan perangkat lunak yang baru, port-port ke komputer – komputer baru, dan masih banyak lagi pengembangan yang lebih bagus lainnya. Saat ini, MINIX merupakan system operasi yang berbeda dibandingkan dengan kebanyakan perangkat lunak yang lainnya. Pada umumnya model yang dihasilkan oleh perusahaan merupakan gagasan – gagasan untuk sebah produk, membuat perangkat lunak, kemudian mengenalkan ke customer untuk digunakan. Para pemakai tidak diperbolehkan untuk memodifikasi program, dan penolakan permintaan sumber kode. Diskusi publik tentang sistim internal tidak mendapatkan sambutan yang bagus.

MINIX,  jika dibandingkan dengan system lainnya, pendekatan MINIX lebih terbuka. Source program untuk seluruh sistem operasi adalah tercakup di paket software dasar, dan para pemakai motivasi untuk merangkai sistim itu sesuai dengan kebutuhannya. Ribuan orang-orang di USENET sudah melakukan hal tersebut.

Operating System Reliability

Di dalam pandangan kita, satu-satunya cara untuk memperbaiki kehandalan sistem operasi adalah dengan mendapatkan lnput dari model sistem operasi yang berjalan di dalam kernel, yang setiap baris instruksinya dapat dieksekusi dalam sistem. Hampir semua kemampuan sistem operasi, terutama semua driver piranti harus dipindahkan ke proses-proses mode pengguna,  dan meninggalkan suatu microkernel kecil yang dijalankan di dalam kernel. Dalam menggerakkan seluruh  sistem operasi, suatu mode pengguna seperti di Linux melakukan rebooting kembali sistem operasi setelah terjadi penurunan drastis dengan cepat, tetapi tidak menimbulkan permasalahan pada setiap baris instruksinya, sehingga yang diperlukan adalah dengan membagi inti dari sistem operasi functionality-including  sistim file, manajemen proses, dan graphics-into berbagai proses-proses yang ada, meletakkan masing-masing driver piranti di suatu proses yang terpisah, dengan pengontrolan yang sangat ketat sehingga masing-masing komponen juga dapat melakukannya. Jadi hanya dengan arsitektur seperti itulah  kita dapat memperbaiki keandalan suatu sistem.

Alasan pengaturan modular seperti di atas dapat menghasilkan disain multiserver menjadi lebih baik dibanding suatu desain yang monolitis. Pengaturan yang pertama, yaitu dengan menjalankan banyak kode dari mode pengguna ke inti gaya dari sistem komputer, kita tidak mengurangi banyaknya bugs tetapi kita mengurangi tenaga dari tiap bugs yang menyebabkan kerusakan. Bugs di dalam proses-proses mode pengguna mempunyai sangat sedikit peluang ke struktur data inti dan tidak dapat menyentuh alat-alat perangkat keras yang tidak diperbolehkan.  Penurunan drastis yang fatal dari suatu proses mode pengguna jarang terjadi, sedangkan suatu penurunan drastis dari inti  selalu terjadi.

Dengan adanya patahan sistem operasi ke dalam banyak proses, maka masing-masing proses tersebut menunjuk pada suatu ruang spasi, sehingga kesalahan-kesalahan yang ditimbulkan dapat kita batasi. Suatu bug yang ada di dalam  audio dapat diputar dan didengarkan, tetapi  tidak dapat menghapus sistem file yang telah ada. Pada suatu sistem yang monolitis, bug-bug yang ada di dalam setiap fungsi  dapat menghancurkan kode dan struktur data yang ada di dalamnya yang fungsinya tidak saling berkaitan dimana fungsinya jauh lebih kritis.

Dengan membangun sistem berdasarkan kumpulan proses-proses user mode, fungsi dari masing-masing mesin bisa dibersihkan secara pasti dan membuat segala jenis sistem lebih mudah dimengerti dan diimplementasikan. Sebagai maintibilitas dari sistem operasi akan meningkat, kerena modulnya dapat mengatur secara bebas dari modul yang lainnya selama interface dan struktur data yang terhubung saling merespon.

Selama artikel tidak terfokus kepada keamanan secara langsung, ini penting untuk mendefinisikan bahwa kehandalan dan keamanan sistem operasi sangat berhubungan erat.  Sistem keamanan biasanya dirancang dengan bayangan model sistem multi-user, bukan sistem  single-user dimana user tersebut akan menjalankan kode hostile. Bagaimanapun, kebanyakan masalah-masalah keamanan disebabkan oleh kode yang tidak dikenal yang terinfeksi oleh virus dan worm yang dipenuhi oleh bug seperti buffer overruns. Dengan memindahkan sebagian besar kode dari intinya, Oleh  eksploitasi dari komponen sistem operasi yang disalurkan kurang terlalu kuat. Kelebihan penulisan tumpukan pada  driver audio mengakibatkan terjadinya kekacauan pada komputer yang menimbulkan suara gaduh,  tetapi  berkompromi dengan sistem keamanan, karena pengendali audio tidak mempunyai superuser yang istimewa. Jadi, dengan demikian, selagi kita tidak akan mendiskusikan masalah keamanan, desain kita memiliki potensi yang  besar untuk memperbaiki keamanan.

The MINIX 3 Architecture

Untuk menguji gagasan – gagasan yang kita keluarkan , kita memiliki struktur/kontruksi suatu system prototipe POSIX-conformant. Sebagai dasar untuk menggunakan prototipe, kita menggunakan system operasi MINIX karena ukuran nya yang sangat kecil dan dapat menampung banyak history. MINIX merupakan suatu system operasi tanpa microkernelbased yang lahir dengan source code yang lengkap, kebanyakan ditulis di C. Versi awal MINIX ditulis oleh salah satu pengarang (AST)  pada tahun 1987, dan sudah dipelajari oleh lebih dari sepuluh ribu siswa dari seratus univesitas dalam kurun waktu 19 tahun. Lebih dari 10 tahun  di sana telah hampir tidak ada bug reports  mengenai kernel, kiranya  karena ukuran nya yang kecil.

Kita memulai dengan MINIX 2 dan untuk memodifikasinya sangatlah susah, menggerakkan  control – control kernel dan lebih banyak lagi, tetapi kita memutuskan untuk menyimpan nama  dan menyebutnya sistem baru MINIX 3. Itu didasarkan pada suatu microkernel sekarang yang  berisi  di bawah 4000 LoC, dengan banyak server-server mode pengguna dan control – controlnya bersama-sama melembagakan sistem operasi, seperti yang digambarkan di dalam Gambar 1. Meskipun struktur ini diluar kebiasaan , kepada pengguna sistem hanya muncul   varian UNIX lainnya. Sistem tersebut menjalankan dua compiler C (ACK dan gcc), sama bagusnya dengan banyaknya utilities—Emacs yang populer, vi, Perl, Piton, Telnet, FTP, dan 300 jenis lain. Baru-baru ini, X Windows telah terhubung dengan strukturnya. MINIX 3 tersedia  pada http://www.minix3.org dengan semua source code di bawah pengawasan BSD .

Pendekatan yang digunakan oleh MINIX 3 untuk mencapai keandalan tinggi adalah dengan cara pengasingan kesalahan. Khususnya, tidak seperti OS tradisional, di mana semua kode terhubung ke dalam suatu biner yang sangat besar yang berjalan di dalam mode kernel, di MINIX 3, hanya beberapa bit code yang berjalan di kerner mode, kira – kira 4000. Kode ini menangani interrupts, penjadwalan proses, dan komunikasi interproses. Sisa dari sistem operasi berjalan sebagai koleksi dari proses-proses mode pengguna, masing-masing di encapsulated oleh perangkat keras MMU dan tak satupun dari mereka yang berjalan sebagai superuser. Salah satu prosesnya, menyisipkan server reinkarnasi, serta menggunakan tab-tab pada yang lainnya dan ketika salah satunya mulai bertindak mengesalkan atau penurunan kemampuan, itu secara otomatis digantikan deangan versi yang lebih segar. Karena banyak bug yang bersifat sementara, yang bertindak berdasarkan pemilihan waktu yang tidak biasa, pada umumnya, merestart komponen yang salah memecahkan masalah dan membiarkan sistim untuk memperbaiki dirinya sendiri tanpa reboot dan tanpa pemberitahuan dari pengguna. Properti ini menyebutnya penyembuhan diri sendiri, dan sistem tradisional tidak mempunyai itu.

Struktur dari MINIX 3 ditunjukkan di Fig. 1.Itu dibangun sebagai rangkaian lapisan-lapisan. Pada bagian dasar, mikrokernel berjalan di mode kernel, terdiri dari kira – kira 3000 bentuk dari C dan 800 bentuk kumpulan. Sebelum ia menjadi lapisan dari driver peranti, dengan masing-masing driver dalam proses user-mode yang terpisah untuk menggantikannya itu harus gagal. Lalu menjadi server-server, form yang mana inti dari sistem operasi. Server reinkarnasi diatas termasuk, server file, manajer proses, dan yang lain, termasuk server X, penyimpan data, dan yang lainnya. Akhirnya, pada bagian atas menjadi proses-proses pengguna. Meski secara internal, MINIX 3 secara keseluruhan sangat berbeda dari  sistem UNIX lainnya, itu didukung oleh standard antarmuka POSIX untuk aplikasi-aplikasi, perangkat lunak UNIX yang normal dapat di ported dengan mudah.

Dengan singkat, microkernel menangani perangkat keras yang mengganggu, memori low-level manajemen, penjadwalan proses, dan komunikasi interproses. Belakangan disempurnakan oleh primitif bahwa mengizinkan proses-proses untuk mengirimkan fixedlength  pesan-pesan untuk meminta proses-proses lain yang ditulis untuk dikirim kembali. Komunikasi yang lebih synchronous, dengan suatu pengeblokan pengirim atau penerima jika  bagian yang lain tidak siap. Mengirimkan suatu pesan dengan mengambil sekitar 500 nsec pada 2,2GHz Athlon. Meskipun suatu system call biasanya mengambil dua pesan (request dan reply), rata-rata 10,000 sistem calls/sec akan menggunakan hanya 1% dari  CPU, maka jalur pesan yang melebihi control mempengaruhi kinerja semuanya. Di dalam penambahan, ada suatu mekanisme pemberitahuan peristiwa yang tidak diblok. Menunggu keputusan yang tersimpan rapi pada suatu bitmap yang dinyatakan secara statis sebagai  bagian dari tabel proses. Pesan ini melalui skema eliminasi semua kernel buffer manajemen dan kernel buffer overrun, sama halnya dengan banyaknya deadlock.

Pada level berikutnya berisi device driver, satu per mayor device. Masing-masing driver adalah user process dilindungi oleh MMU dan user diproses yang sama biasanya dilindungi juga. Mereka adalah proses yang khusus dimana mereka diberikan jalan untuk membuat kernel calls dalam jumlah yang kecil untuk mengambil service kernel.tipikal dari kernel calls adalah me atau meminta data dikopikan atau dari proses user. Suatu bitmap didalam table control proses kernel dimana pemanggilan setiap driver(dan server) bias dibuat. Dan juga, kernel dapat mengetahui dimana port driver I/O diijinkan untuk digunakan, dan mengcopynya mungkin dengan ijin yang tegas.

interface sistem operasi dibentuk oleh satu set server. Yang paling utama adalah  file server, manajer proses, dan reincarnation server . User Processes  membuat system call POSIX  dengan mengirimkan suatu pesan kepada salah satu server tersebut, yang kemudian mengakhiri panggilan.  Reincarnation server  merupakan sistem yang utama dan berbeda dengan sistem lainnya, karena ia merupakan induk proses dari semua server dan drivers. Ia berasal dari unit yang berbeda, yang merupakan akar dari ordinary user process, serta dapat mengatur dan menjaga sistem operasi. Jika suatu server atau driver crashes atau pengeluaran lainya, itu akan menjadi suatu sistem yang tidak berguna sampai reincarnation server mengumpulkannya, di mana setiap waktu reincarnation server melihat tabel-tabel yang ada guna menentukan tindakan yang harus dilakukan. Tindakan umum yang dilakukan adalah membuat driver atau server yang baru dan menginformasikannya proses-proses yang lain untuk melakukannya.

Akhirnya, kita memiliki sebuah ordinary user process, yang memiliki kemampuan untuk mengirimkan fixed-length massages kepada sebagian layanan server yang membutuhkan, tetapi tidak memiliki kemampuan lain yang mendasar.

User View

Dilihat dari segi tampilannya MINIX 3 terlihat seperti UNIX, hanya saja sedikit lebih besar. Dengan munculnya MINIX 3 sistemnya hampir sama dengan UNIX yaitu sekitar 400 program standard yang dimiliki oleh UNIX diantaranya yaitu :

Shells: ash, bash, pdksh, rsh

Editors: emacs, nvi, vim, elvis, elle, mined, sed, ed, ex

Language tools: cc, gcc, g++, bison, flex, perl, python, yacc

Programming tools: cdiff, make, patch, tar, touch

Networking: ssh, telnet, ftp, lynx, mail, rlogin, wget, pine

File utilities: cat, cp, bzip2, compress, mv, dd, uue, GNU utilities

Text utilities: grep, head, paste, prep, sort, spell, tail

Administration: adduser, cron, fdisk, mknod, mount, cvs, rcs

Games: dungeon, nethack

Pada saat ini  user interfacenya hanyalah X, tetapi terkadang GUI bisa ditambahkan jika lightweight yang sesuai dengan  GUI dapat ditemukan. Berikut ini adalah contoh screenshoot dari MINIX3 :

Living with Programming Restrictions

Kita akan menunjukan sebagian dari properti, kelebihan, dan kelemahan-kelemahan dari model programming, tetapi sebelum kita mulai, mengingat kembali kegunaannya, berdasarkan sejarahnya, batasan–batasan programmer dalam membangun sebuah program. Marilah kita lihat beberapa contoh diantaranya:

Pertama, ketika MMU pertama muncul, pengguna diharuskan membuat systen call untuk menjalankan I/O, dibanding harus menjalankan I/O itu sendiri. Adanya masalah yang membuat kernel call berjalan lebih lambat dibandingkan dengan komunikasi I/O secara langsung, tetapi hasil yang akhirnya muncul adalah batasan terhadap seorang programmer dalam melakukan kinerja yang kecil, karena bug-bug di dalam kode pengguna tidak bisa lagi dirubah.

Ke dua, ketika E.W. Dijkstra menulis pernyataan yang dikenal hingga sekarang “Goto Statement Considered Harmful” [10], masalah – masalah yang sering dialami kebanyakan programmer adalah gagalnya mereka di gaya penulisankode program. Meskipun pada mulanya keberatan, gagasan tersebut berguna juga, dan programmer belajar membuat struktur program yang benar.

Ketiga, ketika pemrograman berorientasi objek diperkenalkan, banyak programmer yang menolak gagasan, sejak mereka tidak bisa lagi mengubah struktur data internal ke object yang lain, pada hal praktek sebelumnya atas dasar efisiensi. Sebagai contoh, ketika Java diperkenalkan kepada programmer C, banyak di antara mereka melihatnya sebagai suatu keterkaitan, karena mereka tidak bisa lagi dengan bebas mengolah penunjuk. Meskipun demikian, pemrograman berorientasi objek sekarang menjadi sesuatu yang biasa dan mempunyai peranan penting untuk menjadikan kualitas kode yang lebih baik.

The MINIX 3 Restrictions

Model programing MINIX 3 juga lebih membatasi untuk pengembangan sistem operasi dibandingkan dengan apa menanganinya, tetapi kita percaya batasan-batasan pada akhirnya menuju ke sistem yang lebih handal. Untuk sementara waktu, MINIX 3 dibuat di C, tetapi beberapa modul dibuat ulang dengan menggunakan bahasa yang lebih aman, seperti Cyclone, mungkin akan terjadi nanti. Marilah kita mulai gambaran model kita dengan memperhatikan sebagian dari batasan ini.

Restricted kernel access. Kernel MINIX 3 mengirim berbagai kernel call untuk mendukung server user mode dan driver sistem operasi. jika digunakan masing-masing driver dan server mempunyai bitmap di dalam tabel proses yang membatasi dengan kernel call. Perlindungan sangat berat sekali, jadi sebagai contoh, suatu peranti driver bisa saja mempunyai punya ijin untuk menjalankan I/O atau membuat salinan dan dari user-processes, tetapi tidak mamatikan sistim, membuat proses-proses baru,  atau mengeset ulang batasan kebijakan.

Memory protection. Di dalam rancangan multiserver MINIX 3, semua server dan driver sistem operasi berjalan sebagai pemisah proses user-mode. Masing-masing encapsulated di alamat pribadi yang dilindungi oleh perangkat keras MMU. Percobaan akses secara ilegal ke proses memory yang lain akan menaikkan MMU tanpa terkecuali dan pelanggar akan dihentikan oleh manajer proses.Sistim file dan peranti driver perlu berkomunikasi untuk menjalankan peranti I/O, tetapi oleh kernel, penggunaan media safe virtual copies akan diakhiri. Salinan ke proses yang lain dimungkinkan hanya jika pada saat proses dengan jelas memberi ijin seperti sistim file. Desain ini menyingkirkan kepercayaan dari driver dan mencegah perubahan memori.

Restricted I/O port access. Masing-masing driver mempunyai batasan port-port I/O yang bisa diakses. Karena proses-proses pengguna tidak mempunyai I/O yang istimewa, kernel harus memediakannya dan memeriksa permintaan I/O yang diizinkan. Batas port yang bisa diakses, diatur pada saat driver mulai bekerja. Untuk ISA device dilakukan dengan bantuan konfigurasi file; Untuk PCI devices, batasan port secara otomatis akan ditentukan oleh PCI bus server. Batasan port yang untuk masing-masing driver disimpan di dalam masukan tabel proses driver di dalam kernel. Perlindungan ini memastikan printer driver tidak membuat hal yang tidak perlu ke disk, baik yang disengaja maupun tidak sengaja, karena setiap percobaan yang dibuat yang ingin disimpan ke disk, akan dinyatakan kegagalan kernel call oleh port I/O. Server dan proses-proses user yang biasa tidak memiliki akses ke setiap port I/O.

Restricted interprocess communication. Proses tidak akan mengirimkan pesan-pesan ke sembarang proses. Lalu, kernel mengijinkan siapa yang mengirim ke siapa, dan pencegahan terhadap pelanggaran-pelanggaran. IPC sederhana dan tujuan yang diijinkan diatur oleh  server reinkarnasi pada saat  proses sistim yang baru mulai bekerja. Sebagai contoh, driver mengijinkan berkomunikasi hanya dengan file server saja dan bukan dengan proses yang lain. Fitur ini menghapus beberapa bug yang mana proses mencoba untuk mengirimkan pesan yang tidak diharapkan ke proses yang lain.

Operating System Development in User Space

Beberapa  aspek yang lain dari MINIX 3 programming model. Walaupun ada beberapa pembatasan, seperti yang ditunjukkan di atas, kita percaya bahwa memprogram di suatu lingkungan sistem operasi multiserver mempunyai banyak manfaat dan boleh menjurus kepada produktivitas yang lebih tinggi dan mutu kode yang lebih baik.

Short development cycle (Dengan pengembangan yang sangat cepat). Perbedaan yang sangat besar antara suatu yang monolithic dan suatu sistem operasi multiserver adalah mereka dengan segera memperbaikai sistem yang dimiliki ketika memperhatikan siklus pengembangan dari komponen-komponen sistem operasi. Programming sistem di suatu sistem yang monolithic secara umum melibatkan editing, penyusunan, pembangunan kernel, dan mengulang kembali untuk menguji komponen yang baru. Suatu penurunan drastis yang akan memerlukan pengulangan yang lain, dan debugging yang membosankan, low-level biasanya mengikuti, sering tanpa menggunakan suatu timbunan inti. Di dalam kontras, pengembangan berjalan di suatu sistem multiserver seperti MINIX 3 jauh lebih pendek. Pada umumnya, langkah-langkah itu dibatasi pada mengedit, menyusun, menguji, dan debugging. Kita akan menguraikan langkah-langkah ini di bawah.

Normal programming model (Programming normal model). Karena para pengontrol dan server-server hanyalah proses-proses pengguna biasa, mereka dapat menggunakan setiap pustaka-pustaka yang diperlukan. Dalam beberapa hal, bahkan memanggil sistem POSIX sehingga dapat digunakan. Kemampuan itu untuk meyakinkan bahwa ini dapat dibandingkan dengan lingkungan yang tersedia bagi penulisan para programmer untuk pengkodean kernel-kernel yang monolithic. Pada intinyanya, bekerja di dalam programming membuat mode pengguna lebih mudah.

No system downtime (Tanpa sistim downtime). Pengulangan  kembali yang diperlukan untuk suatu sistem operasi yang monolithic secara efektif memulai dengan semua pemakai, maksud bahwa suatu pengembangan sistem yang terpisah adalah untuk lebih disukai. Pada MINIX 3, tidak ada pengulangan kembali yang  diwajibkan untuk menguji komponen-komponen baru, maka para pemakai lain tidak terpengaruh. Lebih lanjut, bug-bug atau permasalahan lain terisolasi di dalam komponen-komponen yang baru dan tidak bisa mempengaruhi seluruh sistem, karena komponen yang baru menjalankan satu proses yang mandiri di suatu lingkungan eksekusi yang terbatas. Permasalahan seperti itu tidak bisa mempengaruhi seperti di suatu sistim yang monolithic.

Easy debugging (Debugging yang mudah). Debugging suatu driver piranti di suatu kernel yang monolithic adalah suatu tantangan yang riil. Sering kali sistem hanya menghentikan dan programmer tidak mempunyai suatu petunjuk apapun dalam memecahkan permasalahan. Menggunakan sebuah simulator atau emulator biasanya berasal dari tidak adanya penggunaan karena pada umumnya alat itu yang sedang kontrol karena sesuatu yang baru dan tidak didukung oleh simulator atau emulator. Di dalam kontras, di dalam MINIX 3, suatu driver piranti hanyalah seorang proses pengguna, maka jika itu hancur, maka akan meninggal di balik suatu timbunan inti sehigga dapat diperiksa dengan semua perkakas debugging normal. Sebagai tambahan, keluaran dari semua printf() statemen-statemen di dalam driver-driver dan server-server secara otomatis keluar ke suatu server untuk pencatatan, yang menulisnya ke suatu file. Setelah digagalkan sesuai dengan pengontrol yang baru, programmer dapat menguji catatan itu untuk melihat pengontrolan sedang lakukan tepat sebelum itu mati.

Low barrier to entry (Penghalang rendahnya masukan). Karena para pengontrol penulisan dan server-server adalah banyak, maka lebih mudah di dalam sistem konvensional, peneliti-peneliti dan yang lain dapat mencoba yang baru dengan mudah. Penggunaan percobaan dapat membantu field dengan membiarkan orang-orang dengan pengalaman gagasan-gagasan kecil tetapi yang baik di dalam programming kernel untuk mencoba gagasan mereka dan membangun prototipe-prototipe yang mereka tidak bisa membangun dengan kernel-kernel yang monolithic. Meski yang paling keras bagian dari penulisan suatu driver peranti yang baru bisa mengerti perangkat keras yang nyata, komponen-komponen sistem operasi lain dapat mudah untuk mewujudkan. Sebagai contoh, studi kasus pada akhir artikel ini menggambarkan bagaimana kemampuan semaphore dapat ditambahkan pada MINIX 3

High productivity (Produktivitas tinggi). Karena pengembangan sistem operasi di dalam ruang pengguna adalah lebih mudah, maka programmer dapat melakukan pekerjaan lebih cepat. Karena tanpa membangun sistem yang panjang, maka bug tersebut sudah dipindahkan dipindahkan, pada waktu tersimpan. Akhirnya, karena sistem itu tidak perlu kembali lagi setelah suatu pengontolan selesai, dengan cepat programmer sudah memeriksa timbunan inti, catatan dan sudah memperbaharui kode, dimungkinkan untuk menguji pengontrol yang baru tanpa pengulangan kembali. Dengan suatu kernel yang monolithic, dua pengulangan kembali sering diperlukan: Satu untuk memulai sistem setelah penurunan drastis dan satu untuk pengulangan kernel yang baru dibangun

Good accountability (Tanggung-jawab yang baik). Ketika seorang pengontrol atau server rusak, itu adalah jelas nyata (karena master, server reinkarnasi, mengetahui proses yang keluar). Sebagai suatu konsekuensi, kebanyakan lebih mudah di dalam sistem yang monolithic untuk mengajak berpikir mengenai kesalahan, penyebab penurunan drastis  adalah mungkin menurut hukum dapat digunakan, karena meyebabkan kerusakan berakhir. Memegang produsen-produsen dari perangkat lunak komersil dapat digunakan untuk error mereka, di dalam dengan tepat cara yang sama seperti produsen-produsen dari perputaran, pengobatan-pengobatan, dan produk-produk yang dapat dipertanggungjawabkan jika dipergunakan lain, boleh memperbaiki kualitas software

Great flexibility (Fleksibilitas yang tinggi). Model kami yang modular menawarkan administrasi sistim fleksibilitas dan pembuatan yang besar dan banyak akan lebih mudah. Karena modul-modul sistem operasi hanyalah memproses, secara relatif mudah untuk menggantikannya. Itu menjadi lebih mudah untuk mengatur sistem operasi dengan pencampuran dan mempertemukan modul-modul. Lebih lanjut, jika suatu driver piranti perlu untuk ditambah, ini biasanya dilaksanakan masih diatas, tanpa kehilangan layanan atau downtime. Penggantian modul adalah kebanyakan lebih keras di dalam kernel-kernel yang monolithic dan sering juga memerlukan suatu pengulangan kembali. Akhirnya, pemeliharaan juga menjadi lebih mudah, karena semua modul bersifat kecil, yang mandiri, dan dipahami dengan baik.

Conclusion

MINIX 3 adalah sistem operasi baru, design sistem operasi memiliki banyak modular yang sangat dihandalkan sistem operasi . Seperti layaknya inovasi yang lain, pencarian batasan – batasan tertentu pada lingkungan eksekusi, tetapi jangkauan mulltiserver  buatan  MINIX 3 lebih mudah digunakan oleh programmer OS. Pengembangan Siklus  dipercaya akan menjadi lebih pendek (kecil), pengefisenan system kerja sudah tidak lagi diperlukan, tampilan program terlihat seperti POSIX, serta pengujian dan debugging akan menjadi lebih mudah. Produktivitas programmer mungkin akan semakin meningkat,  sehingga kwalitas code dapat dipertanggung jawabkan. System administrator juga bermanfaat, karena perkembangan configurability dan maintainability dimliki oleh sistem operasi Minix 3.

Akhirnya, kita telah memiliki gambaran tentang model programming yang ditentukan oleh pesan program MINIX 3 dengan konstruksi dari suatu sinyal server  yang sederhana dan pembahasan tentang bagaimana cara mengembangkan manfaat dari modular MINIX 3.

Iklan