Mostrando postagens com marcador kernel. Mostrar todas as postagens
Mostrando postagens com marcador kernel. Mostrar todas as postagens

Rocky Linux migrará para Hurd

Rocky Linux Project shifts focus to Rocky GNU/Hurd

Rocky Linux migrará para Hurd

 O projeto Rocky Linux anunciou que pretende migrar para o microkernel GNU Mach que conhecemos pelo nome de suas daemons, o Hurd. 

 Todos nós conhecemos o Rocky Linux e o Alma Linux que como distribuições que surgiram como substitutos ao antigo CentOS que foi descontinuado (mais detalhes sobre o CentOS Stream podem ser conferidos na minha live). Ambas as distribuições passaram a ganhar atenção e até mesmo a serem financiadas por grandes empresas (é, foi necessário acontecer o desastre para depois financiar o que já era para ser financiado...)

State packages for Enterprise Linux

Processo de criação das distribuições da família Fedora

 O Hurd por sua vez é o microkernel do projeto GNU que, além de não ter sido feito pelo próprio projeto, ainda sofre com lentidão em seu desenvolvimento. Mas parece que agora o Hurd está começando a apresentar sinais de poder ser utilizado para que ele inicialmente projeto, "um projeto grande e profissional" pois, para uma distribuição como Rocky Linux que já é utilizada em produção e que está se consolidando anunciar uma migração, é porque coisa boa pode estar vindo por aí. Recentemente eu escrevi que a equipe do Hurd está adotando o framework Rump Kernel, o que pode ter ajudado um pouco nesse processo.

 O projeto anunciou que nos próximos anos estarão trabalhando na migração do RHEL para o Hurd e passará a se chamar Rocy GNU/Hurd. Foi criado até mesmo uma FAQ para ajudá-los entender melhor como será o processo de migração.

 Bom, tudo isso parece até mesmo uma piada de primeiro de Abril, mas é mesmo kkkkkkk

Lançado bc 5.2.3

Lançado bc 5.2.3

Lançado bc 5.2.3

 Na terça Feira, Gavin Howard lançou a versão 5.2.3 da linguagem bc. Caso você ainda não conheça, a linguagem bc é uma dependência muito importante para a compilação do kernel Linux. Mas sempre faço a ressalva de que não se trata da linguagem bc do projeto GNU, e sim da versão de Gavin Howard.


 Essa versão é versão de correção de um bug na opção -f que pode ser apresentado quando se passa um arquivo com múltiplos comentários ou strings ao comando bc (bc -f <<< arquivo).

bc 5.2.3
bc -f ou bc --file=arquivo
 O procedimento de compilação e instalação pode ser conferido na própria página de download. Vale lembrar que o terminal de comandos toybox também possui a linguagem bc do Gavin, porém, o projeto toybox mantem a versão 1.0 (onde encontrei o bug de loop). É aconselhável a não utilizar nem a versão que se encontra no toybox e nem a do GNU (por conter bugs que já foi explicado na entrevista do Gavin).

Bug encontrado na linguagem bc do toybox

Framework Rump kernel do NetBSD como uma solução para o Hurd

Framework Rump kernel do NetBSD como uma solução para o Hurd

Framework Rumpkernel do NetBSD como uma solução para o Hurd

 Em fevereiro deste ano Damien Zammit apresentou no FOSDEM uma solução para o Hurd*. A ideia é adotar o framework rump kernel do NetBSD; o que não é nenhuma novidade já que o Rump kernel já está presente no Hurd desde 2015 implementando seus recursos de USB e de áudio.

 Outras fontes também estão presentes no Hurd como partes do próprio Linux como servidor de arquivos ext2fs, servidor de rede pfinet, NIC, drivers de disco e muito mais. Algumas versões possuem suporte para execução de rede Linux 2.6.xe e drivers de disco no modo de usuário através da camada de compatibilidade DDE.

 A vantagem de utilizar o Rump kernel no Hurd é que o framework traria mais drivers com uma interface estável sem a necessidade de ficar reinventando a roda e debugar processos e drivers de forma pratica. Como o Hurd é um microkernel, os recursos do Rump kernel (gerenciamento ACPI e PCI e driver) vão rodar em processos separados como servidores.

 Pode ser que o Rump kernel realmente traga vantagens ao Hurd  uma vez que o Hurd possui suporte a hardware muito limitado (até hoje limitado a i386), apresenta muitas falhas (inclusive de kernel panic com muita frequência, muito maior do que o Windows apresenta tela azul) e não há (como nunca houve) previsão de lançamento de uma versão estável que possa ser utilizado em produção.

Hurd source code

O código fonte do Hurd e suas limitações podem ser conferido clicando aqui

GNU/Hurd takes 5 minutes to boot up on a AMD ThreadRipper
Depoimento do GNU/Hurd levando 5 minutos para bootar em um AMD ThreadRipper de 48 núcleos.

 É como já mencionado por Henrik Ingo em seu livro livro Open Life escrito em 2006 e traduzido para inglês pela própria irmã do Linus, Sara Torvalds:
"Uma ironia é que o projeto GNU mencionado por Linus ainda não conseguiu concluir seu próprio ‘grande e profissional’ kernel Hurd. Todo o crédito a eles por não terem desistido, no entanto. Eu venho acompanhando o desenvolvimento do Linux de perto há meia década e durante todo esse tempo o Hurd esteve quase completo. De alguma forma, é divertido ver que a situação deles era a mesma há treze anos, quando o Linux nasceu."
 Dezessete anos depois que o livro Open Life foi escrito pela primeira vez (sua primeira edição em 2.005) e o Hurd ainda não apresenta sinais de que terá uma versão estável. Honestamente não acredito que um dia o Hurd venha a se tornar funcional (há até mesmo piadas na gringa referentes ao Hurd onde a humanidade vai entrar em extinção em 2.050 enquanto que o hurd vai ficar pronto somente depois de 2.060). Há outras versões de microkernel muito mais interessantes que o Hurd e que eu relato no meu artigo 5 diferentes modelos de kernel.

Quando o hurd ficará pronto? Quando mais ninguém precisar?
Quando o hurd ficará pronto? Quando mais ninguém precisar?

 *O nome original deste microkernel é Mach e não Hurd; Hurd é o nome do seu conjunto de daemons (incrível como brigam tanto pelo reconhecimento do nome GNU querendo forçar todos a chamar Linux de GNU/Linux mas quando se trata do nome do microkernel Mach, eles enfatizam o nome do conjunto de daemons...). O Mach não foi desenvolvido pelo projeto GNU e sim pela universidade Carnegie Mellon e trata-se do mesmo microkernel utilizado pela Apple para o desenvolvimento do MacOSX (a junção do Mach kernel com o kernel FreeBSD,  do 4.4BSDLite e do NetBSD forma-se o XNU kernel base que dá origem ao sistema operacional Darwin, ou simplesmente, o MacOSX). E assim continuam a incansável luta para um dia tentar tornar o Hurd funcional.

A junção de microkernel Mach com porções de kernel como do FreeBSD, do NetBSD e do 4.4BSDLite formam o kernel hibrido XNU, base do sistema operacional Darwin (o MacOS X)
A junção de microkernel Mach com porções de kernel como do FreeBSD, do NetBSD e do 4.4BSDLite formam o kernel hibrido XNU, base do sistema operacional Darwin (o MacOS X)

 O site oficial o Mach pode ser conferido aqui.

Lançado bc 5.2.2 por Gavin Howard

Lançado bc 5.2.2 por Gavin Howard

Lançado bc 5.2.2 por Gavin Howard

 Há 3 dias foi lançada a versão 5.2.2 da linguagem bc de autoria de Gavin Howard (caso não conheça, Gavin Howard já nos concedeu uma entrevista muito interessante).

 Esta é uma versão de produção que corrige um bug, uma falha de segmentação se argv[0] for igual a NULL.

 Este não é um bug crítico; não haverá necessariamente vulnerabilidade. Não há necessidade de atualizar caso não queira. Eu, como acompanho o projeto e estou sempre testando (inclusive reportando bugs caso encontre) então baixei e compilei minha versão.

 Lembrando, o toybox também possui a linguagem bc do Gavin, porém, o projeto toybox mantem a versão 1.0 (onde encontrei o bug de loop). É aconselhável a não utilizar nem a versão que se encontra no toybox e nem a do GNU (por conter bugs que já foi explicado na entrevista do Gavin).

airyxOS: Um clone do macOS?

airyxOS: Um clone do macOS?

airyxOS: Um clone do macOS?

 Na Segunda Feira eu fiz uma live tratando de um suposto clone do MacOSX que recebeu o nome de airyxOS. Então nesta live tratamos o que esse sistema operacional realmente é, sua proposta, seu design como modelo de kernel, sistemas de arquivos que possui suporte, init system utilizado pelo sistema, GUI, como rodará as aplicações do MacOSX, arquitecturas que possui suporte, se está funcionando e muito mais. Valeu a pena fazer esta live.




Novidades no Btrfs 5.17

Btrfs 5.17

Novidades no Btrfs 5.17


 Essa semana foi lançado o kernel Linux versão 51.6 e muitos sites como o OMG! Ubuntu e o XDE Developers descrevem que os gamers vão amar esta versão devido o recurso de futex2. Particularmente não encontrei essas notas no anuncio do Linus Torvalds. Eu encontrei até mesmo sobre o Batman (batman-adv e b.a.t.m.a.n. Abreviação de better approach to mobile ad-hoc networking) mas não sobre o que são demonstrados nos sites. Esse release está mais relacionado a correções e reversões do que novidades em si.
"Portanto, isso contém principalmente algumas correções de driver (principalmente rede e rdma), uma correção de uso de credencial do cgroup, algumas correções de rede principais, um algumas reversões de última hora e algum outro ruído aleatório. O shortlog anexado é tão pequeno que você também pode rolar isto."
 Bom, mas novidades também estão vindo aí no Btrfs (e provavelmente no kernel 5.17 já anunciado o seu desenvolvimento). David Sterba da equipe do Suse anunciou no dia 11/01/2022 a atualizações do Btrfs 5.17.

