A farsa "Linux é apenas o kernel"

A farsa por trás do termo "Linux é somente o kernel": A verdade que não te contam sobre isso

 Por quase três décadas vem sendo propagado aos quatro cantos do mundo a vaga informação:

"O nome do sistema operacional não é Linux, Linux é somente o kernel do sistema operacional e somente com o kernel você não faz nada. As ferramentas do sistema operacional são do projeto GNU. Então, o nome correto é GNU/Linux."

 Ou postam em todos os lugares o estafante texto de autoria de Ricahrd Stallman:

"...Eu gostaria intervir por um momento. O que você está se referindo como Linux, é de fato, GNU/Linux, ou como eu recentemente passei a chamar, GNU mais Linux. Linux não é um sistema operacional em si..." ... "....Linux é o kernel: O programa no sistema que aloca recursos da máquina para outros programas que você executa. O kernel é uma parte essencial de um sistema operacional, mas inútil por si só..."

 Agora a moda da vez é dizer "GNU com ou sem Linux"... Patéticos... Estranho é que eu percebi que passaram a utilizar este argumento depois que mencionei no meu vídeo Linux ou GNU/Linux? Eis a questão que "no meu canal eu trato de Linux com ou sem GNU". Simplesmente pegaram a mesma frase inverteram, mas eu duvido que eles vivam sem Linux:

 Eu até poderia escrever pelo menos mais dois ou três artigos debatendo ponto por ponto desta frase, mas o meu foco aqui será unicamente no trecho "Linux é apenas o kernel". Então, bora!

Linux: mais do que o kernel do sistema operacional

 Linux surgiu como um pequeno e singelo kernel, com apenas um conjunto de drivers que Linus portou de seu emulador de terminal que havia desenvolvido como aprendizado, o suporte a hardware era limitado, travava quando atingia o limite máximo de memória e estes são apenas alguns dos problemas que Linux enfrentava. No final da descrição da licença do kernel 0.01 (que nesta ocasião ainda era regido sob a licença da convenção de Berna do século XIX) o próprio Linus Torvalds afirmou na época que:

 "Infelizmente, um kernel por si só não te leva a lugar algum. Para se ter um sistema funcional você precisa de um shell, compiladores, uma biblioteca e etc. Essas são partes separadas e muitas estão sob uma licença rigorosa (ou mesmo mais flexível). A maioria das ferramentas utilizadas com Linux são software do GNU e estão sob a GNU copyleft."

 Não somente em sua licença como também no arquivo README Linux—a free unix-386 kernel, especificamente em Coisas faltando/incompletas no Linux (Things missing/incomplete in Linux) é descrito que:

"Nenhum dos importantes comandos de administração do sistema ainda foram escritos para Linux. Estes incluem coisas como mkfs, format, fsck, mknod e etc. Alguns destes precisam de recursos do kernel ainda não implementados (format, mknod), alguns precisam apenas serem escritos. Assim como a biblioteca, eu aceitaria quaisquer arquivos distribuíveis livremente."

  Se o desenvolvimento do Linux tivesse parado por aqui, estaria correto afirmar que Linux era apenas um kernel, mas este argumento foi válido somente até a versão 0.10, pois a partir do kernel 0.11, lançado no dia 19 de Dezembro de 1991 (apenas quatro meses após seu nascimento), surgiram os primeiros comandos do Linux fidsk, mkfs e fsck desenvolvidos pelo próprio Linus Torvalds para tornar Linux self-hosting já que acidentalmente Linus havia discado a partição do Minix ao invés de seu modem destruindo completamente a partição do Minix:

Linus relatando sobre a criação dos comandos mkfs/fsck/fdisk para o kernel 0.11

 Menos de um mês depois, foi lançado o kernel 0.12 com mais comandos como o mkswap, pois nesta versão originou-se o suporte a memória virtual no Linux, também chamado paginação de disco ou paginação de memória (Memory paging ou disc paging em inglês). A ideia surgiu quando um alemão contatou Linus perguntando como utilizar o GCC no Linux já que ele possuía apenas 2MB de RAM e era a exata quantidade exigida para executar o GCC. Foi aí que durante três dias Linus trabalhou no desenvolvimento da paginação de disco, vindo a concluí-la no dia 25 de Dezembro de 1991. Isso foi uma revolução no Linux pois não era um qualquer sistema operacional possuía suporte a memória virtual. Daí em diante as pessoas pararam de comparar Linux ao Minix e passaram a compará-lo ao Coherenlt que foi o primeiro clone do Unix na história:

Nota de lançamento do kernel 0.12 descrevendo o comando mkswap adicionado ao mkfs

 A maioria dos comandos desenvolvidos por Linus Torvalds ainda estão presentes nas distribuições e também deram origem a outros pacotes como o util-Linux, o e2fsprogs e o busybox. Hoje em dia, a maioria dos comandos nas distribuições são do próprio Linux:

Comandos de autoria do Linus Torvalds no util-linux

Comandos de autoria do Linus Torvalds no busybox

Design and Implementation of the Second Extended Filesystem

Comando badblocks de autoria de Linus Torvalds no pacote e2fsprogs

Linus Torvalds também contribuiu para o comando route

 A partir da versão 0.11 Linux passou de um simples, pequeno e inacabado kernel a um kernel self-hosting contendo os recursos e comandos necessários para a sua administração do sistema, quebrando assim o ciclo do README do kernel 0.01. Mas a comunidade Linux não parou por aí e vocês verão a seguir como a partir destes recursos, a comunidade Linux o evoluiu para um sistema operacional.

 Fato curioso é que Linus havia perdido interesse em continuar o desenvolvimento do Linux até ocorrer o acidente com o Minix. Já pensou se isso não tivesse acontecido ?

 Só com um kernel e as ferramentas do projeto GNU, você não consegue fazer porcaria nenhuma já que o GNU não possui metade das ferramentas necessárias para se ter um sistema operacional.

A evolução do Linux

 Surgiu então a primeira comunidade Linux composta por membros da comunidade Minix. Hoje a comunidade Linux é composta por indivíduos, organizações, instituições governamentais, acadêmicas  e empresariais do mundo todo.

 Sua gigantesca comunidade não o limitou a simplesmente um kernel com comandos e passou a transforma-lo em um verdadeiro sistema operacional desenvolvendo todos os tipos de recursos necessários para isso além de portar ferramentas de outros Unix para Linux (sim, Linux também é um Unix. Aliás, Linux é mais do que um Unix) e receber suporte de outros projetos como é o caso do comando file (que eu não faço ideia de onde o projeto GNU tirou que pertence a eles) e o Shadow. Exemplos de pacotes e comandos do próprio Linux são o at, o Batch (que é uma parte do at), o Linux PAM, o Procps, o Psmisc, o Util-linux, e2fsprogs, iproute2, kmod. De bibliotecas facilmente temos a uclibc, a dietlibc, a musl, newlib e klibc. Existe uma lista enorme somente de bibliotecas C mas poderíamos contar até com mais em outras linguagens. Já mostrei aqui três compiladores além do GCC que compilam o kernel Linux como o tinyCC, o ICC da Intel e o LLVM. Na parte de init systems (BSD, SysVinit, upstart, systemd e etc) também temos uma lista enorme e de carregadores de boot temos outros também. Confiram mais em /pub/linux/utils/ e pub/linux/.

 Uma boa recomendação de leitura é o artigo O dia que Laurent Bercot calou RMS: Eu não uso GNU e seu projeto  

toybox, desenvolvido para Linux e mais tarde portado para FreeBSD

moreutils Uma coleção de ferramentas para Unix que ninguém pensou em escrever

uutils ou rust core utils

Comandos do embutils desenvolvidos para Linux

Comandos do ubase inspirados no util-linux porém mais simples

sbase

minibase

9base port de várias ferramentas originárias do Plan 9 para os Unixes

vcoreutils que é desenvolvido na linguagem V

 Já se passaram 34 anos e muita coisa mudou desde o seu primeiro lançamento. E de tudo o que foi mencionado aqui, sabe o que pertence ao GNU? Nada! Tudo no Linux é uma questão de escolha; opções não faltam.

