O'ylab qarasam, odamlarga shunchaki alternativ narsalarni ko'rsatish kerak ekan.

Endi bu kanalda shu o'zimni expirementlarim, OSS, bazida koryera haqida gaplashamiz.

Hullas kim kimni aldayabti, qaysi til yaxshi yomon vaxakazolarga tupurgan holda. Turli qiziq mavzular haqida tajriba almashamiz. Faqat biroz autism va enthusiasm bilan.

Saviyasiz trollinglar va commentda yemagan narsalar bo'lsa oldindan aytaman ayamay chopaman mute qilmay, restrict qilmay balki ayamay chopaman. Agar man shunaqa qilsam feedback bering iltimos harxolda kanaldan o'zimni chopmaymanu.

O'zim file spec yasab ko'rganimdan kegin tushundimki bu yerda ham ajoyib abstraksiyalar qilsa bo'lar ekan. Shu o'rinda aytish keraki aslida bir ideya masalan shu journaling juda ko'p joylarda ishlatilingan. Bu haqida yuqorida ham aytgan edim. Lekin g'oyaning tadbiq qilinishi ham turlicha ko'rinishda bo'lgan. O'zim qilayotgan narsani biroz optimizatsiya qilish haqida o'ylar ekanman bu narsa turli layerlarda bo'lishini kuzatdim.

Masalan bazida I/O sababli dastur sekinlashishi mumkin bu muammoni hal etishga juda ham ko'p uslublar bor va bularni talabga qarab layer by layer ko'raveramiz.


Masalan Hardware levelda ham optimizatsiya uchun turli yechimlar qilingan, Bu yerda shularni bazilari bilan tanishishingiz mumkin: https://storedbits.com/hmb-vs-pseudo-slc-vs-dram-ssd/

Undan tashqari OSlarda alohida asynchronus I/O APIlar ham chiqib ketgan linuxda io_uring misol.

App layer uchun ham yechimlar ko'p biroz generallaridan biri shu Streamlar. Lekin general narsalar har doyim ham specific muammolarga yechim emas. Biz nima qilmoqchi ekanimizga qarab talablar o'zgaraveradi.

Ko'pchilik universitetlarda Computer architecture, Operating systems fanlari o'tiladi. Manashu fanlarda Harware yoki Kernel kabi mavzularni yaxshi o'qib qo'yish va bunga vaqt ajratish zarar qilmaydi, muhimi sizda background bo'lsin tushunchalar bo'lsin. Kegin qidirib topaverasiz. Yaqin kelajakda boshingiz crud qilishdan chiqmasligni bilsangiz ham yaxshi o'qing.

Buning asosiy sababi biror narsani detailed design qilganingizda juda ham ko'p nuanslar chiqib kelaveradi. Masalan birxil natija beradigan kodni turli uslubda yozish yoki optimizatsiya qilish vaxakazolar uchun biz ko'proq narsa discover qilishimiz va effectivelarni yaxshi o'rganishimiz kerak.

Masalan haskellda streamlar mavzusida juda ham ko'p experimentlar qilingan ekan. Birnechta major librarylar ham bor: conduit, pipes, streamly. Batafsil bu yerda: https://jmtd.net/log/haskell_streaming/
Bunday yechimlardan tashqari turlicha experiment namunalari bor. Kimdirlar parallel stream processing ustida research qilgan va shu tajribalardan kelib chiqib nimadir yechim qilgan vaxakazo. Hullas bular orasida adashmasam 2kun adashib qoldim juda ham ko'p ishlar qilingan ))

Hullas faylar contentini qanday o'qiyman yoki faylga qanaqa uslubda content yozaman degan savol mani shulargacha olib bordi. Qiziq tomoni shuncha narsani process qilib ham shunchaki readFile va writeFile qivorishim mumkin. Buncha ovoragarchilikdan maqsad shunchaki vibelearning emas. Masalan man oldin ham io_uring haqida o'qigan edim, oldin ham ma'lumotlar dbda qanaqa saqlanishini ko'rgan edim(Btree, MergeTree etc). Bu safargi rabbithole bilan shularni biroz update qivoldim. Albatta man qanaqadir Database, Filesystem yozishim uchun bu bilimlar umuman yetmaydi. Lekin ish bahonasida biroz learning ham zarar qilmaydi. Faqat oshirib yubormaslik kerak masalan crud yozaman deb OS haqida kitob o’qimaysizu :) Hammasi sekin sekin bilimlarni update qilib yuramiz va muhim qismi focus ko’p joyda bo’lishi kerak emas. Prioritetga qarab bo’lishi kerak. Shunda yuqorida aytganimdek o’rgangan narsalarni esdan chiqarish imkoni kamayadi. Doyim yangi mavzu o’rganish esa esdan chiqishga sabab bo’ladi. Albatta eng muhim qismi practice ham qilish kerak. Imkon boricha qanaqadir code yozish kerak.

