POLEMICA - Linux ou BSD? Qual o melhor?

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

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

   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.

• Manual Arch Linux

    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

    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

    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.

http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/14518

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Diferentes arquiteturas de processadores

Diferentes arquiteturas de processadores

    Desde o ano passado, um dos assuntos que mais vem ganhando repercução é sobre a Apple migrar de X86 da Intel para seu próprio ARM chamado Apple Silicon, o Linux passar a ter suporte a esse processador da Apple, a NVidia adquirir a arquitetura ARM e o Risc-V passar a ganhar mais notoriedade depois da ultima menção. Depois de tudo o que mencionei, me senti inspirado a escrever este artigo.

    Eu já escrevi uma série chamada "Dando uma olhada na arquitetura dos processadores" onde debato como o processador é constituído internamente (andei até mesmo dando uma atualizada tratando da arquitetura de Havard mostrando em que se difere da arquitetura de Von Neumann e pretendo adicionar mais coisas. Mas  vamos deixar isso para o futuro Deus permitindo que eu faça).

O que é arquitetura de processador?

    De acordo com o Dicionario de Termos da computação e da Internet (Dictionary of Computer and Internet Terms) arquitetura de processador é um conjunto  de instruções que decodificam e executam operações aritméticas e lógicas. Esse conjunto de instruções são denominados ISA (Instruction Set Architecture) e, nas minhas palavras, arquitetura dos processadores é a forma como essas instruções são organizadas. Apesar de popularmente acabarmos tendo contato com apenas com X86, existe uma boa variedade de arquiteturas como CISC, RISC, EPIC e ZISC e Linux é uma fonte abundante para adquirir conhecimento sobre elas.

    Dentro das arquiteturas existe uma gama de fabricantes diferentes. Então agora vamos estudar um pouco sobre as arquiteturas, suas variedades e aonde geralmente são aplicadas.

CISC

    CISC (Complex Instruction Set Computers) é uma arquitetura construída com muitas instruções de linguagens de máquina diferentes. Tem como objetivo em seu design completar uma tarefa em poucas linhas de código assembly fazendo com que o compilador tenha pouco trabalho para traduzir o código de alto nível. O problema disso é que as suas tarefas acabam exigindo múltiplos ciclos, fazendo com que leve pelo menos duas vezes mais tempo para executá-las.

    Ressalva, não confunda CISC com CICS. CICS (Costumer Information Control System) é uma extensão da IBM utilizada no IBM System Z que tem como objetivo tornar fácil escrever programas e permitir usuários entrar, recuperar e atualizar dados através do seu terminal (fortemente utilizado em sistemas de pontos de venda, reservas de hotel e sistemas de cobrança).

    Popularmente conhecemos a arquitetura CISC devido aos x86 da Intel, da AMD e da Via (após ter adquirido a antiga Cyrix); mas há outras empresas que também já  fabricaram processadores CISC difrentes de x86 como o VAX, o IBM System/370 e o s390 e houve também o Motorola 6800 (também conhecido como m68k ou simplesmente 68k) na década de 80 que foi o primeiro processador de 32 bits amplamente utilizado e foi o processador do vídeo game Mega Drive, do Macintosh (pois é, a migração de PowerPC para Intel e depois de Intel para ARM não são as únicas experiências que a Apple já teve em sua história), dos computadores da HP e da Sun Microsystem. Falando em Sun Microsystem, foi devido o Motorola 6800 que os desenvolvedores de SunOS tornaram o GCC funcional para uso em produção (o que até então, era simplesmente um compilador inviável).

    Parece estranho afirmar, mas deve ser dito. Foi o x86 que tornou os PCs interessantes (especificamente o 386 a partir de 1986); mas historicamente o x86 parou de fazer sentido para o mercado há algum tempo. Basta repararmos como exemplo Apple em 2018 que vendeu 217.7 milhões de Iphones e 18.2 milhões de Macs (mais de 10 vezes mais dispositivos ARM, o que a chamou a sua atenção para abandonar o x86).

RISC

    Abreviação de Reduced Instruction Set Computer (Computador com conjunto de instruções reduzidas) é a arquitetura que realiza processos de forma simplificada e que foi projetada para desempenho. Devido haver poucas instruções a serem escolhidas, ela leva menos tempo para identificá-las tornando os resultados mais eficientes e executando os processos mais rapidamente e alocando somente as instruções necessárias por clock. Foi criada inicialmente na IBM por John Cocke e sua equipe de pesquisadores em 1.974 como controlador de central telefônica (a telefonia sempre tendo importância na computação). Essa arquitetura levou à uma corrida do ouro dos processadores para concorrer contra o CISCI da Intel. 

