Pada akhir Mei,
Embox , yang secara tradisional, ambil bagian dalam
OSDay . Konferensi, seperti tahun lalu, diadakan di gedung utama RAS. Kali ini didedikasikan untuk keandalan. Topik keandalan perangkat lunak sudah lama. Hal ini dipengaruhi, misalnya, oleh
Frederick Brooks dalam karya legendarisnya
Mythical Man-Month , yang juga disebut beberapa kali di konferensi itu sendiri. Buku itu menyebutkan bahwa salah satu masalah yang dihadapi dalam proses menciptakan
sistem operasi
OS / 360 adalah kurangnya jumlah programmer yang memenuhi syarat. Mungkin, untuk alasan yang sama, banyak waktu di konferensi dikhususkan untuk pendidikan di bidang pemrograman sistem. Secara umum, siapa yang tertarik pada apa, menurut pendapat saya, ide-ide menarik diungkapkan dan dibahas di konferensi, saya minta kucing.
Membuka konferensi, salah satu pendirinya, Dmitry Zavalishin
dzavalishin , mengungkapkan beberapa poin:
- Sistem perangkat lunak modern sangat kompleks sehingga keandalan diperlukan untuk salah satu dari mereka, dan tidak hanya untuk "yang khusus", seperti sebelumnya
- Orang yang berbeda mungkin memiliki gagasan berbeda tentang keandalan perangkat lunak, misalnya, beberapa orang menganggap keandalan sebagai sinonim untuk keamanan.
- Metode untuk memastikan keandalan dapat berbeda, berdasarkan setidaknya pada asumsi bahwa konsep keandalan berbeda
Pada hari pertama, ISP RAS mempresentasikan
laporan tentang keandalan perangkat lunak dari sudut pandang akademik. Dan meskipun itu lebih merupakan penghargaan terhadap sejarah, jelas dari masalah itu jauh dari baru, dan definisi keandalan, serta metode untuk menilai itu, sangat beragam. Laporan itu, meskipun sangat terpotong (karena pembicara mencoba menyimpannya dalam 30 menit), menarik karena sifat ilmiahnya.
Metode instrumental
Metode untuk memastikan keandalan kode dapat dibagi menjadi beberapa kategori. Saya akan mulai dengan alat yang menjadi tuan rumah konferensi, ISP RAS, terkenal. Pegawainya mempresentasikan
laporan tentang pengalaman memverifikasi potongan-potongan kernel Linux menggunakan alat klever.
Klever adalah kerangka kerja terbuka untuk verifikasi kode statis. Sebenarnya, masalah yang diselesaikan penulis laporan dapat dirumuskan sebagai berikut. Verifikasi kode statis terlalu rumit untuk memeriksa proyek-proyek modern secara keseluruhan, tetapi Anda dapat mencoba mengisolasi beberapa bagian yang kurang lebih terisolasi, misalnya, subsistem kernel Linux atau driver terpisah, dan, setelah mengatur lingkungan yang sesuai untuk itu, verifikasi. Kemudian Anda dapat mencoba iteratif melakukan ini dengan seluruh proyek.
Metode arsitektur
Pendekatan lain untuk membangun sistem yang lebih andal adalah penggunaan teknik "arsitektur". Bagi mereka, saya akan memasukkan ide memori
Phantom OS dan arsitektur
MILS (Multiple Independent Levels of Security / Safety).
Laporan tentang MILS berurusan dengan propertinya untuk meningkatkan keamanan sistem kritis dan diserahkan ke Kaspersky Lab.
Laporan tentang pengumpul sampah dalam kondisi memori persisten disajikan tidak hanya oleh penulis OS Phantom, tetapi juga oleh seorang mahasiswa di Universitas Innopolis. Tentu saja, gagasan menggunakan bahasa kelola untuk meningkatkan keandalan sistem bukanlah hal baru. Dan dalam laporan itu, menurut pendapat saya, keterlibatan siswa dalam proyek open-source untuk membuat perangkat lunak sistem adalah penting.
Pendekatan metodis
Yang paling banyak dalam hal jumlah laporan, tetapi pendekatan yang diremehkan untuk meningkatkan keandalan perangkat lunak, menurut pendapat saya, adalah "metodis". Jika Anda memikirkannya, pemisahan sistem operasi sebagai entitas terpisah bertujuan untuk meningkatkan keandalan perangkat lunak. Programmer mendapat kesempatan untuk menggunakan kembali layanan sistem, dan tidak mengembangkannya lagi.
Sebuah laporan tentang metodologi untuk mengembangkan perangkat lunak penting disajikan oleh FSUE GosNIIAS. Laporan ini dikhususkan untuk pengembangan
DO-178C standar (CT-178C dalam versi Rusia). Seperti dalam standar itu sendiri, laporan itu memiliki banyak "kebosanan," tetapi bagaimanapun, ketika Anda membuat pesawat terbang, Anda tidak dapat menyingkirkan beberapa ide yang mempesona, Anda perlu memeriksa beberapa kali sebelum melakukan perubahan sedikit pun. Secara umum, ukur sekali, potong tujuh kali, oh, sebaliknya, tentu saja. Secara alami, laporan itu menarik bukan karena "kebosanannya", tetapi karena fakta bahwa alat dikembangkan untuk mengotomatiskan proses ini, mis. untuk mengurangi "kebosanan."
Sumber terbuka
Akhirnya, saya beralih ke bagian di mana Embox berbicara.
Laporan kami berjudul "Organisasi dukungan untuk akselerasi 3d dalam RTOS berdasarkan proyek sumber terbuka". Di dalamnya, sebagian besar dikhususkan untuk penjelasan, dan di sini keandalan. Bahkan ada slide seperti "Keandalan dan akselerasi perangkat keras 3d". Keandalan, tentu saja, tidak dalam akselerasi 3d, tetapi dalam frasa "berdasarkan proyek open source". Intinya adalah bahwa kami dapat menambahkan dukungan untuk akselerator vivante 3d tertutup menggunakan proyek open source. Dan meskipun proyek
Mesa yang kami gunakan sangat terkait dengan antarmuka kernel Linux, adaptasi membutuhkan upaya yang jauh lebih sedikit dan mengandung jauh lebih sedikit baris kode daripada pengembangan dari awal.
Seperti yang telah saya catat, open-source adalah kategori paling banyak yang terhubung dengan laporan di konferensi. Sebagai contoh, Basalt SPO menyajikan
laporan tentang pengembangan alat sinkronisasi file clsync. Saya tidak akan membahas detail teknis, hal lain yang penting. Seperti yang ditunjukkan dalam nama perusahaan,
alat ini adalah open source , dan setelah laporan itu beberapa kiat diikuti, misalnya, untuk menggunakan
futex , yang disarankan oleh pembicara untuk bergabung dengan proyek dan memperbaikinya secara mandiri.
Menurut saya, yang paling menarik dalam hal opensource adalah
laporan dari karyawan Positive Technologies, Alexander Popov.
Laporan tersebut berjudul "Bagaimana STACKLEAK Meningkatkan Keamanan Kernel Linux" dan sepertinya itu didedikasikan untuk cerita STACKLEAK dan dimakan dengan apa. Tetapi waktu utama dari laporan ini adalah untuk topik ini, yang diungkapkan dalam frasa dari anotasi hingga laporan:
“Alexander telah melakukan pekerjaan ini selama satu tahun. Dia akan berbagi pengalamannya dengan komunitas pengembangan kernel Linux .
" Yaitu, selama tahun ini perubahan yang bermanfaat didorong, banyak orang terlibat, perubahan diperiksa di bawah mikroskop oleh spesialis berkualifikasi yang bekerja di berbagai subsistem inti. Tentu saja, ini tidak menjamin tidak adanya kesalahan sama sekali, tetapi mengurangi jumlahnya, dan karenanya meningkatkan keandalan kode.
Pendekatan alternatif
Pada konferensi tersebut, seperti
tahun lalu , sebuah
laporan tentang QP OS disajikan. Dalam abstrak laporan Anda dapat melihat yang berikut: "Sistem operasi QP OS yang aman adalah pengembangan sepenuhnya dalam negeri, dibuat" dari awal "oleh tim perusahaan ilmiah dan teknis" Cryptosoft. " Laporan ini juga menyuarakan prinsip pengembangan dari awal, tidak hanya dari sistem operasi, hypervisor, tumpukan jaringan, tetapi juga semua subsistem dan aplikasi pengguna, serta kompiler, mesin virtual C #, dan, seperti yang saya pahami, semua alat pengembangan lainnya. Untuk pertanyaan saya kepada pembicara, bagaimana dengan keandalan, karena rasio jumlah kesalahan per seribu baris kode belum dibatalkan. Saya mendapat jawaban bahwa keandalan dapat dipahami sebagai hal yang berbeda, dan itu dianggap dapat diandalkan untuk sistem operasi yang diberikan jika jatuh kurang dan kurang antara dua restart. Setelah laporan, di sela-sela, saya menyarankan mengambil proyek terbuka untuk memberikan dukungan yang lebih lengkap untuk
samba . Tetapi dia menerima jawaban bahwa itu adalah posisi berprinsip untuk mengembangkan segala sesuatu secara independen, dengan penjelasan bahwa pendekatan semacam itu memiliki hak untuk hidup. Yah, saya menyebutnya pendekatan alternatif.
Perlu dicatat bahwa ada pameran di konferensi, dan sebuah stan disajikan di mana OS QP dapat diadili secara langsung. Saya bermain-main dengan editor mereka, itu bekerja dengan cukup baik. Di stand, mereka mengkonfirmasi bahwa mereka bahkan tidak meminjam kode perpustakaan untuk bekerja dengan xml. Selain itu, mungkin pendekatan serupa "semua dari awal" berasal dari ruang lingkup di mana pengembang bekerja. Bola ini ditandai dengan keamanannya yang berlebihan, lebih baik jatuh daripada membookmark suatu tempat. Benar, ini tidak membenarkan penolakan untuk menggunakan kode sumber terbuka.
Sulit waktu nyata
Di bagian ini, saya tidak bisa tidak merujuk pada laporan lain, setidaknya karena pembicara merujuk pada presentasi saya, oleh karena itu saya berhak melakukan hal yang sama. Setelah pidato saya, saya ditanya apakah dukungan akselerator 3d tidak mengganggu memberikan karakteristik real-time, dan secara umum, apakah proyek kami OS real-time yang sulit? Saya menjawab dengan mengelak pertanyaan terakhir, karena waktu di konferensi terbatas, dan pertanyaan tentang apa yang dimaksud dengan waktu nyata memerlukan penjelasan yang agak serius. Pembicara yang disebutkan berbicara tepat setelah saya dengan
laporan tentang Eremex FX-RTOS RTOS dan menyatakan bahwa, tidak seperti proyek kami, OS mereka adalah sistem waktu-nyata yang sulit. Tanda waktu nyata yang sulit, menurut pembicara, adalah tidak adanya siklus dengan jumlah iterasi variabel dengan gangguan yang diblokir.
Saya tidak berani menilai apakah ada potensi loop tak terbatas dengan interupsi yang diblokir di FX-RTOS RTOS atau tidak, karena kode ini ditutup, tetapi, tentu saja, saya setuju bahwa siklus seperti itu tidak dapat diterima bahkan dalam OS biasa, belum lagi RTOS!
Selain itu, selama laporan, dinyatakan bahwa pengembang berhasil menghindari interupsi pemblokiran (masking) sepenuhnya, meskipun hanya pada arm cortex-m, tetapi ini masih merupakan pencapaian besar, yang, menurut pembicara, juga menunjukkan waktu nyata. Selain itu, speaker berhenti untuk waktu yang lama pada perangkat berbasis FX-RTOS, yang menjawab melalui antarmuka UART selama beberapa milidetik, yang sekali lagi menunjukkan waktu nyata yang sulit.
Saya tidak tahu siapa di antara kita yang memiliki pendekatan alternatif terhadap konsep "waktu nyata", saya hanya akan mengungkapkan sudut pandang saya. Dan saya hanya akan menjawab pertanyaan apakah Embox adalah sistem waktu-nyata.
Konsep waktu nyata berhubungan langsung dengan prediktabilitas perilaku sistem di bawah pengaruh faktor (baik internal maupun eksternal). Dari sini koneksi konsep real time dengan konsep reliabilitas berikut. Oleh karena itu gagasan bahwa windows, sebagai OS universal, tidak dapat diandalkan, dan sistem operasi real-time (seperti sistem yang dibangun di atasnya) dapat diandalkan.
Parameter waktu reaksi adalah salah satu faktor prediktabilitas yang paling penting, tetapi dalam sistem waktu-nyata, bukan laju reaksi yang lebih penting daripada variasi waktu reaksi, dan harus dibatasi secara ketat. Saya menemukan definisi di mana soft real time didefinisikan sebagai sistem dengan nilai respons rata-rata kecil dari sistem, dan hard - dengan maksimum kecil. Dan karena kecepatan prosesor modern telah sangat meningkat, waktu (rata-rata) eksekusi tidak lagi memainkan peran itu, karena untuk meningkatkan kecepatan reaksi itu cukup untuk menempatkan prosesor yang lebih kuat. Tetapi tidak mungkin untuk menyingkirkan pengaruh algoritma dan arsitektur, yaitu, Linux dengan
penjadwal jujurnya , yang ditujukan untuk memuat CPU maksimum, tidak dapat dianggap sebagai sistem waktu-nyata. Meskipun saya yakin bahwa waktu reaksi menurut UART dapat dibuat sangat kecil, itu tidak akan stabil, karena penjadwal dapat memutuskan bahwa itu perlu memuat prosesor dengan beberapa tugas lain, dan waktu respons akan meningkat secara tak terduga. Oleh karena itu, kita dapat merumuskan karakteristik berikut dari sistem operasi waktu nyata: ini adalah sistem operasi yang memberikan kontrol terbaik untuk semua sistem mereka, termasuk yang internal. Ambil contoh,
ARINC-653 dengan persyaratannya dalam hal penjadwal dengan jadwal statis. Dalam sistem operasi ini, pengembang memiliki akses ke tabel perencanaan, yang dia isi pada saat pengembangan sistem. Artinya, pengembang mengalokasikan waktu (slot waktu) dalam periode perencanaan umum untuk setiap bagian, semua interupsi dinonaktifkan (kecuali untuk timer, tentu saja, hanya tersedia untuk penjadwal), dan pengembang harus membuat jadwal waktu sehingga setiap bagian memiliki cukup waktu untuk menyelesaikan masalahnya. Pada saat yang sama, penjadwal tidak memiliki hak untuk mengubah jadwal ini.
Jika Anda berpikir tentang apa sistem operasi lain yang menyediakan akses penuh atau diperluas ke "jeroan ayam itik" Anda, mudah untuk sampai pada kesimpulan bahwa proyek modern OS kecil memiliki nama bangga RTOS (sistem operasi real-time). Karena mereka menyediakan akses ini, dan pengembang sudah bertanggung jawab untuk memastikan bahwa sistem akhir yang dibangun atas dasar RTOS memenuhi semua persyaratan, termasuk prediksi reaksi terhadap dampak apa pun!
Adapun Embox, kami juga menyediakan mekanisme kontrol untuk semua layanan, termasuk kernel. Dan dari sudut pandang ini, Embox adalah sistem operasi waktu-nyata. Ya, sistem dengan arsitektur MILS dibuat berdasarkan Embox (saya tidak secara sadar menyebutnya ARINC-653, karena ARINC-653 ditentukan oleh sertifikat untuk kepatuhan dengan standar), tetapi Anda juga dapat membangun arsitektur lain yang akan menjamin prediksi reaksi yang cukup. Satu pelanggan, misalnya, memeriksa waktu respons pada osiloskop, waktu akurat untuk beberapa siklus prosesor dan sangat terbatas. Benar, sistem tidak dimuat, dari aplikasi aktif, hanya server yang berputar, yang bereaksi terhadap peristiwa tersebut. Tetapi pelanggan sangat senang dengan hasilnya. Oleh karena itu, kami percaya bahwa hanya mungkin untuk berbicara tentang waktu nyata dalam aplikasi ke sistem secara keseluruhan, dan pengembang bertanggung jawab untuk ini, dan sistem operasi waktu nyata yang keras hanya menyediakan mekanisme untuk mencapai waktu yang sangat nyata ini. Kami lebih akurat dalam klasifikasi kami dan kami telah menulis
»Embox - Essential toolbox untuk pengembangan tertanam" .
Kader memutuskan segalanya
Ungkapan aneh dalam judul “Apa yang Anda perlu ajarkan kepada siswa sehingga mereka segera mulai bekerja di perusahaan IT Rusia dan tetap di sana” - ini sebenarnya pertanyaan yang diangkat dalam diskusi panel. Seperempat konferensi dikhususkan untuk masalah pelatihan dan pendidikan di bidang IT. Memahami pentingnya dan pada saat yang sama ketidakkonsistenan masalah, panitia sangat menarik mendekati masalah. Empat laporan disampaikan, sebagaimana dipahami oleh penyelenggara, para pembicara mewakili pendekatan kompetitif. Jadi, dua laporan tentang kursus dengan nama yang sama "Arsitektur Komputer dan Bahasa Perakitan" di fakultas
VMK MSU . Satu laporan dibuat oleh
George Kuryachiy , yang lainnya -
Padartan Vartan . Sebenarnya, pendekatannya serupa, dan tidak masalah bahwa assembler MIPS dipelajari dalam satu mata kuliah, dan x86 pada mata kuliah lain. Dalam kedua kasus, para guru berusaha mengembangkan kursus di bidang praktis. Sebagai kelanjutan dari topik tentang pentingnya komponen praktis pelatihan, sebuah
laporan oleh Aleksey Khoroshilov "Merancang kernel dari sistem operasi" disajikan. Kursus ini, dapat kita katakan, memperluas pemahaman arsitektur komputer dan memungkinkan siswa untuk menyelam lebih dalam ke inti sistem operasi. Akibatnya, alih-alih pendekatan yang bersaing, ternyata fakultas VMK memiliki pendekatan sistematis, yaitu, kursus tidak bersaing, tetapi saling melengkapi dan mengembangkan satu sama lain. Sebenarnya, memang seharusnya begitu. Ungkapan itu juga berbunyi: "Untuk belajar memprogram, Anda perlu memprogram", yang, menurut pendapat saya, mendefinisikan prinsip umum pelatihan di bidang TI.
Bahkan di bagian ini, Roman Simakov dari perusahaan "RED SOFT" membuat
presentasi "Fitur pelatihan programmer sistem di kota-kota kecil". Sisa pembicara di bagian ini berasal dari Moskow, seperti yang mungkin Anda duga.
Laporan tentang masalah-masalah yang tercantum mengingatkan saya sangat (dan bukan hanya saya) dari
laporan "Kesalahan dalam pengawasan negara pendidikan tinggi - masalah utama pendidikan tinggi di Rusia" dari konferensi OSEDUCONF-2018 yang dijelaskan oleh saya di
hubBandingkan:
diambil dari halaman dengan abstrak dari
laporan saat ini
1) Ketika mengalokasikan dana anggaran untuk spesialisasi di universitas, memperhitungkan jumlah lulusan yang bekerja di spesialisasi ini. Jika spesialis tidak diminta, maka tidak masuk akal untuk membiayai tempat anggaran. Ya Lulusannya bekerja, membayar pajak, tetapi menghasilkan sesuatu yang lain! Ketika mendaftarkan seorang karyawan, seorang majikan dapat menunjukkan keahlian dan universitasnya, dan sekarang semua ini sangat mudah dijumlahkan.
2) Ubah dasar komersial pendidikan. Anda perlu membayar bukan untuk persiapan, tetapi untuk hasilnya. Perusahaan IT dapat memesan pelatihan spesialis dan membayar sesuai dengan hasilnya. Secara kasar, spesialis perusahaan menghadiri ujian, mengevaluasi sendiri dan “menandatangani sertifikat penerimaan” dari hasil pelatihan.
Ini diambil dari ulasan saya tentang laporan tentang
HabréDalam laporan ini, penulis menguraikan masalah ketidakefisienan pendidikan saat ini. Alasan yang mungkin untuk ini adalah birokrasi. Tentang masalah birokratisasi saya tidak akan menyebar banyak. semua orang terhubung dengan proses pendidikan, dengan satu atau lain cara, dihadapkan dengan itu. Penulis menyatakan pendapat bahwa masalah utama pendidikan adalah prosesnya dikendalikan, bukan hasilnya. Artinya, persyaratan formal dikenakan pada universitas, dan mereka diverifikasi. Nilai nyata dari pendidikan adalah permintaan lulusannya.
Dalam kedua kasus, ide utamanya adalah bahwa universitas harus melatih spesialis yang sukses dalam industrinya, dan tidak melaporkan jumlah tempat. Ketika penulis laporan itu diberitahu bahwa gagasan-gagasan ini bukan hal baru, ia tersinggung dan mengatakan bahwa gagasan itu asli. Tidak ada yang meragukan hal ini, tetapi fakta bahwa kedua laporan tersebut disajikan oleh kota-kota kecil (Murom dan Pereslavl-Zalessky) menunjukkan bahwa masalah dengan distribusi uang anggaran untuk pendidikan cukup serius, dan terutama terlihat di kota-kota kecil.
Adapun pertanyaan dari judul artikel, saya menyarankan penulisnya untuk tidak berpikir tentang apa yang perlu diajarkan programmer, tetapi untuk mengembangkan industri TI itu sendiri. Jelas bahwa jika seorang spesialis tidak menemukan aplikasi untuk pengetahuan dan keterampilannya, ia akan pergi ke tempat mereka akan diminta. Industrilah yang membentuk persyaratan untuk spesialis, dan bukan universitas atau negara. Saya didukung oleh pembicara dari ISP RAS, yang mengatakan bahwa harus ada "trinitas": pendidikan, sains, industri. Tanpa salah satu komponen ini, bagian lain mulai melorot.
Selain itu, saya merujuk pada
artikel saya "Di mana mendapatkan seorang programmer" di mana saya mencoba menawarkan pendekatan saya untuk meningkatkan pendidikan di bidang TI.
Ringkasan
Ringkasnya, saya ingin mencatat bahwa konferensi ini menarik terutama karena keragaman pendapat dan, tentu saja, kualitas laporannya. , , , .
.
,
. .