PX5: Um dos melhores RTOSes do mercado

PSX5: Um sistema operacional Real Time ótimo para embarcados

PX5: Um sistema operacional Real Time ótimo para embarcados

 Em 2017 eu havia postado um artigo que, devido ao tamanho do Linux, RTOSes (Real Time Operating System = Sistemas Operacionais em Tempo Real) estavam ganhando mais destaque em IoT do que o Linux. Foi apresentado soluções de reverter essa situação reduzindo tanto o tamanho do kernel quanto do filesystem. Mas os RTOSes voltam a ganhar destaque; especificamente o PX5.


 O PX5 é um RTOS da quinta geração projetado para aplicações em embarcados como semáforos, mutex, fila de mensagens e IoT. Focado em tamanho, desempenho, segurança e proteção reduzindo o time-to-market, melhorando a qualidade de firmware e aprimorando a portabilidade entre plataformas.

 No site oficial do PX5 é descrito que:

 "Liinux é um dos sistemas operacionais mais populares no ambiente de embarcados detendo a marca de 70% deste mercado. Porém Linux é muito intensivo no uso de memória e de processamento dentro deste tipo de plataforma".

 E não; antes que algum apaixonado se manifeste, utilizar Rust NÃO solucionaria este problema. O que pode ocorrer na verdade é o contrario; os binários Rust são simplesmente enormes. A ideia do PX5 é trazer as pthreads da API POSIX encontrada em embarcados Linux para dentro do RTOS em dispositivos com recursos limitados.

PX5 RTOS + Linux Pthread
PX5 RTOS + Pthread do Linux

 Por esse motivo, o PX5 foi construído sobre a implementação das pthreads e tambem oferece extensões real-time como event flagsqueues rápidascronômetros, e gerenciamento de memória

 Implementado sob funções da linguagem C, PX5 é um dos menores RTOSes dependendo de menos de 1KB de FLASH e 1KB de RAM em microcontroladores de 32 bits à 80MHz. O PX5 também é extremamente rápido e eficiente podendo completar o seu carregamento em menos de um microsegundo (podendo ser instalado e utilizado em minutos) além de conseguir determinar quais threads serão ou não necessárias para o dispositivo.

 O PX5 é projetado explicitamente para segurança em proteção incluindo a tecnologia patent-pending Pointer/Data Verification (PDV) que é uma técnica que ajuda a detectar e mitigar corrupção de memória intencional ou acidental. 

PX5 design
Design do PX5

 Seu código é também simples e fácil de manter. Devido sua API consistir em implementações nativas da pthreads POSIX, suas aplicações são facilmente portáveis tanto para Linux quanto para outros RTOSes. Muitas empresas já são parceiras do PX5 tanto em provedores de núvem, Semiconductores, embarcados e consultorias. Há também o Zephyr que é financiado pela Linux que eu pretendo abordar aqui no blog. Até a próxima, povo.


Dois novos recursos para o Zsh

Sebastian Gniazdowski desenvolveu dois novos recursos para o Zsh, o Zsh Angel IQ System e o Zinit-4. O Zinit 4 é um gerenciador de plugin do Zsh flexível e rápido que lhe permite instalar qualquer programa vindo do GitHub e de outros sites. Zinit 4 é atualmente o único gerenciador de plugin que fornece turbo mode que produz uma inicialização do Zsh 50-80% mais rápida e há relatos de o Zsh ser inicializado até cinco vezes mais rápido.


Sebastian aconselha a não utilizar outra fonte do Zinit uma vez que outra foi encontrada e aparenta ser um projeto chinês suspeito. Há também o branch de zdharma-continuum que Sebastian chegou a enviar commits porém eram recebidos de forma demorada e ao ponto que já não estavam mais recebendo. Sebastian então resolveu reiniciar o Zinit como um fork já que tem planos para ele.

 Outro projeto de Sebastian é o Zsh Angel IQ System é um conjunto de extensões inteligentes do próprio Zsh. entre os vários recursos estão o Smart Console que gera uma interface de texto para configurações (assim como o comando aptitude).



puzzleFS: Um container filesystem

puzzleFS: Um container filesystem

puzzleFS: Um container filesystem

 PuzzleFS é um novo sistema de arquivos projetado especificamente para o emprego de containers. De autoria do engenheiro de software romeno Ariel Miculas que trabalhar na  Cisco, se inspirou no filesystem de Wedson Almeida Filesystemo puzzlefsfoi projetado para solucionar problemas de limitações existentes no formato OCIv1 como tamanho dos arquivos seja com ou sem compressão junto com o fs-verity para garantir a integridade. Para isso, Ariel Miculas utilizou o design do OCIv2 que soluciona muitas das falhas da versão anterior e que podem ser lidas aqui.

 O principal foco do projeto é reduzir a duplicação, o que até então não há nada de novidade como pode ser Llido aqui no blog sobre deduplicação). O que pode ser o diferencial é a técnica utilizada no puzzlefs que no caso é o algoritmo FastCDC.

 O puzzlefs foi desenvolvido na linguagem Rust para fazer uso de segurança de memória (o que na verdade também é possível com outras linguagens né, mas está valendo).


 E por ultimo, o puzzlefs compartilha o mesmo código entre user space e kernel space. Atualmente só é possível o puzzlefs através do FUSE (userspace filesystem ).


