Sistem Operasi Sivelkiriya: Deskripsi Pendahuluan

Halo Habr.

Artikel ini membuka serangkaian publikasi tentang sistem operasi Sivelkiriya, yang saat ini berada pada tahap awal desain dan pengembangan. Artikel-artikel dalam seri ini akan menjelaskan secara terperinci masalah sistem sistem operasi populer dan menyarankan cara untuk menyelesaikannya. Penulis tidak menetapkan tujuan meyakinkan siapa pun tentang apa pun dan hanya berfokus pada deskripsi solusi yang diusulkan untuk mendapatkan manfaat dari diskusi. Publikasi akan dilakukan dalam beberapa bagian, karena volume uraian lengkap melampaui batasan yang masuk akal pada ukuran artikel.

Semua orang yang tertarik, selamat datang di kucing.

Saat ini, Anda tidak akan mengejutkan siapa pun dengan pernyataan tentang pengembangan sistem operasi selanjutnya, yang seharusnya menjadi lebih baik, lebih nyaman dan lebih menarik daripada pendahulunya dan pesaingnya. Setidaknya ada tiga pemain utama di pasar OS untuk komputer pribadi dan dua di pasar OS untuk perangkat seluler. Terlepas dari keragaman yang tampak, tidak mungkin untuk tidak mencatat kesamaan tertentu di antara mereka: meskipun teknologi dan metode untuk menyajikan layanan oleh sistem operasi bervariasi, sebagian besar konsep dan konsep tetap tidak berubah ketika berpindah dari satu sistem ke sistem lainnya.

Jadi, hampir semua sistem operasi yang populer saat ini memberikan dukungan untuk fungsionalitas umum di level implementasi (windows, grafik, file, jaringan, peralatan), tetapi tidak pada level ekspresi konsep-konsep area subjek (pesan obrolan, daftar lagu, tagihan layanan). Pengecualian yang ada (daftar kontak, clipboard, bilah notifikasi) hanya menekankan aturan. Implementasi teknis (file, proses, utas) juga sangat mirip dalam banyak hal.

Unit penggunaan kemampuan komputer dalam semua kasus adalah aplikasi, yang dengan sendirinya memutuskan bagaimana mengarahkan sumber daya yang tersedia untuk mencapai tujuan mereka. Berbagai aplikasi hanya saling terhubung sejauh pengembang mereka telah menjaga koneksi seperti itu; Seringkali, program yang melakukan fungsi dekat tidak dapat bertukar data, memiliki antarmuka yang berbeda, menggunakan terminologi yang berbeda, dan sebagainya. Ini isolasi komponen memiliki akar teknis murni, tetapi sebagai akibatnya pengguna menderita. Komputer dari alat integral berubah menjadi tumpukan solusi heterogen, dan kompatibilitas universal, yang pantas menjadi prinsip dasar desain, tetap hanya peluang opsional.

Saat ini, ada semakin banyak solusi yang mengintegrasikan berbagai aplikasi dan layanan satu sama lain. Produsen produk perangkat lunak tampaknya telah menyadari bahwa mengurangi banyak kemungkinan pada satu sistem yang nyaman adalah satu-satunya cara untuk harmoni dan ketertiban, yang membuat kehidupan pengguna menjadi lebih baik dan lebih mudah. Namun, dalam banyak kasus, perjuangan buta dari program yang tidak kompatibel, yang masing-masing mencoba merangkul yang besar, digantikan oleh perjuangan integrator yang bahkan lebih ganas, yang melakukan segala kemungkinan untuk tidak membiarkan pengguna (dan pengembang) keluar dari platform mereka. Alih-alih menyatukan dunia, integrator memisahkannya untuk memerintah.

Aspek lain yang tak terhindarkan dari dunia aplikasi individual untuk memecahkan masalah spesifik adalah bahwa masing-masing aplikasi akan memiliki kelebihan dan kekurangannya sendiri, seringkali tidak dapat dipulihkan. Pilihan antara kegunaan, fungsi yang kaya, dan dukungan untuk operasi tertentu sama tidak terhindarkannya dengan yang disesalkan. Jika pengguna membutuhkan kemampuan yang tidak disediakan dalam kerangka satu aplikasi untuk mencapai tujuannya, ini memaksanya untuk menggunakan lebih dari satu alat, menghabiskan waktu dan upaya untuk beralih dan mentransfer data.

