Sistem operasi (OS) adalah topik yang luas. Selama beberapa dekade, satu pendekatan telah mendominasi di sini: Unix. Memang, sebagian besar sistem modern, termasuk sebagian besar distribusi GNU / Linux, * BSD dan macOS, mematuhi arsitektur Unix. (Tidak ada Windows, tetapi hampir tidak ada yang menarik pada topik ini).

Pada tahun 2000, Rob Pike membuat presentasi tentang mengapa penelitian perangkat lunak sistem tidak relevan . Karena pesimisme atau pengabaian terhadap komunitas, ia tampaknya benar-benar mengabaikan keluhan yang dikumpulkan oleh banyak pengguna Unix dalam The Unix-Haters Handbook (1994). Buku ini sengaja sarkastik, tetapi menunjukkan beberapa masalah kritis dengan sistem Unix - dan mereka belum terselesaikan.

Pada tahun 2006, Elko Dositra menerbitkan disertasinya, "Model Penerapan Perangkat Lunak yang Sepenuhnya Fungsional , " yang menggambarkan manajer paket Nix yang fungsional. Pada 2008, penulis menerbitkan NixOS: distribusi Linux yang berfungsi penuh . Walaupun NixOS menggunakan kembali banyak perangkat lunak gratis untuk sistem Unix, ia sangat jauh dari desain dan filosofi Unix sehingga hampir tidak dapat disebut "sistem Unix".

Nix adalah lompatan besar ke depan dalam rekayasa sistem. OS ini tidak hanya menyelesaikan banyak masalah Unix (termasuk kritik dari koleksi yang disebutkan sebelumnya), tetapi juga membuka jalan bagi banyak fungsi dan studi lain yang dapat memainkan peran yang sangat penting di zaman kita, ketika keandalan dan keamanan telah menjadi topik utama banyak ilmiah, publik dan politik. debat.

Pike salah. Dan ini membuktikan poin lain yang lebih umum: mungkin lebih bijaksana untuk menahan diri dari menyatakan penelitian apa pun yang tidak relevan jika Anda tidak dapat membuktikan ketidakmungkinan pengembangan lebih lanjut. Dan laporan tersebut hampir tidak dapat dianggap sebagai bukti matematis. Dia hanya memperkuat gagasan bahwa Unix "cukup baik" dan bahwa Anda harus memahami fitur dan masalahnya.

Untungnya, pesimisme yang tidak perlu ini berpandangan pendek dan tidak bertahan lama: hanya beberapa tahun kemudian, sistem Nix membuktikannya salah.

Penampilan Guix

Guix adalah manajer paket pada Nix, dan GuixSD adalah sistem operasi, setara dengan NixOS, yang bertujuan untuk menjadi "OS yang sepenuhnya dapat diprogram". Memang, hampir semua yang ada di sini ditulis dan dikonfigurasi dalam Skema Guile : dari manajemen paket Guix hingga sistem inisialisasi gembala GNU .

Guix sangat berbeda dari sistem operasi Unix. Anda dapat melihat dokumentasi dan mengevaluasi tingkat perubahan:

• Panduan Resmi dan Daftar Fitur
• Panduan Paket Guix adalah pengantar teknis (salin di sini ).

Manfaat Guix

Manfaat Guix bersifat revolusioner sampai pada titik di mana sisa OS tampak seperti sistem warisan dibandingkan dengan itu.

Fitur favorit pribadi saya:

• Sistem kekebalan: Guix menyimpan riwayat semua perubahan di tingkat sistem dan pengguna. Jika pembaruan merusak sesuatu, Anda selalu dapat memutar kembali. Hal ini membuat sistem hampir kebal .
  
• Integritas: karena konfigurasi bersifat deklaratif, itu memberi pengguna atau administrator sistem kontrol penuh. Pada varian Unix lainnya, akan lebih sulit untuk mengatakan ketika beberapa file konfigurasi acak berubah.
  
• OS yang sepenuhnya dapat diprogram: konfigurasi sistem program dan gunakan sistem kontrol versi. Banyak layanan sistem dapat dikonfigurasi dalam Skema Guile: dari aturan udev ke Xorg, PAM, dll. Berkat Guile, konfigurasi dapat bergantung pada perangkat keras atau bahkan nama host!
  