Kernel: A alma do sistema operacional 

 Se lembram da frase "Algumas destas (ferramemtas) precisam de recursos do kernel" no README lá no início do artigo? Pois é, três coisas podemos mencionar aqui que ocorrem a medida que novos recursos ganham vida no kernel. A primeira é o desenvolvimento de ferramentas para a administração exatamente de recursos do kernel como exemplos os comandos do iproute2 (arpd, bridge, ctstat, devlink, ip, lnstat, nstat, rdma, routef, routel, rtacct, rtmon, rtstat, ss, tc e tipc) para administrar o framework de sub-sistema de redes do Linux; o iptables e nftables para administrar o framework de filtro de pacotes netfilter; os comandos do e2fsprogs (lsattr, chattr, fuse2fs, badblocks, dumpe2fs, e2freefrag, e2fsck, e2image, e2label, e2mmpstatus, e2undo, e4crypt, e4defrag, filefrag, fsck.ext2, fsck.ext3, fsck.ext4, logsave, mke2fs, mkfs.ext2, mkfs.ext3, mkfs.ext4, mklost+found, resize2fs, tune2fs) para a administração de recursos sistemas de arquivos da familia ext*; podemos citar atributos estendidos com o getfattr e o setfattr, ACL POSIX, capabilities e os comandos para administração dos sistemas de arquivos como btrfsprogs, xfsprogs e os próprios comandos fdisk, mkfs, mount e fsck são parte da administração dos sistemas de arquivos; os comandos getenforce, setenforce e até a opção -Z no comando ls são para administrar o SELinux (bom, essa é bem básica do SELinux já que o mundo SELinux é muito maior do que isso); os módulos Apparmor, Tomoyo, MAC e DAC também possuem seus comandos; o comando watchdog para monitorar e gerenciar comportamentos anormais de hardware e software e  automaticamente reset ou rebootar o sistema se necessário utilizam o módulos como softdog e incontáveis outros. No Linux existe até o módulo B.A.T.M.A.N. (better approach to mobile ad-hoc networking) que utiliza os comandos batctl e batman-adv para administração (há também a daemon comando alfred).

 A segunda é o desenvolvimento de ferramentas devido o kernel fornecer recursos para isso. Containers por exemplo são uma mistura dos recursos name space e cgroups (cgroups é fonte de recursos para vários outros programas que utilizamos e uma das principais fontes de recursos para do systemd. O systemd faz uso também do dbus que inclusive é utilizado também na parte de virtualização); o próprio kvm (kernel based virtual machine) como o próprio nome diz é um recurso do kernel para virtualização e que foi adicionado por volta de 2007 (veja na RedHat e na aws); o iproute2 já citado anteriormente, depende de vários recursos do kernel como exemplo a parte de routing policy database (ip rule list e ip route list table local) que depende dos recursos do kernel IP: advanced router e IP: policy routing e o seu IP in IP tunneling que depende dos módulos ipip.o e new_tunnel.o; o novo comando mu (veja também no git) utilizado para exibir o uso de memória por arquivo, depende da systemcall cachestat() do kernel; todos os programas dependem do kernel para serem executados através do recurso ELF (Exectuable and Loadable File) que substituiu o a.out.

 Sabe o shebang (#!) que utilizamos no início de nossos scripts? Pois é! Não é o shell que lê este comentário para interpretar os scripts e sim o kernel através da system call execv (fs/exec.c).

Recursos ELF e #! dentro de Executable file formats no kernel

 Até o seu navegador depende de recursos do kernel a para sua execução e não estou falando de drivers drivers, estou falando de gerenciamento de processo e memória, acesso ao sistema de arquivos, recursos de segurança como Sandboxing e etc. 

 A terceira é o desenvolvimento de novos programas pegando partes do código do próprio kernel. Citando dois exemplos, na FAQ da dietlibc descreve que é utilizado o layout struct stat do kernel em sua interface. O segundo é no projeto Psmisc (que contém comandos como killall, pidof e pstree) que utilizaram o src/loop.h do pacote util-linux que por sua vez, pegaram do kernel Linux.

 O kernel é mais do que o coração do sistema operacional, ele é a alma do sistema operacional pois seu sistema operacional depende muito mais do kernel do que você imagina. Se só com o kernel não se faz nada, sem o kernel, muito menos. Sem o kernel não há sistema operacional.

Linux: Mais do que um Unix

 Aproveitando que falamos de pegar partes do código do próprio kernel para para a construção de novas ferramentas, quero sugerir meu artigo Linux: Mais do que um Unix onde debato sobre algumas das centenas de system calls da API própria do Linux que lhe proporciona recursos que nenhum outro Unix possui (e nem a API POSIX).

Por que foi propagado que Linux é apenas o kernel?

 Este foi o meio que RMS, a FSF e o projeto GNU resolveram utilizar para virar os holofotes para si, tentar se tornar o centro das atenções e se promover já que ideia de ter um sistema operacional completo falhou. Como Rob Landley menciona no Ohio Talk em 2013:

"Os BSD não é uma ameaça existencial para o Linux, mas o Linux é para o GNU".

 O projeto GNU foi iniciado quase oito anos antes do Linux e como tudo na vida é incerto, o curso da história mudou, Linux tomou proporção que não era esperada e passou a ganhar notoriedade em toda a comunidade de tecnologia que não, proporção essa que todos esperavam que ocorreria para o GNU.

 Sabendo que as pessoas não possuem o hábito de leitura (e esse é o grande declino moral das sociedades), passaram então a explorar este ponto fraco a seu favor. No final das contas, tudo uma questão de vaidade ou outras intenções. O que mais me intriga é ver profissionais de Linux vergonhosamente defenderem este argumento.

Conclusão

 Foi-se o tempo que Linux era somente um kernel. O que começou como um projeto pessoal, um pequeno kernel sem pretensões ou expectativas, apenas uma diversão e um desafio para um hacker aplicar seus conhecimentos, inesperadamente evoluiu e se tornou um verdadeiro sistema operacional contendo comandos, shells, bibliotecas, init systems e até mesmo sua própria API.

 Pode não ser considerado um sistema operacional completo, o que dificilmente algum sistema operacional é (muito menos o GNU) já que em todos os sistemas operacionais (especialmente no GNU que não contém metade das ferramentas necessárias para se ter um sistema operacional funcional) são utilizadas ferramentas de outros sistemas ou de outros projetos pois o compartilhamento de conhecimento e a colaboratividade sempre foram as bases da cultura hacker.

 E se Linux fosse realmente apenas o kernel do sistema operacinal, sabe qual a importância isso teria entre verdadeiros profissionais de tecnologia? NENHUMA! O importante é o sistema funcionar e atender as demandas.

 Já aos que vão vir afirmar que discordam (sempre escuto ou leio isso), só tenho um recado a deixar : Eu não dou a mínima importância para concordância ou discordância. As evidencias estão aí, basta terem maturidade e hábito de leitura. 

• O dia que Laurent Bercot calou Richard Stallman: Eu não uso GNU, eu uso Linux!
• Projeto Skarnet
• A verdadeira face de Richard Stallman
• Muito além do GNU
• Daemons, daemons e mais daemons (init)
• Muito além do GNU: Os vários sabores de bibliotecas C

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

Red Hat descontinua suas operações na Russia

 Ontem (dia 08/03/2022) foi anunciado que a Red Hat descontinuará suas operações na Russia. Como a Bielorrússia é aliada da Russia, as operações acabam sendo descontinuadas nos dois países. A situação é ainda mais grave, pois isso faz com que a IBM também saia do mercado dos dois países.

"Isso inclui descontinuar relações de parceria com organizações baseadas ou sediadas na Russia ou na Belarus.”

 A Red Hat e a IBM são apenas duas de muitas empresas que estão fechando seus escritórios de ambos os países; outras como Microsoft, Google, Apple  já fizeram o mesmo. Mas a Red Hat e a IBM não pararam por aí; a empresa anunciou também está prestando apoio a todos os empregados e associados da IBM/RedHat na Ucrania. 

“Ajudamos os Red Hatters na Ucrânia e suas famílias (incluindo cônjuges, filhos e familiares) a se mudarem com segurança para países próximos e continuamos a ajudar aqueles que permanecem no país de todas as maneiras possíveis. Somente nos últimos dias, os ônibus organizados pela Red Hat transportaram com segurança várias dezenas de familiares de nossos associados ucranianos através da fronteira para a Polônia. Também estamos apoiando nossos associados na Rússia*. E para qualquer Red Hatter que precisar, não importa onde você esteja, temos recursos adicionais de bem-estar disponíveis.”

"Ouvi histórias notáveis ​​sobre essas ações, incluindo um associado na Polônia que dirigiu  por várias horas em cada direção para pegar a esposa e o filho de um colega na fronteira com a Ucrânia e abriu sua própria casa para eles"

“Esse espírito de união e cuidado mútuo não me surpreende – já vi isso na Red Hat muitas vezes. É o que torna os Red Hatters tão especiais e o que me deixa orgulhoso todos os dias."

 Parabenizo a Reed Hat e a IBM por não virarem as costas e prestarem todo apoio possível a população ucraniana e população russa que acabaram sendo afetados.

*São 183 empregados na Russia. Slava Ukraini.

Mais sobre a Red Hat pode ser conferido aqui

https://www.redhat.com/en/blog/red-hats-response-war-ukraine

QUER APRENDER LINUX DE VERDADE? ENTÃO CONFIRA O MEU CURSO DE LINUX CLICANDO AQUI :) 

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

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Linux: Mais do que um Unix

