Mostrando postagens classificadas por relevância para a consulta fork. Ordenar por data Mostrar todas as postagens
Mostrando postagens classificadas por relevância para a consulta fork. Ordenar por data Mostrar todas as postagens

O que são forks?

/*Como mencionei no meu ultimo artigo sobre os BSDs, que cada um deles surgiram de alguma forma como fork, surge então a questão: E o que são forks afinal de contas?*/

 Forks são softwares que originam de projetos já existentes dando origem a outros da mesma ramificação.  
 Para melhor compreensão, Digamos assim como as distribuições Linux, em que uma distribuição deriva da outra (o Ubuntu deriva do Debian, CentOS deriva do Red Hat Interprise Linux por exemplo) assim é inicialmente com um fork. Mas diferente de uma distribuição (onde o Ubuntu sempre derivará da próxima versão do Debian e o CentOS da próxima versão do RHIL) em um fork isso ocorre somente na sua primeira versão, pois já nos seus próximos lançamentos serão independentes do software a qual se originou, já não vindo obrigatoriamente a ter mais algum vinculo com o projeto ou a comunidade de origem. Logo, o fork só deriva do projeto original na sua primeira versão.


Essa é a ideia de um fork: O(s) desenvolvedor(es) pega(m) a cópia do código fonte do software e inicia(m) um projeto independente em cima do que obtiveram, vindo a criar um software separado. Desta forma existem dois projetos semelhantes em propósito, porém, cada um possuindo certas características próprias.


O sentido etimológico da palavra Fork (pronuncia-se /fɔːk/ em inglês britânica e /fɔːrk/ em inglês americano; é... deixa eu ajudar na pronuncia, pronuncia-se fôrk com um "r" quase mudo em inglês britânico e fôrk com um "r" mais acentuado em inglês americano), que pode ser confundido com a palavra inglesa garfo (talvez foi por isso que a equipe do Devuan usou um garfo como simbolo do sistema),
 significa “dividir em ramos, ir por caminhos separados”.
Dentro do ambiente de software existem também forks, onde se invoca uma chamada fork do sistema para que um processo em execução se divida em duas copias (quase) idênticas que se separam para realizar tarefas diferentes.


Os motivos pelas quais existem os forks são vários: Dar continuidade a um projeto que já não existe mais, desavença entre as comunidades, iniciar um novo projeto (porém a partir de um já existente, proporcionando produtividade assim), implementações que foram recusadas, vaidade e sei la o que mais. Esse processo (onde um grupo de desenvolvedores de desentendem com os planos de desenvolvimento do software e iniciam um novo projeto baseado no mesmo código fonte) é chamado de forking the project (tipo... de uma forma sátira e em um termo menos constrangedor, lascar o projeto).


Alguns projetos que podemos citar aqui como fork seriam:

  • IllumOS (e seus derivados, como o OpenIndiana. Nome mais sugestivo não tem) que originou-se do OpenSolaris após a Oracle obter a Sun Microsystem e descontinuá-lo.
  • MariaDB originou-se do MySQL que foi criado pelo próprio fundador do projeto após a Sun Microsystem ter sido adquirida pela Oracle... também... (é... tempos difíceis).
  •  X.org como fork do  XFree86 por questões de licença entre outras coisas.
  • PCLinuxOS como fork do antigo Mandrake em 2003 e depois em 2007 fork do Mandriva usando seus snapshots.
  • Mageia e o OpenMandriva como fork do Mandriva.
  • LibreSSL do OpenSSL
  • Eudev do Systemudev
  • UselessD que surgiu do systemd(que está dando dor de cabeça para todo mundo).
  • O open source também foi um fork do free software. O motivo foi o Stallman não aceitar um meio caminho pro software livre (Dando créditos a quem merece, essa foi o amigo Helio Loureiro que me forneceu).

E querem uma lista maior para isso? Consultem então a página Lista de forks em Inglês no Wikipedia (está um pouco desatualizada, mas dá para o gasto).


 Um site que permite forks é o próṕrio GitHub. Alguns exemplos que pondem notar seriam esses:
 Referências:

A polêmica história do código de conduta do Linux

