Bedrock Linux - no artigo semanal de Jesse Smith

faz algum tempo que senti ter atingido o “limite” das distros que estou disposto a tentar. ─ Gostaria de continuar tendo uma “gentoo-based” (gostei do Sabayon), mas instalar o Gentoo “na unha” está além do que me interessa por enquanto. ─ LFS, então, nem pensar.

Desde quando cheguei a esse ponto, há uns 2 anos, Bedrock foi a única “distro” que realmente me interessou ─ mas até hoje consegui me segurar.

Já foi abordada aqui, pelo @GRUB em Outubro 2020.

“Geologicamente”, Bedrock é a “rocha-base”, e em cima dele podem-se instalar algumas outras distros, como “estratos”.

Esta semana, Jesse Smith dedicou sua avaliação ao Bedrock, e até onde consigo entender (de leituras anteriores), me pareceu uma descrição correta, porém simples e bem sintetizada. ─ Além disso, ele tentou forçar alguns limites, por curiosidade, ─ e conta os resultados.

Por exemplo, usar o Void com Runit como base e depois instalar Arch e Ubuntu. O Snap2 não funcionou (não tenho interesse nele), mas o AUR e o Flatpak, sim.

Interessantes, as observações sobre as pastas e arquivos de sistema “repetidos” e a manobra para colocar no Menu do Void os aplicativos das outras camadas.

Interessante, também, que o Void + Arch + 2 versões do Ubuntu ocuparam apenas 7 GB em disco. ─ Essa era uma das minhas preocupações.

Esta é apenas a tradução automática, que também funcionou razoavelmente bem:

───────────────────
Bedrock Linux 0.7.20 Bedrock LinuxBedrock Linux é um dos projetos mais interessantes que encontrei em minhas viagens pela comunidade de código aberto. Bedrock Linux é uma meta distribuição, o que significa que não é realmente uma distribuição do kernel do Linux e das ferramentas de usuário correspondentes. Em vez disso, é um tipo especial de ferramenta que permite que diferentes distribuições do Linux trabalhem juntas como se fossem um único sistema operacional.

Dito de outra forma, considere que muitas pessoas se preocupam com quanta diversidade (ou fragmentação, se você preferir) existe no ecossistema Linux. As pessoas se preocupam com a existência de muitos gerenciadores de pacotes, muitos formatos e padrões diferentes. Eles se sentem frustrados por saberem que diferentes distribuições têm diferentes pontos fortes e fracos. Eles se irritam com o conflito de querer instalar um Red Hat Enterprise Linuxclone para obter estabilidade de longo prazo enquanto também deseja alguns programas de ponta do repositório do Arch Linux .

Bedrock Linux busca reverter, ou pelo menos oferecer uma alternativa, à fragmentação. Com o Bedrock, podemos instalar uma distribuição, que podemos considerar nosso sistema operacional principal ou primário. Então, sem usar uma máquina virtual, Bedrock nos permite instalar uma segunda distribuição e colar efetivamente as partes da segunda distribuição que queremos. Isso significa que você pode ter a estabilidade e o enorme repositório de pacotes do Debian em seu sistema operacional principal, enquanto faz a amostragem dos novos pacotes mais recentes demonstrados no Fedora e obtém programas raramente empacotados do Repositório de Usuário do Arch Linux ( AUR) Com o Bedrock Linux, a ideia é que você não precisa escolher qual distribuição deseja executar e não precisa de máquinas virtuais ou partições separadas para cada distribuição. Bedrock efetivamente cola múltiplas distribuições, junto com suas ferramentas e gerenciadores de pacotes, em uma meta-distro.

Vamos dar uma olhada em um exemplo prático de Bedrock em ação. Antes de mergulhar, lembre-se de que existem algumas limitações. Existem componentes de distribuições que não funcionam bem ao trabalhar além dos limites de Bedrock. Existem também algumas limitações que são abordadas no site da Bedrock. Por exemplo, normalmente é uma boa ideia usar o software init e os ambientes de desktop de sua primeira distribuição (primária). Em outras palavras,com SysV init e Xfce, mas depois decidir que deseja usar a área de trabalho Cinnamon e o systemd de uma instalação secundária do Linux Mint . Tente certificar-se de que o init, o gerenciador de serviço e os ambientes de desktop que você deseja estão todos na distribuição primária. Ferramentas complementares, gerenciadores de pacotes e aplicativos de desktop de sistemas secundários parecem funcionar conforme o esperado.

