NixOS Portuguese - Public Room Timeline

	NixOS Portuguese	376 Members
	Sala de Conversação sobre o ecossistema Nix em português. Ponteada com o grupo do Telegram: https://t.me/nixosbrasil/ Link Matrix: https://matrix.to/#/!BrOouUOucaGdxbaRca:nixos.org	19 Servers

Load older messages

Sender	Message	Time
13 Dec 2022
GALLY	In reply to Victor Matheus o lennart ta empenhado em fazer qualquer distro q se dispor a isso ser compatível com erase your darlings, dependendo só de /boot e /usr (além de labels gpt). deem uma olhada a partir da linha 600 https://github.com/systemd/systemd/blob/main/TODO Interessante. Pena ser systemd.	15:32:34
GALLY	In reply to Victor Matheus isso é uma opção permanente, ou tem que rodar de tempo em tempo pra ele percorrer tudo e fazer os links q puder? É um comando para se usar de tempos em tempos. Então, opção 2.	15:33:55
Lucas Eduardo	In reply to Victor Matheus o q to pensando seria algo como ter /nix/store /nix/objects sendo /nix/objects onde são dropados os arquivos reais, e aí o ostree vai jogando pra /nix/store/$hash conforme o caso (se novo, adiciona aos objetos, se conhecido, cria o link) é assim q instalação/atualização de flatpak funciona No caso o nix deixa em /nix/store/.links	15:34:28
Victor Matheus	não tem nada q impeça de implementar o conceito em outros inits; mas pra ser consistente, tem que ser um init com "auto-governança" digamos assim, como o systemd	15:35:06
Lucas Eduardo	https://youtu.be/Z7p9-m4cimg	15:47:59
Erik	In reply to Victor Matheus o q to pensando seria algo como ter /nix/store /nix/objects sendo /nix/objects onde são dropados os arquivos reais, e aí o ostree vai jogando pra /nix/store/$hash conforme o caso (se novo, adiciona aos objetos, se conhecido, cria o link) é assim q instalação/atualização de flatpak funciona O ostree n faz tudo com diff de binario, de forma incremental? Que eu me lembre ele funcionava com isso...	16:10:59
Erik	In reply to Erik O ostree n faz tudo com diff de binario, de forma incremental? Que eu me lembre ele funcionava com isso... Sipa o nix faz a nivel de hash de arquivo, enquanto o ostree vai usar algo como o rsync, montando de forma incremental/delta cada arquivo.	16:17:05
Erik	Toda vez que tu apagasse uma geração antiga teria que refazer todos as geraçoes upstream	16:20:13
Lucas Eduardo	In reply to Erik Sipa o nix faz a nivel de hash de arquivo, enquanto o ostree vai usar algo como o rsync, montando de forma incremental/delta cada arquivo. Isso deve gerar uma fragmentação desgracenta e só vai funcionar com uma performance decente em SSD	16:33:58
PedroHLC	In reply to Victor Matheus pelo q entendi daí, sejam duas /nix/store/$hash diferentes, vc pode acabar com o mesmo exato arquivo armazenado duas vezes (uma lib por ex, se a compilação assim cria-las), sendo q poderia ser um hardlink Kkkkk vc pode sempre por a nix-store com dedup no ZFS	16:44:03
Victor Matheus	Mas a ideia do ostree é justamente usar full posix pra isso, sem depender de filesystem	16:44:49
Victor Matheus	Lembre q ele saiu de dentro da redhat, q não vai nem adotar openzfs, muito menos dar "aval" pra suse apoiando btrfs	16:45:27
Victor Matheus	Em vez disso tão empilhando lvm+xfs(stratus) +ostree+composefs (esse é novo) pra fazer tudo q btrfs/zfs se propõem, cp reflink+snapshot+dedup+verity	16:46:54
Victor Matheus	* Em vez disso tão empilhando lvm+xfs(stratis) +ostree+composefs (esse é novo) pra fazer tudo q btrfs/zfs se propõem, cp reflink+snapshot+dedup+verity	16:47:06
Victor Matheus	Eu acho maneiro pq vc pode pegar só uma parte dessa pilha q interesse, ao mesmo tempo em q a grana e devs da redhat seriam muito bem vindos no btrfs	16:48:39
Victor Matheus	In reply to Erik Toda vez que tu apagasse uma geração antiga teria que refazer todos as geraçoes upstream Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto. Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch. Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo.	17:01:18
Victor Matheus	* Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto. Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch, dropar o arquivo novo em objects, e linkar pra branch q tá pedindo. Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo.	17:02:11
Lucas Eduardo	In reply to Victor Matheus Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto. Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch. Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo. Ele descarta na hora ou é que nem git que as vezes tem que rodar um git gc?	17:04:17
Victor Matheus	Não faço ideia. Mas eu esperaria algo automático baseado em tempo. Se não rolou um ostree-pull q reusou em xtempo, limpa. Como ele é daemonless, deve verificar isso só quando vc faz alguma operação. Claro, nada impede de uma implementação acima dele lidar com isso mais agressivamente, tipo o deb-ostree do endless, ou rpm-ostree dos fedora	17:09:18
Victor Matheus	O flatpak por ex mantém um.removed por um tempo, nunca monitorei quanto	17:09:50
Victor Matheus	Pelo menos a doc da cli do ostree é muito confusa e desatualizada, achei na doc comandos totalmente fora de ordem/q a cli disse pra mim q não existem	17:14:14
Erik	In reply to Victor Matheus Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto. Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch. Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo. hmmn, onde que entra a parte do "atomic"?	17:21:02
Victor Matheus	In reply to Erik hmmn, onde que entra a parte do "atomic"? Ele troca o link, é uma operação só, ou tá linkado em oldfile, ou em newfile	17:24:23
Victor Matheus	Se for um arquivo novo, e não uma troca de arquivo, simplesmente criar o link.	17:25:43
Lucas Eduardo	eu to estudando uma forma de fazer isso ai só que multiplos discos	18:21:15
Victor Matheus	Btrfs faz isso aí, o cp no btrfs é um hardlink sempre q possível, cruzando discos. Lvm + xfs vai ter isso tbm	18:40:55
Leonardo Neumann	In reply to Victor Matheus Btrfs faz isso aí, o cp no btrfs é um hardlink sempre q possível, cruzando discos. Lvm + xfs vai ter isso tbm Reflink você quis dizer	19:57:59
Leonardo Neumann	Que é o nome da cópia "deduplicada" do btrfs	19:58:20
Victor Matheus	No fim é um hardlink, só q direto no filesystem, não via vfs	19:58:46
Victor Matheus	O userspace só consegue descobrir se sair rodando stat em tudo e comparando até achar igualdade de inode	20:00:06

Show newer messages

Back to Room ListRoom Version: 9