Essa semana eu tratei sobre o código de conduta do kernel Linux onde exponho a minha opinião sobre o assunto. No vídeo proponho também o que poderia ser solução (bem difícil de implementar) para o futuro (talvez longínquo) mostrando casos já existentes no próprio kernel Linux e que poderiam evitar tal problema recorrente:


Porém, gostaria de debater mais dois comentários; um que li quando o CoC estava em alta e esqueci de debater e outro que recebi e achei interessante.

-O primeiro o pessoal anda falando de criar um fork do Linux para solucionar esse problema... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... É sério isso?

Ok, forks do Linux já existem como o do Facebook para utilizado para manter o foco do desenvolvimento do Btrfs e toda a melhoria alí vão para a mainline do kernel vanilla; o de Matthew Garrett que já foi desenvolvedor do kernel Linux e, após sair do desenvolvimento, decidiu criar um fork para manter um patch que adiciona suporte em nível de segurança estilo BSD; o da FortiNet chamado FortiOS e muitos outros. Além de já existirem forks, do que adiantaria criar fork (ou forks) do linux se o código dos mesmos desenvolvedores estarão lá? Eles irão requerer seu código até mesmo do(s) fork(s) por se tratar exatamente do mesmo código (e logo, propriedade deles)... Iriam cair no mesmo paradigma dos BSDs que mencionei...

O segundo trata-se de uma pergunta; se a GPL não foi adotada pensando no modelo de desenvolvimento bazar. A verdade é que a GPL não implica em nada em modelo de desenvolvimento nenhum; ou seja, não tendo nada a ver com o modelo de desenvolvimento Bazar do livro "A Catedral e o Bazar" de Eric S. Raymond".  Os próprios modelos catedral e bazar são coisas muito além do GNU. Você pode adotar qualquer outra licença e seguir o modelo de desenvolvimento que você preferir. Provas disso são que:
  1. O modelo bazar já era adotado no Linux quando Linux ainda estava sob a licença da convenção de berna do século XIX (que foi a primeira licença adotada no Linux).  
  2. O próprio micro kernel GNU Mach do GNU está sob GPL e a comunidade GNU segue o modelo catedral (e não o modelo bazar ;)
Por hora é só pessoal, um abraço e FALOWSSSS...

Lançado Unleashed 1.3

illumOS
illumOS ganha um fork
 Unleashed é um fork do sistema operacional illumOS (e sendo o illumOS um fork do Open Solaris e por sua vez, um derivado do Solaris). O meu primeiro vídeo no canal eu relatei um pouco sobre o Open Solaris já que havia ouvido pessoas dizendo que se tratava de uma distribuição Linux. Caso não saiba o que é um fork, eu tenho um artigo aqui no blog que pode conferir e entender melhor, basta clicar aqui ;)

 Automaticamente o Unleashed herda as características do Open Solaris como o ZFS, o DTrace e o Crossbow e vários outros recursos que podem ser conferidos clicando aqui. Veja aqui meu antigo vídeo sobre o Open Solaris.


 Existem vários em torno de oito distribuições derivadas do illumOS; cada um desses destinado a soluções diferentes como Workstation, servidores, storagesHypervisorA lista de distribuições derivadas do illumOS que podem ser conferidas clicando aqui ou visualizando a imagem abaixo.
Distribuições derivadas do illumOS
Distribuições derivadas do illumOS
 Esse fork surgiu pela comunidade acreditar que poderia fazer melhor do que os derivados do illumOS adotando uma postura diferente em relação à compatibilidade e redução de interações de códigos, buscando modernizar o sistema operacional através da remoção de código legado. Com isso, apesar de um descendente do Solaris, o Unleased torna-se binariamente incompatível com o Solaris por removerem um monte de partes (digamos) sujas.

 A comunidade quer adotar um ambiente de compilação diferente já que do illumOS é antigo. Querem que o ./configure seja o suficiente para a maioria dos programas (sem ser necessário ficar especificando flags ou lincar bibliotecas adicionais).
sendo o 
Curso Linux: Da migração a administração do sistema operacional
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
 Essa é uma comunidades sendo totalmente Open Source (não pretendem ter binários proprietários e nem blobs no sistema operacional), com uma liderança limpa, um sistema operacional completo, com lançamentos periódicos (um a cada três meses com patches de segurança entre os lançamentos),


Como Facebook utiliza Linux e o Btrfs: Uma entrevista com Chris Mason

