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.

Man ko’rgan birnechta dasturchilar turlicha commitlar qilishadi PRga. Mana yana qiziqlaridan biri :)

FAFO deriving custom typeclass.

Hullas bungacha manda journal entry Key Val dan tashkil topgan edi. Manabunday:

let entry = Entry::new(vec![
            Field::string("_SYSTEMD_UNIT", "myapp.service"),
            Field::string("PRIORITY", "6"),
            Field::string("MESSAGE", "Application started"),
        ]);

Ammo bu narsa yomonam noise beradi. Rustda ham Haskell kabi derive qilsa bo'ladi typeclasslarni. Shu ideya hayolga keldi. Yani manabunaqa qilsa bo'larmikan ?

#[derive(JournalEntry)]
pub struct ServiceLog {
    #[journal(rename = "_SYSTEMD_UNIT")]
    pub unit: String,

    #[journal(rename = "MESSAGE")]
    pub message: String,
    #[journal(rename = "PRIORITY")]
    pub priority: u32,
}

Agar shunaqa bo'lsa man o'zim yasagan tipni osongina journal entryga ham o'gira olaman shu bilan birga type safety ham joyida qoladi. Undan tashqari log entrylar tag bilan ajratilgan bo'ladi constructor namega qarab bu esa journalda grouping kabi narsalar qilishga juda foydali.

Haskellda siz yozgan typeclassni derive qilish unchalik qiyin emas. GHC.Generics bilan ishingiz anchagina oson ham bitadi, bu mavzularda juda ko'p resurslar bor. Lekin rustda esa bunday mavzular haqida kerakli resurslar deyarli topolmadim. Topganim bitta shu HeapSize. Ishqilib anchagina FAFOlardan kegin bu narsani yedirdim vanihoyat man yozgan typeclassni derive qilsa bo'ladigan bo'ldi.

Implementation: https://gist.github.com/lambdajon/c815ea20b9743e69fba9911e7583d930

Aytgancha

FAFO -> Fuck Around and Find Out

Rust fichalaridan foydalanib nafaqat safe balki declarative va qisqaroq code yozsa bo'ladi.

Bunga sekin sekin ko'nikish kerak. Masalan shu macro bilan ancha user friendly bo'ldi. Undan tashqari boshqa narsalar ham bor, bazida ko'p narsani boilerplate qilib yuboramiz.

Refactoring sessiyalarini shunga ham ko'paytirmoqchiman. Shu orqali o'rganamiz har bir masalaga intensiv yondoshuvni. Agar language feauturelardan foydalanmasak Rustda yozgan bilan C++ da yozganimiz farq qilmasligi mumkin. Agar biz shunday train qilib yursak, yangi narsalarga ko'proq tolerant bo'lsak shunda Codeni AI yozberadimi yoki o'zimiz yozamizmi doyim ham katta axamiyatga ega emas. Chunki biz aynan qanday codeni qabul qilishni bilamiz aks holda AI generate qilib bergan har qanday kodni ishlataveramiz va yetmaganiga o'zimiz yozgan govnokodlarni AIga review qildiramiz.

Haskell yoki Rustga o'xshagan tillarda optional tiplarga duch kelasiz. Imperativ tillardagi NULL o'rniga ko'proq manashunday abstraksiyalar ishlatilinadi.

Haskell: Maybe
Rust: Option

Bu abstraksiyalar bizga optional valuelar bilan ishlagani kerak, imperativ tillarda aytganda nullable valuelar bilan. Ammo bilamizki imperativ tillarda null hamma joyda osilib yuradi, niz nullable valueni olib yana boshqa funksiyaga bervorishingiz mumkin vaxakazo hullas hamma joyda null tekshirish potensiali mavjud.

Immutable tilda ishlar ekansiz imperativ tillardagi odatlarni sekin chetga surish kerak. Optional narsalarni eng boshidan hal etish kerak. Bo'lmasa o'zingizni Option tipni ham qurib o'tirasiz.

Bu draft PRda aynan shu muammoni yechimini ko'rsak bo'ladi: https://github.com/bleur-org/bleur/pull/17/changes

Ammo muammo bundanda kengroq ekan, Biz Configuration degan tipda Empty degan varianti olib tashladik va endi bizda Configuration tipida empty case yo'q. Lekin muammo shundaki uning Template yoki Collection tiplariga kerakli valuelar Collection tipi construct bo'lish vaqtida bo'lmasligi mumkin.

Manashu sababli konstruksiyalar yanayam teparoqdan refactor qilinishi kerak, PRda aynan todo qolib ketgan.

PR o'ziga etibor bersangiz birgina empty case sababli qancha code kerakmas bo'lib qoldi. Shu sababli ham bunday holatlarda o'zingizni custom empty caseni qurmaslik kerak. Eng boshidan aniq ajratib olish kerak hammasini shunda ortiqcha code bo'lmaydi, ortiqcha unwrap ham bo'lmaydi. Vaqtim bemalol bo'lganida PR yakunlab qo'yaman va natijani ulashaman.

Maxsus empty caselar bazida bo'lishi mumkini ammo bu boshqa mavzu bizni contextga umuman aloqador emas.

Manashu ham misol bo'ladiki biz language feauturelardan foydalanishni o'rganishimiz kerakligiga. Albatta hammasini sekin sekin o'rganamiz.