Fedora 17 Beefy Miracle vai tentar de novo migrar para o Btrfs (e mudar a estrutura de diretórios)
Lembra daquela proposta de mudar todos os executáveis e bibliotecas (do /bin, /sbin, /lib, etc.) para o /usr? O comitê de engenharia aprovou para o Fedora 17.
E lembra daquela malfadada transição para o Btrfs como sistema de arquivos default, que ocorreria no Fedora 16 mas foi cancelada devido a detalhes como a ausência de ferramenta apta à manutenção dos discos? A ferramenta almejada continua ausente, mas a mudança para o Btrfs foi aprovada novamente para o Fedora 17. Será que agora vai?
E tem mais mudanças aprovadas, inclusive o suporte default a multiseat, a remoção do ConsoleKit, a migração completa para o systemd e o funcionamento do GNOME Shellem computadores sem aceleração 3D. (via h-online.com – “Btrfs and new file system structure agreed for Fedora 17 – The H Open Source: News and Features”)
@brlinuxblog
Feed RSS
O Btrfs tem tudo para ser um substituto à altura para o Ext4, mas bem que eles podiam criar um nome mais bacana para esse FS.
E o Reiser4 por que não vai prá frente? Pelos Benchmarks do Phoronics ele parece ser muito bacana tbm…
Sobre a proposta de mudar todos os executáveis e bibliotecas (do /bin, /sbin, /lib, etc.) para o /usr, eu só seria a favor se fosse adotado por todas as distros, senão vira a casa da mãe Joana. Sou totalmente contra caso não seja assim, temos que seguir o padrão LSB, mas estou vendo que cada distro está seguindo seu rumo e não pensando no Linux como um todo. Eu acho que esse caminho é perigoso, se cada distro quiser fazer o que bem entender sem seguir um padrão, daqui a pouco você terá que fazer treinamento para aprender a conhecer cada tipo de distro.
O Reiser4 não vai pra frente pq o cara que colocava a parada pra frente ta preso.. hehe
Tanto se fala do btrfs mas até agora eu não encontrei nada sobre como realizar e como restaurar a snapshot criada. Ou seja, o principal diferencial do btrfs ainda é pouco (se é) divulgado. A única distro que atualmente eu vi fazer uso prático do btrfs foi o OpenSuSe que nessa última versão trouxe o Snapper (há alguns videos de apresentação) de forma reduzida pode se afirmar que ele (o Snapper) cria algo como os pontos de restauração do windows, armazenando todas as alterações do sistema e caso de algo errado basta voltar atrás. Gostaria que esse recurso fosse implementado rápido nas outras distros seria algo muito útil. Mas como eu ressaltei sequer encontrei material que ensine de forma explicada como criar e restaurar (ainda que manualmente) as snapshots no btrfs.
Concordo com o Fabio Slenio, vai virar bagunça (ou bagunçar mais ainda). Vai ficar cada vez mais distante da familia RH/CentOS. Eu uso os 3 e a comodidade de precisar aprender apenas uma filosofia é muito conveniente para mim
Linux e a eterna fragmentação…
HGil, sobre snapshots no Brtfs:
Simple Automated btrfs Snapshots with btrfs-snap
Introducing snapper
More Brtfs goodness snapshots
Olha, eu espero sinceramente que alguém da comunidade Fedora esteja lendo esses comentários.
Já digo de antemão, caso realmente coloquem tudo no /usr fugindo dos padrões LSB e do Linux não utilizarei mais o Fedora, muito menos recomendarei o Fedora a algúem. Essa fragmentação que está originando é extremamente prejudicial ao Linux, a Canonical quer seguir um modelo, o Fedora outro, onde vamos parar? Porque não criam um comite das principais distro, sentam, analisam e tomam uma decisão em conjunto.
Sinceramente, é lamentável tal postura do Fedora Project.
Para quem achou curioso o nome:
http://beefymiracle.org/history.html
Notícias assim que reforçam a idéia de que o Fedora não passa do balão de ensaio da Red Hat.
Muita coisa crítica modificada ao mesmo tempo.
@Denis… Meu bom Deus, isso piorou a minha opinião sobre o nome esquisito dessa versão do Fedora. Parece um bando de doidos falando… Crux Santissima!
lamentável essa idéia do Fedora Project. O padrão LSB é solenemente ignorado pelas distribuíções, com isso quem ganha é o concorrente: Microsoft Windows. E as empresas que desenvolvem hardware e as de Software vão simplesmente ignorar o Linux por causa desta bagunça.
Lendo isso infelizmente muitos manutendores das distros c/ essa falta de (respeitar ao menos) padrão mostra como é comum pessoas não valorizar a liberdade e achar que é fazer do jeito que bem quiser sem regras mínimas, sem coerência, bagunça…
Eu até acho interessante questionar os padrões, por exemplo o SystemD e o menos hypeado Upstart parecem ambos superiores ao System-V. Que se evolua, preferencialmente escolhendo um só ou estabelecendo alguma forma simples de interoperar.
Mas precisa mudar tudo ao mesmo tempo ? Sistema de arquivos, estrutura dos diretórios, inicializador.. ?
Acredito que quanto ao sistema de arquivos, tudo bem. é apenas uma opção default que vc pode optar por usar a seu sistema preferido. Quanto a questão dos diretórios, por não conhecer muito e não ter ideia do impacto desta mudança, não da para ter uma opinião, embora se existe um padrão pré-determinado e sou a favor do uso do mesmo, se a distro não concorda convoque uma reunião com a entidade que define os padrões e mostre as vantagens e desvantagens do novo, e não se esqueça de implementar algo que deixe os dois minimamente compatíveis para que não vire uma bagunça.
@Ricardo Silva
Perdi alguma parte da história de seu comentário, que modelo que a Canonical quer seguir que interfere nos padrões? O Unity é apenas um gerenciador de janelas, até onde eu saiba, não deve/deveria modificar o desenvolvimento de softwares para que se escreva algo especifico para Ubuntu.
É isso que se espera de uma distro-cobaia que é lançada semestralmente. Mudanças e mais mudanças bruscas. O mesmo aconteceu com o Ubuntu e aquela coisa chamada Unity.
Quando forem escolher uma distro, escolham algo mais conservador e que tenha um suporte a longo prazo, e não essas distros cobaias que cada versão não duram nem um ano e não há padrão nenhum, é tudo uma bagunça.
Para cada distro antiga que se desvirtua, duas outras distribuições novas preenchem seu lugar.
Ao contrário da árvore Red-Hat, a do Debian continua aí, disponível para todos os tipos de clientes e tratando-os iguais; a distro raiz continua conservadora (para dar às suas filhas a liberdade de não serem) e seu modelo de pacotes sempre colocando a cabeça para fora na seleção natural.
Os filhos do Slackware continuam mantendo o seu nicho em tamanho constante, não ganhando muitos usuários, mas também não perdendo.
Padrões são uma coisa boa. A LSB, assim como as normas POSIX e o System V, já faz parte do que torna o Linux (ao menos em seu modelo GNU-Like), Linux.
Chutar um padrão sem nenhum motivo mais forte que a vontade de criar um diferencial, é estúpido.
Aliás sempre é estúpido chutar um padrão. Se tem uma ideia melhor, junte gente que pensa como você, converse com que não pensa como você em busca de consenso e crie um novo padrão.
Mas a estrutura de diretórios vai mudar ou só vai mudar no estilo GoboLinux, que “invisivelmente” continua no padrão LSB?
Todo mundo so reclama, ninguem comentou se sera uma boa mudanca do padrao LSB ou nao. Se for positivo, as outras distros vao mudar, e nenhuma distro concordaria em fazer tantas mudancas pq nenhuma toma frente como o FEDORA faz, se nao for desenvolvido primeiro no FEDORA, sera desenvolvido em qual distro? Ja que o FEDORA eh o COBAIA, entao que ele modifique…
Essa mudança nos diretórios (que achei ruim) nem fará tanta diferença, está tudo no PATH mesmo. Talvez em scripts que usam caminhos “cravados”, mas como, por enquanto, links simbólicos segurarão o lugar…
Suporte nativo a multiseat? Isso muito me interessa (sobretudo no meu trabalho). Agora, remoção do ConsoleKit é algo que me surpreende.
alguem precisa ir na frente abrindo caminho na floresta!
é natural essa postura do fedora
alguns criticam, mas mal sabem que isso é benéfico pra todos
Disso tudo, o mais preocupante, é a questão de não aderir ao LSB.
Agora, interesante será ver o Gnome Shell sem aceleração 3d.
Essa mudança não faz tanta diferença mas acho que o caminho é esse. Quanto ao padrão, esse deve ser o padrão no futuro e as principais distros irão segui-lo.
Fazer do seu jeito e esperar que o padrão siga você é trollesco. Falta de respeito com as outras distribuições e com os usuários delas. Ponto final.
Não acho que seja falta de respeito, se o propósito do Fedora é ser uma distribuição inovadora, não precisa seguir as regras, e sim testar novos conceitos. Se os mesmos derem certo vão ser adotados pelo LSB se não mudam de novo.
Acho bem interessante uma distribuição do porte do Fedora tomar esta iniciativa, porque resultados se veem na prática e não em reuniões teóricas. E quem é usuário do Fedora tem que levar em conta a finalidade da distribuição.
Que é isso @Porfírio, não precisa exagerar, eu uso RedHat e CentOS nos servidores e Fedora no netbook (com uma partição Ubuntu que não uso muito). Em todos eu altero o script de inicialização para por o /sbin e o /usr/sbin na variável PATH, também (já que o /bin e /usr/bin já estão lá). Não vejo qual a vantagem de não fazê-lo. Assim como não vejo vantagem em deixar tudo separado em /bin, /usr/bin, /sbin e /usr/sbin. Com certeza os links simbólicos que ficarão no lugar segurarão os scripts e outros programas que vão buscar os binários em determinadas pastas, que é como costumo fazer meus scripts (não deixo eles buscarem os binários pela variável PATH). Ou seja, eu uso justamente as distribuições que certamente alterarão esse paradigma e eu busco determinados binários em determinados diretórios, teria tudo para ser contra essa mudança, mas não sou.
Primeiro vem os colonizadores/exploradores, depois vem os fazedores de leis e padrões, é nessa ordem que funciona a coisa. Se a coisa estivesse realmente boa, não haveria exploradores tentando outros caminhos.
Se essa estória de migrar todos os diretórios para o /usr (como no Windows é no c:Windows (de sistema) e no c:program files (de usuário) e no outro post me censuraram por dizer isso…) é interessante se acabarem de vez com a lambança dos links simbólicos. É simples, aponta para a pasta do aplicativo em /usr/aplicativo e mais nada.
Eu gosto muito do exemplo do java. Rastreim o java no sistema de vcs. Vão achar algo assim:
java instalado em /usr/java ou /usr/lib/java;
um link /usr/java apontando para o link /etc/alternatives/java que aponta para /usr/java ou /usr/lib/java.
isso é só um exemplo, tem muito mais bizarrisses do tipo espalhado pelo sistema.
Se acabar com isso, para mim está perfeito. Nem precisava fazer a migração!
No Windows é uma zona, não peguem o Windows como parâmetro.
Os caminhos serão definidos no path, gente, quem não chegou ontem sabe que já mudamos pontos de montagem, sistemas de abstração para acesso a nós de dispositivos de hardware, X Window System, sistemas de detecção automática de hardware, enfim…
Antigamente o /usr/local era muito mais usado do que hoje, o /opt também. Ninguém morria, ninguém deixava o sistema porco, fazendo do jeito correto, tudo ficava lindo.
Olhem o devfs, como era, gente: http://tldp.org/HOWTO/SCSI-2.4-HOWTO/dnamesdevfs.html
O Fedora vai vir empacotado de acordo. Software de terceiros deve seguir nossos padrões e se seguir, funcionará. Software a ser compilado deve usar sistemas de compilação inteligentes, dependendo de como for, vai funcionar perfeitamente e dependendo de como não funcionar, poderemos fazer com que siga o padrão do Fedora.
Nada para bater o pé. Tenho mais medo do Btrfs, na verdade. Mas quanto mais bugs, melhor, o pessoal reporta, eles vão sendo corrigidos e o software vai ganhando em confiabilidade. É só assim que funciona, com o Linux foi assim por anos a fio com a árvore instável do kernel e ninguém morreu, muito pelo contrário.
Isso me lembra um trecho do FreeBSD Handbook: http://www.freebsd.org/doc/pt_BR.ISO8859-1/books/faq/funnies.html#CHANGING-LIGHTBULBS
Não ter padrão não é um problema do GNU/Linux, é uma CARACTERÍSTICA.
Quer padrão? Corre pras distros enterprise.
Porque a comunidade não remove de vez a necessidade de usar linha de comando?
Deveria fazer isso oras.Interface na linha de comando somente na hora da inicialização.
A comunidade das pessoas interessadas em remover de vez a necessidade de usar a linha de comando poderia se reunir para tentar fazer isso e ver até aonde chega.
Ainda não migrei (parcialmente) para o b-tree filesystem porque não há ferramenta para fsck. Porém, achei interessante o Fedora eliminar o ConsoleKit (nunca gostei do modo como ele gerencia as sessões). Aliás…
https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/263245
Eu fico “de cara” com uma questão que seria resolvida com meia hora de diálogo ou alguns e-mails.
Um padrão não é imutável. Vc. só precisa discutir e entrar em consenso. Porque não fazer isso ANTES de implementar por conta própria? Porque não fazer um plano de migração onde TODAS as distros podem se beneficiar?
Porque dificultar a vida de quem faz pacotes do tipo tar? Vai ter que montar um pacote separado, específico pro Fedora?
Porque inserir mais incompatibilidades ainda entre as distribuições?
Da até vontade de criar distro sem a “interface” modo texto.Exceto aquelas coisas essenciais que não dá .
É um absurdo ainda que precisamos nos comunicar o sistema com a linha de comando.Ou aquele negócio de frontend da linha de comando é horrivel.O pessoal não sabe se comunicar diretamente com a máquina pela interface gráfica não?