Dynamic frequency scaling
Juda ham qiziq narsa modern cpularda mutlicoredan tashqari frequency stagelar ham bor. Masalan: power save, normal, boost.

5Ghz frequencylik cpu doyim 5Ghz ishlamaydi, boshlang’ich chastota bo’ladi. Eng qizig’i esa. O’sha 5Ghzlik cpuni 6-7Ghz qilish ham mumkin, bu narsa overclocking deyiladi.

Yana bir qiziq narsalardan biri pseudo random generator. Linux o'zida /dev/random va /dev/urandom faylarini ochib raqamlarni olsangiz bo'ladi. Lekin bu maxsus shifrlangan random raqamlar yani decode qilish kerak.

Random generate qilish bilamizki doyim o'ziga yarasha challengelardan iborat va buning turlicha algorithmlari mavjud.


Real usecaselardan biri.
cat /dev/random | hexdump bilan biz random hex generate qilsak bo'ladi, hex esa uuidga o'xshab ketadi, aniq formati va size esda yo'q bilganlar share qiling iltimos, lekin biz ls /dev/disk/by-uuid buyrug'i bilan disklar idsini ko'rsak bo'ladi va bu biz randomdan olgan formatga juda o'xshash. Ushbu idlar bizga booting paytida beriladi.

Batafsil: https://en.wikipedia.org/wiki//dev/random

D-bus degan qoʻshiq eshitayotganmidiz?

Dbus degan anime edi.

Yangi o'yinchi.

Kechadan buyon bu loglarni alohida storagega vaqtincha saqlash bizdagi logs(huddi gnome logs) kabi app uchun ko'rastish uchun mos keladigan structure o'ylayotgan edim.

1. Sqlite yoki bo'lmasa boshqa emmbeded databasedan foydalanish g'oyasi kelgandi. Ammo buning minusi loglarni dbga yozib kegin undan yana dump export qilish va server sideda ushbu loglarni yana transform qilish qiyinroq bo'lishini o'yladim.

2. Har bir problem alohida folderda saqlanadi va FS o'zida strukturalanadi, huddi linux kabi )) Ammo bu narsa report paytida collect qilib compress qilishga efficent emas chunk ko'p bo'lsa processing uzoqroq vaqt olishi mumkin.

Hullas bugun ham ushbu masala muhokamasi bo'ldi. Lekin boshqa ideya kelib qoldi. Huddi systemd journal kabi journaling organize qilsakchi ?

Linuxda jouraling yetarlicha efficient qilingan write, search, read hammasi norm. LSM tree ishlaydi undan tashqari ushbu formatni export qilish uchun ham tayyor alogirthmlar ko'p, bu degani, bizga katta loglar kelsa ham chiroyli formatga olish va troubleshooting qilish osonroq bo'ladi indexing ham oson. Hullas ideya tayyor va shuni minimalroq versiyasini yasash kerak endi.

Systemd doclarni aylanib yurib journal file formati haqida o'qib qoldim. Hullas bu narsani prototype versiyasini qilib ko'rishga arziydi, manda xozircha systemd kabi juda ko'p parametrlar emas shu sababli taxminan manashu narsalarni yaxshi qilib olsak vapshem zo'r bo'ladi.

- Can store binary data, up to 2^64-1 in size
- Seekable
- Primarily append-based, hence robust to corruption

Journal file format haqida batafsil: https://systemd.io/JOURNAL_FILE_FORMAT/

Loglar huddi suflyorga o'xshaydi.

Bir uxlab tursam yangi odamman.

Hullas tajribam davomida sezdimki man o'rgangan ko'p narsalar esdan chiqgan. Masalan 2020 yil distrubuted systems mavzulari rossa hype bo'layotgan davrda manam zadrod bo'lib o'qigan edim. U payitlar optionlar kam edi, highload degan kanalda juda ko'p mavzular topganman va yana birnechta shu youtube kanallardan qidirib bazi communitylardan kerakli odamlardan so'rab o'rgangan edim. Kegin Domain driven design ham shunaqa bo'lgan Evnasni 700 betlik nazariyasini o'rganaman deb rossa siqilgan edim unda ham shu axvol youtube, gotoda Martin Fawler amakilar chiqib rossa ko'p narsalar aytib berishardi.

2023 deyarli hechvaqo o'rganmagandim, devopslik qilganman va baravar 3ta ishda ishlagan payitim bo'ldi. Biror yangi narsa o'rganish uyoqda tursin odamlarni ko'rishni istamay qolgandim.

2024 true oop o'rganaman deb hamma joyni rasvo qilganman. Nu asosan ko'p yangi perespektivalarni discover qildim. Asosan professionalism o'rgandim desam bo'ladi. Hayotga logn term qarashni boshladim.

2025 Functional programming, Haskell etc..

Ishqilib tushundimki paytida rossa ishlatgan narsalarimi ko'pi ham esdan chiqib ketgan fikrimcha bu normal holat. Hullas kerak bo'lganida topilmaydigan uyda yotgan batareyka yoki boshqa narsa kabida bu foydalanilmagan bilim. Shu sababli nimadirdan foydalanmasam uni o'rganishga vaqt sarflash haqida o'ylab ko'raman. Agar kamida shu mavzuda expirementlarga vaqt ajrata olishimni sezsam unda qo'rmasdan o'rganaman.

O'tgan kuni bir hamkasbim bilan shu backendagi bir muammosi haqida gaplashgan edik na terminlar esga keladi na odamga o'xshab tushuntirolaman. Biroz 5-6 daqiqa o'ylab kegin gapirib berdim.

Biror narsa yaxshi esda qolishi uchun esa rutine kerak yani qanaqadir davomli shu narsaga qaytaverish. Bo'lmasa esda qolmaydi ham kerak bo'lganda esga kelmaydi ham. Shu sababli endi takrorlashni odat qila boshladim.