• Pengganti langsung untuk manajer paket lain (tidak begitu baik): mengapa secara terpisah mengelola paket Emacs, Python atau TeXlive jika ada antarmuka tunggal untuk semua orang (lihat di bawah )! Lebih mudah untuk menulis dan memelihara deklarasi untuk profil pengguna.
  
• Definisi paket tipuan: Jauh lebih efisien untuk mengembangkan definisi paket secara massal . Itu menggantikan konsep seperti flag USE Portage (lihat di bawah ).
  
• Beberapa cara mengeluarkan paket: Paket Guix dapat memiliki beberapa "cara penerbitan", yang digunakan untuk memisahkan berbagai komponen (perpustakaan, alat tambahan, dokumentasi, dll.). Pada sistem operasi lain (biasanya Debian), lebih sulit untuk menebak paket mana yang cocok.
  
• Input non-multiplikasi: Dalam terminologi Guix, “input” adalah dependensi paket. Profil dan lingkungan pengguna hanya berisi paket-paket yang diinstal secara eksplisit oleh pengguna dan tidak harus bergantung pada mereka. Misalnya, lihat inxi , alat untuk melaporkan informasi sistem: jika saya hanya tertarik pada laporan tentang sistem / peralatan inxi, tidak perlu menambahkan dua hingga tiga lusin alat baris perintah tambahan ke PATH . Guix memungkinkan Anda untuk menampilkan di profil pengguna hanya apa yang benar-benar dia butuhkan.
  
• Lingkungan Guix: Ketika Anda menjalankan guix environment SOME-PACKAGES Guix mengatur lingkungan sementara di mana semua persyaratan untuk SOME-PACKAGES . Ini dapat digunakan untuk dengan mudah mengkonfigurasi lingkungan build untuk proyek, serta untuk tujuan lain (lihat di bawah). Satu kualitas hebat - memungkinkan Anda menjalankan program tanpa menginstalnya di profil pengguna.
  
• Pembaruan sebagian: 100% didukung. Ini mungkin alasan utama kerusakan pada rilis mengambang seperti Arch Linux dan Gentoo: karena hanya beberapa versi yang didukung di sana pada waktu yang sama (biasanya hanya satu), seluruh sistem harus diperbarui seluruhnya. Ini berarti lebih banyak lalu lintas dengan setiap pembaruan. Dengan Guix, paket apa pun diperbarui secara terpisah.
  
• Integrasi berkelanjutan atau mengapa Guix dapat bekerja tanpa pengelola paket: terima kasih untuk build yang dapat direproduksi dan dukungan untuk pembaruan parsial, jika paket itu bekerja pada Guix, itu akan berfungsi "selalu" dan beberapa dependensi tidak akan rusak selama pembaruan berikutnya (lebih tepatnya, jika ketergantungan merusak paket, maka ini sepele diperbaiki untuk menggunakan versi perpustakaan yang benar). Dengan demikian, bekerja dengan paket dapat ditransfer ke "ladang pertanian" (satu di Hydra dari proyek Nix, yang lain di Cuirass ). Bandingkan ini dengan sebagian besar komunitas GNU / Linux lainnya, yang membutuhkan lusinan pengelola untuk memutakhirkan ribuan paket. Pendekatan ini tidak berskala: pada akhirnya, distribusi ini mandek pada beberapa ribu paket. Di Guix, jumlah paket dapat tumbuh dengan tenang tanpa takut runtuh. Pada saat yang sama, kontributor dapat digunakan secara lebih efisien.
  
  Di Guix, membangun dari sumber sama mudahnya. Sebenarnya, ini tidak begitu penting bagi pengguna akhir: Guix dapat dengan mudah kembali ke perakitan dari sumber jika paket yang sudah jadi tidak tersedia.
  
• guix import dan guix refresh : Secara otomatis dan rekursif membuat atau memperbarui definisi paket. Ratusan definisi diproses secara bersamaan. Fitur-fitur tersebut menekankan manfaat dari bahasa pemrograman nyata di OS. Yang merupakan tugas yang sulit pada kebanyakan sistem operasi, relatif mudah diimplementasikan di Guix.
  