A página de compatibilidade aponta que algumas ferramentas especializadas como Timeshift para instantâneos Btrfs e SELinux não funcionarão corretamente com Bedrock porque é necessário fazer alguma manipulação incomum para colar várias distribuições.

Com essas limitações em mente, decidi configurar o Voidcomo minha distribuição primária e, em seguida, execute três testes. A primeira era instalar o Arch Linux e tentar adicionar algum software do repositório do usuário do Arch (também conhecido como AUR). A segunda foi instalar o Ubuntu 18.04 e, em seguida, substituí-lo pelo Ubuntu 20.04 para ver como Bedrock faria com a busca de uma nova versão de um sistema operacional e, em seguida, removendo a versão anterior, essencialmente executando uma atualização ao vivo sem reinicializações. Eu também estava curioso para ver se os pacotes Snap funcionariam dentro do Ubuntu rodando em Bedrock quando Void é o sistema operacional principal. Os pacotes Snap requerem o systemd para funcionar, que seria incluído no nível de Bedrock do Ubuntu, mas o Void executa o software runit init que não é compatível com o Snaps. Eu estava interessado em ver os resultados práticos.

Começando

Comecei meu teste realizando uma nova instalação do Void. Eu escolhi a construção glibc da distribuição com o ambiente de desktop Xfce. O Void é uma distribuição relativamente pequena e foi rápida de configurar. Em seguida, baixei o script Bedrock apropriado para minha arquitetura de CPU (x86_64) e executei o que Bedrock chama de comando “hijack” enquanto converte uma distribuição existente na plataforma Bedrock. O comando parecia assim: “sudo sh ./bedrock-linux-0.7.20-x86_64.sh --hijack”.

Bedrock sequestrando a distribuição do Void
Bedrock Linux 0.7.20 - Bedrock sequestrando a distribuição Void
(tamanho total da imagem: 196kB, resolução: 1280x1024 pixels)

O script produz um grande banner com um aviso nos informando que esta é uma ação perigosa e irreversível. Depois de aceitar a responsabilidade pela tentativa de conversão, o script fez algumas verificações iniciais e concluiu sua configuração em menos de cinco segundos. O script termina aconselhando-nos a reiniciar o computador para concluir o processo de configuração do Bedrock.

Deste ponto em diante, quando o sistema inicializasse, ele faria uma pausa e perguntaria qual sistema de inicialização deveria ser executado. No início, eu tinha apenas o runit do Void instalado e era a única opção disponível. Se não fizermos uma seleção, o primeiro será escolhido automaticamente após 30 segundos.

No início, o Vazio parecia o mesmo de sempre. Consegui fazer login, executar programas e, geralmente, nada parecia mudar. No entanto, lembrei-me de que ainda não tinha instalado as atualizações de software e executei o gerenciador de pacotes XBPS para obter as versões mais recentes dos pacotes. Assim que reiniciei o sistema, o Void não conseguiu mais inicializar. O processo de inicialização exibiria uma série de erros do sistema de arquivos, todos relacionados ao Btrfs. Eu tinha configurado o Btrfs como o sistema de arquivos principal do Void com a ideia de possivelmente usar alguns de seus recursos, como expansão de volume e instantâneos posteriormente.

Como não consegui inicializar o sistema, executei uma nova instalação, desta vez configurando Void no sistema de arquivos ext4. Em seguida, usei o script Bedrock para sequestrar o Void novamente. Desta vez, quando usei o XBPS para instalar todas as atualizações em espera, o sistema reiniciou normalmente. Parece que Bedrock e Btrfs têm alguns problemas de compatibilidade além das limitações de instantâneo Timeshift mencionadas anteriormente.

Neste ponto, Bedrock está no sistema, ou dito de outra forma, Bedrock se tornou o sistema operacional subjacente. No entanto, ainda não está fazendo nada por nós. No meu caso, eu ainda estava (para todos os efeitos práticos) apenas executando o Void. Para realmente usar o Bedrock, precisamos buscar novas distribuições (eu os chamo de sistemas operacionais secundários) e colar suas partes no Bedrock. Podemos fazer isso com o " brl fetch"comando. Cada nova distribuição é referida como uma camada ou" estrato “por Bedrock. Podemos ver os estratos disponíveis que Bedrock sabe como instalar executando” brl fetch --list ". Por exemplo, para instalar o Arch Linux em cima de Bedrock, podemos executar “brl fetch arch”.

Executando o gerenciador de pacotes Arch em um sistema baseado em Void
Bedrock Linux 0.7.20 - Executando o gerenciador de pacotes Arch em um sistema baseado em Void
(tamanho completo da imagem: 194kB, resolução: 1280x1024 pixels)

Bedrock baixa e inicializa um conjunto mínimo de pacotes Arch Linux e, a partir desse ponto, podemos executar comandos Arch e usar o gerenciador de pacotes pacman da distribuição . Os comandos Arch, como o pacman , agem como se estivessem instalados junto com as ferramentas Void. Por exemplo, se eu executar “xbps-install”, ele será reconhecido como um comando Void, mas se eu executar “pacman”, ele será automaticamente reconhecido como um comando Arch e usará os arquivos e bibliotecas Arch para fazê-lo funcionar. A experiência é quase totalmente transparente.

Neste ponto, eu era capaz de instalar os pacotes de desenvolvimento do Arch e pegar pacotes de terceiros do Arch User Repository, construí-los, instalá-los e executar esses programas junto com os aplicativos Void.

Uso diário e surpresas

Anteriormente, eu disse que trabalhar com arquivos e aplicativos de vários níveis (ou estratos) é quase transparente. Normalmente, a execução de um aplicativo ou a execução de uma tarefa na linha de comando age como se o Bedrock fosse apenas uma distribuição típica do Linux e puxa os arquivos e programas de que precisa de cada estrato perfeitamente. No entanto, há momentos em que isso não é verdade e pode pegar uma pessoa de surpresa.

Por exemplo, eu tinha o editor de texto vi instalado no Void e o editor de texto nano instalado sob os estratos Arch. Se eu quisesse editar um arquivo de texto em meus documentos pasta, eu poderia executar “nano ~ / Documents / myfile.txt” ou “vi ~ / Documents / myfile.txt”. Bedrock encontraria corretamente o editor de texto adequado, em seus respectivos estratos, e então abriria meu arquivo. Isso funciona maravilhosamente bem. No entanto, há momentos em que cada estrato tem sua própria cópia de um arquivo. Por exemplo, o arquivo / etc / os-release existe nas distribuições Void e Arch. Se eu executasse “nano / etc / os-release”, veria a versão Arch desse arquivo de texto, enquanto se executasse “vi / etc / os-release” veria a versão Void do arquivo. Bedrock me apresentaria a versão do arquivo de texto correspondente aos estratos em que encontrava o programa que eu estava executando.

Isso pode pegar uma pessoa de surpresa se cada distribuição que instalar tiver sua própria cópia, por exemplo,arquivo de configuração. Dependendo de qual ferramenta usamos para visualizar o arquivo de configuração, podemos ver um arquivo totalmente diferente. Para contornar essa situação complicada, o Bedrock nos permite especificar com quais camadas queremos trabalhar. Isso é feito com o comando strat , como em “strat arch cat / etc / os-release” ou “strat void cat / etc / os-release”. Ambos os comandos exibirão o conteúdo do arquivo de lançamento nas camadas nomeadas.

Visualização de arquivos com o mesmo nome em diferentes estratos
Bedrock Linux 0.7.20 - Visualização de arquivos com o mesmo nome em diferentes estratos
(tamanho total da imagem: 149kB, resolução: 1280x1024 pixels)

Você deve estar se perguntando, como eu, se há uma maneira de determinar quais partes do sistema de arquivos são duplicadas entre camadas e quais, como nosso diretório inicial, são exclusivas e, portanto, não são afetadas pelo uso de aplicativos de distribuições diferentes. Parece que executar o comando mount e verificar os sistemas de arquivos nos mostrará se uma região está duplicada entre os estratos, exigindo que usemos o comando strat para especificar qual camada queremos usar. Por exemplo, a execução de “mount | grep / tmp” mostra que vários diretórios / tmp estão em uso. Da mesma forma, “mount | grep / etc” mostra mais de um / etc diretório. No entanto, quando executei “mount | grep / home / jesse”, não havia entradas que parecessem indicar que meu diretório inicial é único em todas as camadas.

Os aplicativos que instalei em minha distribuição primária (Void) apareceriam no menu de aplicativos, embora os programas instalados em níveis secundários (Arch e Ubuntu em meu experimento) não. Eu poderia contornar isso criando manualmente um atalho no menu do aplicativo ou copiando o inicializador que eu queria dos estratos da distribuição secundária. Por exemplo, eu poderia copiar lançadores dos estratos do Ubuntu executando “cp /bedrock/strata/ubuntu/usr/share/applications/gimp.desktop ~ / .local / share / applications /”.

Adicionando mais camadas

Anteriormente, mencionei que podemos ver quais distribuições podem ser instaladas no Bedrock como camadas adicionais executando “brl fetch --list”. No entanto, se quisermos obter uma versão específica de uma distribuição, a sintaxe muda ligeiramente. Por exemplo, para ver todas as versões disponíveis do Ubuntu, podemos executar “brl fetch ubuntu --releases”. Isso listará a versão da distribuição usando números ou, no caso do Ubuntu, com nomes de código. Podemos então pegar uma versão anterior do Ubuntu usando um comando como “brl fetch -r bionic ubuntu” ou “brl fetch -r focal ubuntu”. Em situações em que desejamos instalar várias versões da mesma distribuição, precisamos criar um nome personalizado para os estratos (algo diferente de apenas “Fedora” ou “Ubuntu”). Podemos fazer isso especificando o sinalizador “-n”, por exemplo: “brl fetch -n myfocal -r focal ubuntu”. Isso resulta na nova versão do Ubuntu sendo chamada de “myfocal” em vez do rótulo mais genérico “ubuntu”.

Executando o GIMP a partir dos estratos Ubuntu Bionic
Bedrock Linux 0.7.20 - Executando o GIMP a partir do Ubuntu Bionic strata
(tamanho total da imagem: 337kB, resolução: 1280x1024 pixels)

Tentei instalar os pacotes Snap nos estratos do Ubuntu. O primeiro problema que encontrei foi que o software Snap não estava instalado na camada mínima do Ubuntu. Eu instalei o snap e o snapd . O cliente snap seria executado, mas não consegui fazer com que o serviço snapd fosse executado. O comando service start salvaria o relatório de que não foi capaz de ser executado em um ambiente chroot. Consegui, no entanto, instalar a estrutura Flatpak, habilitar o repositório Flathub e executar jogos empacotados com o formato Flatpak.

Executando um pacote Flatpak
Bedrock Linux 0.7.20 - Executando um pacote Flatpak
(tamanho de imagem completo: 148kB, resolução: 1280x1024 pixels)

Por falar em trabalhar com pacotes de software, é possível instalar o mesmo programa em múltiplos estratos. Isso é especialmente útil se quisermos experimentar várias versões do mesmo aplicativo. Em um ponto eu instalei o GNU Image Manipulation Program (GIMP) 2.8 no Ubuntu Bionic e GIMP 2.10 no Ubuntu Focal. Eu poderia então lançar qualquer uma das versões especificando os estratos que contêm a versão do GIMP que eu queria. Na linha de comando, parecia “strat bionic gimp” e “strat focal gimp”. Os estratos compartilham um espaço de processo e o GIMP permitiria apenas que uma versão de si mesmo rodasse ao mesmo tempo.

Assim que terminarmos a distribuição, podemos removê-la com o comando “brl remove”. Isso limpa a camada de distribuição e seus programas do sistema.

Colar várias distribuições juntas e usá-las quase perfeitamente parece complexidade o suficiente para mim e eu realmente gosto de como a Bedrock lida bem com a fusão de distribuições. Para as pessoas que desejam ainda mais potência, existem alguns conceitos adicionais interessantes que a Bedrock oferece. Por exemplo, podemos fazer uma cópia de um estrato. Isso significa que podemos, por exemplo, fazer um backup de uma distribuição existente, fazer uma atualização nela e, se algo der errado, podemos simplesmente excluir a camada atualizada e voltar a usar a cópia de backup. Em outras palavras, podemos fazer imagens quase reais de nosso sistema operacional antes de realizar operações arriscadas.

Conclusões

Bedrock é um dos projetos mais intrigantes que tive o prazer de usar recentemente. Ele não apenas fornece uma caixa de ferramentas incrível para fazer as distribuições funcionarem juntas sem a necessidade de máquinas virtuais ou Docker, mas também rapidamente e com o mínimo de conhecimento exigido pelo usuário. Resumindo, temos uma maneira muito fácil de executar várias distribuições como se fossem um sistema operacional quase sem sobrecarga extra em termos de uso de CPU ou memória. Nós usamos um pouco de espaço em disco extra, mas rodar Void, duas versões do Ubuntu e uma cópia do Arch consumiu apenas cerca de 7 GB de espaço em disco - aproximadamente a mesma quantidade de consumo de disco que algumas grandes distribuições convencionais usam.

Também gosto de como Bedrock basicamente reverte a fragmentação da distribuição. Se você está cansado de precisar executar distribuições diferentes para obter acesso a um programa ou gerenciador de pacotes específico, pode executar o Bedrock e obter acesso a quase tudo e usá-lo perfeitamente como um sistema operacional. É realmente um trabalho de engenharia notável e, quando me acostumei a ver como os diferentes estratos se encaixam, não encontrei praticamente nenhum problema com isso. Havia a desvantagem de não poder usar SELinux ou Btrfs com Bedrock, mas os recursos de cópia de estratos de Bedrock fornecem uma espécie de instantâneo e há outros controles de acesso que as pessoas podem usar no lugar do SELinux. No geral, estou muito feliz com Bedrock.
───────────────────
https://distrowatch.com/weekly.php?issue=20210705#bedrock
───────────────────
EDIT - Esclarecimentos técnicos:
───────────────────

ParadigmComplex

·3h · fundador e desenvolvedor líder

Embora a ideia central do artigo seja boa, muitos detalhes estão claramente confusos; Eu gostaria de abordar aqueles abaixo.

Estou prolixo abaixo para minimizar a possibilidade de um mal-entendido sobre alguns detalhes diferenciados, em vez de parecer aborrecido ou punitivo.

Com o Bedrock, podemos instalar uma distribuição, que podemos considerar nosso sistema operacional principal ou primário. Então, sem usar uma máquina virtual, Bedrock nos permite instalar uma segunda distribuição e colar efetivamente as partes da segunda distribuição que queremos.

Com a Bedrock, você pode escolher quais partes vêm de quais distros. Se você deseja obter a maior parte de suas peças de uma distro que você pessoalmente modela mentalmente como sua “principal”, isso é útil; no entanto, é um pouco autolimitado e nada precisa disso. Outra opção válida é misturar e combinar com granularidade suficiente para que não haja uma distro que seja obviamente a distro “primária”. Para um exemplo concreto e prontamente disponível, estou digitando esta mensagem em uma firefox janela Arch que é uma janela gerenciada pelo Gentoo dwm rodando no Xorg do Debian em um sistema que foi instalado com o instalador do Fedora. Eu estava executando o kernel do Debian até recentemente, quando comecei a brincar com o novoio_uring funcionalidade, para a qual tenho usado recentemente o kernel mais recente do Arch. Claramente, nenhuma distro tradicional poderia apontar como a distro primária em meu sistema.

Bedrock é comercializado como uma (meta) distro ao invés de um utilitário, em grande parte porque pensar em Bedrock como a parte essencial / definidora do sistema, ao invés de um de seus estratos acidentais / trocáveis ​​/ descartáveis, é um modelo mais representativo do que é realmente tecnicamente indo. Bem, isso e porque é a resposta mais fácil para a questão de qual distro um usuário do Bedrock que está aproveitando ao máximo o Bedrock está executando.

Por exemplo, normalmente é uma boa ideia usar o software init e os ambientes de desktop de sua primeira distribuição (primária). Em outras palavras, você pode ter problemas se instalar o MX Linux com SysV init e Xfce, mas depois decidir que deseja usar o desktop Cinnamon e o systemd de uma instalação secundária do Linux Mint. Tente se certificar de que o init, o gerenciador de serviços e os ambientes de desktop que você deseja estão todos na distribuição primária.

Este não é o caso. Após a conclusão do processo de sequestro, a Bedrock não tem nenhum motivo para se preocupar com qual distro você escolheu para fornecer o instalador. Na verdade, eu fiz brl remove o fedora stratum hijack-time criado no sistema que estou usando para digitar esta mensagem; Faz muito tempo que não recebo o que Jesse está chamando de distribuição “primária”.

O que eu acho que está se referindo aqui é o fato de que Bedrock não pode (atualmente) fazer coisas sensíveis a inits e init como ambientes de desktop de diferentes estratos simplesmente funcionarem. Quando você instala um ambiente de área de trabalho com a maioria dos gerenciadores de pacotes de distro, ele cria uma configuração que diz ao init para iniciar as dependências de tempo de execução desse ambiente de área de trabalho. Bedrock não pode (atualmente) fazer esta configuração funcionar apenas através dos limites do estrato, então se você inicializar com um init de um estrato diferente, o init não sabe que precisa iniciar as dependências do ambiente de desktop. Como resultado, o ambiente de trabalho pode não funcionar direito.

Freqüentemente, é possível fazê-los funcionar criando manualmente os arquivos de configuração init compatíveis com o Bedrock que dizem ao init desejado para iniciar os serviços do ambiente de desktop, mas nem sempre é possível, e mesmo quando é, pode ser difícil para alguns usuários. A solução mais fácil é apenas obter o ambiente de inicialização e desktop do mesmo estrato. Observe que isso não precisa ser o estrato de sequestro; pode ser qualquer um, basta que ambos sejam do mesmo.

Eu também estava curioso para ver se os pacotes Snap funcionariam dentro do Ubuntu rodando em Bedrock quando Void é o sistema operacional principal. Os pacotes Snap requerem o systemd para funcionar, que seria incluído no nível de Bedrock do Ubuntu, mas o Void executa o software runit init que não é compatível com o Snaps. Eu estava interessado em ver os resultados práticos.

Esperançosamente, depois de ler o que escrevi acima, pelo menos uma razão pela qual isso não vai funcionar está agora clara. Infelizmente, existem outros também, e é improvável que snapd-off-systemd seja algo que Bedrock abordará em um futuro previsível.

No entanto, lembrei-me de que ainda não tinha instalado as atualizações de software e executei o gerenciador de pacotes XBPS para obter as versões mais recentes dos pacotes. Assim que reiniciei o sistema, o Void não conseguiu mais inicializar. O processo de inicialização exibiria uma série de erros do sistema de arquivos, todos relacionados ao Btrfs. […] Parece que Bedrock e Btrfs têm alguns problemas de compatibilidade além das limitações de instantâneo Timeshift mencionadas acima.

Ninguém mais relatou esse problema, mas não é impossível que o uso do btrfs seja um nicho o suficiente na comunidade de Bedrock, que simplesmente não apareceu. Vou ver se consigo reproduzi-lo e, em caso afirmativo, pelo menos documentar, se não detectá-lo, no momento do sequestro e abortar ou corrigir o problema subjacente.

Se eu executasse “nano / etc / os-release”, veria a versão Arch desse arquivo de texto, enquanto se executasse “vi / etc / os-release” veria a versão Void do arquivo. Bedrock me apresentaria a versão do arquivo de texto correspondente aos estratos em que encontrava o programa que eu estava executando.

Isso pode surpreender uma pessoa se cada distribuição instalada tiver sua própria cópia, por exemplo, do arquivo de configuração sudo. Dependendo de qual ferramenta usamos para visualizar o arquivo de configuração, podemos ver um arquivo totalmente diferente. Para contornar essa situação complicada, o Bedrock nos permite especificar com quais camadas queremos trabalhar. Isso é feito com o comando strat, como em “strat arch cat / etc / os-release” ou “strat void cat / etc / os-release”.

