Bundan tashqari, sane-airscan barcha asosiy BSD distributivlariga (FreeBSD, NetBSD va OpenBSD) va ChromeOSʼga kiritilgan. ChromeOSʼda bajariladigan fayllar hajmiga qoʻyilgan talablar juda qatʼiy boʻlgani uchun Goʼda yozilgan ipp-usb qabul qilinmadi va mening mahsulotimni tanlash oʻrniga ular Rustʼda oʻzinikini yaratdi. Yaqinda FreeBSDʼda ipp-usb porti paydo boʻldi, ehtimol, endi boshqa BSDʼlarda ham tez orada paydo boʻlar...
Bu ikkala paket birgalikda Linux va *BSD uchun hujjatlarni drayverlarsiz skanerlash toʻplamini tashkil qiladi, yaqin kelajakdagi bir necha yil davomida eski skanerlar yoʻqolib ketganda esa boshqa drayverlar ham qolmaydi.
Bundan tashqari, ipp-usb USB-qurilmalarda drayversiz chop etish imkonini beradi.
Bu yerda men mashhur OpenSource paketlarining muallifi boʻlish nimani anglatishi haqida hikoya qilmoqchiman. Garchi bu ish ortidan koʻp pul ishlab topmagan boʻlsam-da (aslida, men bunga umid ham qilmagan edim), bu menga bebaho tajriba olib keldi.
Umuman olganda, OpenSource paketlarni ommalashtirish dasturiy taʼminot mahsulotlarini bozorga chiqarishga oʻxshash jarayon deb oʻylayman. Bu faoliyat bilan shugʻullanish davomida (1) men uchun ishlaydigan dasturni yozish, (2) mahsulot deb atash mumkin boʻlgan dasturni yozish va (3) mahsulotni bozorga olib chiqish oʻrtasidagi farqlarni juda yaxshi tushuna boshlaysiz.
Birinchisi ikkinchisiga qaraganda ancha kam vaqt oladi. Ikkinchisi esa uchinchisiga qaraganda kamroq vaqt talab qiladi.

Bularning barchasi qanday boshlangan?

Boshlanishi juda oddiy: men skanerli, koʻp funksiyali printer sotib olgandim va uni Linuxʼda skanerlab boʻlmas edi.
Bu boradagi maʼlumotlar bilan tanishib, skanerimning protokoli eSCL deb atalishi, uning spetsifikatsiyasi eʼlon qilinmagani, bu protokol uchun Reverse engineering mavjudligini bilib oldim. Shuningdek, protokol murakkab emasligi va hatto Pythonʼda yozilgan, ammo mening qurilmam bilan uncha chiqisha olmaydigan skript borligini aniqladim.
Protokol faoliyati DNS-SD (u ham MDNS, ham Randezvois, ham Bonjour — protokol koʻplab nomga ega boʻlishi mumkin) yordamida qurilmani qidirish va uncha murakkab boʻlmagan XMLʼga ega HTTP orqali qurilma bilan aloqa oʻrnatishdan iborat.
SANE drayveri nima ekanini koʻrib chiqdim va “sendasturchisan”, oʻzim drayver yozishga harakat qilib koʻrsam-chi deb oʻylab qoldim. Kamiga, vazifa ham unchalik murakkab emasdek tuyuldi.
Shu bilan uni yozishni boshladim. Ish tezda libcurlʼda bir nechta soʻrovlarni yozib, keyin uni qandaydir tarzda SANE drayveriga oʻxshash holatga keltirishdan emas, balki odatdagidek yigʻish tizimi, loglar, drayverning umumiy infratuzilmasi, konfiguratsiya fayli parseri va hokazolardan boshlandi. Axir men 3-bosqich talabasi emas, balki professional dasturchiman-ku...
Aytgancha, tezda libcurlʼdan foydalanishdan voz kechishga toʻgʻri keldi. SANE drayveri tabiatan istalgan dastur kontekstida ishlaydigan shared object va DLL hisoblanadi. Masalan, LibreOffice kabi katta va murakkab dasturda. Libcurl esa statik holatga ega boʻlib, undan foydalanish uchun oldin aniq soʻrov bilan ishga tushirish va keyin aksincha qilish kerak. Agar dastur kontekstida libcurlʼdan foydalanadigan ikkita DLL boʻlsa, u holda ular oʻzaro yoqalashib qolishi hech gap emas.
Jarayon mobaynida raqiblarim — sane-escl drayverini ishlab chiqqan va mendan tom maʼnoda ikki haftaga oʻzib ketgan fransiyalik talabalar paydo boʻlgani maʼlum boʻldi. Hatto boshlagan bu ishimni toʻxtatmoqchi ham boʻldim, lekin ularning “isxodnik”larini koʻzdan kechirib, davom ettirishga qaror qildim.
Shu orada talabalar men dastlab kirishni rejalashtirgan SANE loyihasiga qabul qilindi. SANE loyihasida eSCL drayveri yetishmayotgandi va men kurashishim kerak edi.

“Drayversiz” skanerlash va chop etish nima?