• Saluran Guix: salah satu fitur favorit saya! Arch Linux atau Gentoo mengharuskan Anda membuat repositori lokal. Karena mereka tidak mendukung pembaruan parsial, pengguna perlu melakukan pemeliharaan dari waktu ke waktu (mis., Pastikan bahwa pembaruan ketergantungan tidak merusak paket). Saluran Guix yang menguntungkan mengganti overlay AUR dari Arch Linux dan Gentoo, memungkinkan siapa saja untuk mendistribusikan definisi paket mereka, misalnya, dari repositori Git. Sekali lagi, ini menjamin transparansi lengkap (suap, sejarah, dll.).
  
• Emacs-Guix : Sejauh yang saya tahu, Guix adalah satu-satunya distribusi yang hadir dengan antarmuka pengguna Emacs yang paling kuat!
  
• Paket Guix : alternatif nyata untuk wadah seperti Docker. Sebagian besar sistem kontainer mengalami masalah kritis: mereka tidak dapat diputar ulang dan pada kenyataannya mereka adalah binari buram, yang secara kategoris tidak dapat diterima untuk pengguna yang peduli dengan kepercayaan, keamanan dan privasi. Sebaliknya, paket Guix benar-benar jelas, dapat diproduksi ulang, dan transparan.
  
• guix system vm dan guix system disk-image : Guix membuatnya sepele untuk memainkan seluruh sistem saat ini sebagai USB langsung, di dalam VM atau pada mesin jarak jauh.

Guix dibandingkan dengan pesaing

Debian, Arch Linux, dan sebagian besar distribusi GNU / Linux lainnya

Distribusi GNU / Linux biasanya tidak memiliki manfaat Guix yang disebutkan di atas. Kekurangan paling kritis:

• Kurangnya dukungan untuk beberapa versi paket atau "neraka ketergantungan." Katakanlah mpv terbaru membutuhkan ffmpeg baru, tetapi memperbarui ffmpeg merusak sebagian besar program lain. Kami terjebak dalam dilema: memecah beberapa paket atau menyimpan versi lama. Lebih buruk lagi, mungkin tidak ada paket yang cocok sama sekali, atau tidak ada dukungan OS. Masalah ini melekat pada sebagian besar distribusi yang tidak dapat menjamin pemenuhan tugas utama mereka: paket untuk program apa pun .
  
• Ketergantungan kritis pada pengelola. Manajemen paket non-fungsional berarti bahwa semua paket harus selalu diuji kompatibilitasnya. Ini adalah kerja keras bagi mereka yang memikul tugas ini. Dalam praktiknya, ini berarti bahwa kualitas manajemen paket sangat tergantung pada orang. Distribusi tanpa jumlah pemelihara yang memadai pasti akan menderita dan mungkin mati. Persyaratan tenaga kerja ini biasanya tidak diskalakan dan, ketika jumlah paket meningkat, mengarah pada peningkatan kompleksitas (baik dalam basis kode dan dalam manajemen).

Gentoo, * BSD

Gentoo dan distribusi lainnya dengan manajer paket Portage memiliki fitur terkenal: Flag USE untuk mengaktifkan fungsi di seluruh sistem (misalnya, bisu, aktifkan dukungan GUI, dll.).

Bendera USE membuatnya sepele untuk mengaktifkan atau menonaktifkan fungsi dari pembuat paket (dan keuntungannya adalah mereka diuji). Di sisi lain, Portage tidak memungkinkan Anda untuk mengkonfigurasi fitur yang tidak dipikirkan sebelumnya. Sebagai contoh, jika sebuah paket memiliki suara tambahan, tetapi pembuatnya belum menetapkan flag yang sesuai, pengguna tidak akan dapat berbuat apa-apa (kecuali untuk membuat definisi paket baru).