Chris Mason

Aprenda o estado de desenvolvimento do Btrfs nessa entrevista com o principal autor, Chris Mason.

POLEMICA - Linux ou BSD? Qual o melhor?

Linux ou FreeBSD?
Linux e FreeBSD e não Linux VS FreeBSD

    A verdade é que não há melhor ou pior! Cada um é bom nas áreas em que se especializaram ou que atuam (nada impedindo-os que cada um as ampliem).

    Recentemente postaram em um grupo em uma rede social tal pergunta, então peguei exatamente este título escrito na rede social e resolvi fazer uma analise sobre os BSDs para poder responder sobre o assunto, pois não somos xiitas ao ponto de não utilizar e/ou testar outros sistemas operacionais (mas talvez não seja um assunto que eu queira mais abordar. Quero focar mais em Linux desde que já expliquei sobre esse assunto anteriormente no artigo sobre as diferenças entre os dois sistemas que traduzi do distrowatch). Alias, uma das qualidades que Linux proporciona aos seus usuários é o amplo conhecimento (mais uma das liberdades que existem dentro do mundo Linux e que muitos exploram pouco): Outras arquiteturas, que dentro do próprio kernel é possível notar quantas arquiteturas são suportadas (e tem gente ainda achando que Linux só é para servidores ou que só exista x86...), outros filesystems (por que para técnico em Windows é assim, tudo para eles é partição: Partição FAT, partição NTFS... Conhecimento proporcional = 0; por que partições e filesystems são coisas totalmente diferentes), outros sistemas operacionais, outras licenças.

Arquiteturas dentro do kernel Linux.
Arquiteturas dentro do kernel Linux

Filesystem no kernel Linux.
Filesystem no kernel Linux.

    Não vou narrar aqui a história do BSD, por que já a abordei inesperadamente no vídeo "Não viva de boatos"; aconselho a dar uma olhadinha logo abaixo:



    Mas uma coisa que vale a pena mencionar é que BSD é o nome dos sistemas derivados desta família, da licença e do próprio layout criado para o BSD. Layout B

Layout BSD no Porteus

   Já que teve gente quem criticasse a imagem que aqui utilizei do Porteus Linux para mostrar o Layout BSD (que no Layout SystemV é diferente, utilizando /etc/init.d/serviço) fazendo a afirmação de que eu mencionei que o runlevels do BSDs vão de 0-6 (o que não afirmei em momento algum) então estou postando hoje (lembrando, este artigo foi publicado no dia 26/02/2015 e estou inserido este parágrafo no dia 03/03/2015 ) o manual do Arch Linux que eu já havia postado no vídeo "Não viva de boatos" logo acima, pois assim como o Slackware, essa é outra distribuição que utiliza esse layout para controlar seus serviços. Caso queiram, verifiquem na página 4 para entenderem a diferença entre os dois padrões.
    De opinião própria, o que cada um oferece de melhor seria que o Linux é muito interessante na parte de multi-processamento (invejável), desempenho (invejável também) e virtualização. Enquanto os BSDs são muito bons em Firewall (o firewall do Linux, no caso o Netfilter, também é muito bom, porém os BSDs possuem o firewall mais poderoso do mundo o Package Filter).

    Assim como no mundo Linux, que possui quatro distribuições como principais (apesar que o Arch anda ganhando muita notoriedade): Slackware (forte no aprendizado de Linux bem na essência. Nesse aspecto o LFS também merece esse crédito), Debian (focado na segurança e estabilidade), Redhat (ótimo em soluções empresariais) e Gentoo (forte em otimização de desempenho); os BSDs também possuem quatro principais e cada uma delas voltada á um foco principal. Todas as demais (digamos assim) distribuições BSDs derivam dessas quatro:

Beastie
  • FreeBSD: focada em robustez e eficiência tanto para ambientes tanto de servidores quanto para desktop (hoje portado para várias arquiteturas). Seu lema é "The power to serve" (O poder para servir"). Seu mascote é um demônio chamado Beastie. Esse é o BSD mais utilizado entre todos os outros. 
  • NetBSD: Focada em rodar no maior número de plataformas possíveis tornando-o o OS mais portável do planeta; tanto que seu lema é “Of course it runs NetBSD” (É claro que roda NetBSD!). Roda em tudo essa bagaça.
  • OpenBSD: focado primariamente em segurança e nos tópicos relacionados (forte integração de segurança, criptografia a um nível TOP LEVEL. Esse é o sistema operacional mais seguro do mundo). Seu mascote é um peixe que mais parece... com... um baiacu.
  • DragonFlyBSD Com muitos conceitos inspirados do AmigaOS (que, alias, Mathhew Dillon é conhecido por criar o compilador C DICE no Amiga) e com recursos similares ao do Linux, é focado em proporcionar uma infraestrutura SMP compatível que seja fácil de entender, manter e de desenvolver. Esse foi o que mais utilizei, Então, vou basear a minha experiência nele. Gravei a imagem iso em um pendrive com um simples comando dd conforme descreve no meu manual Caixa de Ferramentas do Unix, criptografa tudo no momento da instalação (dispositivo, filesystem, home... até cansa na hora de bootar e ter que ficar digitando senha, mas garante ótima segurança), utiliza os filesystems UFS ou HAMMER (H.A.M.M.E.R foi desenvolvido pelo próprio Matt Dillon para suportar HDs de 4 teras  ou até storages acima de um exabyte e tem uma pancada de recursos), vem no caso como o FreeBSD (sem interface gráfica). Bom, gostei dele até demais. Uma coisa que Matt Dillon merece crédito foi o fato de ter descoberto bug no processador da AMD onde foi até convocado pela própria AMD para ajudar na correção de tal erro.
    Cada um desses quatro surgiram de alguma forma como fork: o FreeBSD e o NetBSD como fork do 386BSD iniciado como patchkit em 1993; depois o OpenBSD como fork do NetBSD em 1995 devido intrigas internas entre os desenvolvedores; e depois o DragonFlyBSD como fork do FreeBSD em 2003 quando o desenvolvedor do FreeBSD, Matt Dillon  entrou em desacordo com ao comunidade do FreeBSD ao propôr melhorias na parte de clustering no kernel entre outras coisas. Alias, essa é uma coisa que não concordo quando foi dito em outro artigo que traduzi sobre a definição Unix-Like onde afirmaram que os BSDs são clones do UNIX.
Principais distribuições BSD
Principais distribuições BSD

    Os BSDs estão sob a licença chamada... BSD em que reza mais ou menos o seguinte: "Do whatever the hell you want with the code, just give us credit for writing it" (Faça seja o que for que quiser fazer com o código, dê-nos apenas crédito por escrevê-lo). Caso queiram saber mais sobre a diferença entre as licenças, sugiro a leitura do artigo "Definição sobre software livre".

    Todos os BSDs se preocupam com segurança (apesar que cada um tem um nível diferente do outro). Muitos desenvolvedores trabalham em mais de  um sistema.

Diferença de segurança entre OpenBSD e FreeBSD
Diferença de segurança entre OpenBSD e FreeBSD



    Os BSDs possuem uma família de grande também (alguns descontinuados, outros forks e assim segue) que podem ser acompanhados no wikipedia.
 Moral da história, é que eu acho que os dois sistemas devem sempre andar em harmonia e não ficar com diferenças que geram intrigas (não gosto dessas brigas que não levam a nada). Acho que ambos os sistemas deveriam ser mais unidos; ambos cresceriam até mais rápido ao meu ver.

Minha opinião sobre o Unity


Eu sou um péssimo usuário de Ubuntu. A primeira versão que utilizei foi o 4.10 que na época utilizava o Gnome e eu simplesmente odiava as cores do ambiente gráfico trabalhadas pela Canonical. Então, antes de fazer qualquer comentário sobre este artigo dizendo que sou defensor de Ubuntu, tenha em mente tudo isso. Mas sei que muitos inscritos no meu canal e que leem meu blog usam Ubuntu, sei que o Ubuntu não é bugado como muitos afirmam como eu mesmo fiz durante muitos anoa (inclusive são os mesmos que afirmam que Android não é Linux, não sabem que muitas distribuições incorporam patches de correções desenvolvidos pela Canonical, não sabem que muitas distribuições estão hospedadas e possuem repositórios em servidores Ubuntu e nem que o Ubuntu domina a nuvem. Boa base de estudo que tem...) e azar, é Linux também.

O Ubuntu merece respeito por ter também trazido aumentado o número de usuários e continuar trazendo ainda mais assim como fez o Kurumin, como fez o Mandriva (e faz hoje no Open Mandriva) e como faz o OpenSuse. Isso é importante.

Vários projetos da Canonical são sacrificados ao longo de sua existência, mas falando do fim do Unity (tudo bem, estou um pouco atrasado, mas quis dar minha opinião assim mesmo) que foi noticia até mesmo na BBC, com isso a Canonical também desistiu do Mir vindo a migrar para o Wayland (acho da hora esse nome).

Minha primeira exposição ao Unity que consigo me recordar foi em 2011 e me lembro de ter odiado e não voltei a vê-lo mais por um bom tempo. Na versão 14.04 do Ubuntu que me mostraram o Unity novamente, eu ate aceitei melhor, já funcionava melhor e ate me adaptei rápido porque parecia com o Gnome 3 (claro que se parecem, o Unity é um fork do Gnome 3. Foi ate uma curva de aprendizado rápido).

Com o fim do Unity, não faltou quem criticasse mas também gerou um fork do garoto (acho o máximo isso no mundo FOSS e defendo isso). Mas essa não é a unica mudança anunciada para o 18.04. Antes disso anunciaram também o fim da arquitetura de 32 bits nesta versão para desocupar sua server farm.

Bom, expondo meu ponto de vista, acho que vai ser interessante o retorno ao Gnome:
  1. Irão poupar tempo e muitos esforços no desenvolvimento focando somente nos recursos que quiserem adicionar na modificação do Gnome.
  2. Economizar recursos financeiros para serem investidos em outras partes do projeto.
  3. E a curva de aprendizado dos seus usuários não será tão difícil já que são dois ambiente parecidos. Melhor do Unity para o Gnome do que foi do Gnome para o... Gnome...

Pois é, o que chamamos hoje de Mate era exatamente o Gnome; o Mate é um fork da versão dois do Gnome. Isso pode ser conferido no meu antigo blog que na época mostrei quando foi lançado o Debian 6. Agora... do Debian 6 para o 7... Foi uma mudança radical de um ambiente gráfico para o mesmo (Incrível! não? De um ambiente gráfico... para o mesmo)
viva a liberdade da criação de forks
Então, é isso; vamos agora aguardar e ver o que acontece. Talvez seja uma mudança boa (ou talvez não); só basta esperar, acompanhar e ver o que acontece. Eu vejo essa volta para o Gnome mais como um corte de gastos (o que não é ruim) se associarmos isso ao fim da arquitetura de 32 bits no Ubuntu (que está acontecendo também no Open Suse e no Debian), o fim do Mir, o fim Ubuntu Phone e o fim do upstart em favor do systemd. Melhor contribuir com outros projetos já existentes usufruindo do que eles tem a oferecer e eles usufruírem de suas contribuições do que reinventar a roda. Isso tudo converge a um padrão.

OpenZFS abandona o termo slave em seu código

OpenZFS abandona o termo slave em seu código
OpenZFS abandona o termo slave em seu código
 Na Quarta Feira (dia 10 de Junho) o desenvolvedor Matthew Ahrens da ZFS founding enviou  a pull request para o git do projeto OpenZFS. Não se trata de um bugfix ou adição de novos recursos e sim um cleanup alterando o termo "slave" para "dependents" de todo o código do OpenZFS.

 Na request, Matthew explica que sua motivação é que o efeito horrível da escravidão humana continua a afetar a sociedade e que o termo "slave" na computação é uma referencia desnecessária para uma dolorosa experiencia humana.

Pull Request de Matthew Ahrens
Pull Request de Matthew Ahrens
 A pull requeste foi aceita e a partir de agora iremos passar a utilizar o termo deps no ZFS. Então, fica a dica para irem se adaptando ao novo termo; não é algo que vai impactar no trabalho de ninguém, não é algo que necessite toda uma curva de aprendizado, é simplesmente uma mudança de termo.

 Esse já não é o primeiro caso que vemos acontecer no mundo de software que há a iniciativa de adotar um novo termo devido o anterior ser ofensivo. Pouco antes do escândalo em que Stallman se envolveu, um grupo resolveu criar um fork do editor de imagens Gimp pelo mesmo motivo. O fork recebeu o nome de Glimpse (vislumbre) já que o nome Gimp pode referir-se a vários termos ofensivos de acordo com o site Merriam.

Site oficial do editor de imagem Glimpse
Site oficial do editor de imagem Glimpse
 Será que o Bash não vai entrar na mesma onda? Há pouco tempo anarquistas apareceram segurando placas com a frase "IT TAKES A BULLET TO BASH A FASH" (é necessário uma bala para esmagar um arrogante). Em inglês, o termo bash tem os significados pancada, bater, xingar, esmagar, surrar.

 OK, podemos até afirmar que no caso terminal, Bash é o acrônimo de Born Again Shell fazendo referencia e homenagem ao terminal Born Shell e não tem nenhuma intenção de expressar nenhumas das palavras que mencionei. Sim, é verdade, mas o Gimp também não pois seu nome é a abreviação de GNU Image Manipulation Program e anteriormente (antes de integrar o projeto GNU) era General Image Manipulation Program e mesmo assim resultou em um fork por conta de seu nome... Como diria o grande pensador contemporâneo:
Se Gimp quer dizer GNU Image Manipulation Program e GNU quer dizer GNU is Not Unix e Unix quer dizer UNiplexed Information and Computing Service for UNIX; logo, o nome Gimp quer dizer GNU is Not UNiplexed Information and Computing Service for UNIX Image Manipulation Program.
 Se tem duas outras expressões que também deveriam pensar em mudar é o nome de #! (te garanto que vai encontrar certas coisas que não estava esperando) e do comando word counter (wc, parece banheiro em inglês). Geraçãozinha viu...

CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Liberty Linux: Um novo fork do CentOS

Open Enterprise Linux Association

Liberty Linux: Um novo fork do CentOS

 Forks do CentOS já não são nenhuma novidade desde que a Red Hat anunciou o fim do seu suporte  na versão 8, o que rendeu muito pano para manga. A Red Hat anunciou o inicio do CentOS Stream onde as atualizações passariam primeiro pelo CentOS Stream para depois chegar oo Red Hat Enterprise Linux.

 Com isso, surgiram dois forks do CentOS, o Rocky Linux e o Alma Linux que passaram a ser financiados por grandes empresas que dependiam do CentOS (que basicamente o que faziam era pegar as atualizações do Red Hat Enterprise Linux e empacotar para as suas respectivas distribuições).



 Só que no dia 21 de Junho o Vice Presidente, Core Platforms Mike McGrath anunicou que o CentOS Stream será o único repositório para os lançamentos públicos do código fonte do Red Hat Enterprise Linux e derivados. OU SEJA, os dois forks já não passariam  mais a ter acesso aos patches do RHEL. Os projetos se pronunciaram sobre a decisão da Red Hat e os prolanos para o futuro. A matéria pode ser lida clicando aqui.



 Não somente os dois projetos se pronunciaram. A Oracle postou sua frustração com a decisão da Red Hat uma vez que sua distribuição, a Oracle Linux, é uma derivada do RHEL. Mas a empresa não parou por aí, a Oracle anunciou que estaria trabalhando para remediar esse problema, deixou recado aos desenvolvedores de Linux que estava contratando e por ultimo, deu um recado a IBM:

"Finalmente, para a IBM, aqui está uma grande ideia para você. Você diz que não quer pagar todos aqueles desenvolvedores RHEL? Veja como você pode economizar dinheiro: basta retirar de nós. Torne-se um distribuidor downstream do Oracle Linux. Ficaremos felizes em assumir o fardo."

 A Oracle não está errada já que grande parte da arrecadação (tanto da IBM quando da Red Hat) vem da Oracle e de seus parceiros e não somente dos seus próprios serviços (honestamente? Eu já temia que a Red Hat poderia ter mudanças não muito boas após ser adquirira pela IBM).

E não parou por aí, no dia seguinte, a Suse anunciou o investimento de $10 milhões em um fork do RHEL. Algo que para mim soou um tanto quando estranho já que eu não entendi a estratégia da empresa, mas OK, uma boa atitude.


 Formou-se então a parceria entre a CIQ (empresa que desenvolve o Rocky Linux) a Suse e a Oracle que deram origem a distribuição Liberty Linux ou também conhecida como OpenELA (Open Enterprise Linux Association) que passa a dar suporte de compatibilidade com o RHEL 8 e 9 (e possivelmente o 7) e assim dando sobrevida ao CentOS.


 O processo de migração é feito removendo o apontamento dos repositórios da Red Hat e apontando para os repositórios da Suse não sendo necessário reiniciar seu sistema mas também sendo possível desta forma.

Liberty 9 after RHEL 9 upgrade
Liberty 9 após atualização do RHEL 9

 A Suse também entregará o Suse Manager (ferramenta similar ao Satellite) para facilitar a administração do OpenLA e que permite transformar o RHEL em Liberty Linux de forma muito simples (o Suse Manager permite administrar outras distribuições). Também é possível obter assinatura de suporte da Suse com quatro planos para escolher: O Suse Liberty Lite, Suse Liberty Basic, Suse Liberty Professional e o Suse Liberty Entreprise.


Suse Liberty Linux Subscription plans
Planos de assinatura do Suse Liberty Linux


 Já existem empresas no Brasil que realizaram a migração do CentOS para o Liberty Linux. Desejo sucesso ao projeto e que tanto as empresas envolvidas quanto nós (usuários) saiamos ganhando com essa iniciativa.

Site oficial do OpeneLA

Mais sobre a Suse

Mais sobre a Oracle


Marcadores

A pior história sobre Linux que já ouvi (6) A.I (2) ambiente gráfico (19) AMD (14) analise (10) Andriod (16) android (7) Apple (1) arm (5) artigo (5) aws (1) bc (23) benchmark (6) BetrFS (1) blackhat (1) BSDs (34) btrfs (32) bugs (2) Caixa de Ferramentas do UNIX (18) canonical (1) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (33) comp (1) compressores (9) consoles (1) container (8) CPU (19) cracker (1) criptografia (5) crowdfunding (9) cursos (24) daemons (14) Debian (31) desempenho (2) desenvolvimento (104) desktop (19) DevOps (3) DevSecOps (4) dic (1) Dica de leitura (91) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (4) diocast (1) dioliunx (3) distribuições Linux (14) Docker (13) DragonflyBSD (24) driver (2) dropbear (3) ead Diolinux (2) edição de vídeo (5) embarcados (1) EMMI Linux (4) emuladores (9) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (11) filesystem (82) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (21) Funtoo Linux (13) games (95) garbage collector (1) gerenciadores de pacotes (4) glaucus (8) GOG (3) google (9) gpu (3) hacker (2) hardware (104) hash (1) helenos (3) I.A (1) init system (13) Intel (15) inteligencia artificial (2) IoT (1) ispconfig (1) jogos (39) kde (1) kernel (142) lançamento (64) leis (1) LFCS (1) libs (2) licenças (10) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (4) lkgr (1) LPI (8) LTS (1) Mac (1) machine learning (1) matemática (9) mesa redonda (27) microcontroladores (1) microsoft (6) microst (1) muito além do GNU (180) musl (3) não viva de boatos (9) navegadores (5) NetBSD (7) newlib (1) nim (12) nimlang (4) nintendo (1) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) ONLYOFFICE (5) open source (85) OpenBSD (8) OpenShift (1) oracle (1) os vários sabores de Linux (46) padrim (2) palestras e eventos (5) partições (6) pentest (8) performance (1) pipewire (1) plan9 (3) playstation (1) processadores (30) professor Augusto Manzano (11) Programação (72) promoção (1) propagandas com Linux (8) ps4 (1) real-time. (1) Red Hat (23) redes (4) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (14) RISCV (13) rtos (1) runlevel (2) rust (16) Sega (1) Sega Saturn (1) segurança digital (28) servidor web (2) servidores (3) shell (11) shell script (8) sistema operacional (25) skarnet (2) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (10) Steam no Linux (8) supercomputadores (4) suse (7) systemd (9) terminal (90) terminal de comandos (21) toca do tux (1) toybox (30) tutorial (6) Tux (3) ubuntu (1) unboxing (7) UNIX (17) UNIX Toolbox (13) vartroy (1) vga (1) virtualização (3) vulnerabilidade (7) wayland (5) web (1) whatsapp (1) whitehat (1) Windows Subsystem for Linux (2) wine (14) WoT (1) yash (1) ZFS (16) zsh (3)