Pengembangan perangkat lunak adalah proses yang memakan waktu, dan karena itu kuantitas dan kualitas fungsionalitas dalam produk apa pun pasti akan terbatas. Pada saat yang sama, bagian terbesar dari tugas dan masalah yang diselesaikan oleh pengembang telah diselesaikan dalam produk lain; menggunakan kembali solusi ini alih-alih mengembangkannya akan membebaskan sumber daya yang dapat digunakan untuk mencapai tujuan lain yang lebih penting bagi pengguna.

Akhirnya, perilaku program seringkali tidak etis. Alih-alih membantu pengguna dalam pekerjaan mereka, program-program membanjiri dia dengan komentar dan saran yang mengganggu. Alih-alih mengembangkan cara yang nyaman untuk menyediakan layanan berdasarkan saling menghormati, mereka mencampur konten iklan dengan target. Hasilnya adalah situasi di mana bahkan pemilik perangkat tidak mengontrol perilakunya.

Sistem operasi Sivelkiriya dimaksudkan sebagai solusi untuk masalah di atas dan beberapa masalah lainnya. Menurut rencana dan desain, harus terpusat, dengan hormat, pada kondisi yang saling menguntungkan, membantu mencapai kategori peserta berikut dalam proses mengembangkan dan menggunakan perangkat lunak:

  1. โ€” , , , .
  2. โ€” , , , , โ€” , - .
  3. โ€” , , .
  4. โ€” , , , .
  5. โ€” , , , .

Di bawah ini kami akan menjelaskan arsitektur sistem operasi semacam itu dan bagaimana hal itu membantu memperbaiki situasi. Artikel lebih lanjut dalam seri ini akan memeriksa secara rinci masalah yang diselesaikan untuk menunjukkan bahwa mereka memerlukan pendekatan sistematis. Akhirnya, keuntungan dan kerugian dari solusi yang diusulkan dan bagaimana hal itu dapat berubah dari konsep menjadi produk jadi akan ditampilkan.

Konsep OS Sivelkiriya


Sistem operasi Sivelkiriya dimulai dengan revisi dari dasar-dasar, di mana bagian dari konsep yang diterima secara umum dihilangkan atau diganti. Entitas berikut, yang biasanya membentuk dasar sistem operasi, tidak ada dalam OS Sivelkiriya:

  1. Aplikasi.
  2. Proses.
  3. File sebagai area data pada disk.
  4. Sistem file ujung ke ujung, navigasi yang dibatasi hanya oleh hak akses.
  5. Baris perintah sebagai lingkungan untuk menjalankan aplikasi individual.
  6. Skrip universal.
  7. Ketersediaan API sistem operasi dasar untuk komponen apa pun.
  8. Kemampuan untuk mentransfer langsung perpustakaan standar dari sebagian besar bahasa pemrograman modern. Akibatnya, kemampuan untuk langsung mentransfer perangkat lunak yang ada dari sistem operasi lain, kecuali dalam kasus tertentu.
  9. Dukungan untuk bahasa pemrograman tanpa orientasi objek.

Daftar ini tidak lengkap. Ini tidak berarti membatasi kemampuan seorang programmer atau pengguna dan hanya menunjukkan bahwa dalam kerangka OS Sivelkiriya, tujuan yang sama dicapai secara berbeda dari pada kebanyakan sistem operasi yang ada.

Setelah meninggalkan entitas yang sudah mapan ini, kami bermaksud membangun sistem operasi berdasarkan prinsip-prinsip berikut:

  1. ยซยป - , , , . , , , , . . , , .
  2. . , , , , .
  3. , . , ( ). ( ) . , ( ) .
  4. , , , , . , .
  5. Setiap modul hanya tersedia data dan metode interaksi dengan sistem operasi yang diperlukan untuk menjalankan fungsinya (ditentukan oleh prototipe). Tidak ada modul yang memiliki akses ke semua fungsi sistem operasi. Duplikasi fungsi yang sudah ditugaskan ke prototipe tertentu dalam modul yang terkait dengan prototipe lain tidak diperbolehkan.
  6. Pengembangan antarmuka data dan modul prototipe dilakukan terus menerus, dengan upaya bersama dari pengembang program dan pengembang sistem operasi. Antarmuka dan prototipe dimodifikasi dan ditambah sesuai kebutuhan.


Artikel-artikel berikut dalam seri ini akan menunjukkan secara terperinci bagaimana prinsip-prinsip ini dan lainnya akan diterapkan dalam praktik.

Artikel kedua dari siklus tersedia di sini . Teks lengkap tersedia di situs web proyek .

Source: https://habr.com/ru/post/undefined/


All Articles