Sebagai perbandingan, Guix memungkinkan Anda untuk sepenuhnya menyesuaikan semuanya, meskipun dengan sedikit lebih banyak kode Skema. Dalam kode pseudo, tampilannya seperti ini:

 (loop-over (TARGET-PACKAGES) (package (inherit TARGET) (changes-here... including patches, build options, etc.)) 

Kumpulan kode seperti itu menetapkan definisi untuk TARGET-PACKAGES dengan perubahan Anda. Tidak ada perubahan yang perlu dilakukan pada definisi paket. Kapan saja, pengguna tetap memegang kendali penuh atas perubahan yang mungkin dilakukan pada paket.

Saya mencintai Gentoo, tetapi setelah beralih ke Guix, batasan Portage menjadi jelas.

• Sistem flag USE tidak memungkinkan penyesuaian fungsi sewenang-wenang yang tidak direncanakan.
  
• Menggunakan bendera menambahkan seluruh kelas kompleksitas (lihat semantik atom yang agak rumit) untuk menggambarkan dan mengelola hubungan fungsi antar paket. Guix sepenuhnya menghapus tingkat kerumitan ini menggunakan Skema Guile untuk hubungan program.

Selain itu, Portage menderita masalah yang sama dengan kurangnya dukungan yang tepat untuk beberapa versi, dan flag secara signifikan meningkatkan skala masalah (sering keluhan tentang Portage): ketika flag USE yang tidak kompatibel berlaku untuk beberapa dependensi, pengguna harus mencari solusi secara manual. Terkadang ini berarti bahwa fungsi yang diperlukan tidak berlaku (setidaknya tanpa kerja signifikan pada definisi paket).

Dalam praktiknya, Guix menyediakan paket yang telah dikompilasi - penghemat waktu yang sangat besar dibandingkan dengan Gentoo (walaupun Portage mendukung distribusi paket biner).

* Sistem BSD (mis. FreeBSD) menderita masalah serupa di make config .

Nix

Nix adalah terobosan bersejarah dalam riset sistem operasi, dan Guix meminjam hampir semua idenya dari sana. Saat ini, Nix masih merupakan salah satu OS aktif terbaik. Guix mungkin tidak akan ada jika bukan karena satu cacat.

Menurut pendapat saya, Guix memecahkan masalah Nix utama: alih-alih bahasa spesifik domain (DSL), bahasa pemrograman Guile Scheme Lisp yang lengkap digunakan di sini.

"Menerapkan bahasa pemrograman Anda sendiri" adalah kesalahpahaman yang sangat umum dalam pengembangan perangkat lunak. Ini melanda banyak proyek di mana konfigurasi atau bahasa pemrograman menderita dari kerugian berikut:

• ekspresif dan kemampuan terbatas;
  
• Bahasa lain untuk belajar (tetapi bukan sesuatu yang sangat berguna dan universal), yang membutuhkan upaya dari pengguna dan, dengan demikian, menciptakan penghalang entri;
  
• kode yang kurang mudah dibaca (setidaknya pada awalnya);
  
• seringkali kinerjanya buruk.

Ada begitu banyak proyek dalam bahasa lokal atau bahasa yang terlalu terbatas:

• XML, HTML (lebih baik: S-XML )
• Buat, Autoconf, Automake, Cmake, dll.
• Bash, Zsh, Fish (lebih baik: Eshell atau scsh )
• JSON, TOML, YAML
• Portage ke Nix Ebuild dan banyak aturan sintaks lainnya untuk definisi paket OS
• Firefox saat digunakan XUL (Mozilla sejak meninggalkannya) dan sebagian besar bahasa homegrown lainnya untuk ekstensi
• SQL
• Oktaf, R, PARI / GP, sebagian besar program ilmiah (mis. Common Lisp, Racket, dan Skema lainnya)
• Ekspresi reguler ( rx dalam Emacs , PEG dalam Racket , dll.)
• sed, AWK, dll.
• Sebagian besar konfigurasi init, termasuk systemd (bahkan lebih baik: Gembala GNU )
• cron (lebih baik: mcron )
• conky (tidak sepenuhnya dapat diprogram, meskipun ini harus menjadi fitur yang paling diantisipasi dari program serupa)
• TeX, LaTeX (dan semua turunannya), Asymptote (bahkan lebih baik: scribble , skribilo - masih dalam pengembangan; hingga Januari 2019, TeX / LaTeX masih digunakan sebagai langkah perantara dalam menyiapkan PDF)
• Sebagian besar program dengan konfigurasi yang tidak menggunakan bahasa pemrograman untuk tujuan umum.

Menemukan kembali roda biasanya bukan ide yang baik. Ketika datang ke alat penting seperti bahasa pemrograman, ini memiliki konsekuensi yang sangat dramatis. Diperlukan upaya tambahan yang tidak perlu, kesalahan terjadi. Komunitas itu tersebar. Komunitas yang lebih terkonsolidasi lebih efisien dan memanfaatkan waktu mereka dengan lebih baik jika mereka meningkatkan bahasa pemrograman yang ada dan berkembang dengan baik.

Bukan hanya untuk desktop

Guix mendukung beberapa arsitektur (i686, x86_64, ARMv7, dan AArch64 pada Januari 2019), dan berencana untuk mendukung lebih banyak core di luar ekosistem Linux (katakanlah * BSD, GNU Hurd, atau mungkin sistem Anda sendiri!).

Ini membuat Guix alat yang hebat untuk menggunakan server (yang dapat direproduksi) dan sistem khusus lainnya. Saya berpikir bahwa dalam embedded system, Guix dapat bersaing dengan sangat baik dengan OpenWRT (walaupun akan membutuhkan beberapa pekerjaan untuk port ke embedded system).

USB langsung mereproduksi sendiri

Di atas, saya menyebutkan guix system disk-image : misalnya, ini memungkinkan Anda untuk membuat ulang sistem saat ini pada USB flash drive.

Dengan demikian, klon dari sistem saat ini mudah untuk terhubung di mana saja dan mereplikasi lingkungan saat ini yang tepat (minus perangkat keras). Anda dapat memasukkan data pengguna di sana: kunci PGP, email. Semuanya tersedia segera setelah diunduh.

Jelas, kloning bekerja lebih jauh dari mesin tempat klon dipasang: alih-alih Guix "telanjang", OS yang lengkap dikerahkan, siap untuk bekerja.

Mengganti manajer paket lain

Emacs, Python, Ruby ... dan kekuatan guix environment

Guix dapat mengganti manajer paket apa pun, termasuk manajer paket bahasa pemrograman. Ini memiliki beberapa keunggulan:

• Reproduksibilitas di mana-mana.
  
• Kembalikan di mana-mana.
  
• Tidak perlu mempelajari manajer paket lain.

Pada titik ini, Anda harus menyebutkan guix environment . Perintah ini mengatur lingkungan sementara dengan hanya satu set paket tertentu, seperti virtualenv . Fitur pembunuh adalah sifatnya universal untuk semua bahasa dan kombinasinya.

Texlive

(Penafian: Pada Januari 2019, sistem build TeXlive untuk Guix sedang dirancang ulang).

TeXlive menerima penyebutan khusus karena sangat mengerikan :), yang sekali lagi menegaskan peran penyelamatan Guix!