Linux: MAIS DO QUE UM UNIX

    No artigo "O que define um Unix?" mostrei que Linux é um legitimo Unix, mas uma coisa que muita gente não sabe é que Linux se tornou mais do que um Unix possuindo sua própria API. Quando analisei o ext4 do HelenOS para descobrir se tratava-se do próprio filesystem do Linux ou feito do zero, uma das coisas que eu fiz foi exatamente tentar identificar em seu código algo específico do Linux. Para se ter uma ideia do que estou falando, reparem as linhas #include dos arquivos balloc de ambos os Ext4:

Arquivo balloc.c do Ext4 do Linux

Arquivo balloc.c do Ext4 do HelenOS

    Interessante MAS... para que possuir uma API própria se Linux já é um sistema operacional Unix? Ou seja, ele possui suporte as especificações POSIX e SUS assim como todos outros Unix. Para responder a essa pergunta é interessante ler a respeito dos mitos sobre o systemd que Lennart publicou em seu blog. E é aí que chegamos no mito de número 16:

16. Mito: systemd não é portável por razão nenhuma.

 Sem sentido! Utilizamos funcionalidade específica do Linux porque precisávamos dela para implementar o que queríamos. Linux possui tantos recursos que UNIX/POSIX não possuíam, e queríamos capacitar os usuários com esses recursos. Esses recursos são incrivelmente uteis, mas somente se eles são expostos de verdade de um jeito amigável ao usuários, e é isso o que fazemos com o systemd.

    Esse é o ponto chave; sua própria API lhe proporciona recursos que nenhum outro Unix possui (nem mesmo a própria POSIX). Foi graças a essa API que conseguiram implementar em apenas um ano recursos no systemd que ninguém conseguiu implementar no Upstart em seis (e nem no SystemV em 15).

