Neste recente posicionamento da Red Hat, muitas pessoas sentiram que sua confiança foi abalada. Se tem uma coisa difícil, é reconquistar a confiança dos clientes.
4 curtidas
Quem paga pelo RHEL continuará pagando feliz e a cantar. A comunidade prejudicaria a Red Hat se parasse de contribuir com o Fedora e com o CentOS Stream, o que não vai acontecer.
1 curtida
Querendo ou não, a RHEL meio que é a única distro no mercado que formalmente oferece algo que podemos chamar de uma ABI de espaço de usuário estável para empresas de longo prazo e com altíssima estabilidade no Linux. Não é um mero acaso que vários outros produtos de softwares meio que só dão suporte oficial para a distro.
Alguém pode dizer que Debian e afins também fazem algo similar, mas nunca vi estas distros garantirem a compatibilidade ao nível de ABI para diversas bibliotecas em até 3 major releases. Saber que o app que você desenvolveu e faz uso do glibc hoje vai funcionar no RHEL 8, 9 e 10 sem precisar de manutenção é uma grande questão, e estamos falando de major releases de longa duração, 10 anos.
3 curtidas
Isso é misleading, o Debian e o RHEL tem meios diferentes de contabilizar suporte, após 4 anos os RHEL entra em suporte de manutenção e depois em ELCS, nessa última fase são 6 anos, o Debian tem o ciclo todo em 5 anos… nenhum dos dois tem suporte entre Majors esse suporte é providenciado pela própria glibc da GNU, é importante lembrar que o ELCS da RHEL é bem diferente do que muita gente pensa, ele só garante acesso (pago, o que não é errado, mas é algo a parte se comprar apenas o suporte base vai ter acesso a apenas 5 anos o que o torna igual o Debian) a documentação de sistema:
uma assinatura do Red Hat Enterprise Linux fornece acesso contínuo ao conteúdo lançado anteriormente no Red Hat Customer Portal, bem como a outros conteúdos, como documentação e base de conhecimento da Red Hat […] nenhuma correção de bug, correção de segurança, habilitação de hardware ou análise de causa raiz está disponível durante esta fase.
Se a pessoa baixar ou gerar um snapshot da documentação Debian, o “ELCS caseiro unilateral” vai ter praticamente o mesmo efeito do RHEL
2 curtidas
“Misleading” é tentar fazer parecer que 5 anos (e não 4 anos como você quis fazer parecer) de supporte completo + 3~5 anos de suporte de manutenção + 2 anos de suporte extendido (ai sim onde não inclui nenhuma correção de bug, correção de segurança, habilitação de hardware ou análise de causa raiz) é a mesma coisa que apenas a garantia de suporte formal por 5 anos do Debian.
Não fale de coisas das quais não sabe, glibc é apena uma das bibliotecas neste nível de compatibilidade (CL1), desde o 8 existe sim garantia de compatibilidade formal de ABI entre 3 major releases (atual + duas):
A cada major release eles liberam um guideline oficial de compatibilidade de aplicação.
De boa? RHEL tem um público feliz e satisfeito. Tudo dá certo e funciona bem, treina time, certifica e bem como a Cisco indica mercado para os profissionais. Uma decisão como essa não muda absolutamente nada para os seus usuários. No meu entendimento não abalou nada, até porque conversei com alguns amigos que lidam com RHEL e todos “unanimemente” acharam ótima a decisão.
Segundo eles há uma confusão no mercado que dificulta o lado deles, desse modo as coisas ficam mais claras e ele visualizam um horizonte temporal com maiores ofertas profissionais.
Sim, tem muitas pessoas que acham que os clones são exatamente a mesma coisa e alguns até supõe que licenciados RHEL sempre dão suporte para qualquer coisa parecida com a distro e não é bem assim.
A Red Hat é um dos principais contribuidores para o desenvolvimento do kernel do Linux. Eles colaboram ativamente com a comunidade do kernel, contribuindo com código, correções e melhorias. Essas contribuições ajudam a impulsionar o desenvolvimento do Linux como um todo e beneficiam outras distribuições além do RHEL. Uma pequena lista de contribuições que me lembro de cabeça:
Systemd
Ansible
SELinux
KVM
Apoia fortemente o Gnome
RPM
Fedora
Cockpit
DNF
oVirt
OpenStack
Kubernetes
OpenShift
SCAP
Gcc
Aí tudo tem tem o dedo da RHEL.
1 curtida
Do que vi por exemplo no Hacker News, onde vejo vários desenvolvedores de várias empresas, sim, abalou a confiança e muita gente disse que não vai indicar o uso do RHEL em novos projetos.
Aqui onde trabalho, só usamos RHEL em um produto, porque ele é crítico e foi exigência do cliente, pois queria ter alguém para “processar”, caso desse algo errado.
De resto, os outros sistemas rodam em Debian ou containers Ubuntu no Azure.
2 curtidas
Cara a garantia de compatibilidade de 3 releases são um conjuntos restrito de pacotes cuja compatibilidade ABI se dá pela glibc (ela impõe marcadores, e fora a libxml2 e libxlst nenhuma das outras quebra API/ABI a mais de 10 anos ou segue o versionamento semântico com separação de Major, qualquer app ou serviço que use SSL ou curses pode e vai quebrar se for necessário, vou nem falar de GUI ou linguagens de ligação dinâmica (Python, Node, Lua…), experimenta rodar um app GTK de 3 versões atrás, não vai rolar, a RHEL não tem dó de quebrar scripts de manutenção entre versões como dá pra ver aqui (esse aqui vai parecer que eu tô zoando), aqui e aqui
Embora eu tenha errado por 1 ano, o Debian continua com suporte de 5 anos corridos antes da ELCS, e considerando que o novo modelo da RHEL ainda está em fase de implantação a menos que ocorram graves falhas de segurança e o Debian quebre o processo de migração N+2 (o que sinceramente eu duvido que aconteça) o nível de suporte continua igual para ambos com a RHEL podendo escolher se corrige ou não problemas RHEA (sendo esse quase certo que não) e RHBA apenas RHSAs são de alguma forma garantidos (vai ter que fazer uma conta pra saber se vai ou não receber) (crítico) tem vários poréns e detalhes não levados em conta nessa discussão
1 curtida
Uh?
Não parece não… Você só pode estar zoando… Você busca as coisas antes? Eu nem sei se eu devo perguntar o que você quer falando em Python, Node… Não quer aproveitar para colocar Javascript e PHP na lista? Quem sabe todas as linguagens/bibliotecas/frameworks que vem a mente.
Que? O lifecycle dos RHEL sempre foi muito longo, o 5 foi de 2007 até 2017 + extended life, o 6 de 2010 até 2020 + extended life. Dando uma olhada na documentação oficial, nem pacotes CL1 é uma novidade… Eu que nunca fui verificar se isso existia para releases mais antigas, e fazendo uma busca percebi que até o RHEL7 tem:
Eu nem sei o que eu estou fazendo aqui discutindo isso, já que o assunto parece mais guiado por questões fundamentalistas do que técnicas. Eu nem sei se estou discutindo pois estou mais corrigindo coisas do que discutindo. 
1 curtida
Não to dizendo que o suporte não é longo, to dizendo que esse suporte não é tão efeitivo como a maioria pensa, ter um suporte longo é diferente de ter um suporte efetivo longo, NA PRÁTICA você vai ter consultoria pra auxílio de migração e correção para um bug muito grave que afete muita gente
Falo nada… Deve afetar 10^-3 apps do Linux da era do 2.26
1 curtida
Aí tranquilo, não tenho problema nenhum com opiniões e percepções pessoais. Só não precisava daquela lambança toda ali em cima de “nenhuma das outras quebra API/ABI a mais de 10 anos, é a própria glib que garante compatibilidade de ABI por todos estes anos, confia.”
Quem sabe, vai que é bem menor? 10^⁻33 talvez? Talvez se a gente usar random para decidir…
Você deve achar que eu tô de meme, mas não
tem métricas pra medir isso, graças a projetos como Debian que fragmentam pacotes dá pra saber quantos pacotes fazem linkagem direta para os arquivos alterados e surpreendentemente são pouquíssimo e os que fazem são pacotes de interface que se fizerem do jeito CERTO não teriam problemas, se você reparar (vou pegar só a glibc mas acontece com todos) a quebra de API/ABI acontece no libresolv, se você abrir o changes vai notar que a maioria das quebras acontece com funções e métodos que começam com __ e ns segundo a documentação da biblioteca essas funções são para chamada INTERNA da biblioteca e não devem ser chamadas diretamente (não é oficialmente mas imagino que seja porque C não possui funções protegidas mas anyway) isso significa que simplesmente a menos que algum projeto aleatório esteja fazendo um uso indevido da glibc resolv ainda que eles tenham quebrado a assinatura dessas funções não devem ter ocorrido quebras em nenhum pacote, vai ter quebra se mesmo usando corretamente o projeto fazer linkagem estática dessas bibliotecas a questão aqui é, a RHEL não fornece cobertura a linkagem estática então qual a diferença pro Debian? Pega a documentação dessas libs e veja os pontos de quebra, praticamente todas acontecem em pontos onde ninguém fora a própria biblioteca deveria estar usando…
TLDR; Essas quebras acontecem em pontos não cobertos pela compatibilidade da RHEL porque segundo a documentação dos projetos ninguém deveria acessar eles fora a própria lib
1 curtida
Não… É que realmente não importa se é 10^⁻6 ou 10^⁻33, ser ABI compatível significa ser 100% compatível com a versão anterior, é para acontecer com 0… Mesmo.
Só de pthread_cond_signal estar na lista em um release entre 8 meses já é um baita problema. Mesmo sabendo de antemão que esse pacote só vai entrar daqui a 2 anos por estar em uma distro long release, é um baita problema.
Não suportar linkagem estática não importa, ninguém em sã consciência com esse tipo de demanda faria linkagem estática, glibc é componente do sistema, não do app. Se a pessoa quer esse abacaxi de amarrar uma versão x de uma biblioteca do sistema ao seu pacote, ela já está na distro errada, precisa repensar suas demandas. Nem vou comentar uso de métodos internos… Quem escolhe dar um tiro no pé não tem santo que ajude.
1 curtida
Creio que um dos grandes problemas que existem no GNU/Linux nem sejam tanto as ABIs, mas os gerenciadores de pacotes e a maneira como os pacotes são atualizados.
Vamos um exemplo utilizado pelo Windows. O .Net são inteiros, se vc desenvolve para uma versão que não é a current vc consegue utilizar o seu programa apenas instalando a versão que suporta o seu programa. Ele não quebrará até que a Microsoft depois de duas décadas deixar de dar suporte a uma de suas versões. O próprio modo de compatibilidade ainda é um último recurso para a sobrevivências dos produtos.
No GNU/Linux isso não é assim, é um monte de jeitos e maneiras. O Ubuntu core e os Snaps são uma tentativa de resolver isso. Onde vc terias várias versões ao mesmo tempo e de forma transparente, como se fosse uma plataforma, não é uma má ideia.
Chegaremos lá!
No caso do RHEL é fácil manter, pois ninguém fica fuçando e atualizando servidor em curto espaço de tempos. Igual dizem que o Fedora é um “teste” do RHEL, na prática isso não tem muito a ver. Fedora é uma “forma” de tornar amigável o RHEL.
1 curtida
Mas o ponto é esse meu caro, essas “quebras” de ABI listadas só acontecem se você estiver fazendo algo MUITO errado com o projeto, o suporte super estendido da RHEL ou a promessa de ABI não vão ajudar se a pessoa não seguir tudo certinho a documentação, e se a pessoa seguir vai ser irrelevante, o ponto é esse
Ai que está, você não compreende para que serve suporte de longuíssimo prazo, como eu mencionei la em cima:
Este cliente:
- Não aceita riscos estatisticamente improváveis.
- Quer economizar dinheiro na manutenção e se manter atualizado, uma distro de longíssimo suporte pode significar +2x custo para você, mas -2x para esse cliente, por N motivos.
- Não aceita o risco futuro imposto pela necessidade de portar seu projeto para a nova interface destas bibliotecas mesmo que seja 5 anos. E aqui o motivo não importa, (impacto financeiro, de estabilidade, segurança, etc).
Não faz o menor sentido trazer problemas como linkagem estática vs dinâmica ou uso de funções internas do glibc que são problemas de projeto de baixa maturidade no ciclo de gestão onde os processos de CI/CD são outros.
Projetos podem ter demandas radicalmente diferentes, alguém desenvolvendo uma loja virtual, outro um sistema de arquivos e outro um sistema que controla uma máquina de radiografia, tem demandas totalmente diferentes
Em alguns sistemas críticos, não é aceitável isso, e dai você tem 2 soluções:
-
Além de tocar seu projeto você mantém a sua versão da glibc repassando os patches para versões antigas o que é caríssimo. estamos falando de alguns engenheiros de desenvolvimento sênior super nichados e nada baratos. Para impactar o mínimo possível seu projeto e continuar recebendo patches de segurança.
-
você paga alguém para garantir isso…
Estamos falando de empresas que produzem e dão manutenção, digamos, em ERPs/DBMSs/etc de escala global, o buraco é mais em baixo. Coisas nesta escala, só o mero planejamento de atualização de infra dentro da org inteira a nível global, pode ser um plano de 1 ano ou mais (se isso envolver zero mudanças no software), com um custo absurdo, quem dirá o de desenvolvimento e implantação de uma nova versão.
Red Hat abalou foi a galera do Alma Linux e do Rocky Linux e demais do ctrl + c ctrl + v. Não creio que a galera pagante vai deixar de usar RH por causa disso, até porque isso não afeta eles.
Se eu entendi muito bem todo o código da Red Hat estará disponível através CentOS Stream com exceção ao que for proprietário da Red Hat. Algumas atualizações podem chegar antes ou depois que a verão Enterprise.
Endento o ponto da Red Hat e até certo ponto a comunidade, mais tirando a Oracle que diretamente ou indiretamente contribuía com patch do Red Hat, os demais apenas aguardava para reempacotar.