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

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).

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.

Feliz aniversário de 30 anos, Linux




    Em março deste ano a Linux Foundatio publicou imagens para celebrar os trinta anos do Linux. Essas informações podem ser lidas clicando aqui.

    30 anos atrás neste mesmo dia, Linus Torvalds publicava sua segunda mensagem sobre o Linux. Em uma entrevista de 2008 ao Museu da Historia do computador, Linus afirma que estava trabalhando na verdade trabalhando inicialmente em um clone do Minix já que as coisas no Minix eram horríveis e ele desenvolvia suas próprias versões das mesmas coisas do Minix (driver de discagem de internet, de HD, de sistema de arquivos e tudo) para seu emulador de terminal, só que verões melhores das mesmas coisas.

 Foi daí que em um determinado momento Linus decidiu desenvolver um kernel para ter o seu clone do Minix porém esse clone do Minix se transformou em um clone do Unix e Linus Torvals dispara esta mensagem no dia 3 de Julho e não deixava claro que estava trabalhando no Linux:


  Devido a um projeto que estou trabalhando (no minix), estou interessado na definição do padrão posix. Alguém poderia me indicar um formato (de preferência) legível por máquina das regras de posix mais recentes?
     Sites FTP seriam bons.

 Esta mensagem não deixa bem claro que Linus estava desenvolvendo um clone do Unix e por isso as pessoas demoraram a responder. Então Linus passou a utilizar os manuais POSIX da Sun Microsystems que ele conseguiu na biblioteca da universidade de Helsinki. Até que depois de um tempo as pessoas o enviaram os manuais para trabalhar em seu sistema operacional. Ari Lemke (o verdadeiro autor do nome Linux) leu a mensagem acima e disponibilizou o subdiretório FTP para da universidade para Linus com o nome de Linux (foi a partir daí que o sistema operacional, que iria se chamar Freax, passou a se chamar Linux).

    Então, no dia 25 de Agosto, quando  Linus se sentiu seguro de disponibilizar o seu código fonte, era publicado a mensagem de lançamento do kernel 0.01
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: O que vocês mais gostariam de ver do minix?
Summary: pequena enquete para meu novo sistema operacional
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki
Olá a todos aí fora utilizando minix –

    Estou fazendo um sistema operacional (livre) (apenas um hobby, ele não vai ser grande e profissional como o GNU) para clones AT 386 (486). Ele está fermentando desde abril e está começando a ficar pronto. Eu gostaria de qualquer feedback sobre coisas que as pessoas gostam/não gostam no minix, já que meu sistema operacional se assemelha um pouco com ele (mesmo layout físico do sistema de arquivos (devido a razões práticas) entre outras coisas). Eu já portei o bash (1.08) e o gcc (1.40), e as coisas parecem funcionar. Isso implica que vou conseguir algo prático em alguns meses e gostaria de saber quais recursos a maioria das pessoas gostaria. Todas as sugestões são bem-vindas, mas não prometo que as implementarei :-)

Linus (torvalds@kruuna.helsinki.fi)

PS. Sim - é livre de qualquer código minix e tem um fs multi-thread. NÃO é portável (usa comutação de tarefas 386, etc.) e provavelmente nunca suportará nada além de discos rígidos AT, já que é tudo o que eu possuo.
    E aqui estamos hoje. Um hobbie que começou em seu quarto como um projeto pessoal e acadêmico  e que evoluiu e se tornou o maior projeto colaborativo da história do mundo.



Engenheiros da Amazon começam a trabalhar em um novo recurso de memória para Linux

Engenheiros da Amazon começam a trabalhar em um novo recurso de memória para LinuxEngenheiros da Amazon começam a trabalhar em um novo recurso de memória para Linux
Engenheiros da Amazon começam a trabalhar em um novo recurso de memória para Linux (fonte da imagem da memoria RAM: pngegg

    Engenheiros da Amazon andam trabalhando em um recurso para Linux chamado DAMON que serve para monitoramento de acesso que lida com sistemas que possuem alto carregamento de memória. DAMON é um framework que torna o motor de gerenciamento a acesso de dados da memória mais útil para ambientes de produção e implementa um módulo estático do kernel para recuperação proativa leve utilizando esse motor.

    De acordo com send Request enviado, a empresa Google (agradeço ao Helio Loureiro por ter revisado o erro para mim) já implementa a mesma ideia em seu data center para eliminar altos consumos de CPU e memória e por fim a empresa propôs o solução no evento LSFMM'19. DAMOS melhora o limite de velocidade, a priorização e o uso de Watermarks. Ele encontra regiões na memória que não são acessadas por um específico espaço de tempo e limpa a página.

    Alguns problemas ainda existentes são o fato de que a versão atual do DAMOS só possuir suporte a endereçamento de espaço virtual; já esse novo patchset trás suporte a acesso endereçamento físico. O controle muito agressivo que pode causar em overhead arbitrário.

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.
 QUER APRENDER A UTILIZAR LINUX DE VERDADE, ENTÃO VENHA APRENDER COMIGO ;)
    No kernel Linux 5.12 o recuso DAMON_RECLAIM (que é o recurso que é executado para a limpeza de memória) com ZRAM e speed limit de 10GB/s, puderam ter ganho de 32% com a o uso apenas de 1.91% de sobrecarga. O consumo total do DAMON (especificamente o DAMON_RECLAIM) é de 5.72% em single CPU time e o consumo total de CPU para om monitoramento fica em torno somente de 1,448%. Já o DAMON_RECLAIN sem speed limit ativado atinge ganho de 46.50% de memória mas incorre no consumo de 11% de CPU time e resulta na perda de 4.79% de desempenho do fluxo de trabalho.

    Será possível controlar o DAMONS através da linha de comando e ou através do sysfs (/sys/modules/damon_reclaimparameters/).

Kernel Linux 5.12 e novidades no Btrfs

Kernel Linux 5.12 e novidades no Btrfs
Kernel Linux 5.12 e novidades no Btrfs

    Não é nada de novidade que o kernel Linux 5.12 foi lançado, mas alguns recursos são tão interessantes que decidi bater um papo explicando o que gostei. Muitos mencionam somente sobre o suporte a joystick Dualsense do PlayStation5, mas o kernel 5.12 traz novidades muito interessantes como o suporte ao Zoned, o suporte a Idmapped mounts e muito mais. Se perdeu a live, confere aí embaixo que está bem interessante.


Linux: Mais do que um Unix

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:

balloc do Ext4 do Linux
Arquivo balloc.c do Ext4 do Linux
balloc do Ext4 do HelenOS
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:

Mito: systemd não é portável por nenhuma razão. 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 possuem, 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.
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).
    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.
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 systemdBenno 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.



    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.
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).
    É 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.

Communicating between the kernel and user-space in Linux using Netlink sockets

    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)

    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).



    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).


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 é 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:

In 2012 François Tigeot and a dedicated group of helpers began retooling DRM (the graphics subsystem) with an active port from Linux, slowly bringing DragonFly up to modern standards. As of 2015 fully accelerated 2D, 3D, and video support is operational with Xorg. At around the same time there was also a concerted effort to upgrade the sound system with a major HDA port from FreeBSD. Graphics, Video, and Sound have turned DragonFly into quite a nice desktop.

    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.




    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.


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.
https://www.linuxbnb.net/home/adding-a-system-call-to-linux-arm-architecture/

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 (16) 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)