AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
An Open Source, community owned and governed, forever-free enterprise Linux distribution.
almalinux.org
-
Prezados usuários,
Por questões de segurança, a partir de 22/04/2024 os usuários só conseguirão logar no fórum se estiverem com a "Verificação em duas etapas" habilitada em seu perfil.
Para habilitar a "Verificação em duas etapas" entre em sua conta e "Click" em seu nick name na parte superior da página, aparecerá opções de gestão de sua conta, entre em "Senha e segurança", a primeira opção será para habilitar a "Verificação em duas etapas".
Clicando alí vai pedir a sua senha de acesso ao fórum, e depois vai para as opções de verificação, que serão as seguintes:
***Código de verificação via aplicativo*** >>>Isso permite que você gere um código de verificação usando um aplicativo em seu telefone.
***Email de confirmação*** >>>Isso enviará um código por e-mail para verificar seu login.
***Códigos alternativos*** >>>Esses códigos podem ser usados para fazer login se você não tiver acesso a outros métodos de verificação.
Existe as 3 opções acima, e para continuar acessando o fórum a partir de 22/04/2024 você deverá habilitar uma das 03 opções.
Tópico para tirar dúvidas>>>>https://forum.adrenaline.com.br/threads/obrigatoriedade-da-verificacao-em-duas-etapas-a-partir-de-24-04-2024-duvidas.712290/
Atencionamente,
Administração do Fórum Adrenaline
[TÓPICO OFICIAL] Linux Distros
- Iniciador de Tópicos Core
- Data de Início
almalinux.org
Cara, o Manjaro é uma boa, mas se dependesse da minha sugestão; MX, POP/Os, ou Mint, entre os 3 o MX é o mais leve, se o xfce não te agradar pode tentar o KDE, Boa sorte e volte sempre
Uma análise abrangente dos problemas de GPL com o modelo de negócios do Red Hat Enterprise Linux (RHEL)
Este artigo foi originalmente publicado principalmente como uma resposta para a mudança da Red Hat por não mais publicar por completo, a fonte correspondente para RHEL e o prévia descontinuação do CentOS Linux (que são eventos relacionados, como descrito abaixo). Esperamos que isso sirva como um documento que discute a história do modelo de negócios RHEL da Red Hat, o fornecimento de código-fonte relacionado e os problemas de conformidade GPL com RHEL.
Por aproximadamente vinte anos, a Red Hat (agora uma subsidiária integral da IBM) experimentou a construção de um modelo de negócios para implantação de sistema operacional e distribuição que parece, sente e age como proprietária, mas no entanto, está em conformidade com a GPL e outros termos padrão de direitos autorais. Ativistas de direitos de software, incluindo SFC, passaram décadas conversando com a Red Hat e seus advogados sobre como o modelo de negócios do Red Hat Enterprise Linux (RHEL) era um desastre e era ativamente hostil para Software Livre e de Código Aberto (FOSS) orientado para a comunidade. Essas súplicas, discussões e incentivos, até onde sabemos, foram ouvidos e ouvidos com seriedade pelos principais membros do departamento jurídico e da OSPO da Red Hat departamentos e até mesmo pelos principais executivos de nível C, mas acabaram sendo rejeitados e ignorado - às vezes até com uma "multa, então nos processe por violação da GPL”. Ativistas encontraram esta discussão frustrante, mas manteve a natureza e a posse dessas discussões como um “segredo aberto” até agora porque todos esperávamos que o comportamento da Red Hat melhorasse. Eventos recentes mostram que o comportamento simplesmente piorou e é provável que fique ainda pior.
A maneira mais concisa e concisa de descrever o modelo de negócios do RHEL é: “se você exercer seus direitos sob a GPL, seu dinheiro não é bom aqui". Especificamente, o Red Hat da IBM oferece cópias do RHEL para seus clientes, e cada cópia vem com um suporte e atualização automática em um contrato de assinatura. Como entendemos, este contrato afirma claramente que os termos não pretendem contradizer quaisquer direitos de cópia, modificação, redistribuir e/ou reinstalar o software quantas vezes e em quantos lugares como o cliente gosta (ver §1.4). Além disso, porém, o contrato indica que se o cliente se envolver nessas atividades, a Red Hat se reserva o direito de cancelar esse contrato e não fazer mais contratos com o cliente para suporte e serviços de atualização. Em essência, a Red Hat exige que seus clientes escolher entre (a) sua liberdade e direitos de software e (b) permanecer um cliente Red Hat. Em algumas versões desses contratos que analisamos, a Red Hat ainda se reserva o direito de “avaliar” um cliente (efetivamente um BSA -estilo de auditoria) para examinar como muitas cópias do RHEL estão realmente instaladas (consulte §10) — presumivelmente para o propósito da Red Hat obter as informações necessárias para decidir se deve “demitir” o cliente.
Os advogados da Red Hat claramente assumem a posição de que este modelo de negócios está em conformidade com a GPL (embora não tenhamos tanta certeza), alegando que nada nos acordos GPL exige que uma entidade deve manter uma relação comercial com qualquer outra entidade. Eles argumentaram ainda que tais negócios relacionamentos podem ser encerrados com base em qualquer comportamento - incluindo exercendo direitos garantidos pelos acordos GPL. Se essa análise está correta é uma questão de intenso debate, e provavelmente apenas um caso no tribunal que contestasse esta questão em particular produziria uma resposta definitiva sobre se esse comportamento desagradável é permitido (ou não) sob os acordos GPL. Os debates continuam, ainda hoje, nos círculos de especialistas em copyleft, se esso modelo em si viola a GPL. Não há, porém, dúvidas de que este disposição não está no espírito dos acordos GPL. O modelo de negócio RHEL é hostil, capcioso, caprichoso e digno de vergonha.
Além disso, este modelo de negócios RHEL permanece, até onde sabemos, único na indústria no setor de software. A Red Hat da IBM definitivamente merece crédito por tão cuidadosamente construir seu modelo de negócios de tal forma que passou a maior parte das últimas duas décadas em território obscuro de “provavelmente não violar a GPL”.
Talvez o maior problema com um modelo de negócios obscuro que contorna o linha de conformidade GPL é que as violações podem acontecer e acontecem - desde mesmo um pequeno desvio do modelo de negócios que claramente viola a GPL. Pré-IBM, a Red Hat merece uma certa quantidade de crédito, como a SFC ciente de apenas dois incidentes documentados de violações da GPL que ocorreu desde 2006 em relação ao modelo de negócios RHEL. Nós decidimos compartilhar alguns detalhes gerais dessas violações para fins de explicar onde esse modelo de negócios pode ultrapassar os limites com tanta facilidade.
Na primeira violação, uma grande empresa da Fortune 500 (que vamos chamar de Empresa A ), que usaram o RHEL internamente e também construíram produtos baseados em Linux voltados para o público, decidiu criar um produto (que chamaremos de Produto P ) baseado principalmente no CentOS Linux, mas P incluiu alguns pacotes construídos a partir de fontes RHEL. Empresa A não procurou nem solicitou serviços de suporte ou atualização para este separado Produto P. A Red Hat mais tarde tomou conhecimento de que o Produto P continha alguma parte do RHEL, e a Red Hat exigiu pagamentos de royalties pelo produto P. A Red Hat ameaçou revogar o suporte e atualizações de serviços nos servidores RHEL internos da Empresa A se tais royalties fossem pagos.
Como a Empresa A era poderosa e tinha bons advogados e equipe de desenvolvimento de negócios, eles não concordaram. Empresa A em última análise continuou (até onde sabemos) como cliente RHEL para seus servidores e continuou vendendo o Produto P sem pagamento de royalties. No entanto, um a demanda por royalties para distribuição é claramente uma violação, pois essa demanda cria um “restrição adicional” nas permissões concedidas pela GPL. Como declarado na GPLv3:
A Red Hat tentou impor uma restrição adicional nesta situação e, portanto, violou a GPL. A violação foi resolvida, pois nenhum royalty foi pago e a Empresa A não enfrentou consequências. A SFC soube do incidente mais tarde, e informou a Red Hat que a demanda anterior de royalties foi uma violação. A Red Hat não contestou nem concordou que era uma violação e concordou informalmente tais exigências não seriam feitas no futuro.
Em outro incidente de violação, descobrimos que a Red Hat, em um determinado país fora dos EUA, estava exigindo que qualquer cliente que diminuísse o número de máquinas RHEL sob contrato de serviço com a Red Hat assinam um acordo adicional. Este acordo adicional prometia que o cliente deletaria todas as cópias do RHEL em toda a organização, exceto o cópias do RHEL atualmente contratadas para serviço com a Red Hat. Novamente, esta é uma “restrição adicional”. Os acordos GPL dão a todos o direito irrestrito de fazer e manter tantas cópias do software como quiserem, e um distribuidor de software GPL pode não exigir de um usuário atestar que excluiu essas cópias legítimas e licenciadas de software licenciado por terceiros sob a GPL. A SFC informou o departamento jurídico da Red Hat desta violação, e nos foi assegurado que este acordo adicional não ser apresentado a qualquer cliente da Red Hat no futuro.
Em ambas as situações, nós da SFC estávamos preocupados que eles fossem apenas um “ponta do proverbial do iceberg”. Durante anos, ouvimos de clientes da Red Hat que eles estavam realmente confusos. É comum na indústria falar sobre “licenças por estação RHEL” e muitos especialistas em aquisições de software do setor não estão cientes das nuances do modelo de negócios RHEL e não entendem seus direitos. Nós permanecemos muito preocupado com o fato de os vendedores da RHEL confundirem propositalmente os clientes para vender mais “licenças por estação”. Muitas vezes nos leva a perguntar: “Se uma licença violação GPL acontece no mato, e todos os envolvidos não ouvem, como alguém sabe que os direitos de software foram de fato pisoteados naquelas matas?”. Assim como fazemos com o maior número possível de relatórios de violação da GPL, perseguimos zelosamente as violações da GPL relacionadas ao RHEL que são relatados para nós, e se você estiver ciente de um, por favor envie- nos um e-mail para compliance@sfconservancy.org imediatamente. Tememos que seja por incompetência ou malícia, muitos vendedores e empresários profissionais de desenvolvimento da RHEL podem violar regularmente a GPL e ninguém sabe isto. Dito isso, o modelo de negócios conforme descrito pelo Red Hat da IBM pode estar em conformidade com a GPL - é tão obscuro que qualquer ajuste para o modelo em qualquer direção parece definitivamente violar, em nossa experiência.
Além disso, a Red Hat explora o clássico “caveat emptor” abordagem - popular em muitos negócios obscuros ao longo da história. Enquanto, tecnicamente falando, um leitor cuidadoso dos acordos GPL e RHEL entende a barganha que está fazendo, suspeitamos que a maioria das pequenas empresas simplesmente não tem a perspicácia e o conhecimento de licenciamento da FOSS para realmente entender aquele negócio.
Até “aquisição” do CentOS pela Red Hat no início de 2014 , CentOS forneceu um excelente contrapeso para os problemas com o modelo de negócios RHEL. Especificamente, o CentOS era um projeto voltado para a comunidade, com muitos voluntários, apoiados por algum envolvimento de pequenos negócios, para recriar versões do RHEL usando as fontes feitas para o RHEL. Nossa visão pré-2014 era que o CentOS era o “canário em a mina de carvão escura” do negócio RHEL. Se o CentOS parecia vibrante, utilizável e uma alternativa viável ao RHEL para aqueles que não queriam adquirir as atualizações e serviços da Red Hat, a comunidade poderia ficar tranquila. Mesmo que houvesse violações da GPL pela Red Hat no RHEL, a vitalidade do CentOS asseguraria de que tais violações estavam tendo apenas um pequeno impacto negativo sobre a comunidade FOSS em torno da base de código do RHEL.
A Red Hat, no entanto, aparentemente sabia que essa comunidade vibrante estava cortando em seus lucros. A partir de 2013, a Red Hat iniciou uma série de ações que aumentaram sua aderência. Primeiro, eles “adquiriram” o CentOS. Isso foi inicialmente formulado como um acordo de cooperação, mas a Red Hat fez ofertas de trabalho sistematicamente aos principais voluntários do CentOS que não podiam recusar, adquiriu as pequenas empresas que podiam transformar o CentOS em um produto e, de outra forma, integrou o CentOS nas próprias operações da Red Hat.
Depois que a IBM adquiriu a Red Hat, a situação piorou. Tendo obtido direitos à marca CentOS como parte da “aquisição”, a Red Hat lentamente começou a mudar o que era o CentOS. O CentOS Linux rapidamente deixou de ser um check-and-balance no RHEL e acabou de se tornar um campo de testes para o RHEL. Então, em 2020, quando a maioria de nós estava distraída com o pior da pandemia do COVID-19, a Red Hat encerrou unilateralmente todo o desenvolvimento do CentOS Linux. Mais tarde (durante a parte da variante Delta da pandemia no final de 2021) a Red Hat encerrou o CentOS Linux inteiramente .IBM Red Hat então usou o nome “CentOS Stream” para se referir a pacotes de origem relacionados ao RHEL. Estes não eram (e não são) realmente o RHEL originalmente - em vez disso, eles parecem ser principalmente um teste base para o que pode aparecer no RHEL mais tarde.
Finalmente, a Red Hat anunciou há dois dias que as fontes do RHEL não estariam mais disponíveis publicamente. Agora, para ser claro, os acordos GPL não obrigam a Red Hat a fazer sua fontes publicamente disponível para todos. Este é um equívoco comum sobre os requistiso GPL. Embora os detalhes do provisionamento das fontes variem em diferentes versões dos acordos GPL, o princípio geral é que as fontes precisa ser fornecidas junto com as distribuições binárias para aqueles que receberem, ou (b) para aqueles que solicitarem de acordo com uma oferta por escrito para a fonte. Numa situação normal, sem atenuantes, o fato de uma empresa passou de distribuir fontes publicamente para todos para apenas darem para clientes que já receberam os binários, não aumentariam preocupações.
Nesta situação, no entanto, isso completa o que parece ser uma plano de uma década da Red Hat para maximizar o nível de dificuldade de aqueles na comunidade que desejam “confiar, mas verificar” que o RHEL está em conformidade com os acordos GPL. Ou seja, a Red Hat frustrou gravemente esforços de entidades como Rocky Linux e Alma Linux . Essas entidades são de fato os sucessores intelectuais de Projeto CentOS Linux que a Red Hat desmontou cuidadosamente na última década. Essas organizações procuraram construir distribuições baseadas em Linux que espelhassem os lançamentos RHEL, e agora não está claro se eles podem fazer isso de forma eficaz, já que a Red Hat, sem dúvida, se recusará caprichosamente a vender a eles exatamente um serviço RHEL e atualizar a “licença por estação” a um preço razoável. Parece que, a partir desta semana, é preciso ter pelo menos isso para obter acesso oportuno as fobtes RHEL.
Devido a esse mau comportamento contínuo da Red Hat da IBM, a situação torna-se cada vez mais complexa e difíceis de enfrentar. Nenhum terceiro pode monitorar efetivamente a conformidade do RHEL com os acordos GPL, uma vez que os clientes vivem com medo de perder seus tão necessários contratos de serviço. O Departamento jurídico da Red Hat recusou sistematicamente os pedidos da SFC nos últimos anos para estabelecer alguns forma de monitoramento pelo SFC. (Por exemplo, pedimos para revisar o treinamento materiais e documentos que os vendedores da RHEL recebem para convencer clientes a comprar RHEL, e a Red Hat não está disposta a compartilhar esses materiais conosco.) No entanto, uma vez que o SFC atua como o cão de guarda global para Conformidade com a GPL, recebemos relatórios de violações relacionadas ao RHEL.
Finalmente expressamos nossa tristeza por este longo caminho ter levado a comunidade FOSS a um lugar tão decepcionante. Lembro-me pessoalmente de estar com Erik Troan em um estande da Red Hat em uma conferência USENIX no final dos anos 1990 e conhecendo Bob Young na mesma época. Ambos expressaram o quanto gostariam de construir uma empresa que respeitasse, colaborasse, se envolvesse e, acima de tudo, fosse tratado como igual para todo o espectro de indivíduos, amadores e pequenas empresas que fazem o pluralidade da comunidade FOSS. Esperamos que o a Red Hat moderna passa encontrar seu caminho de volta para esta missão sob o controle da IBM.
O que é exatamente o modelo de negócios do RHEL?
A maneira mais concisa e concisa de descrever o modelo de negócios do RHEL é: “se você exercer seus direitos sob a GPL, seu dinheiro não é bom aqui". Especificamente, o Red Hat da IBM oferece cópias do RHEL para seus clientes, e cada cópia vem com um suporte e atualização automática em um contrato de assinatura. Como entendemos, este contrato afirma claramente que os termos não pretendem contradizer quaisquer direitos de cópia, modificação, redistribuir e/ou reinstalar o software quantas vezes e em quantos lugares como o cliente gosta (ver §1.4). Além disso, porém, o contrato indica que se o cliente se envolver nessas atividades, a Red Hat se reserva o direito de cancelar esse contrato e não fazer mais contratos com o cliente para suporte e serviços de atualização. Em essência, a Red Hat exige que seus clientes escolher entre (a) sua liberdade e direitos de software e (b) permanecer um cliente Red Hat. Em algumas versões desses contratos que analisamos, a Red Hat ainda se reserva o direito de “avaliar” um cliente (efetivamente um BSA -estilo de auditoria) para examinar como muitas cópias do RHEL estão realmente instaladas (consulte §10) — presumivelmente para o propósito da Red Hat obter as informações necessárias para decidir se deve “demitir” o cliente.
Os advogados da Red Hat claramente assumem a posição de que este modelo de negócios está em conformidade com a GPL (embora não tenhamos tanta certeza), alegando que nada nos acordos GPL exige que uma entidade deve manter uma relação comercial com qualquer outra entidade. Eles argumentaram ainda que tais negócios relacionamentos podem ser encerrados com base em qualquer comportamento - incluindo exercendo direitos garantidos pelos acordos GPL. Se essa análise está correta é uma questão de intenso debate, e provavelmente apenas um caso no tribunal que contestasse esta questão em particular produziria uma resposta definitiva sobre se esse comportamento desagradável é permitido (ou não) sob os acordos GPL. Os debates continuam, ainda hoje, nos círculos de especialistas em copyleft, se esso modelo em si viola a GPL. Não há, porém, dúvidas de que este disposição não está no espírito dos acordos GPL. O modelo de negócio RHEL é hostil, capcioso, caprichoso e digno de vergonha.
Além disso, este modelo de negócios RHEL permanece, até onde sabemos, único na indústria no setor de software. A Red Hat da IBM definitivamente merece crédito por tão cuidadosamente construir seu modelo de negócios de tal forma que passou a maior parte das últimas duas décadas em território obscuro de “provavelmente não violar a GPL”.
O modelo de negócios RHEL viola os acordos GPL?
Talvez o maior problema com um modelo de negócios obscuro que contorna o linha de conformidade GPL é que as violações podem acontecer e acontecem - desde mesmo um pequeno desvio do modelo de negócios que claramente viola a GPL. Pré-IBM, a Red Hat merece uma certa quantidade de crédito, como a SFC ciente de apenas dois incidentes documentados de violações da GPL que ocorreu desde 2006 em relação ao modelo de negócios RHEL. Nós decidimos compartilhar alguns detalhes gerais dessas violações para fins de explicar onde esse modelo de negócios pode ultrapassar os limites com tanta facilidade.
Na primeira violação, uma grande empresa da Fortune 500 (que vamos chamar de Empresa A ), que usaram o RHEL internamente e também construíram produtos baseados em Linux voltados para o público, decidiu criar um produto (que chamaremos de Produto P ) baseado principalmente no CentOS Linux, mas P incluiu alguns pacotes construídos a partir de fontes RHEL. Empresa A não procurou nem solicitou serviços de suporte ou atualização para este separado Produto P. A Red Hat mais tarde tomou conhecimento de que o Produto P continha alguma parte do RHEL, e a Red Hat exigiu pagamentos de royalties pelo produto P. A Red Hat ameaçou revogar o suporte e atualizações de serviços nos servidores RHEL internos da Empresa A se tais royalties fossem pagos.
Como a Empresa A era poderosa e tinha bons advogados e equipe de desenvolvimento de negócios, eles não concordaram. Empresa A em última análise continuou (até onde sabemos) como cliente RHEL para seus servidores e continuou vendendo o Produto P sem pagamento de royalties. No entanto, um a demanda por royalties para distribuição é claramente uma violação, pois essa demanda cria um “restrição adicional” nas permissões concedidas pela GPL. Como declarado na GPLv3:
A Red Hat tentou impor uma restrição adicional nesta situação e, portanto, violou a GPL. A violação foi resolvida, pois nenhum royalty foi pago e a Empresa A não enfrentou consequências. A SFC soube do incidente mais tarde, e informou a Red Hat que a demanda anterior de royalties foi uma violação. A Red Hat não contestou nem concordou que era uma violação e concordou informalmente tais exigências não seriam feitas no futuro.
Em outro incidente de violação, descobrimos que a Red Hat, em um determinado país fora dos EUA, estava exigindo que qualquer cliente que diminuísse o número de máquinas RHEL sob contrato de serviço com a Red Hat assinam um acordo adicional. Este acordo adicional prometia que o cliente deletaria todas as cópias do RHEL em toda a organização, exceto o cópias do RHEL atualmente contratadas para serviço com a Red Hat. Novamente, esta é uma “restrição adicional”. Os acordos GPL dão a todos o direito irrestrito de fazer e manter tantas cópias do software como quiserem, e um distribuidor de software GPL pode não exigir de um usuário atestar que excluiu essas cópias legítimas e licenciadas de software licenciado por terceiros sob a GPL. A SFC informou o departamento jurídico da Red Hat desta violação, e nos foi assegurado que este acordo adicional não ser apresentado a qualquer cliente da Red Hat no futuro.
Em ambas as situações, nós da SFC estávamos preocupados que eles fossem apenas um “ponta do proverbial do iceberg”. Durante anos, ouvimos de clientes da Red Hat que eles estavam realmente confusos. É comum na indústria falar sobre “licenças por estação RHEL” e muitos especialistas em aquisições de software do setor não estão cientes das nuances do modelo de negócios RHEL e não entendem seus direitos. Nós permanecemos muito preocupado com o fato de os vendedores da RHEL confundirem propositalmente os clientes para vender mais “licenças por estação”. Muitas vezes nos leva a perguntar: “Se uma licença violação GPL acontece no mato, e todos os envolvidos não ouvem, como alguém sabe que os direitos de software foram de fato pisoteados naquelas matas?”. Assim como fazemos com o maior número possível de relatórios de violação da GPL, perseguimos zelosamente as violações da GPL relacionadas ao RHEL que são relatados para nós, e se você estiver ciente de um, por favor envie- nos um e-mail para compliance@sfconservancy.org imediatamente. Tememos que seja por incompetência ou malícia, muitos vendedores e empresários profissionais de desenvolvimento da RHEL podem violar regularmente a GPL e ninguém sabe isto. Dito isso, o modelo de negócios conforme descrito pelo Red Hat da IBM pode estar em conformidade com a GPL - é tão obscuro que qualquer ajuste para o modelo em qualquer direção parece definitivamente violar, em nossa experiência.
Além disso, a Red Hat explora o clássico “caveat emptor” abordagem - popular em muitos negócios obscuros ao longo da história. Enquanto, tecnicamente falando, um leitor cuidadoso dos acordos GPL e RHEL entende a barganha que está fazendo, suspeitamos que a maioria das pequenas empresas simplesmente não tem a perspicácia e o conhecimento de licenciamento da FOSS para realmente entender aquele negócio.
Por que um CentOS independente era tão importante?
Até “aquisição” do CentOS pela Red Hat no início de 2014 , CentOS forneceu um excelente contrapeso para os problemas com o modelo de negócios RHEL. Especificamente, o CentOS era um projeto voltado para a comunidade, com muitos voluntários, apoiados por algum envolvimento de pequenos negócios, para recriar versões do RHEL usando as fontes feitas para o RHEL. Nossa visão pré-2014 era que o CentOS era o “canário em a mina de carvão escura” do negócio RHEL. Se o CentOS parecia vibrante, utilizável e uma alternativa viável ao RHEL para aqueles que não queriam adquirir as atualizações e serviços da Red Hat, a comunidade poderia ficar tranquila. Mesmo que houvesse violações da GPL pela Red Hat no RHEL, a vitalidade do CentOS asseguraria de que tais violações estavam tendo apenas um pequeno impacto negativo sobre a comunidade FOSS em torno da base de código do RHEL.
A Red Hat, no entanto, aparentemente sabia que essa comunidade vibrante estava cortando em seus lucros. A partir de 2013, a Red Hat iniciou uma série de ações que aumentaram sua aderência. Primeiro, eles “adquiriram” o CentOS. Isso foi inicialmente formulado como um acordo de cooperação, mas a Red Hat fez ofertas de trabalho sistematicamente aos principais voluntários do CentOS que não podiam recusar, adquiriu as pequenas empresas que podiam transformar o CentOS em um produto e, de outra forma, integrou o CentOS nas próprias operações da Red Hat.
Depois que a IBM adquiriu a Red Hat, a situação piorou. Tendo obtido direitos à marca CentOS como parte da “aquisição”, a Red Hat lentamente começou a mudar o que era o CentOS. O CentOS Linux rapidamente deixou de ser um check-and-balance no RHEL e acabou de se tornar um campo de testes para o RHEL. Então, em 2020, quando a maioria de nós estava distraída com o pior da pandemia do COVID-19, a Red Hat encerrou unilateralmente todo o desenvolvimento do CentOS Linux. Mais tarde (durante a parte da variante Delta da pandemia no final de 2021) a Red Hat encerrou o CentOS Linux inteiramente .IBM Red Hat então usou o nome “CentOS Stream” para se referir a pacotes de origem relacionados ao RHEL. Estes não eram (e não são) realmente o RHEL originalmente - em vez disso, eles parecem ser principalmente um teste base para o que pode aparecer no RHEL mais tarde.
Finalmente, a Red Hat anunciou há dois dias que as fontes do RHEL não estariam mais disponíveis publicamente. Agora, para ser claro, os acordos GPL não obrigam a Red Hat a fazer sua fontes publicamente disponível para todos. Este é um equívoco comum sobre os requistiso GPL. Embora os detalhes do provisionamento das fontes variem em diferentes versões dos acordos GPL, o princípio geral é que as fontes precisa ser fornecidas junto com as distribuições binárias para aqueles que receberem, ou (b) para aqueles que solicitarem de acordo com uma oferta por escrito para a fonte. Numa situação normal, sem atenuantes, o fato de uma empresa passou de distribuir fontes publicamente para todos para apenas darem para clientes que já receberam os binários, não aumentariam preocupações.
Nesta situação, no entanto, isso completa o que parece ser uma plano de uma década da Red Hat para maximizar o nível de dificuldade de aqueles na comunidade que desejam “confiar, mas verificar” que o RHEL está em conformidade com os acordos GPL. Ou seja, a Red Hat frustrou gravemente esforços de entidades como Rocky Linux e Alma Linux . Essas entidades são de fato os sucessores intelectuais de Projeto CentOS Linux que a Red Hat desmontou cuidadosamente na última década. Essas organizações procuraram construir distribuições baseadas em Linux que espelhassem os lançamentos RHEL, e agora não está claro se eles podem fazer isso de forma eficaz, já que a Red Hat, sem dúvida, se recusará caprichosamente a vender a eles exatamente um serviço RHEL e atualizar a “licença por estação” a um preço razoável. Parece que, a partir desta semana, é preciso ter pelo menos isso para obter acesso oportuno as fobtes RHEL.
O que aqueles que se preocupam com os direitos de software devem fazer sobre o RHEL?
Devido a esse mau comportamento contínuo da Red Hat da IBM, a situação torna-se cada vez mais complexa e difíceis de enfrentar. Nenhum terceiro pode monitorar efetivamente a conformidade do RHEL com os acordos GPL, uma vez que os clientes vivem com medo de perder seus tão necessários contratos de serviço. O Departamento jurídico da Red Hat recusou sistematicamente os pedidos da SFC nos últimos anos para estabelecer alguns forma de monitoramento pelo SFC. (Por exemplo, pedimos para revisar o treinamento materiais e documentos que os vendedores da RHEL recebem para convencer clientes a comprar RHEL, e a Red Hat não está disposta a compartilhar esses materiais conosco.) No entanto, uma vez que o SFC atua como o cão de guarda global para Conformidade com a GPL, recebemos relatórios de violações relacionadas ao RHEL.
Finalmente expressamos nossa tristeza por este longo caminho ter levado a comunidade FOSS a um lugar tão decepcionante. Lembro-me pessoalmente de estar com Erik Troan em um estande da Red Hat em uma conferência USENIX no final dos anos 1990 e conhecendo Bob Young na mesma época. Ambos expressaram o quanto gostariam de construir uma empresa que respeitasse, colaborasse, se envolvesse e, acima de tudo, fosse tratado como igual para todo o espectro de indivíduos, amadores e pequenas empresas que fazem o pluralidade da comunidade FOSS. Esperamos que o a Red Hat moderna passa encontrar seu caminho de volta para esta missão sob o controle da IBM.
Olá amigos, um bom dia a todos! Faz meses que não utilizo alguma distribuição linux, acho que já tem mais de ano já, mas com a instabilidade do windows 11, provocada pela própris ms, acho que está na hora de ter pelo menos um dual boot, para me manter seguro e quem sabe, ficar em definitivo no linux por completo.
Só que hoje, não faço ideia de como andam as coisas na comunidade, não sei que distro é melhor e etc. Sempre gostei de distro que usasse o ubuntu, pela alta compatibilidade, mas vejo que isso não tem mais revelia hoje, visto que todas as outras opções estão boas ou até melhores que ele.
Dessa vez, vou focar em apenas uma, estudar sobre a mesma para aprender o máximo, não quero ficar pulando de distro e distro como antes, certeza que por causa desse comportamento que deixei o linux de lado. Uma distro que sempre me chamou a atenção e está em destaque ultimamente pelas polêmicas é o fedora, gosto do sistema deles.
Ontem descobri por acaso a versão Nobara, versão personalizada pelo Glorious Eggroll, gostei demais dela, pelo fato dela ser uma versão mais amigável do fedora para iniciantes, seria uma boa para mim, que quer focar o máximo na distro em aprendizagem. O mais legal dela, que me beneficiaria e muito é o foco em jogos, creio que ela deve ser excelente nisso. Lembro dos vídeos dele sobre arch, as configurações que ele fazia para o arch era top demais, pra jogos ficava excelente, lembro que ele focava muito em dxvk no arch, esse build personalizada dele do fedora é muito melhor que na época do arch.
Na opinião de vcs, valeria o teste em usar o Nobara em um dual com o windows 11? Se não, que distros vcs recomendam para mim, que estou a muito tempo distante desse mundo? E na criação de dual com o windows 11, como seria a instalação do mesmo? A questão de secure boot, o fedora iria funcionar sem problemas com ele ativo?
A parte do tpm, teria problemas no fedora? Desculpa pelas perguntas, mas queria saber dessas informações antes de tentar uma instalação, pois não quero remover o windows 11 por completo, pelo menos até ter uma certa habilidade em usar sem problemas o fedora, aí sim, posso removê-lo sem problema algum. No meu caso que possuo vga nvidia, teria problemas com isso, na questão de drivers? O fedora silverblue seria uma boa opção para mim, que busco estabilidade no sistema?
Fora o fedora, o outro sistema que me interessa é o opensuse, gosto do estilo dele, mas não tenho conhecimento sobre suas principais funcionalidades e ferramentas. Seria um sistema indicado para mim também?
Só que hoje, não faço ideia de como andam as coisas na comunidade, não sei que distro é melhor e etc. Sempre gostei de distro que usasse o ubuntu, pela alta compatibilidade, mas vejo que isso não tem mais revelia hoje, visto que todas as outras opções estão boas ou até melhores que ele.
Dessa vez, vou focar em apenas uma, estudar sobre a mesma para aprender o máximo, não quero ficar pulando de distro e distro como antes, certeza que por causa desse comportamento que deixei o linux de lado. Uma distro que sempre me chamou a atenção e está em destaque ultimamente pelas polêmicas é o fedora, gosto do sistema deles.
Ontem descobri por acaso a versão Nobara, versão personalizada pelo Glorious Eggroll, gostei demais dela, pelo fato dela ser uma versão mais amigável do fedora para iniciantes, seria uma boa para mim, que quer focar o máximo na distro em aprendizagem. O mais legal dela, que me beneficiaria e muito é o foco em jogos, creio que ela deve ser excelente nisso. Lembro dos vídeos dele sobre arch, as configurações que ele fazia para o arch era top demais, pra jogos ficava excelente, lembro que ele focava muito em dxvk no arch, esse build personalizada dele do fedora é muito melhor que na época do arch.
Na opinião de vcs, valeria o teste em usar o Nobara em um dual com o windows 11? Se não, que distros vcs recomendam para mim, que estou a muito tempo distante desse mundo? E na criação de dual com o windows 11, como seria a instalação do mesmo? A questão de secure boot, o fedora iria funcionar sem problemas com ele ativo?
A parte do tpm, teria problemas no fedora? Desculpa pelas perguntas, mas queria saber dessas informações antes de tentar uma instalação, pois não quero remover o windows 11 por completo, pelo menos até ter uma certa habilidade em usar sem problemas o fedora, aí sim, posso removê-lo sem problema algum. No meu caso que possuo vga nvidia, teria problemas com isso, na questão de drivers? O fedora silverblue seria uma boa opção para mim, que busco estabilidade no sistema?
Fora o fedora, o outro sistema que me interessa é o opensuse, gosto do estilo dele, mas não tenho conhecimento sobre suas principais funcionalidades e ferramentas. Seria um sistema indicado para mim também?
Última edição:
Uso ubuntu, achei ele melhor pra desenvolvimento (tive problema com fedora), alem de ser muito usado na nuvem, o que torna mais fácil pra quem trabalha na nuvem.
Em relação a jogos, não existe concorrente pro windows. Se tua jogatina se resume a poucos jogos, e esses rodam nativamente no linux, então está de boa. Mas quem gosta de sempre estar testando e jogando coisas novas, o windows é a melhor opção.
Por isso não pretendo remover o windows de primeiro momento, vou ficar também de olho nas promoções e adquirir um novo ssd de pelo menos 240gb para o linux, assim mantenho os dois, cada um em seu disco.
Se o silverblue não fosse tão complicado utilizar em dual boot, eu iria escolher ele, a forma como ele é feito daria certo no meu uso do dia a dia, mas não quero danificar a instalação do windows. Já tentei usar o ubuntu algumas vezes, mas não gosto dele, não sei explicar o motivo disso.
Qual o problema do silverblue? Geralmente dual boot é praticamente igual em qualquer distro.
Diferente da workstation, aparentemente ele não funciona corretamente em dual boot, pelo que entendi no que estava escrito no faq deles. Um dos motivos é por causa da partição efi que o windows cria ser pequena demais e também dele criar cópias do sistema constantes, parece que mexe na partição efi entre outros, não sei explicar direito sobre isso, mas isso causa atritos no dual.
Pelo que pesquisei até dar para fazer dual, mas é complicado demais para mim e o risco de perda de dados era enorme, por isso não tentei arriscar ainda. Se fosse que nem o workstation era fácil, mas com a silverblue não sei fazer o procedimento manualmente de instalação.
Achei interessante esse silverblue, esse conceito de toolbx parece legal.
Processors - eLinux.org
Sobre compilar:
Você pode também usar distros prontas, quase todas elas tem uma versão ARM.
Arch Linux ARM
archlinuxarm.org
Ubuntu for ARM | Download | Ubuntu
Download Ubuntu Server for ARM with support for the very latest ARM-based server systems powered by certified 64-bit processors.
ubuntu.com
Architectures/ARM - Fedora Project Wiki
Portal:Arm - openSUSE Wiki
en.opensuse.org
Accelerating deployment of Arm-based solutions
The collaboration platform for the Arm partnership. Where members can collaborate on Arm Open Source Software and solutions are discussed & worked upon.
www.linaro.org
Tizen | An open source, standards-based software platform for multiple device categories.
An open source, standards-based software platform for multiple device categories, including smartphones, tablets, TVs, netbooks and automotive infotainment platforms.
Se quiser facilitar sua vida, usa algo como o buildroot e só seleciona a plataforma para qual vc quer compilar.
vou dar uma olhada nele
mais tem a lista de suporte ?
Só olhar no kernel na basta de device trees quais as plataformas suportadas:
linux/arch/arm64/boot/dts at master · torvalds/linux
Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
github.com
Fala pessoal, estou com um pequeno e "invisivel" problema, instalei o PPSSPP via flatpak e tá acontecendo uma coisa estranha na placa de som, que causa reverberação e "eco" no som mais distorção, só quando abro o emulador de PSP que isso acontece, fora isso pra mídia, músicas e filmes fica tudo ok.
Engraçado que estou usando uma placa Nvidia antiguinha, mas está tudo ok com o sistema como um todo, muito chato isso acontecer.
Falei a placa pois estou usando HDMI em uma TV.
O negócio é tão chato que até as outras mídias ficam reverberando quando abro o app...
Engraçado que estou usando uma placa Nvidia antiguinha, mas está tudo ok com o sistema como um todo, muito chato isso acontecer.
--- Post duplo é unido automaticamente: ---
Falei a placa pois estou usando HDMI em uma TV.
O negócio é tão chato que até as outras mídias ficam reverberando quando abro o app...
Tudo certo pessoal! Atualizamos os filtros, quem puder testar e passar aqui a experiencia como foi, se funcionou, acha que as indicações fazem sentido, essa é uma V2, a ideia é sempre aprimorar. Vejam e me digam, obg! https://meulinux.com.br/descubra/
Opa, bom dia!!
Grande iniciativa, parece a calculadora de energia pra te indicar a fonte(PSU) ideal para seu PC, mas ainda tem uns detalhes pra trabalhar, agradeço a oportunidade e fico aqui aguardando as novidades, sucesso e votos de prosperidade.
Grande iniciativa, parece a calculadora de energia pra te indicar a fonte(PSU) ideal para seu PC, mas ainda tem uns detalhes pra trabalhar, agradeço a oportunidade e fico aqui aguardando as novidades, sucesso e votos de prosperidade.
É bem isso @Tiago Flanker sei que o desafio é grande pela frente, mas dei o primeiro passo hehehe Valeu pelo incentivo! tmj
Rapaz, bem bacana essa sua calculadora. A cada seleção feita, ela realmente fornece versões que, possivelmente, se encaixam/atendem melhor dentro dos parâmetros. Continuem sempre melhorando
A propósito, sobre a distro POP_OS, a System76 vem falando do update dela pra COSMIC DE em Rust já tem um tempo. Ancioso ao máximo pra testar a "criança" e vocês, quais as expectativas sobre?
Última edição:
Obrigado pelo feedback @MetaliumSP ajuda bastante!! Sobre o Cosmic DE em Rust no Pop, estamos na mesma ehehehe a expectativa por aqui ta grande tbm. No geral estamos tendo boas movimentações no mundo Linux nos ultimos tempos, a polemica da red hat, o steam os liderando, System 76 investindo forte, windows abrindo para linux, softwares cada vez mais multiplataforma (Davince, Figma, Steam...) tô gostando.
Eu mantenho as expectativas baixas, porque eles estão basicamente reescrevendo o Gnome em Rust. Quero ver em ação, o problema é que dificilmente um desenvolvedor vai fazer algo pensando na interface deles, vai ser GTK ou QT, principalmente esse último por ser multiplataforma bem abrangente.
Fora que não gosto da arrogância dos desenvolvedores, inclusive já tretei com um deles no Reddit. Eles são do tipo que não aceitam bem serem confrontados.
Fora que não gosto da arrogância dos desenvolvedores, inclusive já tretei com um deles no Reddit. Eles são do tipo que não aceitam bem serem confrontados.
Obrigado pelas repostas, amigos.
Compartilho de suas visões sobre o tema. Gosto mesmo é de testar várias distros e me familiarizar com suas nuances. Aprender um pouquinho com cada distro, sabem?
Esse lance de devs arrogantes, infelizmente, existe em todas as áreas e prefiro deixar isso de lado pra não me estressar.
Vamos torcer para que com a entrada do SteamOS, os "olhos" se voltam cada vez mais pro mundo Linux e que avanços significativos sejam feitos.
Novamente, obrigado pela atenção e respostas.
Sempre em frente"Tux"
Grande abraço.
Pessoal qual distro é boa para jogos?
Vejo sempre recomendações do POP OS
outra tem como instalar linux sem ter que mexer no boot do win10?
Tipo uma instalação isolada uma da outra.
Vejo sempre recomendações do POP OS
outra tem como instalar linux sem ter que mexer no boot do win10?
Tipo uma instalação isolada uma da outra.
Cara seria bom você ter um hdd ou um ssd só pra isso, e desligar o disco do Windows quando for instalar o linux
Não tem diferença de performance entre as distros, vai do seu conhecimento sobre elas. O Pop_OS é recomendado por já ter várias ferramentas embutidas, que agilizam o processo.