NOVOS RECURSOS

 Agora é possível que o send trabalhe com a realocação de grupo de blocos evitando que falhas ocorram; nova operação de exclusão 'balance paused' que, como o próprio nome já diz, permite adicionar um novo dispositivo ao sistema de arquivos com balance em pausa. o Btrfs também está com novo arquivo sysfs para armazenamento do fsid (em per-device directory) que ajuda a distinguir dispositivos quando seeding estiver habilitado.

MELHORIAS NO DESEMPENHO

 A exclusão de diretórios ficou entre 20% a 40% mais rápidos devido; o zoned mode ficou em torno de 50% durante a montagem; indexação e busca por tamanho com a latência de -30% e menos contenção de tree node locking que permite ganho de até 20%. A parte de desempenho já é uma característica muito boa do Btrfs e de longa data. Eu já até mesmo apresentei essa características em vídeos como benchmarks e comparações com ZFS.



CORREÇÕES DE BUGS

 Houveram correções de bugs (lógico) como falha no ENOSPC quando há escrita direta no range NOCOW; na quota de deablock (e outras operações de quotas); no free space tree e no zoned.

OUTRAS

 Houveram também outras melhorias e limpesas como na parte de HDD e SSD, como o file system lida com erros. Essas novidades ocorreram desde o kernel 5.16-rc8 e estarão disponíveis no link abaixo (um total de 115 mudanças).

HarmonyOS - O sistema operacional que visa substituir o Android

HarmonyOS - O sistema operacional que visa substituir o Android
HarmonyOS - O sistema operacional que visa substituir o Android

 Martin Děcký, um dos autores do sistema operacional HelenOS e que trabalha para a Huawei em um sistema operacional que pretende ser o substituto completo do Android. Em Junho de 2021, Martin concedeu uma entrevista para o site Checo lupa.cz dando uma visão sobre o sistema operacional HongMeng OS e sua relação com o HarmonyOS.

Martin Děcký, um dos autores do sistema operacional HelenOS e do HongMeng OS.
Martin Děcký, um dos autores do sistema operacional HelenOS e do HongMeng OS.

 HongMeng OS é um sistema operacional com seu próprio microkernel que não tem nada a ver com Linux ou base de código de  qualquer outro sistema e que teve seu inicio de desenvolvimento em 2017. Ele tem várias iterações internas e uma terceira transcrição está sendo trabalhada. Martin começou a trabalhar na certificação de segurança deste sistema e alguns de seus colegas começaram a trabalhar em um hipervisor.
Para mim e para a maioria dos meus colegas, o HelenOS foi um projeto que nos moldou em termos de conhecimento e de orientação geral de nossas carreiras. É uma parte fundamental da minha vida profissional. É por isso que lamento que o HelenOS esteja atualmente em uma fase lenta e estou dedicando muito mais tempo e energia a outros sistemas de microkernel.
 Por volta de 2018, o nome do sistema foi alterado para HarmonyOS para melhor adoção no mercado ocidental e a empresa anunciou publicamente que o objetivo era que o HongMeng OS / HarmonyOS era substituir o Android nos smartphones da empresa e ao mesmo tempo ser utilizado em seus navegadores, roteadores, BTS e muito mais. estranhamente depois a empresa decidiu comunicar o sistema sob o nome HarmonyOS e que não tem nada a ver com o HongMeng OS original. HarmonyOS 1.0 é um sistema construído sob o núcleo LiteOS em tempo real enquanto a versão 2.0 do HarmonyOS 2.0 é basicamente Linux mais parte de código aberto do Android mais add-ons internos da empresa.

LiteOS
LiteOS

 O HongMeng OS ainda está evoluindo e há um plano de que ele será o substituto definitivo para o Android.
"Um sistema operacional multiservidor de microkernel é composto de pequenos componentes isolados, cada um executando em um espaço de endereço separado e assim por diante. Esta é uma arquitetura adequada para verificação formal, certificação ou execução em   situações de segurança  e  missão crítica . A sobrecarga associada à comunicação de componentes isolados anda de mãos dadas com isso. Existem cenários, como um smartphone, em que os componentes são um pouco mais monolíticos. Arquitetura flexível significa ter um mecanismo que pode modificar um sistema de componentes e sua arquitetura de modo que durante a implantação seja possível   juntar componentes do espaço do usuário e movê-los de lá para o kernel e assim por diante."
"Há algum tempo, tem havido um esforço para pelo menos unificar os garfos internos do kernel Linux no projeto HULK, o Huawei Unified Linux Kernel, para que tenhamos uma base de código Linux unificada."
 Então, já que a galera está gostando de especular muito sobre o Fuschia, aqui está mais um sistema operacional que irá concorrer com  o Android.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (9) Andriod (14) android (5) artigo (5) aws (1) bc (15) benchmark (3) BSDs (27) btrfs (30) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (24) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (80) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (86) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (20) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (5) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (75) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (101) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (60) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (4) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (146) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (82) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (60) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (1) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (22) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (83) terminal de comandos (11) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (13) zsh (2)