Masalan manga umuman tushunarsiz bo'lgan narsa. Data Deduplication umuman olganda buni biroz tushunaman. Lekin FSda shu narsa qanaqa qilingani qiziq bazi joylarda bu narsa manual yani siz duplicated fielearni birlashtirvorishni aytasiz. Lekin tassavur qiling bu narsa avtomatik bo'lsa, huddi GCga o'xshaganroq.

Lekin qanaqa qilib less overhead qilsak bo'ladi ? yoki qanday qilib bunaqa ishlashi mumkin ?

Masalan duplicated blocklarni birlashtirvorib pointerlarni o'zgartirsa bo'ladi, bazida compressionlar shunaqa focuslar qiladi. Ammo bu narsa Deduplicationda yemasa kerak ))

Endi refactorlar bahona nimalarni qanday dizayn qilish haqida ham detail gaplashishimiz mumkin.

Katta abstraksiyalar kichik abstraksiyalardan tashkil topgan.

Bugun ohirga yetkazolgan ishlarimdan biri faqat quyidagi PR bo'ldi.

Hullas imerativ tillardagi for bilan qilsa bo'ladigan ko'p narsalar uchun turli abstraksiyalar o'ylab topilgan. Masalan haskellda foldlar va Foldable typeclass mavjud. Juda sodda izohlaganda to'plamli strukturalarni(Array, Vector, List etc..) bir valuega olib kelish uchun. Real misolda length yoki reduce kabi funksiyalarni olsa bo'ladi.

Rustda iterator uchun fold bor ekan shundan foydalanib for yoki custom recursion bilan qilsa bo'ladigan narsani fold bilan hal etdim.

Juda sodda va oson code bo'ldi.

https://github.com/bleur-org/bleur/pull/15

Fikrimcha manashu muhim boshlanishiga, kichik turli abstraksiyalarni o'rganamiz kegin ularni yopishtirib complexroq narsalar quramiz.

Ho'sh foldlarga misol qanaqa abstraksiyalarni bilasiz ?

100% coverage.

Tarixdan ma'lumki sanoat rivojlanishi bilan jarayonlarni avtomatlashtirish g'oyalari boshlandi, sodda mexanizmlardan murakkabroq yarm avtomat mexanik qurilmalar turli dvigitelardan tortib zamonaviy elektron qurilmalargacha.

Zamonimiz cyberpunk modeliga ham birmuncha mos keladi. Telefon va bazi gadjedlar bizning organlarimizga aylanib bo'lgan neurolink kabi narsalarni kutib o'tirish kerak emas.

Inson har davrda nimadirni osonlashtirishga harakat qildi ammo har safar qandaydir resurslar yetishmovchiligiga duchor bo'la boshladi. Resurslarni boshqarish esa iqsodiyot kabi fanlar shakillanishiga sabab bo'ldi. Biz tushundiki bazi narsalarga sarflanadigan resurslar cheklangan alternativ yechimlar kerak.

Masalan kiym tikish fabrikasini 100% avtomatlashtirgan afzalmi yoki bo'lmasam yaxshi tikuv mashinalari va tikuvchilarni yonlash kerakmi. Balki qo'lda tikish kerakdir ?

Manashunaqa tradeofflar iqsodiyot perespektivasidan qo'yila boshladi shu sababdan ham kiyim tikish fabirkalari 100% avtonom emas.

AI doirasida bo'layotgan turli fikr va munozalarlar bizni tarixga qarashga signal beradi. Kimdir konservativ kimdir liberalroq pozitsiyadan ushbu masalalarni analiz qiladi. Tarixdan ko'rdik jamiyat oddiy tovarlar oldi berdisidan elektron pullargacha qanday kelganini, tarixdan ko'rdiki hamma vahima qilgan Bitcoin oltin o'rniga o'tishi uchun yaxshigina muammoga ega ekanini(Mining va infratuzulma uchun sarflanadigan energiya)

Sanoat rivojlanishi bilan unga mos iqsodiyot, infratuzulma va yana boshqa ko'plab sektorlar rivojlangan. Yoki bu graphni har tomoni main qilib keltirishimiz mumkin. Lekin fakt shundaki hammasida tradeoff mavjud, ha nimadir kechagiday bo'lmaydi demak biz ham kechagidek bo'lmasligimiz kerak.

Dasturlash ham huddi shunday biz huddi popscience o'rgangandek doirada dasturlashni bilishimiz mumkin, ish ham topa olarmiz mayli. Ammo hal etilmagan muammolar qalashib yotibti. Iqsodiy tomondan boshqa savollar ham bor. Masalan balki fabrikani biroz avtomatlashtirarmi ? Ho'sh agar biz asosan CRUD qilsak shu ishlarni avtomatlashtiraylik, xop shunday bo'lsa ham xarajatlarimiz qanday bo'ladi ? 6ta ishchiga 1000$ to'layotgan edik, Claudecode 200$ dan 3ta hodimga qoldirsakchi ? Shunda 600+3000$. Bizga optimizatsiyalar kerak emas yangi server oladigan bo'lsak xarajat bor yo'g'i oyiga N summa qo'shilar ekan lekin optimizatsiya qilishimizga sarflangan vaqtda N^3 xarajat qilar edik.

