Untuk pertanyaan tentang Linux (L)

Kami melanjutkan dari kenyataan bahwa Anda mendapatkan sistem operasi lengkap, segera sepenuhnya membayar untuk semuanya. (Bill Gates menanggapi pertanyaan tentang persaingan dengan L.)


Semakin banyak saya belajar tentang Linux, semakin sedikit saya membenci B.G.


Sebenarnya, saya tidak pernah merasakan perasaan yang kuat kepadanya, saya baru mulai memahami mengapa perusahaan yang memproduksi Windows membutuhkan uang. Dan menjadi lebih jelas mengapa konsumen lebih suka membayar Bill (tentu saja ada opsi di sini, Anda mengerti), daripada menggunakan alternatif gratis (β€œyaitu, gratis”). Tapi mari kita mulai secara berurutan, dan pertimbangkan dua episode interaksi dengan L.

Baru-baru ini, L telah berfungsi pada perangkat yang saya kembangkan (dalam satu atau lain bentuknya, Anda mengerti ...), dalam kerangka di mana perangkat lunak tujuan khusus dijalankan. Jadi, dalam proses berinteraksi dengan perangkat eksternal (keyboard khusus), ditemukan artefak perilaku OS yang menarik, yang mengarah pada pemikiran yang dinyatakan dalam epigraf.

Episode satu - selama koreksi program keyboard USB, cacat "tidak sengaja, tidak sengaja" diperkenalkan, yang menyebabkan kegagalan deskriptor string perangkat. Bagi mereka yang tidak terlalu terhubung dengan USB, penjelasan yang diperlukan - deskriptor string - adalah bagian opsional dari deskripsi perangkat, yang dimaksudkan hanya untuk memvisualisasikan jenis perangkat dan produsen utilitas sistem. Namun demikian, ini bukan alasan untuk programmer dan kesalahan seperti itu tidak boleh dibuat, tetapi semuanya terjadi dalam hidup. Bagaimana sebuah host yang menjalankan OS waras bereaksi jika perangkat yang salah itu terhubung?

Secara pribadi, saya melihat 3 strategi yang mungkin:

  1. , , β€” , , 7, ;
  2. , , β€” ;
  3. , , β€” , , USB ( ).

PNP: Perlu dicatat bahwa standar untuk antarmuka hanya menyediakan untuk kebutuhan (Gambar 8.31 pada halaman 222), sambil menunggu pesan input, untuk mengontrol waktu dan memproses batas waktu, sebagai salah satu kesalahan yang mungkin - ulangi permintaan 3 kali, dan kemudian berikan sinyal tentang kegagalan transaksi. Tindakan tuan rumah lebih lanjut ditentukan oleh implementasi. Yah, setidaknya, saya tidak menemukan informasi seperti itu dalam standar, meskipun ini belum final.

Jadi, pengembang L tidak membatasi diri pada solusi yang terletak di permukaan dan masuk lebih dalam, setelah muncul dengan cara yang luar biasa menarik dan, kita tidak akan takut dengan kata ini, cara yang sangat kreatif bodoh :

4. ulangi permintaan beberapa kali, setelah kelelahan yang menandai perangkat sebagai salah dan kemudian mematikannya .

Sejauh ini, tidak ada yang kriminal, jika bukan karena satu detail kecil ("semuanya bernuansa") - sementara host L mengulangi permintaan di atas, ia memonopoli akses melalui bus (kemungkinan besar batas waktu pada perangkat keras tidak dimulai atau interupsi dari itu tidak diproses) dan semua (!!!) perangkat USB lainnya tidak digunakan. Proses ini memakan waktu sekitar selusin detik, di mana semua perangkat tidak tersedia - sudah tidak buruk. Dan inilah cherry on the cake - setelah upaya yang melelahkan untuk membaca deskriptor string dari keyboard yang salah, paket biasanya berhenti datang ke sana, setelah 2 menit, ia mengerti "ada yang salah" dan mencoba menampilkan dirinya kepada tuan rumah lagi dengan menghubungkan kembali, menyebabkan proses berulang. Hasilnya dapat dimengerti - bekerja dengan bus sama sekali tidak mungkin jika Anda tidak siap untuk menggunakan mode cegukan.Solusi yang tidak biasa asli, tetapi ini (orisinalitas) adalah satu-satunya keuntungan.