John Cocke e o primeiro protótipo de computador RISC que o garantiu os premios Turing Award em 1987, the US National Medal of Technology em 1991 e o  the US National Medal of Science em 1994.

 A arquitetura RISC é tão interessante que há um ditado que diz que "O mundo é RISC". E não é de se duvidar já que a arquitetura é utilizada desde Supercomputadores como é o caso do Fugaku da Fujistu a micro controladores como o H8/300 da Hitachi.

 Alguns exemplos de processadores RISC são o Dec Alpha (primeiro processador de 64 bits e primeira arquitetura que Linux foi portado em Novembro de 1994); ARM que é muito famoso em dispositivos móveis devido a seu baixo consumo de energia conservando a bateria por mais tempo (diferente do sparc que, apesar de também ser RISC, consome muita energia e não é tão eficiente no uso de memória); Spark da Sun Microsystem (divisão da Oracle) criado para substituir o m68k; o PowerPC que foi desenvolvido pela IBM, Motorola e Apple quando Steve Jobs saiu da Apple e fundou a NeXT e a Pixar no "Project Pink" para competir com a Intel e foi especialmente projetado para emular programas outros tipos de CPU eficientemente. Foi utilizado também no PlayStation 3, no Xbox 360 e consoles da Nintendo como Game Cube, Nintendo Wii e Nintendo Wii U e pelo sistema operacional OS/2); o MIPS, o Cris (utilizado em dispositivos de rede) e até mesmo a série de chips Super FX da empresa britânica Argonaut Games (adquirida pela Synopsy) que foi utilizado em jogos do Super Nintendo como o StarFox e Yoshi's Island possibilitando a renderização de centenas de polígonos 3D simultaneamente e desenhando efeitos em 2D.

Em Mario World 2: Yoshi's Island foi utilizado o chip Super FX 2 que é um Risc customizado e que possibilitou ao jogo ter elementos 3D e 2D (sim, o jogo é 2.5D), polígonos, cores vivas e amplas, efeitos de iluminação, semitransparência e camadas para que objetos possam passar uns pelos outros.

 No Japão surgiu o SuperH após a Motorola processar a Hitachi por questões de licenças do m68k. Então, os engenheiros da Hitachi desenvolveram sua própria arquitetura como substituta. Esse processador foi utilizado nos consoles Sega 32x, Sega Saturn, Dreamcast e fliperamas além de também ser utilizado na indústria automotiva no Japão como robôs que montam carros. Durante a crise asiática, as patentes do SuperH foram transferidas para a empresa Renesas. Há um conjunto de instruções do SuperH chamado Thumb que é utilizado até hoje nos smartphones baseados em ARM. Durante um tempo a ARM pagava à Renesas pelo direito de uso desse conjunto de instruções e como a Renesas não renovou suas patentes, eles passaram a ser utilizados gratuitamente.

RISC VS CISC

    Ambos possuem vantagens e desvantagens e ambos conseguem executar os mesmos tipos de programa; o que vai diferenciar é como é o código de máquina do programa. A principio da leitura deste artigo, o RISC aparenta ser superior ao CISC, mas nem tudo são as mil maravilha. 

    RISC tende a ser mais rápido que CISC SE o acesso a memória for muito rápido; do contrário (se o acesso a memória for relativamente lento) o CISC tende a ser mais rápido que RISC. Além do mais, máquinas RISC tendem a buscar mais instruções da memória para realizar o mesmo trabalho que CISC (ou seja, utiliza-se mais RAM que CISC).

RISC híbrido

    RISCs puros utilizam uma instrução por ciclo de clock. Foi aí que eu conheci a geração de RISCs hibridos que utilizam correção nas instruções de comprimento de 16 bits com registradores e endereço de espaço de 32 bits. Isso torna mais fácil para os compiladores gerarem melhores códigos RISC e retomam grande parte da densidade de código dos projetos CISC. Mais informações sobre chips híbridos podem ser conferidos clicando nesses dois links da Renesas e da Design & Recue.

CISC and RISC debate continues, hybrid wins