Bu yerda “drayversiz” skanerlash va chop etish (driverless), drayversiz skaner drayveri nima ekanini biroz tushuntirib oʻtish lozim.
Agar kimningdir yodida boʻlsa, ilgari barcha printerlar har xil boʻlgan va har biriga oʻz drayveri talab etilgan. Tabiiyki, drayverlar faqat Windows uchun boʻlib, boshqa operatsion tizimlarning foydalanuvchilari oʻz operatsion tizimlariga mos keladigan qurilmani sinchiklab tanlashiga toʻgʻri kelgan.
Aftidan, Microsoftʼni qurilma vendorlari va ularning drayverlari bilan bogʻliq daxmaza qanoatlantirar edi, ammo Apple bundan bezor boʻldi. Apple bundan buyon IPPʼga ega printerlar qutidan chiqarilgan yangi “Mak” bilan toʻgʻridan toʻgʻri ishlashi, qolgan barcha ishlab chiqaruvchilar esa istasa drayverlarini yetkazib berishi mumkinligi, ammo bunga oʻzining hech qanday aloqasi boʻlmasligini maʼlum qildi. “Mak” foydalanuvchilarining injiqligi, hamma narsa “oʻz-oʻzidan” ishlashi, bu sodir boʻlgan paytga kelib ularning koʻpligi va toʻlov qobiliyatini eʼtiborga olgan holda bu texnologiya gʻalaba qozonganiga ajablanmasa ham boʻladi. Endi esa ozmi-koʻpmi barcha printerlar IPPʼga ega.
Drayver qurilmaga emas, aksincha, qurilma bitta, universal protokoldan foydalanadigan drayverga moslashadigan printerda chop etishning bunday usul “drayversiz pechat” deb ataladi.
Apple keyinchalik skanerlar bilan ham xuddi shunday yoʻl tutdi. Ularga koʻra, bu Bonjour Scanning deb ataladi va u eʼlon qilinmagan Bonjour Printing 1.4ʼning (faqat NDA uchun beriladi, menga berilmagan, lekin men ham unchalik soʻramaganman) bir qismi boʻlib, norasmiy ravishda Apple Airscan deb ataladi (Airprintʼga oʻxshash tarzda, ilk nomi — Bonjour Printing bilan), tor doiralarda esa eSCL nomi bilan tanilgan. Aftidan, protokolning muallifi HPʼga oʻxshaydi, ammo bu aniq emas.
Hozir ham barcha skanerlar eSCLʼdan foydalanmaydi, ammo u tomon harakatlar qilinyapti.
HTTP tarmoqni nazarda tutgani, ammo tarmoqsiz va faqat USBʼdan foydalanadigan qurilmalar ham mavjud boʻlgani uchun bu borada biror narsa qilinishi kerak. Natijada USBʼni standartlashtirish bilan shugʻullanadigan tashkilot IPP over USB nomli protokolni ixtiro qildi. Aslida uni HTTP over USB deb atash maʼqulroq boʻlar edi, chunki HTTP-soʻrovi toʻgʻridan toʻgʻri USB endpointʼga yuboriladi va HTTP-javob unga qaytib keladi, HTTPʼga bogʻliq barcha harakatlar shu tartibda ishlaydi: HTTP-transportdan foydalanadigan IPP orqali printerda chop etish, eSCL orqali skanerlash va u orqali hayratlanarli tarzda hatto printerning veb-konsoli ham ishlaydi.
Bu yerda barchasi tuyulgani kabi oddiy emas, chunki HTTP, umuman olganda, TCP uchun moʻljallangan. TCP-bogʻlanishni istalgan vaqtda yopish mumkin va server mijozning soʻrovni davom ettirish ishtiyoqi yoʻqligini toʻgʻri tushunadi. USBʼda esa mijoz bilan aloqa uzilib qolganini aniqlash boʻyicha hech bir narsa koʻzda tutilmagan, shuning uchun mijoz soʻrov joʻnatishni boshlasa, u holda soʻrovni oxirigacha yetkazish va javobni oʻqish kerak. Aks holda toʻliq yuborilmagan soʻrov yoki qabul qilinmagan javobning qolib ketgan qismi USB-buferlarda tutilib qolib, xost va qurilma oʻrtasidagi sinxronizatsiya yoʻqotiladi. Keyin uni tiklash oson emas. Masalan, USB-resetʼga turli xil qurilmalar turlicha javob beradi...

Sane-airscan haqidagi hikoyaning davomi

Bir kun kelib drayverim uyalmasdan odamlarga koʻrsatsa boʻladigan holatga keldi (men tugallanmagan ishni koʻrsatish yoki eʼlon qilishni yoqtirmaydigan odamlardan biriman).
Shunday qilib, goʻl kaminayi kamtarin, sane-backendsʼdagi #202 bagning yechimi sifatida sane-esclʼni olib tashlab, oʻrniga mening mahsulotimni kiritishni taklif qildim.
Shundan soʻng nimalar roʻy berdi?
SANE loyihasining bosh meynteyneri sane-esclʼni yozgan yigitlardan mening ishim borasidagi fikrini soʻradi. Ularning bu haqdagi fikrini va nimani aytganini taxmin qilish qiyin emas (aytgancha, ularning sinov bazasi oʻnlab turli xil qurilmalardan, meniki esa bittadan olingan edi. Tabiiyki, ular oʻz sinov bazalarida mos kelmaydigan qurilmalarni topgan va faqat ular haqida yozgan). Oqibatda bozor uchun kurash yuzaga keldi va natijada quyidagilar sodir boʻldi:

1. Sane-airscan SANE distributiviga kiritilmadi. Avvaliga olishmadi, keyin esa oʻzim xohlamadim

2. Sane-airscanʼda yana bir “drayversiz” protokol — Microsoftʼning WSDʼsi paydo boʻldi.

3. Sane-airscan Linuxʼning barcha distributivlariga kiritildi

4. Sane-escl SANE tarkibiga kiradi, ammo aksariyat distributivlarda taqiqlanadi.