Kenalan Linux saya, setelah menunjukkan fenomena ini, pertama kali mencoba menjelaskannya dengan gaya "ini bukan bug, itu fitur seperti itu" (atau lebih tepatnya, pada awalnya mereka, saat mereka menerima, menyarankan untuk membangun kembali kernel dengan tambalan terbaru, ini adalah respons universal terhadap pesan apa pun di komunitas L tentang kemungkinan kesalahan), dan kemudian mereka mengatakan bahwa, ya, perilaku tersebut tidak benar, tetapi, mungkin, di suatu tempat dalam file konfigurasi rakitan ada bendera, pengaturan ulang atau pengaturan yang, Anda dapat menonaktifkan perilaku sistem ini. Jika ini benar, maka satu-satunya nama untuk bendera yang dapat saya tawarkan adalah (dalam bahasa Rusia): "Saya benar-benar ingin to_OS_be_being_being_something_failing_string_descriptor_as_hysterichka", dengan gaya "Sampai pelacur ini memberi tahu saya namanya, saya tidak akan meminta siapa pun untuk berbicara dengan Anda," maaf untuk bahasa perancis saya. Nah, bahkan jika ini masalahnya, ada bendera seperti itu,Apakah secara default OS tidak boleh dikumpulkan dalam mode normal, tidak sesat? Untuk beberapa alasan, Windows melakukan hal itu. Tentu saja, Anda harus melihat kode sumber host L (kemungkinan besar, driver USB tertentu) dan menentukan apakah ada flag seperti itu dan bagaimana mencapai perilaku sistem yang serupa, tetapi untuk alasan yang tercantum di bawah, ini tidak dilakukan, jadi kami membatasi diri untuk menyatakan fakta. .

Fitur kedua (lebih seperti kesalahan, karena dalam kasus pertama perangkat tidak benar, yang segera saya tekankan) terdeteksi setelah kesalahan program perangkat diperbaiki dan kami mulai bekerja lebih jauh.

Faktanya adalah bahwa pada perangkat yang dirancang ada dua pengontrol yang masing-masing menerapkan fungsi joystick dan keyboard, sementara yang satu memproses sisi kiri keyboard, dan yang kedua memproses bagian kanan. Tetapi satu tombol di panel depan disambungkan ke kedua pengontrol, karena memiliki tanda "KEBAKARAN" di atasnya dan hasil dari kegagalan satu pengontrol akan sangat tidak menyenangkan. Ketika Anda mengklik tombol ini, kedua kontroler menghasilkan simbol "spasi" dan semuanya baik-baik saja sampai kami perhatikan bahwa kadang-kadang (~ 10% dari kasus) setelah melepaskan tombol A, itu terus dianggap ditekan dan aplikasi masuk ke mode api berkelanjutan. Pada saat yang sama, menekan dan menurunkan tombol kembali mengembalikan sistem ke mode normal.

Telah disarankan bahwa acara yang jaraknya dekat (pada waktunya) dari keyboard dapat dilewati, dalam hal ini pesan tentang melepaskan tombol.

Selanjutnya, berbagai langkah telah diambil untuk menentukan penyebab kerusakan, tetapi uraian mereka melampaui ruang lingkup dan subjek untuk posting ini dan akan (saya harap) dijelaskan secara terpisah. Tetapi proses mencari tahu penyebab kesalahan yang sederhana (sekilas) itu sendiri membutuhkan upaya sedemikian rupa sehingga keinginan untuk memahami alasan bug pertama yang dijelaskan dalam posting hilang.
Kembali ke epigraf, saya harus mengatakan bahwa pada Windows 7 cacat ini tidak diamati untuk setidaknya 100 klik, yang menunjukkan stabilitas OS ini pada faktor ini. Sekali lagi, saya tidak melihat kode sumber, tetapi perilaku program berbicara sendiri.

Tidak mungkin bahwa kualifikasi pengembang Windows akan secara signifikan melebihi bahwa untuk komunitas open source dan pertanyaannya, tampaknya, hanya sebagai pengujian, yang jelas dilakukan dalam volume yang lebih besar (dan dengan kualitas lebih tinggi), ketika orang yang menerima uang untuk pekerjaan mereka terlibat di dalamnya ( selain kepuasan moral).

Saya harus mengakui bahwa perilaku A, setidaknya dalam situasi yang dijelaskan, paling baik didefinisikan oleh frasa "itu berfungsi," yang tidak dapat dianggap dapat diterima untuk OS yang mengklaim dapat diandalkan dan tersebar luas, itulah sebabnya sikap saya terhadap B.G. Sebagai hasil dari episode ini, itu membaik, karena dia pasti tidak dapat disalahkan atas apa yang terjadi (walaupun mungkin ada pendapat yang berbeda).

All Articles