Comparação de recursos entre SystemV, Upstart e systemd

    Agora a pergunta deve ter mudado para "mas que recursos são esses?". Vamos nos basear na entrevista que Lennart Poettering concedeu  ao FOSDEM em 2006 e que eu traduzi para vocês:

FOSDEM: Qual funcionalidade específica do Linux que o systemd utiliza e qual a vantagem dessa sobre uma solução que é portável para outros sistemas operacionais?

 Lennart Poettering: Há um monte de funcionalidades específicas do Linux que confiamos. A primeira que vem a mente provavelmente é o cgroups (abreviação de Control Groups) que é um recurso do kernel Linux que pode ser usado para criar processos de grupos hierárquicos, criar label para esses e opcionalmente aplicar limites de recurso ou outras regras para tais. Mas há mais um monte. O systemd íntegra muito bem com o sistema udev que é específico do Linux para eventos hot-plug. Outra, a solução para disk read-ahead incluímos nos usos do systemd, a fanotify() call também específica do Linux. Ou adicionamos suporte a processos spawning em seus próprios namespaces ou com definições limitadas de capacidades, ambas nas quais são features específicas do Linux. Ou adicionamos suporte ao automouter específico do Linux e outras APIs mount tal como polling mount changes via /proc/self/mountinfo na qual não existe em outros sistemas operacionais. Internamente nós utilizamos um monte de API calls mais novas, como a timerfd() ou signalfd() que não estão disponíveis fora do Linux. Essa últimas calls puderam ser emuladas em outros sistemas operacionais, mas utilizá-las simplifica muito o nosso próprio código. E muitos outros features do Linux que utilizamos não possuem contrapartidas adequadas em outros Unixes.

 Não ter que se importar com portabilidade tem duas grandes vantagens: podemos fazer máximo uso do que o kernel Linux moderno oferece nesses dias sem dores de cabeça -- Linux é um dos kernels mais poderosos existentes, mas muitos de seus features não tem sido utilizados pelas soluções anteriores. E segundo, ele simplifica muito bem nosso código e o torna menor: desde que nunca precisamos abstrair interfaces do sistema operacional, o montante de Código grudado (glue code) é mínimo, e consequentemente o que ganhamos é uma chance bem menor de gerar bugs, uma chance bem menor de confundir o leitor do código (consequentemente melhor manutenção) e uma footprint bem menor.

Linux API vs. POSIX API. Imagem extraída da Wikipedia.

 Muitos dos meus projetos anteriores (incluindo PulseAudio e Avahi) foram escritos para serem portáveis. Sendo aliviados das correntes que a exigência por portabilidade coloca em você é um tanto libertador. Enquanto que garantir portabilidade quando se trabalha em aplicações de alto nível não é necessariamente um trabalho difícil, se torna crescentemente mais  difícil se a coisa na qual você trabalha é um componente do sistema (os quais o systemd, o PulseAudio e o Avahi são).

 De fato, o jeito que eu vejo as coisas na API do Linux anda tomando o papel da API POSIX e o Linux é o ponto focal de todo o desenvolvimento de software livre. Devido a isso eu só posso recomendar aos desenvolvedores que tentam hackear somente com Linux em mente e experimentar a liberdade e as oportunidades que ele lhe oferece. Então, obtenha uma cópia do "The Linux Programming Interface", ignore tudo o que ele diz sobre compatibilidade POSIX e parta para a hack em seu surpreendente software Linux. É bastante aliviante!

FOSDEM: Qual é o ponto chave do systemd?

 Lennart Poettering: Não há apenas um, há vários. Já que eu não consigo listar, eu vou mencionar um único. Um que provavelmente surpreende muitos leitores: systemd é o primeiro init system do Linux que lhe permite matar um serviço corretamente. Surpreso com essa declaração? Mas é verdade. Matar uma daemon no Linux é realmente difícil e sem systemd é na verdade quase impossível fazer isso corretamente. (Não, um simples "killall httpd" é devido a muitas razões inadequadas de matar o Apache). Se você quiser saber porque, eu digo o que o systemd faz diferentemente aqui...

    Agora que já temos algum ponto de referência, podemos trabalhar em nosso estudo sobre tais recursos. Vou abordar mesmo os já mencionados por Lennart. Lembrando que se trata de pontos da parte de desenvolvimento, mas também irei tratar  sobre tais recursos de acordo com a visão de um sysadmin  e de usuários comuns (já que também é a razão pelas quais esses recursos existem).