ParthusCeva Announces Architecture Standard for Hybrid DSP/RISC-Based System-on-Chip for ARM Environment

    A maioria dos fabricantes hoje tentam combinar as vantagens de cada arquitetura dentro dos seus processadores. A Intel por exemplo, introduziu através do Pentium a possibilidade de seu processador traduzir internamente instruções CISC em RISC (podendo executar duas instruções por ciclo assim como o RISC) e o J64 que planejam uma aproximação do x86-64 ao j4 com compatibilidade a 32 bits (seu design foi elaborado no ano passado). Portanto, dificilmente temos CISCs puros quanto RISCs puros assim como dificilmente encontramos kernel totalmente monolítico quanto totalmente micro-kernel.

 A AMD também tinha um projeto de ARM chamado K12 focado em eficiência energética 

que era planejado para ser lançado em 2017. O desenvolvimento do K12 inspirou a criação do Opteron A1100 e a engenharia do Ryzen (agradeço ao Anderson Rincon por ter me fornecido a informação sobre o K12 e por ter revisado este texto para mim).

PA-RISC

 Foi uma arquitetura RISC desenvolvida pela HP tendo uma ideia de arquitetura mais precisa (daí o PA do seu nome que é a silga de Precision Architecture) porém esse processador foi substituído pela arquitetura EPIC.

EPIC

 Abreviação de Explicitly Parallel Instruction Computing (Computação com instrução explicitamente paralela), foi criada em parceria entre a HP e a Intel para a criação da família Itanium (também conhecida como IA-64) para substituir o PA-RISC. Itanium foi desenvolvido como uma arquitetura de alto desempenho extremamente paralela realizando tal tarefa ao passar as instruções para o compilador que reorganiza o código para o máximo de paralelismo possível enquanto que o hardware foca em executar as instruções. E aqui mora o grande problema, nos compiladores que foi mais critico implementar do que a Intel esperava; o que resultou em um hardware muito caro e com baixa quantidade de software disponível para a arquitetura.

ZISC

    ZISC (Zero instruction set computer) é uma arquitetura que se baseia nos princípios de correspondência de padrões e ausência de microinstruções. De acordo com documento de patentes do Google sobre circuito neural (ou neurochip ou redes neurais), essa é a arquitetura talvez mais apropriada para as tecnologias neurais devido a forma como trabalha.

DSP

    DSP trata-se na verdade de um processador de sinal de digital (daí o seu nome Digital Signal Processor) que é utilizado para processar áudio (até redução de ruído) e vídeo e é fortemente utilizado em mesas de som e instrumentos musicais. Mas também foi utilizado em cartuchos do Super Nintendo para processar jogos como Super Mario Kart.

    Talvez você deva estar pensando por que estou falando deste tipo de chip como uma arquitetura. Bom, a minha ideia era falar sobre DSP no mesmo artigo "Dando uma olhada na arquitetura de processadores" porque, assim como FPU que era chip separado e hoje é incorporado aos processadores, o mesmo pode ocorrer com os DSPs podendo o seu processador possuir instruções DSP adicionadas a ele. De acordo com informações do J-Core (que é um processador que eu acompanho bastante o seu desenvolvimento) as instruções DSP podem quebrar a pipeline do estilo do RISC e eles possuem um novo design de DSP em desenvolvimento.

    alguns exemplos de DSP que o Linux possui suporte são o Hexagon e o C6x da Texas Instrument.

     Bom, finalizo este artigo por aqui acreditando já estar bom por enquanto dado uma boa base de estudo para todo mundo. Pode ser que eu venha atualizá-lo no futuro assim como faço com os demais artigos.

Dando uma olhada na arquitetura dos processadores #1

Dando uma olhada na arquitetura dos processadores #2

Dando uma olhada na arquitetura dos processadores #3

Dando uma olhada na arquitetura dos processadores #4

https://en.wikipedia.org/wiki/Computer_architecture
https://www.cis.upenn.edu/~milom/cis501-Fall11/lectures/00_intro.pdf

https://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/

http://landley.net/notes-2020.html#26-06-2020

http://landley.net/aboriginal/architectures.html

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Apple e os processadores ARM

Apple e os processadores ARM