Mais sobre deduplicação aqui no blog

PuzzleFS container filesystem

PuzzleFS filesystem driver no site Rust for Linux




Lançado glaucus v3

glaucus-s6-x86-64-v3-20231002

Lançado glaucus v3


 No dia 02/10 foi lançada a versão 3 da distribuição Glaucus (especificamente glaucus-s6-x86-64-v3-20231002). Essa versão se tora um marco importante na história da distribuição pois é a primeira vez que estão lançando uma ISO. A ISO possui suporte a boot tanto a BIOS/MBR quanto a UEFI mas ainda em versão beta e no formato somente leitura. Provavelmente no futuramente terá suporte ao overlayfs para leituta-/escrita e ao EROFS. Com isso, a distribuição Glaucus passa a ser self-hosting e acaba reduzindo a quantidade de pacotes necessários para o boot e tornando-a mais rápida e menor.

 mdevd se tornou a implementação padrão do udev e a libudev-zero se tornou a implementação padrão de libudev. Muon se tornou o meson padrão; o kernel Linux utilizado nesta versão vem dos repositórios da distribuição Arch

 Mais de 79 pacotes são estão disponíveis para uso. Algumas observações que devem ser feitas é que a ISO é compactada com zstd, então leia as instruções de como desempacotá-la. A equipe também aconselha utilizar blake3 para fazer verificação checksum (b3sum glaucus-s6-x86-64-v3-20231002.img.zst).

 Após o boot, você estará logado automaticamente como root. Para alternar entre os terminais, use a sequencia de telcas ALT + arrow esquera/direita. Para confirguar a rede, basta seguir os comandos ip link set eth0 up e sdhcp eth0.

Qual a diferença entre Low Latency e Real-Time no Linux?

Qual a diferença entre Low Latency e Real-Time no Linux?

Qual a diferença entre kernel Low Latency e kernel Real-Time no kernel Linux?


 Com o lançamento do Ubuntu vindo com kernel real-time, surgiu em minha ultima live a duvida na diferença entre kernel Low Latency e kernel Real-Time no Linux. E se trata de uma pergunta muito interessante já que ambos proporcionam performance. Então, o que diferencia um do outro? Aqui vamos nós tentar explicar. 
Primeiro, o que temos que entender é que ambos são real-time. Como já dito, ambos foram desenvolvidos para proporcionar melhor performance, porém, com características e propostas diferentes. Vamos então entender primeiro o que é o real-time.

Kernel real-time

 O kernel real-time visa garantir o máximo de resposta dentro do menor tempo possível. De acordo com a documentação do RHEL8"em muitas cargas de trabalho, o ajuste completo do sistema melhora a consistência dos resultados em cerca de 90%." ... "Ajustar o kernel padrão produzirá 90% dos possíveis ganhos de latência. O kernel Real Time fornece os últimos 10% de redução de latência exigida pelas cargas de trabalho mais exigentes."


 Mas há um problema com o real-time. O kernel real-time pode acabar sacrificando o rendimento e a eficiência energética. Na mesma documentação da Red Hat descreve que "Há alguma sobrecarga adicional do kernel associada ao kernel real-time. Isto se deve principalmente ao tratamento de interrupções de hardware em threads agendados separadamente. O aumento da sobrecarga em algumas cargas de trabalho resulta em certa degradação no rendimento geral. A quantidade exata depende muito da carga de trabalho, variando de 0% a 30%".

Kernel Low Latency

 Já o kernel low latency tem como propósito priorizar as tarefas mais sensíveis e minimizar o tempo que os processos são executados (essa é a ideia de low latency – reduzir o tempo de resposta). De certa forma, low letancy acaba tendo o desempenho um pouco menor, porém, tendo melhor garantia. O kernel low latency é ideal para quem quer trabalhar com aplicações multimédia, jogos, entre outras, mesmo consumindo mais energia que o kernel genérico. Para se ter uma ideia do ganho de performance com o kernel low latency e da garantia de eficiência de energia, é que ele é utilizado até mesmo em embarcados.

Conclusão

 O kernel low latency também é real-time assim também como o kernel real-time também é low latency (ambos focam em performance) e isso pode inicialmente confundir a cabeça das pessoas. Porém, apesar do proposito de ambos ser o mesmo, cada um foi projetado com propostas diferentes, o que acabou por definir a distinção. Se você precisa de performance sem sacrificar eficiência energética, o kernel low latency é a melhor opção enquanto o kernel real-time serve mais para ambientes críticos onde o tempo faz toda a diferença. Já eficiência energética e calor gerado por isso acabam não sendo o problema sendo que esses ambientes são refrigerados.

 Quero aproveitar e indicar o projeto tuned que permite otimizar seu computador para obter melhor desempenho através de seus recursos como latency-performancy ou network-latency, permite otimizar seu desktop, para uso de streaming e muito mais.