CGroups 

    Já mencionado anteriormente, esse recurso foi inicialmente desenvolvido por engenheiros do Google com o nome de Process Container. E para evitar confusão com container, seu nome foi alterado (vale lembrar que quando falamos de container, não estamos tratando unicamente de Docker. O Red Hat Enterprise Linux 8 adota diferentes soluções de containers).

    No vídeo A Tragédia do systemd, Benno Rice (desenvolvedor do FreeBSD) menciona que a comunidade FreeBSD tem como argumento "mas nós temos o Jails no FreeBSD". Benno responde: "Sim tem, mas o Cgroups é muito mais granular, muito mais flexível." Além do systemd, o cgroups é utilizado por projetos como o Docker, o Firejail, o LXC e lmctfy.

D-Bus 

    É uma ferramenta para carregar aplicações e daemons sob demanda (somente quando os serviços são necessários), simplificar a forma como as aplicações se comunicam, ajudar a coordenar o ciclo de vida dos processos e tornar mais simples e mais confiável de codificar aplicações single instance ou daemons. A lista de projetos que fazem uso do D-Bus é enorme (em torno de uns 210 projetos no momento em que escrevo sobre o D-Bus) e podem ser conferidos clicando aqui.

Linux Namespace 

    Dado como a base fundamental dos containers, namespace (man 7 namespace) isola um recurso global do sistema em uma instancia tornando-o invisível a outros processos. Foi inspirado no Name Space do Plan9 (como sempre, o Plan9 contribuindo bastante).

    O Docker é a ferramenta mais famosa a utilizar o namespace (uma vez que o Docker faz na verdade, uso de ferramentas já existentes no Linux. E sim, Docker é especifico para Linux assim como o systemd).

namespace no Docker.

netlink

    Netlink é o responsável por realizar a comunicação (transferência de informações ou troca de mensagens) entre o kernel space e o user space (kernel space e user space é inclusive uma parte essencial que eu tratei no meu artigo 5 diferentes modelos de kernel).

O Netlink possui uma RFC (Request For Comments) de numero 3549 que pode ser conferida clicando aqui

    É composto por interface de sockets para processos do user space e uma API interna do kernel para os módulos do kernel. Também pode ser utilizado como IPC (InterProcess Communication) para permitir processos compartilharem dados entre si.

    O Netlink é uma ferramenta fundamental para o funcionamento Iproute2. tanto que em versões anteriores das distribuições como é o caso RHEL 6 (que tinham o Net-tools como padrão), além de ser necessário instalar o Iproute2, era também necessário configurar e compilar um novo kernel já que não vinham com a maioria dos recursos de controle trafego por padrão.

futex

    Abreviação de fast user-space locking, futex é a base para a construção de fast user-space locking, semaphores, mutexes, variáveis de condições, read-write locks, barriers, e semaphores. No caso o que o futex faz é coordenar o trafego das comunicações no user spcace. futex syscall surgiu no kernel Linux 2.5.7 e foi adicionado no OpenBSD 6.2, passou a ser emulado pelo FreeBSD (Algo também para o NetBSD) e implementado no Windows 8 e Windows server 2012 sob o nome de WaitOnAddress function (synchapi.h). 

https://docs.rs/linux-futex/0.1.1/linux_futex/struct.PiFutex.html

    Falando de Mutex, musl foi a primeira libc do Linux libc a possuir suporte a mutexes safe, condvars e working thread cancellation (todos recursos que foram ignorados por outras bibliotecas durante muito tempo).

    A musl possui suporte a vários desses recursos (conferir a linha Various Linux extensions. Linux extensions referem-se a kernel interfaces fornecidas pelo Linux fora do scope da POSIX e como o epoll, signalfd, extended attributes, capabilities, carregamento de módulo e assim por diante).

https://man7.org/linux/man-pages/man2/futex.2.html

https://man7.org/linux/man-pages/man7/futex.7.html

https://www.kernel.org/doc/html/latest/locking/mutex-design.html

Autofs

    O autofs é uma daemon utilizada para montagem automaticamente dos sistemas de arquivos (o que pode incluir sistemas de arquivos de rede, CD-ROMs, floppies e etc.) sob demanda através do automount e desmontá-los depois de um tempo que não estiver utilizando. A intenção do autofs é economizar recurso computacional e melhorar o desempenho (tentando evitar o uso do /etc/fstab).

man 5 systemd.automount

man 5 autofs

autofs na documentação da Suse

Seccomp (man 2 seccomp) 

    Abreviação de Secure Computing, o Seccomp serve para tornar o acesso a uma thread mais restrita à um numero pequeno de syscalls. De forma mais simples de entender, podemos dizer que o Seccomp é uma Sandbox. O Seccomp faz uso da system call BPF (Berkeley Packet Filters. man 2 bpf) como uma espécie de filtro para os programas. Há também a libsecomp que provê meios de facilitar o uso do Seccomp e do BPF.

    Há uma lista de programas que utilizam o Seccomp como o Android, o Qemu, o Docker, o Firejail, o Firefox, o Tor, o Flatpak e muitos outros.

Capabilities

    Iniciado no kernel 2.2, Linux Capabilities servem para verificação de permissões. São atributos especiais do kernel Linux que garantem privilégios administrativos específicos à processos e à binários que geralmente são reservados e destinados ao ID 0 (ou seja, o usuário root). O que o Capability faz é dividir os privilégios do usuário root em pequenas partes (em unities) garantido assim ao processo privilégios específicos e não todo os privilégios que o usuário root possui (algo parecido com o SUDO ou com os bits especiais, só que de forma mais restrita). Há em torno de 40 capabilities implementadas até o kernel 5.10.

    Capability não é algo exclusivo do Linux; os Unix de um modo geral implementam capabilities. A implementação do Linux é baseado em uma especificação POSIX para varias extensões de segurança dos Unix chamada IEEE Std 1003.1e (ou simplesmente POSIX.1e). Porém, por se tratar de sua própria implementação própria (além de haver extensões que são específicas do Linux), esse recurso entra para a nossa lista.

Udev

    Surgiu no kernel 2.6 como substituto o antigo devfs oferecendo uma base mais limpa e mais robusta de gerenciamento dos diretórios no /dev. O sysfs também surgiu o kernel 2.6 que é gerenciado pelo kernel para exportar informações básicas sobre dispositivos conectados recentemente sendo montado no diretório /sys (o udev pode fazer uso de informações do sysfs para criar device nodes correspondentes ao hardware relacionado).

    O systemd-udev faz uso  de instruções especificadas na regras do udev. Uma boa base de leitura sobre gerenciamento de dispositivos com o systemd-udev é esta aqui.

Evdev

    Como descrito em sua manpage, o evdev  é um driver do Xorg que cuida dos eventos de dispositivos de entrada em /dev/input. Possui suporte a mouse, teclado, tablet e touch‐screen. Existem também a libevdev e evdev para as linguagens Go e Python.

ALSA

    O ALSA (Advanced Linux Sound Architecture, traduzido para português do Brasil como Arquitetura Avançada de Som do Linux) é o servidor de áudio (e framework) responsável pela parte de áudio do Linux. O ALSA gerencia o acesso a placa de som (as interfaces de áudio) e permite que outros programas como esd, aRTs (descontinuado), JACK e o PulseAudio façam acesso às interfaces.

    Foi o substituto do antigo OSS (Open Sound System) da 4front Technologies (apesar que seu ultimo lançamento foi em 2019 para o kernel 4.15). Eu e um amigo debatemos o motivo desta transição em uma série chamada Assunto games (bastando clicar aqui) e lá o Anderson explica as limitações que ocorriam no OSS.

DRM

    DRM é um módulo do kernel que permite acesso direto ao hardware (algo parecido com o que acontece com sistema operacional exokernel). Surgiu no kernel Linux 2.2.18, o DRM fornece vários serviços gráficos a drivers de vídeo (que incluem gerenciamento de memória, gerenciamento de saída, de framebuffer, serviços de DMA e muito mais) através da biblioteca libdrm. O DRM também fornece gerenciamento a monitores através do Kernel Mode-Setting (KMS).

 O DRM é tão interessante que foi portado para o DragonflyBSD como pode ser lido no texto abaixo:

    Existem outras APIs voltadas ao serviço gráfico como V4L2 (Video For Linux) e o FBDEV (Linux framebuffer) que surgiu no kernel 1.3194 e ambos também são específicos para Linux.

epoll

    A API epoll permite as aplicações monitorarem múltiplos descritores de arquivos para determinar quais descritores estão preparados para realizar entrada e saída de forma mais eficiente que as antigas syscalls select() e poll() que apresentavam ser pobres para as aplicações de redes modernas, ter pobre desempenho devido ao seu  design e entregavam ao kernel uma lista completa com todos os descritores de arquivos (que a cada chamada, tinha que ficar reexaminando a mesma lista). epoll Essa é uma das dependências do Wayland. O FreeBSD possui um recurso similar chamado kqueue. O NetBSD também possui possui patches para o kqueue no pkgsrc mas que na época que anunciaram que planejavam portar o Wayland, essses patches não haviam sido aceito upstream.

timerfd

    O propósito do timerfd é que, uma vez que uma API se torna disponível no user space, ela deve possuir suporte indefinidamente para todos os propósitos sem quebrar as aplicações. Já que há vezes que essas regras são quebradas, mesmo em áreas conhecidas para distúrbios como o sysfs, para isso foi criado o timerfd e assim manter maior integridade dos arquivos.

    O timerfd permite que uma aplicação possa obter os descritores de um arquivo para utilizar com eventos e assim eliminar a necessidade de sinais (signals). Já o signalfd é o responsável por criar descritores que podem ser utilizados para aceitar os sinais. Os sinais a que me refiro são por exemplo utilizados no comando kill como podem ser conferidos na manpage man 7 signal.

Linux Security Module

    Linux Security Module (LSM) é um framework de segurança ao kernel. São na verdade extensões de segurança do kernel e não módulos que fornecem interface de politica de segurança MAC (Mandatory Access Control). Dentre eles temos o SELinux (o mais famoso deles sendo utilizado por padrão pelo RHEL, o Fedora e o CentOS); o AppArmor utilizado por padrão no Debian, o LoadPin, o Smack, o TOMOYO, o Yama e o SafeSetID.

Integrity Measurement Architecture

    O Integrity Measurement Architecture (ou simplesmente IMA) serve como subsistema de integridade do kernel que detecta se arquivos foram alterados acidentalmente ou maliciosamente, sejam remotamente ou localmente. O IMA faz parte dos módulos LSM anteriormente mencionados.

http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture

https://sourceforge.net/p/linux-ima/wiki/Home/
https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
https://lwn.net/Articles/137306/
https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture

https://blog.linuxplumbersconf.org/2009/slides/David-Stafford-IMA_LPC.pdf

https://dl.acm.org/doi/10.1145/3407023.3407058

fanotify

    Fanotify também conhecido como o fscking e anteriormente conhecido anteriormente como TALPA, tem como propósito principal servir de scanner de malware no Linux (viruses, root kits, spyware, ad-ware e etc...) "Ué, mas Linux não tem vrius" (sabe de nada inocente). Surgiu na Red Hat em 2008 devido na época o kernel Linux não oferecer uma interface completamente adequada para implementar tais soluções de segurança. Esta ferramenta foi desenvolvida inclusive para atender as necessidades de muitas empresas que fornecem serviços de ati-malware.

https://lwn.net/Articles/339399/

https://support.sophos.com/support/s/article/KB-000034610?language=en_US

CONCLUSÃO

    A maioria dos apaixonados afirmam que Linux não é um Unix.  E honestamente elas estão certas; Linux não é um Unix; Linux é mais do que um Unix. Linux não se limitou somente a o que todos os outros os Unix são ou tinham a oferecer. Linux resolveu explorar melhor o seu potencial.

    Além de ser melhor do que muitos sistemas operacionais em várias áreas (SMP, desempenho, redes, virtualização e muitas outras áreas), ainda agregou recursos que o permitem abranger áreas que seriam inimagináveis a outros sistemas operacionais.

    No artigo "The Hurd and Linux" do site gnu.org é descrito que Linux é arquiteturalmente igual ao kernel Unix e que o trabalho do projeto GNU se direciona a algo muito mais poderoso. O argumento apresentado por Richard Stallman baseia-se na proposta da arquitetura do microkernel (caso não entenda o que é microkernel, sugiro a leitura do meu artigo sobre 5 modelos diferentes de kernel) e que até hoje não aconteceu. Treze anos depois do lançamento do Linux, foi escrito o livro Open Life (traduzido pra inglês por Sara Torvalds, a própria irmã de Linus torvalds) e até então, nada do Hurd se apresentar... Mais de dezesseis anos depois do lançamento do livro Open Life, e o Hurd ainda não demonstra nem sinais de lançamento de uma versão estável. Não adianta acreditarem que o micrkernel é algo mais poderoso focado simplesmente no isolamento do kernel e carecendo de recursos.

    Não dá para debater todos os recursos aqui neste artigo pois, como Michael Kerrisk descreve em seu livro Linux programing Interface, são mais de 500 system calls e library functions e acredito que tudo isso já serviu de uma boa abordagem para entender como Linux é poderoso.

The Linux Kernel API
https://www.fsl.cs.sunysb.edu/kernel-api/
Os 5 diferentes modelos de kernels

Linux APIs
LINUX's History
https://en.wikipedia.org/wiki/Category:Linux_APIs

http://www.infradead.org/~tgr/libnl/

https://wiki.linuxfoundation.org/networking/generic_netlink_howto

https://netfilter.org/projects/libmnl/

https://web.archive.org/web/20110902031641/http://1984.lsi.us.es/~pablo/docs/spae.pdf

https://www.linuxjournal.com/article/7356

https://www.ietf.org/rfc/rfc3549.txt

https://www.infradead.org/~tgr/libnl/

https://www.linuxbnb.net/home/adding-a-system-call-to-linux-arm-architecture/

Flags as a system call API design pattern

 QUER APRENDER A UTILIZAR O BTRFS NO FEDORA, ENTÃO VENHA APRENDER LINUX COMIGO ;)

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