Sebagian besar sistem operasi berbasis Unix biasanya mendistribusikan TeXlive sebagai bagian dari paket paket. Sebagai contoh, Arch Linux memiliki selusin ini. Jika Anda memerlukan beberapa paket TeX dari set yang berbeda, maka Arch Linux tidak meninggalkan pilihan selain menginstal ribuan paket (mungkin tidak perlu), dan TeXlive membutuhkan banyak ruang: ratusan megabita.

Atau, Anda dapat menginstal TeXlive secara manual, tetapi mari kita hadapi itu: tlmgr hanya manajer paket yang buruk, dan itu membutuhkan pekerjaan tambahan yang membosankan.

Menggunakan Guix, paket TeXlive diinstal secara terpisah, seperti yang lainnya, yang membantu Anda memelihara paket TeXlive Anda sendiri atau bahkan membuat spesifikasi lingkungan virtual untuk mengkompilasi dokumen tertentu.

Intinya

Banyak sistem operasi hanya menawarkan dukungan terbatas untuk kernel khusus. Jika pengguna ingin pindah dari kernel default, maka kernel non-standar harus dipertahankan secara manual.

Gentoo diketahui “mengharuskan” kernel pengguna sebagai langkah instalasi yang disarankan (wajib?). Namun, ini bukan prasyarat, dan pengguna sendiri harus mendukung konfigurasi kernel.