Depois que a Apple anunciou a migração de X86 para ARM, muita gente se preocupou quanto a possibilidade de não poder utilizar programas de uma arquitetura em outra. A Apple já fez o processo de transição da arquitetura PowerPC para a X86 sem apresentar trabalhos críticos; desta vez eu acredito que não será diferente. No meu vídeo sobre Ubuntu rodando no meu Power Mac G4 eu explico através do kernel do Mac OS X Leopard como a Apple realizou esse trabalho até que todos os fornecedores pudessem portar os seus programas para X86:

 Migrar para ARM parecia algo previsível; em 2.015 o site Mac Rumors já havia postado a noticia sobre a pretensão da Apple migrar para ARM e a resposta da Intel afirmando que o relacionamento entre as duas empresas ainda era muito forte; em 2.018 a Apple vendeu quase 218 milhões de Iphones e apenas pouco mais de 18 milhões de Macs. As coisas ficaram cada vez mais óbvias com o lançamento do novo Ipad Pro que era mais poderoso que 92% dos desktops acessíveis do mercado da época, rodando Photoshop nativamente, navegando na internet e utilizando Whatsapp ao mesmo tempo (e até arrastando do navegador e soltando no Whatsapp) e termina com a frase "ele é como um computador mas diferente de qualquer computador".

O chip A12X Bionic utilizado no Ipad Pro.

Poderoso o suficiente para photoshop nativo.

Mais rapido do que 92% dos desktops acessíveis.

Navegando na web e usando chat ao mesmo tempo.

Arrastando do navegador e soltando no Whatsapp.

 Por fim a Apple anunciou no mês de Junho que estaria migrando que X86 para ARM. A coisa está feia para o X86, mas parece que somente para a Intel pois a AMD anda ganhando cada vez mais espaço com o núcleo Zen (com mais um console no mercado da Atari) enquanto isso recentemente Linus mandou a real para a Intel desejando uma morte dolorosa ao AVX-512, que a Intel pare de ficar focando em benchmarks com sua Unidade Ponto Flutuante, pare de ficar inventando moda com instruções mágicas e comece a corrigir problemas reais. Para revidar a situação,parece que a Intel está trabalhando em um novo recurso de tecnologia hibrida para o Alder Lake chamado Big-Bigger similar ao design Big.LITTLE da arquitetura ARM.

 Uma coisa que deixou os apaixonados por Mac foi a possibilidade de retrocompatibilidade não somente com Intel, mas também com outras arquiteturas passadas. Um desenvolvedor apaixonado por Macs antigos chamado tenFOURFox escreveu sobre a possibilidade de rodar até cinco arquiteturas em um unico binários (ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 e x86_64) e potencialmente até 17 arquiteturas em  um único binário (ppc750, ppc7400, ppc7450, ppc970, i386, x86_64, x86_64h, armv4t, armv5, armv6, armv6m, armv7, armv7em, armv7k, armv7m, armv7s e todos os outros Macs com AARM.)

 Uma informação que prometi na live que iria pesquisar é qual tecnologia GPU será utilizada nos novos Macs com ARM. A unica coisa que se sabe é que a Apple guarda esse segredo a sete chaves pois parece ser tecnologia própria da empresa.

Imagem aqui

DEMAIS, SÓ FINALIZO DIZENDO QUE, SE VOCÊ É UM USUÁRIO DE MAC OS E ESTÁ PENSADO EM MIGRAR PARA LINUX, MEU CURSO É PENSADO TAMBÉM PARA VOCÊ ;)