Attang, mahoratli siyosatchi boʻlganimda, birini boshqasiga almashtirmay, balki birga qoʻyishni taklif qilgan boʻlardim. Ana shunda WSDʼni yozishga ham hojat qolmasdi.
Oxir oqibat, loyiham SANEʼdan alohida boʻlgani men uchun yaxshi. Relizlar sikli oʻzimniki va menga qulay tarzda, barcha shon-shuhrat ham menga tegishli boʻladi.
SANE tarkibiga kirish uchun boʻlgan muvaffaqiyatsiz urinish natijasi shundaki, sane-airscan SANE litsenziyasi ostida chiqdi (GPL istisnolar bilan, aslida — LGPL). Men bu litsenziyani yoqtirmayman, uni juda qurumsoq deb hisoblayman va SANEʼga aloqam boʻlmaganida 2-clause BSDʼdan foydalangan boʻlardim.
Ochigʻi, foydalanuvchilar bundan yutdi. Keyinchalik maʼlum boʻlishicha, men foydalanuvchilardan javob olgan qurilmalarning taxminan 1/3 qismi (oʻzimning test bazam yoʻq, barcha sozlash ishlarini yozishmalar orqali bajaraman) eSCLʼni emas, faqat WSDʼni qoʻllaydi. 
Xullas, qancha foydalanuvchim bor? Bilmayman. Hozir roʻyxatimda 170 ta qurilma mavjud. Har birining oʻz tarixi bor. Koʻpincha odamlar qandaydir muammo masalasida murojaat qiladi. Muammolarning koʻp qismi mening ishtirokimsiz hal qilindi, menga faqat navbatdagi qurilma ishlab ketgani haqida xabar berishgan. Ayrim foydalanuvchilar shunchaki minnatdorchilik bildirish uchun bogʻlanadi. Baʼzilar hatto roʻyxatimdagi qurilmasi PRʼini yuboradi — men hech qachon ularga mergeʼda yoʻq demaganman.
Mahsulotimdan foydalanadigan va mening mavjudligimdan bexabar foydalanuvchilar soni minglab nafar odam bilan oʻlchanadi. Balki, oʻn minglabdir. Buni qanday aniqlash esa menga nomaʼlum.

Ommalashtirish

Ommalashtirish asosan vaqti-vaqti bilan Linux foydalanuvchilarining ingliz tilidagi forumlariga kirib, muammolarga ega fuqarolarga drayverimni sinab koʻrishni taklif etishdan iborat.
Buni amalga oshirish uchun asosiy distributivlar uchun mos paketlar yigʻishni oʻrganishga toʻgʻri keldi. Chunki biror narsani mustaqil ravishda yigʻish gʻoyasi oddiy foydalanuvchi uchun xuddi jasorat koʻrsatishga oʻxshaydi (istisnolar ham uchraydi).
Buning uchun openSUSE Build Service mavjud boʻlib, ajablanarlisi, u paketlarni nafaqat SUSE, balki koʻplab distributivlar uchun yigʻishi mumkin. Ammo uni tushunish oson emas, uning hujjatlari juda oʻziga xos. Biroq keyin hamma narsa ishlaydi va foydalanuvchilarni dasturlar yigʻishga oʻrgatishga hojat yoʻq.
Rivojlanishda muvaffaqiyatga erishishning yana bir muhim tarkibiy qismi bu — muammolarga duch kelgan foydalanuvchilarga koʻmak berish. Buning uchun anchagina sabr-toqat talab etiladi. Hamma foydalanuvchi ham yetarli malakaga ega emas. Ayrimlariga menga kerakli faylni qaysi katalogdan olishni tushuntirib, uni yuborishini soʻrash unchalik oson ish emas. Baʼzilar esa haddan tashqari sergʻayrat. Joʻnatilgan logdan deyarli hamma narsa maʼlum boʻlib, birozgina qoʻshimcha tekshirish ishlari qolgan vaqtda va unga javob yozayotganimda, foydalanuvchi tizimni uch marta qayta oʻrnatgani, distributivni oʻzgartirgani va turli kutilmagan joylarga qoʻl urgani maʼlum boʻladi. Ana undan keyin esa hamma narsani boshidan boshlashimga toʻgʻri keladi.
Drayverimni oʻz tarkibiga qabul qilgan birinchi distributiv Arch edi. Keyinchalik Ubuntu, Debian va Fedora ham shunday yoʻl tutdi. Keyin esa bu qandaydir tarzda oʻz-oʻzidan davom etib ketdi.
Rossiya distributivlari (Alt va Astra) bu harakatga Gʻarbdagi hamkasblariga nisbatan ancha kechikib qoʻshildi. Boshqalarni kuzatmagandim, shuning uchun yana nimalar boʻlganidan bexabarman.
Qizigʻi, yangi paketlar Ubuntuʼga Debian orqali keladi. Ular oʻzaro juda faol harakat qiladi va Ubuntu Debianʼning kodlar bazasiga asoslanishni juda afzal koʻradi. Paket Debianʼni chetlab oʻtib Ubuntuʼga faqatgina bir holatda, yaʼni Debian baʼzi sabablarga koʻra bu paketni xohlamagan, Ubuntu esa unga ega boʻlishni juda istagan paytda qoʻshiladi.
Masalaga boʻlgan yondashuvlardagi farq ham qiziqarli. Debian/Ubuntu oʻta sinchkovlik bilan koʻzda code review qildi, Fedora esa statik analizator orqali oʻtkazdi. Qolgan distributivlar esa bosh qotirib oʻtirmay, boricha qabul qildi.
Shuni ham taʼkidlab oʻtish kerakki, paket bunday nazoratdan faqat distributivga ilk bor kiritilayotgandagina oʻtadi. Keyinchalik patchlarim faqat qiziqish tufayli koʻrib chiqilganini hisobga olmasak, tayinli eʼtibor berilmagan.