Di Guix, kernel adalah paket reguler yang sepenuhnya dapat disesuaikan, seperti yang lainnya. Anda dapat mengonfigurasi semuanya dan meneruskan file konfigurasi kernel ke definisi paket.

Sebagai contoh, berikut ini adalah definisi dari kernel Linux yang tidak bebas dengan driver iwlwifi (peringatan: Saya sangat tidak menyarankan menggunakan driver berpemilik, karena mereka menimbulkan ancaman serius terhadap privasi dan kebebasan Anda):

 (define-module (ambrevar linux-custom) #:use-module (guix gexp) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix git-download) #:use-module (guix build-system trivial) #:use-module ((guix licenses) #:prefix license:) #:use-module (gnu packages linux) #:use-module (srfi srfi-1)) (define-public linux-nonfree (package (inherit linux-libre) (name "linux-nonfree") (version (package-version linux-libre)) (source (origin (method url-fetch) (uri (string-append "https://www.kernel.org/pub/linux/kernel/v4.x/" "linux-" version ".tar.xz")) (sha256 (base32 "1lm2s9yhzyqra1f16jrjwd66m3jl43n5k7av2r9hns8hdr1smmw4")))) (native-inputs `(("kconfig" ,(local-file "./linux-custom.conf")) ,@(alist-delete "kconfig" (package-native-inputs linux-libre)))))) (define (linux-firmware-version) "9d40a17beaf271e6ad47a5e714a296100eef4692") (define (linux-firmware-source version) (origin (method git-fetch) (uri (git-reference (url (string-append "https://git.kernel.org/pub/scm/linux/kernel" "/git/firmware/linux-firmware.git")) (commit version))) (file-name (string-append "linux-firmware-" version "-checkout")) (sha256 (base32 "099kll2n1zvps5qawnbm6c75khgn81j8ns0widiw0lnwm8s9q6ch")))) (define-public linux-firmware-iwlwifi (package (name "linux-firmware-iwlwifi") (version (linux-firmware-version)) (source (linux-firmware-source version)) (build-system trivial-build-system) (arguments `(#:modules ((guix build utils)) #:builder (begin (use-modules (guix build utils)) (let ((source (assoc-ref %build-inputs "source")) (fw-dir (string-append %output "/lib/firmware/"))) (mkdir-p fw-dir) (for-each (lambda (file) (copy-file file (string-append fw-dir (basename file)))) (find-files source "iwlwifi-.*\\.ucode$|LICENSE\\.iwlwifi_firmware$")) #t)))) (home-page "https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi") (synopsis "Non-free firmware for Intel wifi chips") (description "Non-free iwlwifi firmware") (license (license:non-copyleft "https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.iwlwifi_firmware?id=HEAD")))) 

Kernel dan firmware khusus dapat dimasukkan secara kondisional dalam konfigurasi sistem saat ini (beberapa file config.scm ):

 (define *lspci* (let* ((port (open-pipe* OPEN_READ "lspci")) (str (get-string-all port))) (close-pipe port) str)) (operating-system (host-name "...") ;;... (kernel (cond ((string-match "Network controller: Intel Corporation Wireless 8888" *lspci*) linux-nonfree) (#t linux-libre))) (firmware (append (list linux-firmware-iwlwifi) %base-firmware)) 

Kemudian ikuti langkah-langkah ini untuk menginstal konfigurasi sistem baru:

 sudo -E guix system reconfigure config.scm 

Bahkan tanpa menginstal kernel baru, Anda dapat langsung membuat gambar yang siap untuk boot dari drive USB.

Permainan

Karena paket Guix menggunakan teknologi canggih (misalnya, versi terbaru Mesa) dan memungkinkan penyetelan kernel penuh, ini adalah platform yang ideal untuk gim dan, khususnya, untuk gim pengemasan !

Sayangnya, industri game jauh dari filosofi perangkat lunak gratis, dan sangat sedikit game yang dikemas sebagai bagian dari proyek resmi Guix.

Meskipun Guix menyukai perangkat lunak gratis dan tidak menerima kepemilikan dalam repositori, ironisnya, banyak fitur canggih menjadikan Guix paket manajer yang ideal untuk perangkat lunak berpemilik.

Beberapa manfaat:

• guix environment memungkinkan Anda untuk menjalankan aplikasi apa pun dalam wadah terisolasi yang membatasi akses ke jaringan, menyembunyikan sistem file (tidak ada risiko bahwa program berpemilik akan mencuri beberapa file Anda, katakanlah, dompet bitcoin atau kunci PGP) dan bahkan informasi tingkat sistem seperti sebagai nama pengguna. Ini diperlukan untuk menjalankan program sumber tertutup yang tidak dapat diandalkan.
  
• Manajemen paket fungsional: program sumber tertutup biasanya tidak tahan uji waktu dan istirahat ketika ketergantungan perpustakaan mengubah API-nya. Karena Guix mendefinisikan paket di atas versi apa pun dari dependensi apa pun (tanpa konflik dengan sistem saat ini), Guix memungkinkan Anda membuat paket untuk game dengan kode sumber tertutup yang akan berfungsi selamanya.
  
• Lingkungan yang dapat direproduksi: Program sumber tertutup umumnya portingnya buruk dan mungkin berperilaku berbeda pada sistem dengan dependensi yang sedikit berbeda. Properti reproduktifitas Guix menyiratkan bahwa jika kita membuat paket Guix berfungsi sekali, itu akan selalu berfungsi (kecuali untuk kerusakan perangkat keras atau perubahan konfigurasi perangkat keras).

Untuk alasan ini, Guix adalah alat yang ideal untuk mengemas dan mendistribusikan game sumber tertutup.

Namun, ini adalah topik terpisah yang besar, yang lebih baik ditinggalkan untuk artikel lain.

Kiat dan Trik

Emacs-guix

Salah satu manfaat Guix yang luar biasa adalah antarmuka Emacs-Guix , yang memungkinkan Anda untuk menginstal dan menghapus paket, secara selektif memperbarui, mencari, beralih ke definisi paket, mengelola generasi, mencetak "perbedaan" di antara mereka, dan banyak lagi.

Ini memiliki mode pengembangan untuk perakitan dan pemrograman, serta lingkungan interaktif khusus yang disebut Skema REPL . Ini adalah antarmuka pengguna yang unik untuk sistem operasi.

Ada juga antarmuka Paket Sistem Helm , yang sebagian tumpang tindih dengan Emacs-Guix, tetapi bagi saya sepertinya lebih menyenangkan untuk pencarian paket cepat dan operasi cepat.

Penyimpanan data

Karena Guix menyimpan beberapa generasi konfigurasi sistem (termasuk seluruh riwayat paket), Guix membutuhkan lebih banyak ruang disk daripada sistem operasi lain.

, 2018 25 ( , ), 50 .

guix gc , « », , .

Emacs-Guix mx guix-store-dead-item , .

, guix gc --references guix gc --requisites . guix build ... , .

, , , :

 $ guix gc --references $(guix build -d coreutils) | grep builder /gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder 

Seringkali berguna untuk membuat manifes dari semua paket yang diinstal dalam profil.

Ini dapat dilakukan menggunakan skrip Guile berikut:

 (use-modules (guix profiles) (ice-9 match) (ice-9 pretty-print)) (match (command-line) ((_ where) (pretty-print `(specifications->manifest ',(map manifest-entry-name (manifest-entries (profile-manifest where)))))) (_ (error "Please provide the path to a Guix profile."))) 

Misalnya, jalankan di profil Anda ~/.guix-profile:

 $ guile -s manifest-to-manifest.scm ~/.guix-profile 

Dotfile saya melacak riwayat paket yang diinstal. Karena saya juga menyimpan versi Guix, saya dapat kembali ke kondisi persis sistem saya kapan saja di masa lalu.

Referensi

Beberapa antarmuka web:

• Daftar Paket Guix
  
• Pelacak pesan kesalahan
  
• Keinginan

Dokumen:

• GNU Guix "staging" code ( mengapa Lisp memainkan peran penting dalam pengembangan)
  
• Catatan Peter

Paket tidak resmi:

• Saluran Paket Chromium
  
• Paket dari Oleg Pykhalov