Sistemas operacionais (SO) são um tópico abrangente. Por décadas, uma abordagem dominou aqui: Unix. De fato, a maioria dos sistemas modernos, incluindo a maioria das distribuições GNU / Linux, * BSD e macOS, aderem à arquitetura Unix. (Não há Windows, mas não há quase nada de interessante nesse tópico).
Em 2000, Rob Pike fez uma apresentação sobre por
que a pesquisa de software do sistema não é relevante . Devido ao pessimismo ou desconsideração da comunidade, ele parece ter ignorado completamente as reclamações coletadas por muitos usuários do Unix no
The Unix-Haters Handbook (1994). O livro é deliberadamente sarcástico, mas aponta alguns problemas críticos com os sistemas Unix - e eles ainda não foram resolvidos.
Em 2006, Elko Dositra publicou sua dissertação,
"Um modelo de implantação de software totalmente funcional" , que descreve o gerenciador de pacotes Nix funcional. Em 2008, o autor publicou o
NixOS: uma distribuição Linux totalmente funcional . Embora o NixOS reutilize muito software livre para sistemas Unix, ele está tão longe do design e da filosofia do Unix que dificilmente pode ser chamado de "sistema Unix".
O Nix é um grande salto em frente na engenharia de sistemas. Esse sistema operacional não apenas resolveu muitos problemas do Unix (incluindo críticas da coleção mencionada), mas também abriu caminho para muitas outras funções e estudos que podem desempenhar um papel muito importante em nosso tempo, quando a confiabilidade e a segurança se tornaram o principal tópico de muitos assuntos científicos, públicos e políticos. debate.
Pike estava errado. E isso prova outro ponto mais geral: provavelmente é mais prudente abster-se de declarar qualquer pesquisa irrelevante se você não puder provar a impossibilidade de desenvolvimento adicional. E o relatório mencionado dificilmente pode ser considerado prova matemática. Ele apenas reforçou a idéia de que o Unix é "bom o suficiente" e que você deve aceitar seus recursos e problemas.
Felizmente, esse pessimismo desnecessário acabou por ser míope e não durou muito: apenas alguns anos depois, o sistema Nix provou que estava errado.
Aparência Guix
O Guix é o gerenciador de pacotes do Nix e o GuixSD é o sistema operacional, o equivalente ao NixOS, que visa ser um "sistema operacional totalmente programável". De fato, quase tudo aqui é escrito e configurado no
Guile Scheme : do gerenciamento de pacotes Guix ao sistema de inicialização
GNU shepherd .
O Guix é significativamente diferente dos sistemas operacionais Unix. Você pode visualizar a documentação e avaliar o grau de alteração:
Benefícios Guix
Os benefícios do Guix são revolucionários ao ponto em que o restante do sistema operacional se parece com sistemas legados em comparação a ele.
Meus recursos favoritos pessoais:
- Invulnerabilidade do sistema: o Guix mantém um histórico de todas as alterações nos níveis do sistema e do usuário. Se a atualização quebrar algo, você sempre poderá reverter. Isso torna o sistema praticamente invulnerável .
- Integridade: como a configuração é declarativa, ela fornece ao usuário ou administrador do sistema controle completo. Em outras variantes do Unix, é muito mais difícil dizer quando algum arquivo de configuração aleatório muda.
- Sistema operacional totalmente programável: programe as configurações do sistema e use um sistema de controle de versão. Muitos serviços do sistema podem ser configurados no esquema do Guile: das regras do udev ao Xorg, PAM, etc. Graças ao Guile, a configuração pode estar condicionada ao hardware ou mesmo ao nome do host!
- Substituição direta de outros gerenciadores de pacotes (não tão bons): por que gerenciar separadamente pacotes Emacs, Python ou TeXlive, se houver uma interface única para todos (veja abaixo )! É mais fácil escrever e manter declarações para perfis de usuário.
- Definições de pacotes do Guile: É muito mais eficiente desenvolver definições de pacotes em massa . Ele substitui favoravelmente conceitos como sinalizadores de uso do Portage (veja abaixo ).
- Várias maneiras de emitir pacotes: Um pacote Guix pode ter várias "maneiras de emitir", que são usadas para separar os vários componentes (bibliotecas, ferramentas adicionais, documentação, etc.). Em outros sistemas operacionais (geralmente Debian), é mais difícil adivinhar quais pacotes se encaixam.
- Entradas não multiplicadoras: Na terminologia do Guix, “entradas” são dependências do pacote. O perfil e o ambiente do usuário contêm apenas pacotes instalados explicitamente pelo usuário e não necessariamente suas dependências. Por exemplo, consulte inxi , uma ferramenta para relatar informações do sistema: se eu estiver interessado apenas em relatórios sobre o sistema / equipamento inxi, não é necessário adicionar de duas a três dúzias de ferramentas de linha de comando adicionais ao
PATH . O Guix permite que você exiba no perfil do usuário apenas o que ele realmente precisa.
- Ambientes Guix: Ao executar o
guix environment SOME-PACKAGES Guix configura um ambiente temporário no qual SOME-PACKAGES todos os requisitos para SOME-PACKAGES . Isso pode ser usado para configurar facilmente o ambiente de construção para o projeto, bem como para outros fins (veja abaixo). Uma ótima qualidade - eles permitem que você execute programas sem instalá-los no perfil do usuário.
- Atualizações parciais: 100% suportadas. Esta é provavelmente a principal causa de falhas nos lançamentos flutuantes, como o Arch Linux e o Gentoo: como apenas várias versões são suportadas ao mesmo tempo (geralmente apenas uma), todo o sistema deve ser atualizado como um todo. Isso significa mais tráfego a cada atualização. Com o Guix, qualquer pacote é atualizado individualmente.
- Integração contínua ou por que o Guix pode funcionar sem mantenedores de pacotes: graças às construções reproduzíveis e ao suporte para atualizações parciais, se o pacote funcionar no Guix, ele funcionará "sempre" e alguma dependência não será interrompida durante a próxima atualização (mais precisamente, se a dependência quebrar o pacote, isso é trivialmente corrigido para usar a versão correta da biblioteca). Assim, o trabalho com pacotes pode ser transferido para “fazendas de montagem” (uma na Hydra do projeto Nix e a outra no Cuirass ). Compare isso com a maioria das outras comunidades GNU / Linux, que exigem dezenas de mantenedores para atualizar milhares de pacotes. Essa abordagem não é escalável: no final, essas distribuições estagnam em alguns milhares de pacotes. No Guix, o número de pacotes pode crescer silenciosamente, sem medo de colapso. Ao mesmo tempo, os colaboradores podem ser usados com mais eficiência.
No Guix, construir a partir da fonte também é fácil. De fato, isso não é tão importante para o usuário final: o Guix pode retornar facilmente à montagem a partir das fontes se o pacote finalizado não estiver disponível.
guix import e guix refresh : Crie ou atualize de forma automática e recursiva as definições de pacotes. Centenas de definições são processadas simultaneamente. Tais recursos enfatizam os benefícios de uma linguagem de programação real no sistema operacional. O que é uma tarefa difícil na maioria dos sistemas operacionais, é relativamente fácil de implementar no Guix.
- Canais Guix: um dos meus recursos favoritos! O Arch Linux ou Gentoo requer que você crie um repositório local. Como eles não oferecem suporte a atualizações parciais, o usuário precisa fazer alguma manutenção periodicamente (ou seja, verifique se as atualizações de dependência não quebram os pacotes). Os canais Guix substituem lucrativamente as sobreposições AUR do Arch Linux e Gentoo, permitindo que qualquer pessoa distribua suas definições de pacotes, por exemplo, nos repositórios Git. Mais uma vez, isso garante total transparência (propinas, histórico etc.).
- Emacs-Guix : Até onde eu sei, o Guix é a única distribuição que vem com a interface de usuário mais poderosa do Emacs!
- Pacotes Guix : uma alternativa real para contêineres como o Docker. A maioria dos sistemas de contêineres sofre de problemas críticos: eles não podem ser reproduzidos e, na realidade, são binários opacos, o que é categoricamente inaceitável para usuários que se preocupam com confiança, segurança e privacidade. Pelo contrário, as embalagens Guix são absolutamente claras, reproduzíveis e transparentes.
guix system vm e do guix system disk-image : o Guix facilita a reprodução de todo o sistema atual como USB ativo, dentro da VM ou em uma máquina remota.
Guix em comparação com os concorrentes
Debian, Arch Linux e a maioria das outras distribuições GNU / Linux
As distribuições GNU / Linux normalmente não têm os benefícios mencionados acima do Guix. As deficiências mais críticas:
- Falta de suporte para várias versões de pacotes ou "inferno das dependências". Digamos que o mpv mais recente exija um novo ffmpeg, mas a atualização do ffmpeg interrompe a maioria dos outros programas. Estamos presos a um dilema: ou quebre alguns pacotes ou salve versões antigas. Pior, pode não haver um pacote adequado ou não há suporte para o sistema operacional. Esse problema é inerente à maioria das distribuições que não podem garantir o cumprimento de sua principal tarefa: um pacote para qualquer programa.
- Dependência crítica de mantenedores. O gerenciamento não funcional de pacotes significa que todos os pacotes devem ser constantemente testados quanto à compatibilidade. Isso é muito trabalho duro para aqueles em cujos ombros essa tarefa foi confiada. Na prática, isso significa que a qualidade do gerenciamento de pacotes depende muito das pessoas. Uma distribuição sem um número suficiente de mantenedores sofrerá inevitavelmente e possivelmente morrerá. Esse requisito de mão-de-obra normalmente não é dimensionado e, à medida que o número de pacotes aumenta, leva a um aumento na complexidade (tanto na base de código quanto no gerenciamento).
Gentoo, * BSD
O Gentoo e outras distribuições com o gerenciador de pacotes do
Portage têm um recurso famoso:
flags USE para ativar funções em todo o sistema (por exemplo, mudo, ativar o suporte a GUI, etc.).
Os sinalizadores USE tornam trivial ativar ou desativar funções do autor do pacote (e a vantagem é que elas são testadas). Por outro lado, o Portage não permite configurar recursos que não são pensados com antecedência. Por exemplo, se um pacote tiver um som adicional, mas o autor não tiver definido o sinalizador correspondente, o usuário não poderá fazer nada a respeito (exceto para criar uma nova definição de pacote).
Em comparação, o Guix permite que você personalize completamente tudo, embora com um pouco mais de código de esquema. No pseudo-código, é algo parecido com isto:
(loop-over (TARGET-PACKAGES) (package (inherit TARGET) (changes-here... including patches, build options, etc.))
Esse lote de códigos define as definições de
TARGET-PACKAGES com suas alterações. Nenhuma das alterações precisa ser feita na definição do pacote. A qualquer momento, o usuário mantém controle total sobre as alterações que podem ser feitas nos pacotes.
Eu amei o Gentoo, mas depois de mudar para o Guix, as limitações do Portage se tornaram aparentes.
- O sistema de sinalizador USE não permite a personalização de funções arbitrárias não planejadas.
- O uso de sinalizadores adiciona uma classe inteira de complexidade (consulte a semântica atômica bastante complicada) para descrever e gerenciar o relacionamento de funções entre pacotes. O Guix remove completamente esse nível de complexidade usando o Guile Scheme para programar relacionamentos.
Além disso, o Portage sofre do mesmo problema com a falta de suporte adequado para várias versões e os sinalizadores aumentam significativamente a escala do problema (uma reclamação frequente sobre o Portage): quando os sinalizadores USE incompatíveis se aplicam a algumas dependências, o usuário deve procurar manualmente uma solução. Às vezes, isso significa que a função necessária não é aplicável (pelo menos sem trabalho significativo nas definições de pacote).
Na prática, o Guix fornece pacotes pré-compilados - uma enorme economia de tempo em comparação com o Gentoo (embora o Portage suporte a distribuição de pacotes binários).
* Os sistemas BSD (por exemplo, FreeBSD) sofrem de problemas semelhantes no
make config .
Nix
O Nix foi um avanço histórico na pesquisa de sistemas operacionais, e o Guix emprestou quase todas as suas idéias a partir daí. Hoje, o Nix ainda é um dos melhores sistemas operacionais ativos. Guix provavelmente não existiria se não fosse por uma falha.
Na minha opinião, o Guix resolve o principal problema do Nix: em vez de sua própria
linguagem específica de domínio (DSL), uma linguagem de programação completa baseada em Lisp baseada em Lisp é usada aqui.
"Implementar sua própria linguagem de programação" é um equívoco muito comum no desenvolvimento de software. Isso ocorreu em muitos projetos nos quais a configuração ou a linguagem de programação sofria das seguintes desvantagens:
- expressividade e capacidades limitadas;
- Outro idioma para a aprendizagem (mas não algo muito útil e universal), que requer algum esforço do usuário e, portanto, cria uma barreira de entrada;
- código menos legível (pelo menos no início);
- desempenho geralmente fraco.
Existem muitos projetos em idiomas locais ou muito limitados:
- XML, HTML (melhor ainda: S-XML )
- Marca, Autoconf, Automake, Cmake, etc.
- Bash, Zsh, Fish (ainda melhor: Eshell ou scsh )
- JSON, TOML, YAML
- Portage para o Nix Ebuild e muitas outras regras de sintaxe para definições de pacotes do SO
- Firefox quando usado XUL (o Mozilla o abandonou desde então) e a maioria dos outros idiomas internos para extensões
- SQL
- Octave, R, PARI / GP, a maioria dos programas científicos (por exemplo, Common Lisp, Racket e outro esquema)
- Expressões regulares ( rx no Emacs , PEG na raquete etc.)
- sed, AWK, etc.
- A maioria das configurações init, incluindo systemd (melhor ainda: GNU Shepherd )
- cron (ainda melhor: mcron )
- conky (não totalmente programável, embora esse deva ser o recurso mais esperado de um programa semelhante)
- TeX, LaTeX (e todos os derivados), Assíntota (ainda melhor: rabisco , skribilo - ainda em desenvolvimento; a partir de janeiro de 2019, o TeX / LaTeX ainda é usado como uma etapa intermediária na preparação do PDF)
- A maioria dos programas com configurações que não usam uma linguagem de programação de uso geral.
Reinventar a roda geralmente não é uma boa idéia. Quando se trata de ferramentas importantes como linguagens de programação, isso tem consequências muito dramáticas. Esforços adicionais desnecessários são necessários, erros ocorrem. A comunidade está se espalhando. Comunidades mais consolidadas são mais eficientes e aproveitam melhor seu tempo se melhorarem as linguagens de programação existentes e bem desenvolvidas.
Não apenas para a área de trabalho
O Guix suporta várias arquiteturas (i686, x86_64, ARMv7 e AArch64 a partir de janeiro de 2019) e planeja suportar mais núcleos fora do ecossistema Linux (digamos * BSD,
GNU Hurd ou talvez seu próprio sistema!).
Isso faz do Guix uma ótima ferramenta para implantar servidores (reproduzíveis) e outros sistemas especializados. Eu acho que em sistemas embarcados, o Guix pode competir muito bem com o
OpenWRT (embora seja necessário algum trabalho para portar para sistemas embarcados).
USB ao vivo com reprodução automática
guix system disk-image acima a
guix system disk-image : por exemplo, ele permite recriar o sistema atual em uma unidade flash USB.
Assim, é fácil conectar um clone do sistema atual a qualquer lugar e replicar o ambiente atual exato (menos o hardware). Você pode incluir dados do usuário: chaves PGP, email. Tudo está disponível imediatamente após o download.
Obviamente, a clonagem funciona mais longe da máquina na qual o clone está instalado: em vez do Guix "nu", um sistema operacional completo é implantado, pronto para trabalhar.
Substituindo outros gerenciadores de pacotes
Emacs, Python, Ruby ... e o poder do guix environment
O Guix pode substituir qualquer gerenciador de pacotes, incluindo gerenciadores de pacotes de linguagens de programação. Tem várias vantagens:
- Reprodutibilidade onipresente.
- Reversões onipresentes.
- Não há necessidade de aprender outro gerenciador de pacotes.
Neste ponto, você deve mencionar o
guix environment . Este comando configura um ambiente temporário com apenas um conjunto específico de pacotes, como
virtualenv . O recurso matador é que é universal para todos os idiomas e suas combinações.
Texlive
(Isenção de responsabilidade: a partir de janeiro de 2019, o sistema de compilação TeXlive para Guix está sendo redesenhado).
O TeXlive recebeu uma menção especial porque é especialmente terrível :), o que confirma mais uma vez o papel salvador do Guix!
A maioria dos sistemas operacionais baseados em Unix normalmente distribui o TeXlive como parte de um conjunto de pacotes. Por exemplo, o Arch Linux possui uma dúzia deles. Se você precisar de alguns pacotes TeX de conjuntos diferentes, o Arch Linux não tem escolha a não ser instalar milhares de pacotes (possivelmente desnecessários), e o TeXlive ocupa
muito espaço: centenas de megabytes.
Como alternativa, você pode instalar o TeXlive manualmente, mas vamos ser
tlmgr : o
tlmgr é apenas um gerenciador de pacotes ruim e requer um trabalho adicional tedioso.
Usando o Guix, os pacotes TeXlive são instalados separadamente, como tudo o mais, o que ajuda a manter seu próprio conjunto de pacotes TeXlive ou até a criar especificações de ambiente virtual para compilar documentos específicos.
O núcleo
Muitos sistemas operacionais oferecem suporte limitado apenas a kernels personalizados. Se os usuários quiserem se afastar do kernel padrão, o kernel não padrão deverá ser mantido manualmente.
Sabe-se que o Gentoo “exige” o kernel do usuário como a etapa de instalação recomendada (obrigatória?). No entanto, isso dificilmente é um pré-requisito e os próprios usuários devem suportar a configuração do kernel.
No Guix, o kernel é um pacote regular totalmente personalizável, como qualquer outro. Você pode configurar tudo e passar o arquivo de configuração do kernel para a definição do pacote.
Por exemplo, a seguir estão as definições de um kernel Linux não livre com o driver
iwlwifi (aviso: eu não recomendo o uso de drivers proprietários, pois eles representam uma séria ameaça à sua privacidade e liberdade):
(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"))))
O kernel e o firmware personalizados podem ser condicionalmente incluídos na configuração atual do sistema (algum arquivo
config.scm ):
(define *lspci* (let* ((port (open-pipe* OPEN_READ "lspci")) (str (get-string-all port))) (close-pipe port) str)) (operating-system (host-name "...")
Em seguida, siga estas etapas para instalar uma nova configuração do sistema:
sudo -E guix system reconfigure config.scm
Mesmo sem instalar um novo kernel, você pode criar diretamente uma imagem pronta para inicializar a partir de uma unidade USB.
Os jogos
Como os pacotes Guix usam tecnologias avançadas (por exemplo, as versões mais recentes do Mesa) e permitem o ajuste completo do kernel, esta é uma plataforma ideal para jogos e, em particular, para
empacotar jogos!
Infelizmente, a indústria de jogos está longe de ser uma filosofia de software livre, e muito poucos jogos são empacotados como parte do projeto oficial do Guix.
Embora o Guix represente software livre e não aceite nenhuma propriedade em seu repositório, ironicamente, muitos recursos avançados fazem do Guix um gerenciador de pacotes ideal para programas não livres.
Alguns dos benefícios:
guix environment permite que você execute qualquer aplicativo em um contêiner isolado que restrinja o acesso à rede, oculte o sistema de arquivos (não há risco de o programa proprietário roubar alguns de seus arquivos, por exemplo, carteira de bitcoin ou chaves PGP) e até mesmo informações no nível do sistema, como como nome de usuário. Isso é necessário para executar qualquer programa de código fechado não confiável.
- Gerenciamento funcional de pacotes: os programas de código fechado geralmente não resistem ao teste do tempo e ao intervalo quando uma dependência de biblioteca altera sua API. Como o Guix define pacotes sobre qualquer versão de qualquer dependência (sem conflitos com o sistema atual), o Guix permite criar pacotes para jogos com código fonte fechado que funcionarão para sempre.
- Ambiente reproduzível: programas de código fechado geralmente são mal portados e podem se comportar de maneira diferente em sistemas com dependências ligeiramente diferentes. A propriedade de reprodutibilidade do Guix implica que, se fizermos o pacote Guix funcionar uma vez, ele sempre funcionará (exceto uma falha no hardware ou uma alteração na configuração do hardware).
Por esses motivos, o Guix é uma ferramenta ideal para empacotar e distribuir jogos de código fechado.
No entanto, este é um grande tópico separado, que é melhor deixar para outro artigo.
Dicas e truques
Emacs-guix
Um dos benefícios surpreendentes do Guix é a
interface Emacs-Guix , que permite instalar e remover pacotes, atualizar seletivamente, pesquisar, passar para a definição de pacotes, gerenciar gerações, imprimir as "diferenças" entre eles e muito mais.
Possui modos de desenvolvimento para montagem e programação, além de um ambiente interativo especial chamado Scheme
REPL . Essa é uma interface de usuário exclusiva para o sistema operacional.
Há também a interface
Helm System Packages , que se sobrepõe parcialmente ao Emacs-Guix, mas me parece mais agradável para pesquisas rápidas de pacotes e operações rápidas.
Armazenamento de dados
Como o Guix armazena várias gerações de configurações do sistema (incluindo todo o histórico de pacotes), ele requer mais espaço em disco do que outros sistemas operacionais.
Na minha experiência, em 2018, a partição de 25 GB precisou ser limpa uma vez por mês (levando em conta que tenho grandes solicitações sobre o número de pacotes) e a partição de 50 GB pode ser deixada sem vigilância por um ano inteiro.É conveniente usar o comando para limpar o armazenamento guix gc, mas ele pode remover "muitos pacotes", ou seja, pacotes que serão necessários imediatamente durante a próxima atualização.O Emacs-Guix possui um comando mx guix-store-dead-itemque classifica os pacotes mortos por tamanho e permite que você os exclua individualmente.Se você precisar analisar dependências, veja guix gc --referencese guix gc --requisites. Isso pode ser combinado com a saída guix build ...para ver os diferentes elementos do gráfico de dependência.Por exemplo, para visualizar o código de um dos scripts de construção, abra o arquivo retornado pelo seguinte comando: $ guix gc --references $(guix build -d coreutils) | grep builder /gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder
Geração de manifesto
Geralmente é útil gerar um manifesto de todos os pacotes instalados em um perfil.Isso pode ser feito usando o seguinte script do Guile: (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.")))
Por exemplo, execute-o no seu perfil ~/.guix-profile: $ guile -s manifest-to-manifest.scm ~/.guix-profile
Meus dotfiles rastreiam o histórico de pacotes instalados. Como também mantenho a versão do Guix, posso retornar ao estado exato do meu sistema a qualquer momento no passado.Referências
Algumas interfaces da web:Documentos:Pacotes não oficiais: