O que está acontecendo com o Fedora?

#1

Eu li e ouvi que o Fedora ta ficando diferente, esta removendo o Yum e tem uns tal de ostree e uns bagulho loko que eu nao entendi nada. Alguém pode me explicar porque eu **não to a par do assunto?

0 Likes

#2

Não é só o fedora que está investindo nesse tipo de tecnologia, EndlessOS já usa ostree a tempos, opensuse está investindo no Kubic, ClearLinux no swupd, Canonical no snap…
Basicamente é transformar o “core” do sistema imutável, focando em aplicações via contêiner(flatpak,snap’s…)
Fazendo assim upgrades mais seguros entre vários outros benefícios…

Se quizer ver mais coisas sobre veja as documentações oficiais das distros e eu ultimamente to falando sobre isso tbm…


3 Likes

#3

quem tiver mais fontes de informações que acham interessante sobre essas tecnologias pode me mandar…

2 Likes

#4

O que é?

O OSTree é um sistema versionamento para arquivos baseado no GIT, esse por sua vez é um sistema de versionamento e distribuição de código (curiosidade: foi criado pelo Linus Torvalds o mesmo do Linux) ele é desenvolvido pelo projeto GNOME, ele tem mais problemas que vantagens (até porque vantagem ele só tem uma que é o sistema ser readonly mas enfim)

O OSTree por si só é meio inútil, então algumas ferramentas são usadas em cima dele uma delas é o Flatpak que nada mais é que a Junção do OSTree com um software que permitem criar conteiners de aplicativos o BubbleWrap

Por que usam?

O OSTree tem algumas caracteristicas interessantes:

  • Sistema somente leitura. A única forma de quebrar o sistema é se ele vier quebrado by design

  • Você pode ter várias versões do sistema em paralelo

  • Como o Bubblewrap consegue isolar aplicações do sistema você consegue passar uma imagem de segurança (sim, passar uma imagem porque como o acesso à home é liberado seus arquivos ainda correm riscos sérios inclusive de ataques de ransonware)

  • Atualizações atômicas

Para entender o conceito de atualizações atômicas imagine que cada arquivo é um átomo é que a cada atualização você baixa apenas os átomos diferentes economizando banda

Então isso é uma ótima ideia certo?

Na verdade não, apesar da boa intenção o OSTree tá cheio de problemas e é uma tecnologia que já nasceu ultrapassada. Exemplo do que eu estou falando:

  • O OSTree não consegue usar recursos do sistema hospedeiro, ou seja você precisa ter instalado no sistema e no OSTree duplicando bibliotecas e binários

  • Por ser baseado em GIT ele herda uma das características que pra texto é ótimo mas é péssimo para binários o cache, isto é informações armazenadas localmente para não precisar baixar arquivos inalterados

  • O OSTree não só não consegue compartilhar recurso do sistema como não consegue compartilhar recursos entre versões, no caso do Libre Office que pesa 600 MB se você atualizar você vai ter outra pasta com mais 600 MB tendo ao todo 1,2 GB

  • Como eu disse o Bubblewrap passa uma falsa ideia de segurança, no futuro isso vai ser um problema

  • As atualizações atômicas já são coisa do passado a muito tempo, o zsync (que baixa os pedaços diferentes dos átomos) já era uma solução melhor para esse problema

  • Sistema somente leitura não só existe faz tempo (pra se ter uma ideia a primeira versão do knnopix já trazia isso) como existem mecanismo não apenas superior como mais rápidos e fáceis de armazenar/implementar

Resumidamente os desenvolvedores do Fedora e Endless (que são frutos do projeto GNOME) estão usando apenas pra não dar o braço a torcer

4 Likes

#5

O OSTree não só não consegue compartilhar recurso do sistema como não consegue compartilhar recursos entre versões, no caso do Libre Office que pesa 600 MB se você atualizar você vai ter outra pasta com mais 600 MB tendo ao todo 1,2 GB

Eu percebi algo assim quando eu baixei o Gnome Weather em Flatpak, ele baixou quase que o Gnome todo de novo…

E obrigado aos dois pelas respostas, aprendi muita coisa :wink:

0 Likes

#6

tem fonte dessas informações?

0 Likes

#7

Documentação das tecnologias citadas:

  • Git
  • OSTree
  • BubbleWrap
  • Zsync
  • Knnopix
  • Flatpak

Eu nem tô sendo hater quando eu falo que o Flatpak é problemático e usa tecnologias para um propósito para o qual não foram projetadas, depois de muitos desenvolvedores constatarem os problemas os próprios criadores do Flatpak adicionaram uma maior transparência obviamente sem dar o braço a torcer no tocante ao segundo contra “Git for apps” veja a pasta /var/lib/flatpak/repo para ter uma visão mais “prática” (obs: pra se ter uma noção maior do problema É interessante ter um conhecimento avançado sobre as estruturas do GIT)

Sobre

Por padrão TODOS os Flatpak vem com a “flag” (isso é verificável através do launcher .desktop e na nova versão da Gnome Software) --filesystem=home e a --share=network ativas e marcadas como “required” isso até que faz sentido uma vez que um aplicativo sem acesso ao arquivos e muitos sem a internet são essencialmente inúteis (como Gimp e Chromium por exemplo) o problema é que isso simplesmente inutiliza boa parte da função de um sanboxing já que permite acesso aos arquivos do usuário e a internet (como explicado aqui) permitindo um ataque fácil de ransonware uma vez que o usuário acredita estar em um sandboxing real

As outras são perceptíveis a “olho nu” como:

Basta olhar nas pastas /var/lib/flatpak/apps e /var/lib/flatpak/runtimes especialmente se tiver diferentes versões do mesmo aplicativo ou runtime

E

O mecanismo mais usado e eficiente atualmente é o SquashFS que permite compactação e leitura rápida usadas para instalação das distros, modo live, Snaps, AppImages e uma variedade enorme de projetos e áreas através do loop e do FUSE

A própria Canonical usa com as ISOs do Ubuntu alias uma curiosidade uma vez que você tenha uma ISO do Ubuntu você não precisa baixar os 2GB de uma mesma versão quando se tem uma atualização, por exemplo se você testa as daily builds da Disco Dingo basta executar esse comando na pasta da ISO:

zsync http://cdimage.ubuntu.com/daily-live/current/disco-desktop-amd64.iso.zsync

E você baixa apenas as posições dos eletrons no HD ao invés do átomo inteiro e o melhor: sem manter cache nem histórico de versões economizando espaço

Isso é meio óbvio que acontece, apesar de que na minha opinião seria mais interessante eles mostrarem que são humanos e fazem más escolhas como todo mundo do que insistir no erro

3 Likes

#8

Obrigado pelos seus comentários, foi uma leitura interessante. A meu ver são boas razões para evitar o OSTree e os Flatpaks, nunca fui fã de nenhuma dessas tecnologias e pessoalmente não as utilizo.

0 Likes

#9

O que você acha do Appimage?

0 Likes

#10

O que é?

O AppImage nada mais é que o executável com suas dependências (exceto essas) inclusas em um arquivo arquivos SquashFS autoexecutável através do FUSE sendo assim o AppImage tem vários pontos positivos:

  • Consegue econimizar espaço
  • Consegue ser rápido
  • Tem integração real com com o tema do sistema (coisa que o Flatpak e Snap NÃO possuem, eles apenas simulam a integração)
  • Pode ser usado com diversos sandboxing de forma real sem as brechas do Flatpak
  • São portáveis
  • Suporte ao Zsync
  • Não duplica a maioria das bibliotecasno espaço em disco
  • Não duplica bibliotecas na memória (RAM e SWAP)
  • Não tem dados residuais como cache nem histórico de versões no computador do usuário

Mas nem tudo são flores…

O AppImage apesar de ser em termos tecnicos muito superior ao Flatpak ele traz algumas limitações também, que apesar de poder ser facilmente corrigidaso Simon Peter criador não quer de forma oficial:

  • O AppImage por si só é apenas uma forma de empacotamento assim não possui mecanismos nativos para a criação de repositórios, isso poderia ser facilmente resolvido através de gerenciadores já existentes inclusive como o APT ou mecanismo próprios como o projeto Nitrux faz de forma brilhante, o AppImage até tem uma hub mas é apenas uma Hub ou seja ela apenas lista a ultima versão mas não faz a integração nem atualização automática mesmo que nesse caso existam mecanismos como o AppImageD que faz a integração a partir da pasta ~/Download e o AppImageUpdate que realiza a atualização através do Hub mas não é tão intuitivo quanto o próprio AppImage pelo menos se levar em conta que só no Debian SID e no AUR existem pacotes nativos e em Alpha

  • Dependência do FUSE que apesar de ser excelente uma vez que permite o usuário executar o aplicativo e integrar com o sistema sem ter acesso root e economizar até quase 3/4 do tamanho original como no caso do Inkscape, caso o sistema não tenha ele apesar de existir a opção de extração ela precisa ser feita manualmente o que pode ser um problema em casos mais isolados como WSL

Conclusão…

Apesar de ser claramente superior em termos técnicos (uma comparação mais detalhada pode ser vista aqui) que Flatpaks e Snaps alguns pontos poderiam ser melhorados e de forma simples até porém deve ser implementados por terceiros já que se implementado no “core” do projeto tiraria a essência do projeto que é a independência

2 Likes

#11

acho que tu tinha que avisar as empresas endless/redhat que atualmente investem nessas tecnologias (não que eu ache que por serem empresas bem sucedidas não podem errar ) que é um baita erro!

1 Like

#12

@Natanael.755, você colocou várias informações erradas na sua resposta. Vou tentar clarificar os pontos errados, vamos lá.

O Bubblewrap não faz parte do OSTree. Não sei se o que você está sugerindo aqui é que o próprio Bubblewrap dá acesso a home; se for, então está errado, porque o Bubblewrap não libera nada por padrão. São os manifestos Flatpak que definem se vão ter acesso a home.

Essa analogia está errada. Isso que você está falando são atualizações diferenciais (que o OSTree suporta). Atualizações atômicas são atualizações que ou acontecem com sucesso, ou não acontecem – nunca ficam num estado quebrado. É um conceito que vem do mundo dos bancos de dados.

O OSTree é, também, um gerenciador de sistemas operacionais. Tudo que está no OSTree é deduplicado. Se você usa um sistema gerenciado por OSTree (Endless OS, Fedora Silverblue, etc), não existem arquivos duplicados.

O OSTree não é baseado em Git. OSTree tem conceitos parecidos, mas não é baseado em Git.

Isso está totalmente errado :frowning: OSTree usa bsdiff para calcular a diferença entre arquivos binários. Inclusive consegue calcular a diferença dos cabeçalhos de arquivos ELF. É bem eficiente.

Isso também está completamente errado. OSTree tem deduplicação de conteúdo. O Flatpak implementa versionamento dos aplicativos via ramos, e o OSTree deduplica todo conteúdo igual entre todo e qualquer ramo do repositório. Todos os aplicativos Flatpak compartilham arquivos iguais entre si. Em repositórios OSTree, não existem 2 arquivos iguais em locais diferentes.

No Endless OS, o sistema vai ainda mais longe e aponta o repositório do Flatpak para o próprio root do OSTree. Ou seja, aplicativos Flatpak e o sistema operacional tem todos os arquivos deduplicados, com versionamento, atualização diferencial e atômica, e tudo que tem de bom no mundo.

Não dá para comparar zsync e OSTree. Resolvem problemas diferentes. O zsync não lida, por exemplo, com bootloaders, assinaturas GPG dos commits, etc.

Não entendo o que você quis dizer aqui… o Flatpak usa bindfs, que é um sistema de arquivo virtual FUSE, ou seja, usa tecnologias do próprio kernel para configurar o sandbox. Recentemente, passou a usar também o revokefspara resolver uma outra série de problemas.

Sandboxing e sistemas de arquivo somente-leitura são completamente diferentes. Sandboxing exige escrita de partes específicas do disco. O KNOPPIX usa um sistema de arquivos diferente (iso9660), de CD-ROMs, que não permitem escrita de nada.

Uma coisa não tem a ver com a outra.

Estão usando porque é uma tecnologia que resolve muito bem os problemas que se propõe a resolver. Só isso.

Isso está errado. Menos da metade dos aplicativos que estão no Flathub, por exemplo, tem acesso a home. Essas permissões não são obrigatórias. Não dá para verificar isso via arquivos .desktop, mas sim via $ flatpak info --show-metadata <app-id>.

Você tem que ter em mente que sandboxing é um conceito novo no desktop. Ninguém se preocupou com isso pelos últimos 25 anos. Os aplicativos não estão preparados para isso ainda. Negar qualquer acesso sem ser via portais vai quebrar a maior parte dos aplicativos. E ninguém quer usar aplicativos que não funcionam.

Estranho você falar isso, sabendo que os Snaps usam loopmount para montar os Snaps. Você tem dados sobre o desempenho do squashfs em comparação com bindmounts? Minha impressão é que, como bindmounts são áreas virtuais de memória implementadas diretamente pelo kernel, e não precisam passar pelo subsistema de arquivos, vai ter uma pequena vantagem. Mas sem dados comparativos, falar que um ou outro é mais rápido é pura especulação.

Seria melhor ainda se você fizesse mais pesquisa antes de espalhar informações erradas :frowning:

5 Likes

#13

Vamos lá, pra começar percebi que você curte usar a falácia do espantalho, porque já no começo você responde com:

E de fato, minha critica foi exatamente à possibilidade dos manifestos do Flatpak permitirem isso, em momento algum eu disse que o BubbleWrap é parte do OSTree, eu disse que ele assim como o OSTree é parte integrante do Flatpak, até onde li e não foi pouco vi que não existe um mecanismo de desassociar o BW do Flatpak, se tiver por favor apresente, tenho certeza que é do interesse de muita gente


Verdade, reconheço meu erro nesse ponto


Esse é Exatamente um dos problemas o OSTree só consegue compartilhar recursos com ele mesmo ou seja, eu precisaria que o sistema estivesse disponível em OSTree para não ocorrer, a duplicação de arquivos, não entendi muito bem porque isso seria um contraponto ao meu argumento, além de que de fato fato o Flatpak não consegue compartilhar recursos do sistema hospedeiro (posso estar errado mas se o sistema é construído sobre OSTree ele não é hospedeiro do OSTree mas o próprio OSTree


Apesar de parecer mas um uso da Falácia do Espantalho vou levar como falha na interpretação de texto não disse no sentido de ser baseado no código fonte, mas exatamente no modo de funcionamento (vide artigo citado)


Tá mas isso é basicamente uma explanação do que eu disse (de como o OSTree adapta esse recurso para binários),no meu ponto de vista isso é péssimo para binários, se ficasse no lado servidor eu concordaria com você, mas qual a vantagem de se ter no lado cliente? O zsync parece muito mais eficiente nesse ponto


Isso é coisa de versões mais atuais? Porque na 1.0.7 isso acontece, apesar de nos repositórios de fato isso não acontecer na /var/lib/flatpak/ tem vários arquivos duplicados e tem o problema do Endless OS ser inviável para muita gente então volta ao ponto mais acima


Não entendi muito bem seu ponto, como eu disse o zsync faz o download diferencial e faz a verificação de hash, no entanto feita as devidas implementações é possível fazer verificação de asinatura GPG, Atualizações de sistemas inteiros, etc... e de forma mais prática (AO MEU VER)

Nunca disse que sandboxing e readonly era a mesma coisa na verdade nem tirando do contexto o que eu disse dá pra tirar essa conclusão, além do mais eu disse que existe desde a primeira versão do Knnopix existe não que continuou a mesma coisa, hoje é possível habilitar leitura e escrita em imagens em certos pontos através do mesmo mecanismo usado pelo Flatpak por exemplo (embora não seja limitado a ele)

Não resolve muito bem, resolve e só, em alguns casos como o Endless OS limita bastante o sistema


De fato eu errei aqui o jeito correto de verificar é via flatpak info --show-metadata <app-id>

E sobre isso:

O Android conseguiu isso de uma maneira genial, quando você instalava um app ele listava o que precisava e SE o usuário quisessem poderia liberar ou negar, no desktop (eu posso estar falando besteira) mas bastando mudar as variáveis HOME e XDG_CONFIG_HOME (com outras medidas obviamente) já resolveria parte do problema


Cara você usando novamente a falácia do espantalho, eu disse claramente:

Onde eu disse que era mais rápido? Como você diz aqui:

Eu disse claramente que era mais eficiente no que EU priorizo de fato é mais eficiente já que permite ter arquivos menores e uma leitura rápida sem perda considerável de desempenho e no caso dos AppImage tem o download via zsync fica ainda mais interessante



Sobre isso algumas considerações

Concordo com você tanto é que nessa resposta eu reconheci meus 2 erros, no entanto você por outro lado simplesmente usou da Falácia do Espantalho em diversos pontos, isso não seria pior?

1 Like

#14

Tudo bem, então me ajuda a entender onde você quer chegar.

Você está sugerindo que o Flatpak deveria proibir todo o acesso a home? Se for, a maioria absoluta dos aplicativos deixaria de funcionar imediatamente.

Outra possibilidade é: você está sugerindo que o Flatpak deveria alertar o usuário sobre o acesso a home? Se for, então isso já existe. O Flatpak (e o GNOME Software) mostram quais permissões um aplicativo precisa, e colocam sinais de alerta nas permissões mais importantes.

Se não for nenhuma das duas, favor esclarecer.

Não existe, e não tem motivo para existir.

Não tem como interpretar “Por ser baseado em GIT ele herda uma das características que pra texto é ótimo mas é péssimo para binários” de outra forma além de “OSTree é baseado em Git”. Sua frase não foi ambígua.

Tá tudo errado de novo :frowning:

Primeiro: não é uma explanação do que você disse. OSTree não faz diffs de texto.

Segundo: não é uma questão de opinião. Diffs binários são o que são.

Terceiro: bsdiff é uma implementação, e o rsync (algoritmo que o zsync usa) é outra, de algoritmos de diff binário. E ao que tudo indica, bsdiff consegue gerar diffs um pouco menores comparado ao rsync em média (fonte).

Quarto: OSTree faz o diff(commit-1, commit) no lado do servidor. O lado cliente só baixa via HTTP os aquivos dos diffs.

Quinto: é exatamente assim que o zsync functiona (exceto o fato de que usa FTP ao invés de HTTP).

A ideia do Endless OS é limitar mesmo. Sistemas somente-leitura com aplicativos sandboxed colocam uma série de limitações, e trazem uma série de benefícios. Limitar um sistema não é algo ruim por si só.

De novo, não estou entendendo onde você quer chegar.

Engraçado você citar o Android, que é um sistema somente-leitura com aplicativos sandboxed, como um exemplo de “genial”.

Além disso, os apps do Android foram criados com o sandbox em mente. E usam portais para pedir permissões e usar recursos do sistema. Exatamente como Flatpaks e Snaps funcionam (exceto, claro, que os aplicativos para Linux não estão preparados para se comunicar com portais).

Por último, acho que você realmente está falando besteira. Mudar HOME ou XDG_CONFIG_HOME resolveria qual problema? Se a resposta for “sandbox”, está totalmente fora de cogitação. É uma ideia pior que péssima. Variáveis de ambiente são literalmente o pior jeito de resolver qualquer problema de execução. E as syscals? E os sockets para comunicação inter-processos? E o system bus? Como filtrar as chamadas do session bus?

Você deixou um coringa ali (“com outras medidas obviamente”), mas não consigo imaginar que outras medidas poderiam ser essas.

Não, isso acontece desde o primeiro dia.

zsync não tem absolutamente nada a ver com gerenciamento de sistemas operacionais. zsync faz atualização diferencial e verificação de hash, sim. Mas isso não é gerenciamento de sistemas operacionais.

(Ênfase minha)

Então, não. Se você acha que é só “fazer as devidas implementações”, isso só evidencia que você talvez não tenha noção da magnitude e complexidade de implementar isso.

Primeiro que você já consegue usar chaves GPG com zsync, se você usar SSH para se conectar com o servidor que quiser.

Além disso, mesmo que alguém implemente GPG dentro do zsync, isso ainda não o torna um gerenciador de sistemas operacionais. Rollback de atualizações? Hotfixes? 3-Way Merge dos arquivos de configurações? Bootloader? zsync não faz nada disso, e até onde eu saiba, não tem nenhum plano para ter.

De novo: OSTree não tem nada a ver com zsync. Resolvem dois problemas diferentes.

Realmente, você disse isso mesmo.

E aqui eu faço um adendo: AppImage usa zsync, mas não tem as mesmas funcionalidades que o Flatpak. Por exemplo, não dá pra fazer downgrade dos aplicativos.

0 Likes

#15

Exatamente isso, mas não da forma como está implementada, ao instalar o aplicativo avisar o que o Aplicativo pode fazer como uma “tela de welcome” mais ou menos como ocorre com os APKs

Até tem, a pessoa poderia querer usar outra sandbox a exemplo.

Tem sim, não disse que é um fork do GIT, alias se foi isso que você entendeu, não foi o que eu quis dizer

Erradíssimo, a começar que FTP não tem suporte a download diferencial,o Zsync leva vantagem por não ter dependência nenhuma além do zsync pra baixar

Claro que é, lê de novo a minha mensagem, e a questão é não é que diffs binários são ruins para binários pelo contrário, mas que a distribuição de binários da forma que o OSTree faz é ruim, o zsync (só um detalhe rsync praticamente está pro zsync assim como o OSTree está pro GIT) faz uma vez e você faz upload de um arquivo e baixa apenas partes de um arquivo intacto, (ah outro detalhe toda essa discussão estś no contexto da utilização do OSTree para a distribuição de aplicativos) e creio eu que isso enquadra como ponto de vista

Exatamente e os armazena localmente, ou tem algum bug comigo?

Foi o que eu disse desde o começo

O Android embora seja read only permite desativar esse recurso e usar o sistema em read & write, o sandboxing também é desativável mas ainda sim lista as permissões, o que traz uma diferença gigante pro OSTree e o Endless OS. Teoricamente o Modo de Funcionamento do Android poderia em tese ser atualizado a partir do Zsync de forma similar ao mecanismo que o Ubuntu usava o cdrom upgrade ou através de imagens dos diretórios mantidos de forma readonly

Daí o “parte do problema”, mas a ideia não é usar isso como “sandboxing”

Sim dai o “feita as devidas implementações” GPG é só algo que dá pra implementar, atualizações do sistema também dá pra fazer não é algo complexo basta baixar os arquivos e montar ou extrair

Isso é fácil de explicar o AppImage é exatamente o que o nome diz: uma imagem, não faz nem sentido fazer downgrade em uma imagem (apesar de que dá pra fazer), na verdade o downgrade é a imagem que fica após atualizar

0 Likes