O comando tuned-admin
O comando tuned-admin


A lista de recursos do tuned
A lista de recursos do tuned

É possível rodar Doom em um teste de gravidez?

Doom running on a pregnancy test

É possível rodar Doom em um teste de gravidez?

 Doom deve ser o jogo mais portado que eu já vi na minha vida (isso eu já não sei, vou passar a bola para vocês) porque, eu nunca vi um jogo rodar em tanto lugar que chega a ser inútil. Só que esse em um teste de gravidez me surpreendeu e eu acabei postando o vídeo abaixo:


 E duas perguntas nos comentários me despertaram o interesse de escrever este artigo. Essa proeza foi feita por uma mulher conhecida como Foone que utilizou um teste de gravidez suíço. Este teste possui um microcontrolador Holtek HT48C06 de 8-bit rodando entre 4mhz a 8mhz , 64 bytes de RAM, 1024 palavras de ROM e GPIO de 13 pinos além da bateria de 3v, LEDs e display de cristal liquido.





 Se levarmos em consideração, esta pequena placa é mais poderosa do que o primeiro IBM PC (que depois que urinam, simplesmente jogam fora...). Foone ainda descreve que esse é um chip complexo do que imaginamos por utilizar pipeline e operar uma instrução por ciclo (o que lhe garante bom desempenho), porém, esse chip não é reprogramável e o LCD só exibe quatro objetos (o display não consegue nem enquadrar a shell); logo, na verdade, não há como rodar Doom nesse pequeno hardware. O que Foone fez foi conectar o dispositivo à uma protoboard, substituir tanto o display quanto o microcontrolador e realizar alterações.


 Foone menciona é que "conseguiu exibir um vídeo de Doom no dispositivo, o que não deixa de ser algo próximo mas não interativo". Todos os vídeos de Foone foram postados no site archive.org. Há inclusive um rodando o vídeo I wanna give you up:



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

This is a collection of the unix tools that nobody thought to write long ago, when unix was young.

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


 moreutils, como já descrito no título deste artigo, é uma coleção de ferramentas Unix que ninguém pensou em escrever muito tempo atrás quando o Unix era jovem. Essas ferramentas foram escritas por Joey Hess (veja sua entrevista no LWN.net) que foi um desenvolvedor de respeito do Debian e apaixonado pela linguagem Perl que se questionava se não haveria mais espaço para novas ferramentas em sua caixa de ferramentas do Unix (não o manual que eu escrevi, o conjunto de ferramentas do Unix mesmo). A ideia de Joey é não deixar que certas ferramentas caiam no esquecimento.

 No exato momento, o pacote mais atual inclui as seguintes ferramentas:
  • chronic: executa um comando silenciosamente, a menos que ele falhe
  • combine: combina as linhas de dois arquivos usando expressões booleanas
  • errno: procura nomes e descrições de errno
  • ifdata: pega informações da interface de rede sem verificar a saída do ifconfig
  • ifne: executa um programa se a entrada padrão não estiver vazia
  • isutf8: verifica se um arquivo ou entrada padrão é utf-8
  • lckdo: executa um programa com um "lock held"
  • mispipe: encadeia (pipe) dois comandos, retornando o status de saída do primeiro
  • parallel: roda vários jobs de uma vez
  • pee: faz "tee" da saída padrão para encadeamentos (pipes)
  • sponge: limpa a saída padrão e manda pra um arquivo
  • ts: Insere etiquetas de tempo na entrada padrão
  • vidir: edita um diretório em seu editor de texto
  • vipe: insere um editor de texto em um encadeamento (pipe)
  • zrun: descomprime argumentos para um comando

 De acordo com Joey, sua ferramenta mais popular provavelmente seja o comando sponge que lhe permite realizar coisas como % sed "s/root/toor/" /etc/passwd | grep -v joey | sponge /etc/passwd (mas tome cuidado, este processo deve ser realizado como root).

 O moreutils está disponível no repositório do Debian ou clonado do github do Joey (git://git.joeyh.name/moreutils ou podendo também ser conferidos mais detalhes clicando aqui). Algumas ferramentas precisam ser compiladas enquanto outras são scripts Perl.


 O processo de compilação é simples bastando apenas utilizar o comando make. O único conselho que eu dou é: explore bem as opção do make como é o caso da opção CFLAGS.



 O que eu não gostei foi alguns comandos não ter informações de suas opções (odeio isso) e para entender com eles funcionam, ao menos é possível conferir alguns exemplos no próprio site do Joey.

Marcadores

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