Este /etc/os-release exemplo exato é usado na documentação introdutória do Bedrock, que em vez disso recomenda o uso /bedrock/strata/<stratum>/etc/os-release .

Posso entender que pessoas vindo de algo como contêineres pensem que precisam “entrar” no ambiente do contêiner para ver um determinado arquivo, caso em que o uso de strat aqui é equivalente a docker run [...] cat /etc/os-release ou chroot [...] cat /etc/os-release . No entanto, não é assim que a abstração de Bedrock pretende funcionar, já que a visão de mundo de Bedrock é baseada em tornar recursos acessíveis ao invés de conter coisas; estes são, em certo sentido, opostos.

Devido a uma peculiaridade de implementação, não podemos usar a mesma técnica para ler / gravar em um arquivo que usamos para executá-lo. Para ler / gravar em um arquivo local do estrato específico , use /bedrock/strata/<stratum>/<local-path> . Para executar o arquivo local de um stratum específico , use strat . Usar strat para especificar qual programa do estrato executar para obter um arquivo local como efeito colateral é, pensando bem, um pouco indireto.

Você pode estar se perguntando, como eu, se há uma maneira de determinar quais partes do sistema de arquivos são duplicadas entre camadas e quais, como nosso diretório inicial, são exclusivas e, portanto, não são afetadas pelo uso de aplicativos de distribuições diferentes.

O conceito que Jesse está descrevendo é referido como caminhos locais e globais em termos de Bedrock. Tudo é considerado local por padrão, e a lista de exceções que são caminhos globais é configurada em /bedrock/etc/bedrock.conf . Pode-se consultar um determinado caminho com brl which .

Parece que executar o comando mount e verificar os sistemas de arquivos nos mostrará se uma região está duplicada entre os estratos, exigindo que usemos o comando strat para especificar qual camada queremos usar. Por exemplo, a execução de “mount | grep / tmp” mostra que vários diretórios / tmp estão em uso. Da mesma forma, “mount | grep / etc” mostra mais de um diretório / etc. No entanto, quando executei “mount | grep / home / jesse”, não havia entradas que parecessem indicar que meu diretório inicial é único em todas as camadas.

Os detalhes de implementação ficam complicados aqui, e não há nenhum truque em particular que você possa usar (além de apenas consultar a configuração de Bedrock / Bedrock). Por exemplo: Note que /etc/os-release é local, e /etc/passwd é mundial , mas ambos estão claramente no mesmo ponto de montagem.

Os aplicativos que instalei em minha distribuição primária (Void) apareceriam no menu de aplicativos, embora os programas instalados em níveis secundários (Arch e Ubuntu em meu experimento) não. Eu poderia contornar isso criando manualmente um atalho no menu do aplicativo ou copiando o inicializador que eu queria dos estratos da distribuição secundária. Por exemplo, eu poderia copiar lançadores dos estratos do Ubuntu executando “cp /bedrock/strata/ubuntu/usr/share/applications/gimp.desktop ~ / .local / share / applications /”.

Bedrock faz a maior parte do trabalho necessário para fazer com que os aplicativos cross-stratum apareçam nos menus do aplicativo, impedindo a última etapa de notificar o menu do aplicativo de que ele precisa atualizar seu cache. Se você acionar manualmente uma atualização, ela deve funcionar.

O gimp.desktop arquivo que Jesse copiou funciona parcialmente por uma questão de sorte que sua Exec= linha não usa o caminho para o binário, mas sim pesquisa o $PATH . Se ele tivesse selecionado um exemplo que usa o caminho, ele teria que editá-lo manualmente para incluir strat <stratum> . Se você observar, /bedrock/cross/applications/gimp.desktop verá que o Bedrock já gera versões desses arquivos com os strat injetados apropriadamente para serem usados ​​pelo menu do seu aplicativo. Se você olhar para o /proc/<pid>/environ de seu software de menu de aplicativo, encontrará XDG_DATA_DIRS= apontando para /bedrock/cross para ensinar seu menu de aplicativo a também olhar para este local. Assim que o menu do aplicativo receber a dica de que precisa atualizar seu cache, as entradas do menu do aplicativo cross-stratum devem funcionar.
───────────────────

───────────────────

4 curtidas