Lançado musl 1.2.2

 Mal foi lançado o Alpine Linux 3.13.0 com suporte a musl 1.2 e agora foi lançada a musl 1.2.2. Caso ainda não conheça a musl, confiram meu vídeo na série muito além do GNU:

    Nesta nova versão  novas funções foram adicionadas como reallocarray inspirada no OpenBSD (mais uma função inspirada no OpenBSD), suporte a temporizador de notificação SIGEV_THREAD_ID, tcgetwinsize/tcsetwinsize da futura POSIX e _Fork. também da futura POSIX (que traz vantagem de async-signal-safety).

    A função realpath foi reescrita para não mais depender dos conteúdos do procfs magic symlink (fazendo funcionar em containers ou no chroot onde os conteúdos do /proc podiam não se tornar visíveis ao processo).

    As versões C das funções square root, que são utilizadas em arquiteturas sem instruções FPU nativas, também foram reescritas com melhorias de desempenho (especialmente em arquiteturas que carecem inteiramente de FPU. Essa reescrita também corrige a falta de sqrtl necessária em arquiteturas com quad-precision long double.

 Um bug buffer overflow (CVE-2020-28928) foi corrigido na função wcsnrtombs que também foi reescrita (função pouco utilizada e bug não muito relevante que não a utiliza diretamente por não ser utilizado por componentes de outra libc), mas que pode ser sério para software que a utiliza. 

https://musl.libc.org/releases/musl-1.2.2.tar.gz

https://musl.libc.org/releases/musl-1.2.2.tar.gz.asc

https://github.com/sponsors/richfelker

https://patreon.com/musl

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Muito além do GNU: Os vários sabores de bibliotecas C

 Alguns dias atrás me deparei com o link do site osdev.org sobre implementações de biblioteca C; trata-se de um artigo bem interessante mas muito curto. Como eu já fiz vídeos e artigos relacionados ao tema para a minha série Muito além do GNU (lembrem-se que tudo no Linux é uma questão de escolha. Escolha diz mais respeito a liberdade do que uma ideologia ou uma simples licença), eu resolvi então explorar este texto fazendo minhas observações sobre cada uma delas acrescentando mais informação e adicionando outras.

 As bibliotecas C mais populares são a glibc, uclibc, musl e dietlibc; mas há um mundo muito mais vasto e amplo do que você pode imaginar e aqui vou eu abordar muitas outras. No total, até o momento eu cataloguei por volta de 18 diferentes implementações de biblioteca C.

 Eu não pretendo seguir na mesma ordem que está descrita no artigo e sim na minha própria ordem; basicamente, a ordem que eu conheci ou de forma que eu considero mais coerente de explicar.

Toca do Tux: uutils: Um coreutils escrito na linguagem Rust

There is a comparison table (http://www.etalabs.net/compare_libcs.html) of some of these.

Glibc

 De autoria de Roland McGrath e graças aos esforços de vários projetos e empresas que a mantem para que possam utilizá-la no Linux, é uma biblioteca absolutamente completa e possui suporte a quase todas as arquiteturas. Uma observação muito interessante feita no site:

"Ela não é escrita com nada além do Linux em mente, tornando-a um port difícil."

 Sim, apesar de a glibc ser uma biblioteca do projeto GNU, tecnicamente a glibc é uma biblioteca do Linux. Isso ocorreu porque no inicio dos anos 90 os desenvolvedores de Linux perceberam que glibc carecia de muitos recursos necessários para Linux e assim eles criaram um fork da versão 1.x que foi nomeada simplesmente libc e que conhecemos como libc4 que foi a ultima com suporte ao padrão a.out, a libc5 (/lib/libc.so.5 a primeira a ter suporte ao padrão ELF no lugar do a.out. Há algumas fontes que afiram que havia código da bibliotecas C do 4.4BSD, mas o link do projeto gnu não está mais disponível) e libc6 (/lib/libc.so.6) e foram o padrão nas distribuições Linux durante um bom tempo. A glibc 2.0 surgiu da libc6 e com o tempo, por uma questão de padronização, as distribuições voltaram a utilizar a glibc. Mais informações da libc5 e libc6 podem ser lidos clicando aqui. Já para saber mais sobre libc4, libc5 e libc6 consulte a manpage (man 7 libc).

 Houve também a Eglibc que foi uma variante da glibc fortemente focada em embarcados e com uma série opções e de suporte a arquiteturas que a glibc não possuía (especialmente PowerPC). A Eglibc foi a biblioteca padrão do Debian 5 e possuía suporte de um consorcio. O código da Eglibc foi fundido ao código da glibc na versão 2.20.

 No final das contas a GlibC se beneficiou muito do Linux assim como quase todas as ferramentas do projeto GNU. É difícil prever a linha do tempo das ferramentas GNU sem o Linux.

 Uma das grandes desvantagens da glibc podemos mencionar é o fato de  gerar binários muito grandes. no artigo Analisando 6 diferentes implementações do comando sed eu descrevo uma curiosidade relatada por Rob Landley que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k... Não é a toa que os desenvolvedores de embarcados se declaram inimigos mortais da glibc.

 E a outra desvantagem é estar sob a licença GPL que está em decadência desde 2007 por ser uma licença muito restritiva (até hoje não entendo o conceito de liberdade em algo tão restritivo. Algo totalmente incoerente).A criação da GPLv3 foi uma corda no pescoço da licença e já houveram planos no passado para migra a glibc para a terceira versão. Ainda bem que isso não ocorreu pois geraria um grande colapso nos projetos.

uClibc

 uClibc (pronuncia-se yew-see-lib-see) é uma biblioteca para Linux em embarcados no projeto µClinux. Bem menor do que a glibc porém com suporte a quase todas as suas aplicações e quase todas as arquiteturas (alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC e v850). 

 Foi escrita do zero por Erik Andersen, ex mantenedor do Busybox (que passou a bola para Rob Landley, autor do terminal de comandos toybox), iniciando em 1999 tendo apenas algumas partes de código derivados da glibc como pthreads (threads do Linux, o mesmo recurso que querem fazer uso dentro do sistema operacional RTOS X5) e o suporte a números randomicos.

 O uClibc foi descontinuada por volta de 2012 e criaram um fork chamado uClibc-ng. Aé aonde se sabe, existem poucos mantenedores da uClibc-ng, ou talvez somente um, sob o argumento que é a única que possui suporte a algumas plataformas de hardware antigos.

 Está sob a licença LGPL e o site da uClibc-ng pode ser conferido clicando aqui.

Musl

 Musl já apareceu várias vezes tanto aqui no blog quanto no canal. É construída sobre a API do Linux e a API POSIX e tem como princípios a simplicidade, eficiência de recursos, atenção em correções, segurança sob exaustão de recurso, fácil deploy e suporte de primeira classe para textos UTF-8/multilingual. A musl permite gerar binários menores (mesmo linkados estaticamente) e rápidos. Rich Felker criou o conceito Quality Safe Code; o que leva a biblioteca a ser correta no quesito conformidade e segurança.

Mais sobre a biblioteca Musl pode ser lido clicando aquioca do Tux: musl

 Com o fim da uClibc e depois de ter péssima experiência com programas linkados a outras bibliotecas (seja de forma dinâmica ou estática) que apresentaram falhas, Rich  Felker desenvolveu a musl como uma alternativa a glibc e a Uclibc para oferecer melhor experiência no uso de aplicações linkadas estaticamente (tanto no conceito de segurança quanto eficiência) em embarcados, servidores de desktops.

 Inicialmente esteve sob a licença GPL porém, depois de conversa com Rob Landley (autor do toybox) passou a disponibilizar a musl sob a licença MIT. Hoje a musl é utilizada como padrão nas distribuições Alpine Linux que é inclusive utilizada nas imagens Docker; Adelie Linux que é baseada no Gentoo Linux e eu pretendo fazer um vídeo de Os vários Sabores de Linux; Void Linux que foi criada para implementar os gerenciador de pacotes xbps (haja coragem); Alpaquita Linux criada pela empresa Bell soft para a execução de aplicações Java; Glaucus Linux que, diferente da distribuição Alpine Linux, faz uso do toybox como userspace ao invés do busybox (tive a honra de receber seu autor no meu canal) e há planos para a sua adoção no Debian e no Android.

 Possui em torno de 1200 funções além de todo um conjunto de funções matemática e de printf, porém ainda faltam system calls para serem implementadas. Natanael Copa, autor da distribuição Alpine Linux descreve em sua palestra o que é necessário para substituir a glibc pela musl. Foi a primeira biblioteca a adotar mutexes safe que o pessoal considera incrível, condvars e a primeira a ter working thread cancellation sem race conditions (todos recursos que foram ignorados por outras implementações).

Diet libc

 De autoria do alemão Felix von Leitner, foi criada com foco em otimização de tamanho dos binários assim como a musl e cumpre muito bem esse papel. Eu mesmo já fiz analises tanto no canal quanto aqui no blog compilando o embutils, o minised e o init system runit e os resultados de sua otimização de binários são surpreendentes. Há um vídeo no meu canal onde relato a sua história e recursos interessantes.

Está sob a licença GPLv2 mantendo a compatibilidade com a licença do kernel Linux, sua. Sua ultima versão foi em 2018 e há muitos recursos faltando conforme podemos conferir no link do Ethalabas porém, mesmo que não seja uma informação de conhecimento público, é uma biblioteca muito utilizada no mercado; então as empresas concentram esforços em sua continuidade.

Mais sobre a diet libc pode ser conferido aqui no blog

skalibs

 skalibs é um pacote que centraliza bibliotecas C pequenas e seguras utilizadas para a construção de todos programas da skarnet.org. A ideia é não ter que baixar e compilar bibliotecas grandes e se preocupar com problemas de portabilidade. skalibs está sob a licença ISC e pode ser baixada através do comando

git clone git://git.skarnet.org/skalibs

 ou através de seu repositório GitHub mirror.

Saiba mais sobre a origem da skalibs clicando aqui

Newlib

 Newlib é uma biblioteca fortemente focada em embarcado. Alias, essa é uma das bibliotecas mais amada pelos desenvolvedores de embarcados. É utilizado até mesmo pelos amantes de Dreamcast (e eu não gosto, né). Ela conglomera várias partes de biblioteca sob licenças open-source. e em seu site oficial só é disponibilizada na forma de código fonte.

 Possui suporte a mais ou menos 400 funções e requer threading. Nesse embalo surge a Relibc.

Relibc

 relibc é uma biblioteca C POSIX escrita em Rust. De origem do sistema operacional redoxOS e possui port para Linux. Foi desenvolvida para ser uma alternativa a newlib (por isso coloquei nessa ordem) no RedoxOS e também possuir suporte a system calls do Linux (se system calls Linux tem muito bem) por meio do sc crate.

• GitHub - redox-os/relibc: Mirror of https://gitlab.redox-os.org/redox-os/relibc
• Google Summer of Code/2021/Ideas/Redox Relibc Support - Gentoo Wiki
• Archive Project Details | Google Summer of Code

Bionic

 Bionic é a principal biblioteca do Android; foi construída com porões de bibliotecas do NetBSD,  do OpenBSD, porções de bibliotecas de FreeBSD e partes próprias. Está sob a licença BSD para evitar os conflitos que vem ocorrendo com a GPL; existe até uma política do Android de não haver programas sob GPL no user space do Android.

 Possui suporte a arquiteturas ARM e depois foi estendida a x86 além de suporte a interfaces do kernel Linux. existem algumas limitações como não possuir suporte a locales (até aonde me lembro, a musl também não possui quando tentei compilar o htop que descobri isso), a libthread_db ou libm e possui sua propria implementação pthreads baseada nos futexes do Linux. Existe um relato do Rob Landley que para poder executar o X11 no Android, seria necessário reescrever várias parte do X11 para ser compatível com a Bionic.

olibc

 olibc (Another C Library optimized for Embedded Linux) derivada da bionic, o objetivo da olibc é fundir as melhorias feitas por várias empresas de SoC como a Qualcomm, Texas Instruments, Linaro, etc. A olibc pode se beneficiar de recursos do ARMv7 como NEON, Thumb-2, VFPv3/VFPv4 e as ultimas otimizações de recentes versões dos compiladores.

PDCLib

 PDCLib (ou The Public Domain C Library) visa fornecer uma implementação completa do padrão C99 (nada mais, nada menos do que definido no ISO/IEC 9899. Nem mesmo outras extensões como POSIX) sob a licença CC0 ("No rights reserved").

 Foi desenvolvida originalmente por Martin “Solar” Baute em 2002 e depois de 10 anos, Erin Shepherd assumiu o desenvolvimento até 2018 que implementou muitos recursos significativos (o currículo da Erin é incrível). Em 2018, Martin retornou ao desenvolvimento da PDClib.

 A versão 1.0 ainda não foi disponibilizado mas a PDClib é boa para linkar ao kernel e possui suporte a 120 funções e não possui suporte. Tudo o que já foi implementado pode ser conferido no site oficial clicando aqui:

GitHub da PDCLIB

GitHub da Erin Shepherd

PDCLIB no GitHub do XboxDev

PDPCLIB

 Não confunda PDCLIB (The Public Domain C Library visto anteriormente) com a PDPCLIB (Public Domain Project C Library. Um P a mais e pode confundir dois projetos). Essa biblioteca faz parte do projeto PDOS (Public Domain Operating System) que se trata (digamos) de um clone antigo MSDOS. (mas com suporte tanto a 32 bits do Windows e do MSDOS. Há uma de suas distribuições com suporte a API MVS API em AMODE de 24, 31, 32 e 64 bit).

 A PDPCLIB é biblioteca do PDOS que visa ser uma biblioteca C que visa junto ao GCCMVS (um port do GCC para mainframes da IBM) produzir binários sem restrições devido a sua licença (domínio público). A PDPCLIB segue os padrões da ISO/IEC 9899:1990 (aka ANSI X3.159-1989 aka C90 aka C89) e funciona não somente no MSDOS, no Win32 e no  PDOS/386 mas também no OS/2, MVS (mainframe), CMS, VSE e AmigaOS. 

mlibc

 Escrita em C++, mlibc tem como foco ser totalmente portável e na modularidade. mlibc possui uma variedade de recursos POSIX/Linux/ANSI e é capaz de executar vários programas como Weston, GCC, LLVM, Bash, GTK2/3 e muitos outros mas sem perder o foco na portabilidade (assumindo poucas systemcalls do sistema operacional hospedeiro). Está sob a licença MIT.

mlibc - an existing libc with similar goals to LLVM libc - Runtimes / C - LLVM Discussion Forums

Libc11

 Como o próprio nome já menciona, é focada em ser escrita totalmente na implementação do padrão C11 (ISO/IEC 9899:2011)  e nada mais. Está sob a licença unlicense (public domain), teve seu inicio em 2014 porém seu desenvolvimento anda bem parado. Seu antigo site (http://libc11.org/) está fora do ar, mas existem alguns repositórios git que podem ser encontrados.

GitHub - public-domain/libc11: implementation of the C11 standard library

GitHub - dryc/libc11: A public domain implementation of the C11 standard library.

klibc

 Na computação, klibc é um subconjunto minimalista da biblioteca C padrão desenvolvida por H. Peter Anvin. Ele foi desenvolvido principalmente para ser usado durante o processo de inicialização do Linux e faz parte do espaço inicial do usuário, ou seja, componentes usados durante a inicialização do kernel, mas que não são executados no modo kernel.

Documentação sobre a klibc

Link para baixar a klibc no site kernel.org (e tem gente que acha que o site do kernel só tem kernel)

Mais sobre o Initramfs pode ser lido no site LWN.net

nolibc

 Essa é uma biblioteca do kernel Linux. Foi adicionada ao kernel 5.0 no commit 66b6f755ad45 como uma biblioteca mínima que fornece emulação de baixo nível quando o Linux for inicializado somente para executar um único e minúsculo programa.

 Foi criado por Paul McKenney ao trabalhar para reduzir o tamanho do initrd (que é de 40MB) e do initramfs (que é 10MB) gerados pelo comando mkinitramfs e pelo dracut onde a maioria das coisas eram inúteis. Assim, eliminando o que não era necessário para o dash (e a maioria eram coisas relacionadas a biblioteca), Paul conseguiu reduzir para ~2MB.

Nolibc: a minimal C-library replacement shipped with the kernel [LWN.net]

Neatlibc

 Neatlibc foi desenvolvida pelo iraniano Ali Gholami Rudi para focar principalmente em bootstrapping de seu compilador neatcc. a neatlibc possui suporte as arquiteturas x86, x86_64, ARM de 32 bits; há muitas funções que não são implementadas na neatlibc mas a maioria dos programas desenvolvidos por Ali (http://litcave.rudi.ir/) podem ser compilados com o neatcc e linkados a neatlibc.

Sortix Libc

 Escrita do zero para o sistema operacional Sortix OS, foi implementada grandes partes do padrão POSIX que permite ter suporte a ~70 partes de software de terceiros.

libslack

 Libslack é uma pequena biblioteca de utilidades gerais que foi projetada com uma coleção de módulos e várias funcionalidades para torar a programação no UNIX/C um pouco mais fácil. A principio foi implementada para ser parte do programa daemon embora alguns códigos datam de antes do do daemon. A libslack possui vários recursos que podem ser conferidos clicando aqui. Está sob a licença GPLv3 e disponível para Linux, Solaris/OpenSolaris,OpenBSD, FreeBSD, NetBSD, MacOSX/macOS, kFreeBSD e GNU/Hurd.

MyOS libc

 E por ultimo temos a myOS libc que resumidamente seria você mesmo desenvolver sua própria biblioteca C. A ideia é servir como uma das soluções mais óbvias implementando os recursos personalizados que precisa a seu kernel e ao resto do sistema operacional sem camadas de portabilidade. Outra parte interessante seria a melhor integração com funcionalidades do seu hardware.

 O artigo não inclui o link para o desenvolvimento da biblioteca, então eu resolvi adicionar por conta própria.

Newtime

 Newtime é uma biblioteca C que tem como foco demonstrar falhas sutis da biblioteca e como ela poderia ser hoje em dia já que foi escrita décadas atras. É a bibliotecas mais completa e hackeável com heurísticas desatualizadas. Está sob a licença 0BSD, a mesma do toybox. O autor desta time libc explica neste artigo com detalhes os erros da time libc e como ela poderia ser.

• https://github.com/lhrios/myos
• Creating a C Library - OSDev Wiki
• Writing Shared Libraries With D On Linux - D Programming Language (dlang.org)
• C Library - OSDev Wiki

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) E não esqueçam de conferir também o meu mini curso de atributos no Linux