Yozishma orqali sozlash ishlari

Avval boshdan malakaga ega boʻlmagan foydalanuvchilar qoʻlidagi oʻzaro nomuvofiq  qurilmalar bilan shugʻullanishimga toʻgʻri kelishini anglardim. Shuning uchun darhol yuqori sifatli loglar qayd etish tizimini ishlab chiqdim. Loglarda qayd etilgan maʼlumotlardan sodir boʻlayotgan hamma narsa aniq boʻlishi kerak. Albatta, bu darhol amalga oshmadi, baʼzida biron-bir muammo yuzaga kelganda, loglarda buning tafsilotlari koʻrinmagan vaziyatlar boʻldi va yetishmayotgan narsalarni qoʻshishga toʻgʻri keldi.
Shu bilan bir qatorda taʼkidlab oʻtish lozimki, loglarga hamma narsani qayta-qayta, baʼzan besh martalab (turli darajalarda) qayd etish unchalik ham yaxshi gʻoya emas. Bunday loglarni oʻqish juda qiyin, ular keraksiz ortiqcha tafsilotlar bilan chalgʻitadi.
Idealda logda dasturdagi barcha tarmoqlanishlar va bu tarmoqlanish qarori qabul qilinishiga asos qilib olingan maʼlumotlar imkon qadar tushurib qoldirilmasdan va takrorlanmasdan aks etishi kerak.
Oddiy dastur sozlovchisi emas, balki loglarga koʻra sozlash ishlarini amalga oshirish natijasidagi koʻp yillik tajriba oʻzi-oʻzidan kodni oʻzgacha tashkil qilish uslubi shakllanishiga olib keladi. Asosiy syujetni imkon qadar sodda va ochiq tarzda rivojlantirishga harakat qilasan. Aks holda, keyinchalik tushunish juda qiyin kechadi. Menimcha, bu kodni sezilarli darajada yaxshilaydi va tizimlashtiradi.
Logda dastur va tizimning ishga aloqador konfiguratsiyasi, qurilma maʼlumotlari va hokazolarni qayd etish katta ahamiyatga ega — kerakli maʼlumotlarni aniqlash uchun foydalanuvchiga savollar berishdan (ularning bir qismi foydalanuvchiga tushunarsiz boʻladi yoki notoʻgʻri talqin qilinadi) koʻra oson va ishonchliroq.
Avval boshdanoq muammolarning bir qismi tasvirlarni dekodlash bilan bogʻliq deb oʻylaganim uchun skanerdan olingan tasvirlarni ham biron joyda toʻplash kerak edi. Katta va binar boʻlgani uchun ularni asosiy logga yozish noqulay. Fayllar sonini koʻpaytirish ham yechim emas — keyinchalik foydalanuvchiga aynan qaysi fayl menga kerakligini tushuntirishda qiynalaman.
Yakunda .log fayliga parallel ravishda .tar fayliga ham yozish, olingan tasvir va men oʻqiy olmagan javoblarni oʻsha joyda saqlash qarori qabul qilindi. Bu .tarʼning formati juda oddiy boʻlib, uni toʻgʻridan toʻgʻri dasturda yaratish qiyin emas. Aslida .tar fayllar ketma-ketligi boʻlib, unda har bir fayl uchun sodda sarlavha yoziladi, keyin esa fayl tanasi keladi.

Duch kelgan muammolar

Asosan proshivkalardagi muammolar. Printerlarning proshivkalari hayratlanarli darajada nosogʻlom. XML-eʼdagi arzimagan kamchilik ayrim qurilmalar tomonidan eʼtiborga olinmaydi, boshqa qurilmalarda noaniq xatoni koʻrsatadi, yana birilarini esa qayta ishga tushiradi (men hazillashmayapman).
Nosogʻlomlik borasida Enterprise sinfiga mansub qurilmalar isteʼmol sektorining arzon qurilmalaridan ortda qolmaydi. Bundan tashqari, ular uyquga keta oladi va uygʻonishi uchun yarim daqiqa kerak, yarim uyquda oʻzini gʻalati tutadi va buni hisobga olish lozim.
Negadir HPʼning baʼzi qurilmalari HTTP soʻrovidagi Host: maydonida localhost yozilgan boʻlishini xohlaydi. Aks holda ishlamaydi. Bu nima, tarmoq orqali kirishga boʻladigan urinishga qarshi sodda himoyami? Tushunarsiz! Ular buni xohlaganini qanday taxmin qildim? Bilmayman, ichki hislarim ishga tushdi, ammo buni qandaydir tarzda sezdim.
SANEʼning oʻziga xos xususiyatlari tufayli skanerlash jarayonini ishga tushiradigan drayver vazifasini bajarib qaytgandan soʻng darhol tasvirning haqiqiy parametrlari (soʻralganlar haqida emas, chunki ular farq qilishi mumkin) haqidagi savollarga toʻgʻri javob berishi kerak. sane-escl skanerlash soʻrovi boshidan jarayon tugashiga qadar faol boʻlib, bu muammoni hal qiladi. Men esa yanada murakkab yoʻldan ketdim: drayverim soʻrovdan darhol skanerlashni boshlashga qaytadi, haqiqiy parametrlar sifatida soʻralgan parametrlarni beradi, tasvirlar orasida farq aniqlangan taqdirda haqiqiy tasvirni vaʼda qilingan parametrlarga moslashtiradi.
Buning sharofati bilan mening drayverimda cancel toʻgʻri ishlaydi.
Ayrim qurilmalar oʻlchamlarni oʻzi uchun qulay kattaroq oʻlchamga yaxlitlab, soʻralganidan kattaroq tasvir yuborgani sababli kesishni joriy etishga toʻgʻri keldi. Keyinchalik baʼzi qurilmalar WSD rejimida soʻralgan oʻlchamni umuman eʼtiborsiz qoldirishi maʼlum boʻlganda bu mexanizm menga qoʻl keldi.
Baʼzi qurilmalar oq-qora koʻrinishda skanerlash soʻroviga javoban RGB-fayl joʻnatishi mumkin. Undagi tasvir oq-qora boʻlishi mumkin, ammo RGB boʻlgani uchun rangli ham boʻlishi mumkin. Men rangli rasmni qora va oq rangga qayta hisoblashim kerak edi. Keyin bu mexanizmni biroz umumlashtirib, yorugʻlik va kontrastning in-software boshqaruvini yaratdim (hech boʻlmaganda, yorugʻlik boshqaruvini sensorlardan keladigan signallarni oʻqish oʻrniga yomon tasvirlar bilan ishlaganda yaxshiroq natija beradigan yorituv ravshanligini oʻzgartirish orqali amalga oshiradigan baʼzi qurilmalar uchun in-hardwareʼni yaratishim kerak edi).
Yaqinda PNGʼni qoʻllab-quvvatlashi eʼlon qilingan, aslida esa JPG joʻnatadigan qurilmaga duch keldim. Fayl signaturasi boʻyicha format avtodetektini yaratishga toʻgʻri keldi.
Baʼzi qurilmalar yuqori aniqlikda skanerlash imkoniyatiga ega ekaniga davogarlik qiladi, aslida esa buni amalga oshira olmaydi. Aftidan, xotirasi yetmaydi. Ularni aniqlashga va vaʼdalariga ishonmaslikka toʻgʻri keladi — mening hali tasvirni olmasdan, soʻrovda berilgan parametrlarning oʻzini qaytarish borasidagi tanlovim nafaqat afzalliklarga, balki ahamiyatga ham ega.