Reallik qanday ekani biroz bo'lsada tushunarli bo'ldi deb o'ylayman.

Yaqin kunlarda Xinuxʼda boʻlayotgan oʻzgarishlar:

- GNOME oʻzbek tili tarjimalari boʻyicha yuborilgan kamchiliklar toʻgʻirlandi va yangi qoʻshilayotgan dasturlarni ham tarjima qilish jarayoni ketyapti. Tarjima qilingan oʻzbek tili ulushi 73 % dan 76 % ga oʻsdi.
- Kutubxonalarda paydo boʻlgan zaifliklarni (CVE) bartaraf etish uchun Xeonitte, software-center, e-imzo-manager ishlatgan kutubxonalar versiyasi eng oxirgi versiyasiga koʻtarildi.

Yangi dastur ishlab chiqilmoqda:

Relago — lambdajon va let-rec
tomonidan ishlab chiqarilayotgan tizimda paydo boʻlgan error xabarlarni payqab, batafsil error log haqida foydalanuvchiga UI dasturi orqali umumlashtirilgan jurnal qilib koʻrsatadi.

With sigma @shakhzodme

Our Σboys :)

Yana bir qiziq challenge.

Tassavur qiling biz bir filega Nta processdan turib content yozyabmiz va bu holatda race condition bo'lib contentlar kasha bo'lib tushish shansi bor. Masalan Process 1 hali yarmini yozib bo'lmasadan process 2 yozishni boshlaydi vaxakazo.

Ho'sh ushbu masalani qanday hal etsak bo'ladi ?

Hayolga keladigan eng sodda misollar quyidagicha.

1. File locking, bu huddi mutexlarni FSdagi versiyasiga o'xshaganroq conceptda ishlaydi. Lekin muammosi agar ko'p concurrent jobs bo'lsa deadlocks. Lekin garantiya beradi kernel darajasida.

2. Posix based systemlarda ham file denoscriptorda atomic operations qilsa bo'ladi. Masalan file desriptorni append modeda ochish orqali atomic writelar qilsak bo'ladi. Muammosi max buffer size 4KB.

3. Temp files, masalan har bir process alohida temp file ochadi va kegin safe merge qiladi. Muammosi consistencyga o'zingiz javob berishingiz kerak asosan.

4. Stariy dobriy centeralized mexanizmlar masalan bitta socketda eshitib turamiz va writelar shu socketga bo'ladi socket esa filega yozadi. Ammo over operations.

Bizni relago journalga barmoq bilan sanagulik darajadi processlar ulanadi. Shu sababli bizga mos keladigan va osonroq bitadigan ish bu albatta file locking mechanism. Resurs kam yeydi keginchalik mmap qivolish ham oson va eng muhimi read va write streamlar alohida bo'ladi shu sababli chala loglarni read qilish kabi narsalarga ham duch kelmaymiz. Agar bizni journal entrylar 4kb dan kam bo'lganida atomic qilar edik lekin bunga aniq garantiyalar yo'q xozircha write agnostic qilib entryni chunksdan yeg'ib oladigan qilsa bo'ladi lekin unga oldin max 4kblik buffer qilish kerak hullas ish ko'proq. Qolgan yechimlar esa yoki perfomance issue yoki bo'lmasam optimizatsiya uchun ko'proq code yozish kerak va ularning natijasi ham noaniq.

References:
https://gavv.net/articles/file-locks/
https://www.diskodev.com/posts/linux-atomic-operations-on-files/
https://pvk.ca/Blog/2021/01/22/appending-to-a-log-an-introduction-to-the-linux-dark-arts/

Guys tez maynerlarni o'chiramiz.

https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability.html

Hash funksiya nima deysizmi ?

Masalan biror murakkab qurilmani qiziqib ochasiz va barcha detallarini ajratib qo'yasiz, kegin birdan aralashtirvorasiz hammasini. Manashu holat o'sha qurilmaning hashed versiyasi.

Biroz intro qilishga shuni o'qisangiz bo'lsa kerak: https://tuttlem.github.io/2024/10/26/simple-hashing-algorithms.html

Naxren leetcode agar bunaqa narsalarni hayotga tadbiq qilmasangiz Qo'chqor aka!

Bu yerda esa yanada qiziqroq ma'lumot bor: https://binarymusings.org/posts/rust/rust-hashmap-memory-layout/

Bu yerda SMID bilan qilingan focuslar: https://kylematsuda.com/blog/writing_a_hashmap_part_3a

File locking cooked

Dromatic: f*ck sleep keep coding!
Realist: f*ck coding keep sleep!
Me: f*ck sleep and coding keep shitposting.

Haskell Haskell Haskell!

https://www.youtube.com/watch?v=ETxmCCsMoD0&list=RDETxmCCsMoD0&start_radio=1

WTH man ?

Man nix discourseni ochdim va asablarim tugadi.