Nix Store Path'lari: Hashning Sirri

Keling, to'g'ri gapiray. Siz ham ko'rgan bo'lsangiz kerak — /nix/store ichidagi shu g'alati directory nomlari:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

O'ng tomondagi bash-5.3p9 aniq — bu nima ekanini darhol tushunasiz. Lekin chiziqchasidan oldingi 32 ta belgi? Shu yerda jumboq.

Ko'pchilik shunday tushuntiradi: "Hash inputlardan keladi." To'g'ri, ammo to'liq emas.

Ikki Xil Yondashuv, Bir Joy

Nix store path'lari uchun ikkita alohida mexanizm ishlatadi, va ikkalasi ham /nix/store ostida tinchgina yashaydi. Bu ikkisini aralashtirish — mana bu yerda chalkashlik boshlanadi.

Input-Addressed: Qurishdan Oldin Nomlash

Oddiy package build'lari uchun Nix me'mor kabi ishlaydi. Siz .nix faylini yozasz — Nix uni derivation ga aylantiradi. Bu aniq reja bo'lib, ichida:

• Builder script
• Build argumentlari
• Environment o'zgaruvchilari
• Chiqishlari (outputs)
• Bog'liqliklar (dependencies)

bor.

Shu reja tufayli Nix build boshlanishidan oldin unique identifier hisoblaydi. Binary'lar hali yo'q, lekin Nix ularni qanday chaqirishni allaqachon biladi.

Shuning uchun .nix faylini tahrirlashingiz har doim store path'ni o'zgartirmaydi. Agar o'zgartirishlaringiz derivation'ni o'zgartirmasa, Nix eski nomni qaytaradi. Ikki xil ifoda bir xil derivation'ga olib kelsa, bir xil path'ni oladi.

Content-Addressed: Baytlardan Nomlash

Lekin Nix boshqacha ham ishlaydi. nix store add buyrug'ini bersangiz, Nix tayyor file'ni oladi va darhol baytlarni hash'laydi. Hech qanday evaluation, hech qanday derivation — faqat content.

Bu yerda path nima borlig'iga qarab belgilanadi. Bir byte o'zgartirsangiz — hash ham o'zgaradi.

Bu Farq Nima Uchun Muhim?

Mana nega bu tushuncha muhim:

Path o'zgarishini bashorat qilish. "X ni o'zgartirsam, store path o'zgarmasmi?" — degan savol tug'ilsa, shuni so'rang: bu o'zgartirish derivation'ni yoki content'ni o'zgartiradimi? Comment o'zgartirdingizmi? Ehtimol, path o'zgarmaydi. Dependency versiyasini yangiladingizmi? Albatta, yangi path.

Eski va yangi build birga yashaydi. Nima uchun store ichida turli xil build natijalari birga bo'lishi mumkin? Sababi — ularning identity'lari turli. Nix yozib qo'ymaydi. Unga kerak emas.

Cache ishlatish mantiqiy. Binary cache o'ziga ishonch bilan oldindan built path'ni berishi mumkin, chunki nom build inputlarini aniq belgilaydi. Bir xil nom — bir xil content.

Path Yolg'iz Emas

Store path hech qachon yakka bo'lmaydi. Built package'lar boshqa store path'larni chaqiradi — dynamic library'lar, interpreter'lar, shared assets. Nix bu bog'liqliklarni graph sifatida kuzatadi.

Bu faqat metadata emas — bu to'liq dependency xarita. Har qanday path'dan boshlab, uning closure'ini kuzatishingiz mumkin: bu path ishlashi uchun kerak bo'lgan hamma narsa. Shu texnologiya orqali nix-copy-closure ishlaydi, va shu sababli Nix deployment'lari ishonchli.

Shu bazaning yordamida Nix integrity'ni tekshiradi — diskdagi baytlar hali ham yaratilgandagi yozuvga mos keladimi yoki yo'qmi.

Xulosa

U g'alati hash'lar tasodifiy emas. Bu ataylab qilingan qaror: Nix derivation'larni input'lar bo'yicha, content'ni baytlar bo'yicha nomlaydi. Shu ikki yondashuv tufayli Nix reproducible, tekshirilishi mumkin, va — tushunsangiz — bashorat qilinishi mumkin.

Keyinchalik store path ko'rganda, vahima qilmang. O'ngdan chapga o'qing — bu odamlar uchun qism. Chap tomondagi hash — bu Nix'ning va'dasi: bu nom — shu build, va boshqa hech narsa emas.

Chuqurroq o'rganishga tayyormisiz? Container deployment, infrastructure boshqarish, yoki reproducible build'lar haqida qiziqishingiz — nimani ko'zlasangiz ham, sistemaning ichida nima bo'layotganini tushunish doim foyda keltiradi. Bizning blog'da texnik bilimlarni oddiy tilda tushuntirishga intilamiz.

Xavfsiz build qilishlar!