WSDʼni qoʻllab-quvvatlash

Bu bilan shugʻullanish masalasida uzoq vaqt ikkilandim. Ammo sane-escl ustidan mutlaq raqobatbardosh ustunlikka ega boʻlishni istardim.
Maʼlumki, Microsoft oʻz yulduz va sayyoralari bilan toʻlgan oʻziga xos olam boʻlib, ularda oʻziga xos insoniyat yashaydi. Ularning barcha tarmoq protokollari ham oʻziniki.
Ular printerda drayversiz chop etish va skanerlash gʻoyasini eʼtiborsiz qoldirmadi, lekin buni oʻziga xos tarzda amalga oshirdi.
Bu WSD — Web Services for Devices deb ataladi. WS-Print va WS-Scan. Bunga Webʼning nima aloqasi borligi aniq emas, hech kim oʻz printerini internetga ulab qoʻymaydi, chunki u yerda uzoq vaqtga omon qolmaydi. Ammo Microsoft WSDʼni negadir W3C standartlari sifatida amalga oshirdi. Bundan tashqari, ikkita dialekt mavjud boʻlib, biri MSDNʼda, ikkinchisi esa W3C standartlariga koʻra tasniflangan. Ular bir xilga oʻxshaydi, ammo XML namespacesʼni belgilaydigan URLʼlari turlicha. Mening printerim ikkala variantni ham tushunadi, boshqalarini esa tekshirmadim. Ammo Windowsʼdagi variantni amalga oshirish maʼquldir. Tabiiyki, printer ishlab chiqaruvchilari oʻz mahsulotlarini hech qachon boshqalar bilan sinab koʻrmagani aniq.
WSD — butun boshli bir olam. Ularning hatto tarmoqdagi qurilmalarni qidirish tizimi ham DNS-SDʼga asoslanmagan, balki oʻzining UDP-multikastlar orqali yuboriladigan XML asosidagi tizimi mavjud.
DNS-SDʼdan farqli oʻlaroq, Linuxʼda bunday tayyor xizmat boʻlmagan, uni oʻzim toʻgʻridan toʻgri drayverda yozishimga toʻgʻri kelgan.
Oxir oqibat, WSDʼni tushunadigan qurilmalarning taxminan 1/3 qismi eSCLʼni tushunmasligi aniqlandi. Shunday qilib, koʻpchilikning qurilmalari uchun Linuxʼga moslashishni taʼminlaganim tufayli mehnatim behuda emasdi. Garchi uzoq istiqbolda WSD, katta ehtimol bilan, oʻlayotgan protokol boʻlsa ham. IPP boʻlgani uchun printerda chop etishda undan tayinli foydalanilmagan, aytishlaricha, nihoyat Windows 11ʼda skanerlash uchun eSCL-mijoz qoʻshilgan. Shuning uchun qurilma ishlab chiqaruvchilari WSDʼni qoʻllab-quvvatlash uchun biron-bir motivatsiyaga ega emas. Agar Microsoft ekotizimiga yoʻnaltirilgan juda ajoyib enterprise-bozordan talab tushmasa...

Device discovery