Journal file taxminan manashunaqa formatda bo'ladi.

Eng qizig'i odamlar binary file formatlar uchun encoder/decoder generate qiberadigan DSL ham qilishgan ekan.

Hullas ideya bunaqa.

YAMLda spec yozasiz file formatni, kegin shunga parser generate qilsa bo'ladi aynan o'sha binary data structure uchun.

Batafsil bu yerda: https://kaitai.io/#what-is-it

Man code generate qilib o'tirmadim. Lekin shu yerdagi speclardan qarab simple journal format tuzib ko'rdim va rasmda taxminiy formatni ko'ryabsiz.

Journaling aslida juda ko’p storage related systemlarda ishlatiladi.

Filesystems, databases, etc…

Oldin databaselar haqida biroz o’qigan edim ammo aynan enginelar qanaqa organize qilishini tushungan bilan o’zim yozib ko’rmaganman.

Bu videoni ko’rganda esa juda ko’p joyini tushuna boshladim.

https://youtu.be/wxcCHvQeZ-U?si=MgDkzAHioMqkWW5p

Bizni journal unchalik murakkab ham emas, lekin nosql db ideyasiga juda yaqin, agar eplolsam ADT structure ham qo’shib ko’raman biror field typega.

Hullas kimga journalga 5 qo’yib berish kerak bo’lsa kelourasilar.

1 soat oldin 2025-yil edi axir.

2-qism.

Umringizni sarflab DDIA, Cracking coding interview, clean architecture, clean code vaxakazo adabiyotlarni o'qidingiz.

O'qish yaxshu albatta lekin esda ham qolishi kerakda. Agar siz o'sha kitobdagi narsalarni amalda sinab ko'rmasangiz o'qiganingiz bir tiyn, chunki esingizdan chiqadi yoki yodlab olgan bo'lasiz.

Ko'pchilik interveiwda shaqillatib javoblar berib tashlaydi, UML chizib diagrammalarda vapshem 22-asr yechimlarini qivoradi ammo shu narsani code bilan yozib berolmaydi. Tayyor moduli frameworklar bilan bo'lsa ham qiberolmaydi, masalan spring cloud kabi.

O'zi shu sababli ham hech inteviewlarga tayyorlanmaganman. Algo & DS, System design vaxakazolarga ham unchalik etibor qilmaganman. Esimda qolgani qolgan qolmaganini eslab olaman. O'ylaymanki interviewlarga tayyorlanishdan ko'ra doyimiy learning yaxshiroq foyda beradi, lekin qandaydir vaziyat bo'lsa masalan tezroq ishga kirish kerak, pul kerak bo'lsa ha interviewga tayyorlanasizmi, leetcode yechasizmi farqiyoq. Bu yerda sizni prioritet ish topishdan iborat. Lekin long termda bu strategiya yemaydi, chunki huddi sizdaka templatedagilar qalashib yobitbi. Shu sababli short term uchun ha interviewga tayyorlanasizmi, template narsalarni yodlaysizmi buni axamiyati yo'q chunki tezroq ish topishga extiyoj bo'lishi mumkin lekin long termda bu yaxshi ishlamaydi, chunki inkubatordan chiqgan jojalar kabi birxil sizdakalar qalashib yotibti.
Agarda moddiy resurslarga extiyoj kamroq bo'lsa biroz balandroq dorga osilish, learning paytida ham expirementlar bilan qilish yaxshiroq. Chunki detailarga aralashsiz, murakkab abstraksiyalar sodda abstraksiyalardan tashkil topgan shu sababli siz ham eng quyi abstraksiyalardan boshlab o'rganishingiz va amaliyotlar qilishingiz mumkin. Long termdagi rejalarda trendlar katta axamiyatga ega emas, shu sababli trendagi adabiyotlar yoki trendagi mavzularga emas balki fundamentalroq narsalarni o'rganishga va torroq mavzularda rivojlanishga etibor qaratish yaxshiroq fikrimcha.

Manashu strukturani parsingi tayyor, hashtable qoldi, lekin spec bo'yicha parsing tayyor.

https://github.com/Susambil-Labs/journal-monad/blob/master/src/Journal.hs

Endi bunga write streamlar qo'shish kerak va agar man biror structure berib shuni journalga yozsam o'zi encode qilib streamga tashlashi kerak.

Shunda bunaqa tassavur qilsangiz bo'ladi.

Har bir journal entry bu raw
Har bir entry field bu column.

Ammo journal holatida hammasi dynamic typed yani bunga pofig tiplar.

Ho'sh tiplar qachon kerak aynan databse perespektivasida ?

Man bilganim asosan indexlash uchun kerak. Yani tipga qarab indexing strategiyalari qilinadi. Indexlansa demak search va sort oson bo'ladi eng kamida.

Demak xozirgi turishida bitta NOSQL concept ham tayyor bonusga structured journaling.

Ertaga streamlarni cook qilib ko’ramiz. Haskellda eventga o’xshatibroq stream qilishni bilmayman xozircha. Yoki bo’lmasam database connectionlardan ilhomlanish mumkin. Bunga ham focus o’ylaymiz albatta fikrlar bo’lsa yozib qoldiring.

Data size uchun ham kerak, masalan binary formatlarda hamma data bir biriga yopishib ketadi shunga aniq bit by bit qarash yoki turli focuslar bilan bufferlar qilish kerak. Lekin uyam muammoli. Shu sabab datasize uchun kerak.

Compression uchun kerak. Bizda empty bufferlar 0 0 0 0 bo'ladi, bulari adashmasam losless compress qilsa bo'ladi.

Xozir hayolga kelib qoldi uyqudan oldin.