Bu haqda yana bir ogʻiz soʻz aytib oʻtish kerak.
Tasavvur qiling, qurilmangiz IPv4, IPv6, HTTP, HTTPS, eSCL va WSDʼni qoʻllab-quvvatlaydi. Hatto WiFi va simlar orqali ulangan. Natijada siz uni tarmoqda topasiz... 16 marta, barcha mumkin boʻlgan kombinatsiyalarda.
Topilgan hamma narsani bechora foydalanuvchining boshiga talabalar agʻdaraversin. Bu bizning uslubimiz emas.
Natijada sane-airscan kod bazasining taxminan 1/4 qismi bitta qurilmaning oʻzi qanday shakllarda topilishi mumkin boʻlgan barcha variantlarni birlashtirgan maʼlumotdir. DNS-SD va WSDʼning butunlay har xil nomlardan foydalanishi bu vazifani umuman osonlashtirmaydi.
Bundan tashqari, DNS-SD aslida Avahi domeni keshida topilgan qurilmalar roʻyxatini oʻqiydi. WS-Discovery esa hamma narsani drayver ishga tushgan paytda oʻzi bajarishiga toʻgʻri keladi. Bularning barchasi ishonchli tarzda ishlashi uchun multikast soʻrovini bir marta yuborib, javoblarni biroz kutish va shu bilan tinchlanishning oʻzi yetarli emas. Bir necha soniya skanerlash kerak boʻladi — men tavakkal qilib bu vaqtni 2,5 soniya belgiladim. Hatto bu ham juda uzoq.
Shuning uchun topqir algoritm ixtiro qilishga toʻgʻri keldi: agar topilgan barcha qurilmalar IPP-printerlar (DNS-SD orqali), WSD-qurilmalar yoki eSCL-skanerlar sifatida (oʻlaroq) javob bersa, qidirishni davom ettirishga hojat qolmaydi. Men printer qismi boʻlmagan sof tarmoq skanerlari tabiatda kam uchraydi, printerlar bilan birlashtirilgan skanerlar esa asosan chop etish uchun moʻljallangani uchun IPP protokoliga javob beradi deb umid qilaman. Koʻpgina hollarda bu algoritm qidiruv vaqtini sezilarli darajada qisqartiradi. Nazariy jihatdan baʼzi hollarda uning qurilmani topishi beqaror boʻlishi mumkin va bunga qarshi kurashish maqsadida uni drayver sozlamalari orqali oʻchirib, toʻgʻridan toʻgʻri toʻliq skanerlashga oʻtish mumkin. Lekin hozircha hech kim shikoyat qilgani yoʻq...

ipp-usb

Avval boshdan uni yozmoqchi emas edim. Bundan tashqari, bunday protokol mavjudligini ham bilmasdim.
Sane-airscanʼga bug reportʼni yozgan birinchi odam Linuxʼda va xususan Ubuntuʼda chop etish tizimi uchun masʼul boʻlgan Till Kamppeter edi.
Till — ajoyib muhandis, u bilan ishlash huzur baxsh etadi. Masofadan sozlama ishlari amalga oshirilayotgan paytda undan nimani kutayotganimni bir ogʻiz soʻzimdan tushunadi va kerakli harakatlarni mendan ham yaxshiroq bajaradi. Bunday odam bilan ishlash baxtiga juda kamdan kam hollarda musharraf boʻlasiz.
Uning ixtiyorida boʻlgan printer ham juda ajoyib edi. Barcha qiziqarli protokollar jamlangan qandaydir arzon HP. Bu ajoyib qurilmada hammasi boʻlmasa ham, proshivka xatolarining kamida 90 foizi yigʻilganga oʻxshardi. Agar biror narsa Tillning printerida barqaror ishlasa, u boshqa qurilmalarda ham ishlashiga ishonchim komil edi.
Bir kun kelib, Till nega uning printerida USB orqali sane-escl ishlashi, mening drayverim esa ishlamasligini soʻradi.
Aslida bu savolning javobi ipp-usb edi. Ungacha Linuxʼda bu shunchaki TCP-ulanishlarni qabul qilib, ularni USBʼga uzatadigan demon — ippusbxd mavjud edi. Men unga qoʻl urmoqchi emasdim, lekin bunga majbur boʻldim.
Menda oʻsha paytda IPP over USB qurilma yoʻq edi (aniqrogʻi, printerga ulanadigan kabel yoʻq edi. Ular boshqalar kabi emas, ulagichi kvadrat shaklda). Shuning uchun sozlama ishlari Till bilan yozishmalar orqali amalga oshirildi.
Baʼzan HTTP-soʻrovga javob goʻyo kesilgan shaklda kelgandek edi. Avvaliga ippusbxd notoʻgʻri ishlayapti deb oʻyladim. Har holda u koʻp oqimli (potokli) boʻlib, har bir TCP-ulanishga bittadan oqim (potok) ajratilgan va juda sodda tarzda yozilgan. Oʻz oqimlari orasida chalkashib ketishi ham mumkin edi. U haqda hamma narsani diqqat bilan oʻqib chiqdim. Qanchalik qidirmay, yaqqol koʻrinib turgan hech bir xato yoʻq edi.
Keyin kutilmaganda xayolimga avvalgi javobning bir qismi USB buferida qolishi mumkinligi keldi. Chunki baʼzi hollarda sane-airscan javobni oxirigacha oʻqib oʻtirmay, hamma narsa aniq boʻlganda bogʻlanishni shunchaki uzib tashlaydi.
Men tezda, tom maʼnoda bir necha soat ichida Goʼda boshlangan HTTP-tranzaksiyaning davom ettirilishi mijozga kerak yoki yoʻqligidan qatʼiy nazar, uni har doim oxirigacha yetkazadigan HTTP-to-USB proxy prototipini yozdim va Till yordamida sozladim.
Xullas, hamma narsa — sane-airscan, pechat, ippusbxd orqali hech qachon ishlamagan veb-konsol ishlab ketdi va buning sababini hech kim tushunmadi.
Ammo bu ishlaydigan prototip mahsulotga oʻxshash koʻrinish olishi uchun bir oy vaqt ketdi. Bu vaqt ichida quyidagilarni bajardim:

• Qurilma anonsi DNS-SD orqali amalga oshiriladigan qilindi. Buning uchun qurilma parametrlarini printer qismi uchun IPP, skaner qismi uchun esa eSCL orqali olishni oʻrgandim. Buning uchun IPP mijoz kutubxonasini yozishimga toʻgʻri keldi, chunki Go uchun ishlaydigan tayyor kutubxona topilmadi, mavjud boʻlgani esa ishga yaramasdi va uni tuzatish uchun protokolni tushunish kerak edi. Protokolni esa ishlaydigan shaxsiy kodni yozish orqali tushunish oson edi. Modomiki, uni yozganimdan keyin (bu jami ikki kun vaqtimni oldi), mavjud boʻlganini tuzatishni xohlamadim;

• http.Clientʼdan voz kechildi, chunki Goʼda u asosan avtomatik HTTP-ulanish menejeri hisoblanadi, men esa bu joyda hech bir avtomatlashgan tizim boʻlmasligini, kechayotgan jarayonlarni toʻliq nazorat qilishni istadim;

• Goʼning libusb uchun tayyor qoplamasidan voz kechildi, libusbʼga toʻgʻridan toʻgʻri cgo orqali moslashdim. Chunki boshqa kamchilik bilan ishlaydigan qurilmalar paydo boʻldi va ular bilan ishlash qulayroq boʻlishi uchun qurilmalarga yaqinroq boʻlishni xohladim;

• Avtorotatsiyali loglar yaratildi;

• Konfiguratsiya fayli yaratildi. Keyin Till chetdagi begona kutubxonadan foydalanmaslikni soʻradi, chunki Go ularni oʻzi yuklab oladi, Linux distributivlarni yigʻish tizimi esa tarmoqdan izolyatsiya qilingan holda ishlaydi va har bir qoʻshimcha tashqi qaramlik ancha-muncha bosh ogʻrigʻini yaratadi. Shu sababli parserni qoʻlda qayta yozishimga (aniqrogʻi, ilgari “Si”da yozganimni Goʼga oʻgirishimga) toʻgʻri keldi;

• demon bilan systemdʼdan va usiz ishga tushirildi;

• man-page yozildi.

Bularning barchasi bajarilgandan soʻng ishga yaroqli prototipdan mahsulot hosil boʻldi va bu bir oy vaqt oldi (prototip bir necha soat ichida yozilganini eslang). Ammo Till tashkiliy jihatdan menga katta yordam berganiga qaramay, toʻliq ishlaydigan va rasmiylashtirilgan mahsulot distributivga qabul qilinishiga qadar yana bir necha oy, taxminan bir yil vaqt oʻtdi.
Dasturni yozish, uni mahsulotga aylantirish va bozorga olib chiqish borasidagi bu saboqni bir umrga eslab qoldim. Bu juda ibratli tajriba edi (odatda buni tashkilot amalga oshiradi va bu faoliyatning aksariyati dasturchilarni chetlab oʻtgani uchun ular bu jihatlarni tushunmaydi).

Google bilan tengma-teng

Biz dasturchilar odatda Google bilan suhbatlarda muloqot qilamiz yoki u yerga ishga kiramiz yoki boshqa narsalar boʻyicha bogʻlanamiz.
Google qiziqqan opensors loyihalar muallifi sifatida u bilan ikkita teng shaxs oʻlaroq muloqot qildim.
Ular revyu uchun menga oʻz kodlarini yuborardi, men esa injiqlik qilib, qayta ishlashni soʻrardim (aslida unchalik yomon odam emasman. Ammo ular oʻz muammolarini hal qilardi, men esa keyin bularning barchasiga egalik qilaman). Ular qayta ishlab, yana takror joʻnatardi.
Ular men bilan u yoki bu narsani bajarishning yaxshiroq usulini muhokama qilib, aytganlarimni tinglardi. Baʼzan fikrimga qoʻshilardi, baʼzida esa eʼtiroz bildirardi, ammo bu ikkita teng mavqedagi hamkorning suhbati edi.
Ular ip-usbʼni bir necha hafta ichida Cʼda qayta yozish bilan maqtandi (ular hajmi tufayli ChromeOsʼni Goʼga ololmadi), lekin uddasidan chiqa olmay, nolib keldi. Menga bu ishni olishga shama qilishdi, ammo pul taklif qilinmagani uchun olmadim. Keyin Rustʼda qayta yozishdi va buni uddalashdi. Chunki kutubxonada Rust uchun normal HTTP mavjud, ammo C uchun yoʻq. Qoʻlda yozish uchun esa istak, menda motivatsiya yoʻq edi.
Ularning milliardlab dollari borligi va butun dunyo internetiga egalik qilishi, men esa alohida jismoniy shaxs ekanim muhim emas. Biz teng huquqli, bir-birimizga nisbatan bir xil hurmat bilan gaplashdik. Bu juda gʻayrioddiy tajriba.

Minglab odamlar foydalanadigan dasturni buzib qoʻymaslik uchun nima qilish kerak?

Har bir navbatdagi yangilanish oqibatida buzilishi mumkin boʻlgan OpenSource yomon obroʻga ega kod hisoblanadi (garchi Windowsʼning yangilanishlari bilan bogʻliq soʻnggi yangiliklarni kuzatib, aslida bu obroʻga loyiqmi deb oʻylay boshlaysan).
Muammo shundaki, agar korporatsiya boʻlganimda, mening yuzlab qurilmalar oʻrnatilgan stendim boʻlardi va har bir relizim barcha qurilmalarda sinovdan oʻtkazilardi. Lekin men korporatsiya emasman va sinov stendim yoʻq. Shuningdek, mamnun foydalanuvchilarimdan har bir yangilanishni qayta sinab koʻrishni soʻray olmayman. Ularning muammosi hal qilingan va bu haqda boshqa oʻylashni xohlamaydi, shunchaki hamma narsa avvalgidek ishlashini istaydi.
Juda ehtiyotkor boʻlishga toʻgʻri keladi. Imkon qadar har bir navbatdagi yangilanish dasturning allaqachon sinovdan oʻtgan qurilmalardagi xatti-harakatlarini oʻzgartirmasligi haqida oʻylash kerak. Baʼzida xatti-harakatlarni oʻzgartirish kerak boʻladi va bunda diqqat bilan oqibatlar haqida oʻylab koʻrish lozim.
Umuman olganda, hozircha buning uddasidan chiqyapman. Garchi keng koʻlamdagi qurilmalar bilan ishlash xaskash ustida yurishga oʻxshaydi, qayerda muammo chiqishini hech qachon bilmasang ham, koʻp narsani buzmaganimdan oʻzim hayratdaman.
Ehtimol, u-bu narsani buradik va u ishlab ketdi, ammo sababini bilmaymiz, muhimi — ishlayapti tamoyili asosida ishlash emas, balki bir dunyo texnik muammolarga koʻz yummasdan har doim mohiyatni anglashga boʻlgan koʻp yillik odatim taʼsir qilsa kerak. Oxir-oqibat, muammolar aynan siz ishini toʻliq tushunmayotgan kod qatlamlarida chiqadi. Undagi biror narsaga teginishingiz bilan u ishlashdan toʻxtaydi. Agar bunday kodingiz boʻlmasa (yoki oz boʻlsa), muammoning kutilmaganda paydo boʻlish odati yoʻq. Koʻp vaqtingizni ham olmaydi. Aslida, kodingizni toʻliq nazorat qilsangiz, ishlab chiqish oson va tez kechadi. Shunchaki ishni kamaytirish maqsadida shunday oʻylangani uchun emas, balki moʻjiza tufayli ishlayotgan kodni relizga chiqarmaslik kerak.

Sanksiyalar ostidagi OpenSource

Qizigʻi, hech narsa oʻzgarmadi. Chet ellik hamkasblar va foydalanuvchilarning munosabati avvalgidek qoldi. Bir marta mendan tarmoqqa ulanish bilan bogʻliq muammolarim yoʻqmi va yordam kerakmi deb soʻrashdi, xolos. Hech kim siyosat mavzusini boshqa koʻtarmadi. Yaxshiyamki, hali ham dunyoda tashvishli siyosiy masalalar sizib kirmagan qandaydir sohalar mavjud. Shuningdek, dasturiy taʼminot bir xalqning emas, balki insoniyatning mulki ekani ham yaxshi. Hech boʻlmaganda, ochiq matn bilan yozilganlarini aytyapman.

Bu sarflangan vaqtga arziydimi?

Menimcha, ha
Tor soha uchun moʻljallangan boʻlsa ham, ikkita muvaffaqiyatli loyihaga ega kishiga suhbatda boshqacha munosabatda boʻlishadi.
Menejer buyrugʻi bilan TFSʼdagi tiketlarni yopib emas, balki loyihalarni oʻzingiz mustaqil yuritish orqali orttirilgan tajriba mutlaqo tengi yoʻq (tengsiz) va juda foydalidir. Bu mustaqillikka, rejalashtirishga, maqsadlarni oqilona belgilashga va hokazolarga oʻrgatadi. Bu kuchni behuda sarflamaslikka oʻrgatadi, axir resurslarim miqdori cheksiz emas va bu faoliyat menga daromad keltirmaydi.
Texnik tarafdan oʻz loyihangizda ishlash juda qulay. Oʻzingiz meʼmor, oʻzingiz dasturchi, oʻzingiz sifat nazorati boʻlimi. Boʻlimlar oʻrtasidagi muvofiqlashtiruv ishlarining keragi yoʻq va qarorlar oʻylab koʻrilib, uygʻun birlikda qabul qilinadi. Albatta, bularning hammasini qanday bajarishni yoqtirsangiz va bilsangiz...
Bozorga olib chiqib ommalashtirish tajribasi — dasturchilar kamdan kam hollarda duch keladigan holat. Odatda bu ish beruvchi tomonidan amalga oshiriladi. Shaxsiy tajribangiz koʻplab xomxayollarni yoʻqqa chiqaradi. Masalan, nafaqat mening kompaniya uchun qilayotgan ishlarim, balki kompaniyaning ham men uchun qilayotganlari maʼlum boʻladi. Ishlaydigan, sozlangan, sinalgan kodni yozish mahsulotni yaratishdagi ishlar hajmining yarmidan ham kamligini anglashni (nazariy jihatdan emas, balki tajribada) boshlaysiz. Koʻpincha aytilganidek, koʻp vaqtni bagfiksing emas, balki prototipni mahsulotdan ajratib turadigan, har biri oʻz-oʻzidan unchalik ahamiyatli va katta emasdek tuyuladigan, ammo birgalikda ishlaydigan mayda narsalarni yaratish oladi. Targʻib qilib ommalashtirishning oʻzi juda koʻp vaqt talab etadi. Hatto saʼy-harakatdan ham koʻproq vaqt sarflashingizga toʻgʻri keladi, chunki umuman nomaʼlum mahsulot hech kimga kerak emas, dasturingiz yaxshi boʻlgan taqdirda ham mashhurlik sekin oʻsadi.

Manba: Как делается OpenSource: личный опыт