Feliz 28º aniversário FreeDOS

Happy 28th year FreeDOS

Feliz 28º aniversário FreeDOS


 Hoje, dia 29 de Junho, o sistema operacional FreeDOS. FreeDOS é um clone do antigo sistema operacional DOS da Microsoft e que se mantem em pleno desenvolvimento e atualizado. Quando digo atualizado, digo até mesmo receber suporte a novos recursos (inclusive a ssh e GUI) e a hardware.


E por que alguém iria querer utilizar ou manter um sistema tão antigo? Não sei, talez por necessidades específicas como eu mesmo já presenciei entre 2012 e 2014. Existe até mesmo uma tabela comparando a base de cliente do FreeDOS com a Windows 10 em torno do mundo e pode ser lida clicando aqui. Vale lembrar que recentemente mostraram que há um satelite rodando Windows 98 e que precisa receber atualizações. O que você faria se essa bucha caisse na sua mão?

Flappy Bird rodando no FreeDOS

 Independente do seu gosto por sistemas operacionais, eu quis prestar uma homenagem ao FreeDOS por ser um sistema operacional open-source e devido seu mascote fazer referencia ao Linux (já que o mascote do Linux é um pinguim, a do FreeDOS é um peixe). O site opensource.com prestou uma homenagem também tendo disponibilizados dois manuais em pdf e epub e escrito um artigo que pode ser lido clicando aqui.


Android 13 pode receber ExFAT no lugar do FAT

FAT can be replaced by ExFAT on Android 13

Android 13 pode receber ExFAT no lugar do FAT

 Em Maio eu publiquei que o Android 13 poderia ter o sistema de arquivos ext4 substituído pelo ERFS da Hawei. Agora há rumores que o FAT também poderá ser substituído pelo ExFAT também. Se é verdade ou não, eu não sei pois não encontrei fontes sobre o assunto (caso você tenha encontrado no site do Google, deixe nos comentários para nos ajudar).

 Mas caso essa informação seja verdadeira, A empresa Google irá fazer um grande favor para todos nós. Vale lembrar que em Abril a Sony enviou vários patches para o Linux melhorando enormente o desempenho do ExFAT.

 O Android 13 será lançado em breve, enre o final de Julho e meados de Agosto e trará muitas novidades que podem ser conferidas no próprio blog clicando aqui.

Android 13 release preview
Previsão de lançamento do Android 13


Lançado bc 5.3.2 e 5.3.3

Gavin Howard's bc 5.3.2 and 5.3.3 released

Lançado bc 5.3.2 e 5.3.3

 Mal foi lançado bc 5.3.0 e 5.3.1 e no dia 14 de Junho foram lançadas as versões 5.3.2 e 5.3.3. A versão 5.3.2 traz uma correção de bug no prompt com editline e readline (recursos que apareceram na versão 5.3.0) onde a váriável de ambiente BC_PROMPT não estava sendo respeitada. Essa correção influencia também na saída editline e readline no EOF. A versão 5.3.3, assim como a 5.3.1, corrige um problema no port do bc para FreeBSD. Caso você não utilize FreeBSD, não tem com o que se preocupar.

Compilando o meu próprio bc 5.3.3

Compilando o meu próprio bc 5.3.3


Lançado bc 5.3.0 e 5.3.1


 Gavin Howard é bem dedicado no cuidado de desenvolver o comando bc. Hoje (dia 10/06/2022) Gavin lançou duas versões; a versão 5.3.0 as 12:00 (09:00 da manhã aqui) e três horas depois (14:48:29 MDT. 11:48:28 GMT aqui) a versão 5.3.1.

 Na versão 5.3.0 foi adicionado novos recursos e novas correções de bugs passando a ter suporte a editline e readline history; suporte a opções de linha de comando de definir scale, ibase, obase, e seed (algo que Gavin afirma que discordava da ideia mas que foi solicitado há um bom tempo). A versão do Windows recebeu correção no history foi e reabilitado; manuais recebram correções de informações e formatos diferentes para serem mais confiáveis. 

The -e (editline) option inside configure file
Opção -e (editline) no arquivo configure

The -r (readline) option inside configure file
Opção -r (readline) no arquivo configure

 Já a versão 5.3.1 recebeu a correção de um problema na implementação para FreeBSD (sua maior base de usuários) e também um problema no en_US locale.

 Pode ser que a versão 5.3.0 já está boa o suficiente para você caso não utilize FreeBSD (ou pode ser que que não. Quem garante que não vá precisar utilizar FreeBSD e precise da versão 5.3.1. Sempre peque pelo excesso e não pela falta).

 Para habilitar o recurso editline, basta utilizar a opção -e no arquivo configure.sh-r para readline.

Option editline enabled during the configuration process.
Na primeira linha selecionada de branco, é possível ver que eu escolhi a opção -e e na segunda, a opção BC_ENABLE_HISTORY=1 que significa que o editline foi habilitado (0 significa não habilitado)

 Eu gostaria de dedicar este artigo à Lorinda Cherry, uma das autoras do bc e do dc que faleceu em Fevereiro de 2022 aos 77 anos. Lorinda aparece no famoso vídeo UNIX: Making Computers More Productive - AT&T Archives film from 1982, Bell Laboratories entre os autores do unix Kan Tompson e Dennis Ritchie (Lorinda também merece este mérito). Sua pesquisa sobre dc e bc pode ser conferida clicando aqui.


Laçado DragonFly 6.2.2

DragonFly 6.2.2 released

Laçado DragonFly 6.2.2

 Essa é uma versão de correções. Foram o total de 15 sendo cinco no kernel (além do recurso temporário para problemas relacionados a vnode. Uma das correções também está relacionada ao vnode, mas uma correção intermediária), seis no Hammer2 (e um recurso de report), uma no tmpfs, uma na  libc (além dos novos recursos no stdtime caso haja um overflow e o aumento opendir/readdir buffer size), uma no last (man 1 last) relacionada a uma quebra que ocorre quando time_t fica fora do range e uma no ipfw relacionada a redes mistas e especificações de IP de host nas tabelas de ip. Houveram pequenas melhorias também como a adição de nova configuração no dsynth e sincronização do zoneinfo database com o tzdata2022a do iana.


Analisando 6 diferentes implementações do comando sed

Different implementatins of sed command

Analisando e comparando seis diferentes implementações do comando sed


 Em abriu deste ano eu escrevi o artigo minised: Um sed melhor do que o sed. sed é um comando que como seu próprio nome sugere (Stream EDitor), serve para editar/alterar as informações que são exibidas em sua tela (observação que deve ser feita é que arquivos acessados através do sed não são modificados, apenas a forma como as informações são exibidas; a não ser que as informações exibidas sejam redirecionadas ao arquivo de origem). sed Foi um dos primeiros comandos desenvolvidos para o Unix para processamento de dados e, conforme o e-mail de lançamento do kernel Linux 0.02 "intitulado Códigos livres de kernel parecido com minix para AT-386" no grupo comp.os.minix, é descrito que sed também foi um dos primeiros comandos a ser utilizado pelo Linux:

"Ainda está na versão 0.02 (+1 (muito pequeno) patch já), mas executei com sucesso bash/gcc/gnu-make/gnu-sed/compress nele."

 O gnu-sed é a implementação utilizada na maioria das distribuições Linux porém, como existem diferentes implementações do mesmo comando (assim como existem diferentes implementações de todos os comandos e de todas as ferramentas), eu resolvi analisar e comparar ao menos seis delas apresentando aqui neste artigo os resultados de cada uma.

 Eu analisei o gnu-sed 4.8 disponível no Fedora 35 (sed-4.8-8.fc35.x86_64); o minised 1.16 já apresentado aqui no blog; o Busybox_SED que apesar de ter originado do gnu-sed, já não possui uma unica linha de código do do gnu-sed; logo não tendo mais nenhuma relação um com o outro (para entender melhor sobre esse caso, leia o meu artigo "O Paradoxo do Navio de Teseu no mundo open source" clicando aqui); as versões do toybox 0.8.60.8.7; o 9base sed (de origem do plan9 e depois portado para outros sistemas operacionais) e por fim o sbase sed de origem do Unix e portado para outros Unixes (incluindo Linux na lista de outros Unix) que não possui versão específica. Neste artigo eu irei avaliar as implementações por:
  • Licença
  • Tamanho do binário
  • Recursos disponíveis
  • descrição de ajuda
  • Desempenho
  • bugs
 Para os testes eu utilizei o terminal de comandos zsh por proporcionar melhores informações (inclusive uso de CPU por padrão) e devido o Bash por vezes já ter apresentado bugs que não podem nos garantir confiabilidade nos resultados (leia mais sobre os bugs que encontrei no bash clicando aqui). Em conjunto eu utilizei o comando time.

Stdout difference between bash and zsh by running the time command

Diferença de exibição de resultados do comando time entre os terminais de comando bash e zsh.


 Fiz uso dos materiais públicos aureliothe mouseless Dev que possui até mesmo um mapa mental muito interessante, o manual gnu-sed e os próprios arquivos de testes disponibilizados pelos próprios comandos.

https://themouseless.dev/images/2021/sed/sed.jpg
Mapa mental do comando sed do site The Mouseless Dev

 Ao final de cada teste, eu irei classificar uma ou mais implementações como vencedores e na conclusão do artigo eu irei classificar da primeira a terceira colocação a partir da que proporcionar a maior quantidade de vantagens. Agora vamos partir para o arrebento.


LICENÇAS

 Neste primeiro tópico eu analiso quais as licenças adotadas por cada implementação levando em conta que cada licença proporciona vantagens e desvantagens. Parece um assunto irrelevante, mas trata-se de algo que pode afetar fortemente todo o mercado, todo um ecossistema e automaticamente você (se hoje o busybox estivesse sob GPLv3, provavelmente você nem teria um roteador em sua casa).

Licenças adotadas por cada implementação do comando sed
Licenças adotadas por cada implementação do comando

 Enquanto o gnu-sed está sob GPLv3+, o busybox-sed manteve-se sob GPLv2 mesmo tendo originado-se do gnu-sed (como pode ser lido no artigo O Paradoxo do Navio de Teseu no mundo open source) e é mantido pelo FFC.

BusyBox is not a GNU project, so the Free Software Foundation does not hold its copyrights; instead, those copyrights are retained by the original authors. As Rob looked over the code, he found many contributions with the usual "or any later version" language which would allow a change to GPLv3. Others, however, had the explicit "version 2 only" language. Some, contributed by one Linus Torvalds, state that they "may be redistributed as per the Linux copyright." Some other contributions carry a BSD license - originally with the GPL-incompatible advertising clause. It was quite the mixture of licenses.
Passe o cursos sobre a imagem para ler a tradução (texto original, basta clicar aqui)

 O sbase e o 9base estão sob MIT (9base sob MIT/X Consortium License); o minised foi disponibilizado sob GPL a partir da versão 1.13 e passou a ser disponibilizado sob BSD-like a partir da versão 1.14 em diante com o consentimento de Eric Raymond. O toybox está sob a clausula zero BSD (0-BSD) criada por Rob Landley que na verdade trata-se de uma Domínio Publico apenas sob o nome de BSD (com a aprovação dos próprios membros dos BSDs).

 VENCEDOR: Com exceção da GPL (que possui tendência natural a declínio), todos as demais licenças são muito boas. O busybox_SED ainda pode levar alguma vantagem com a GPLv2 por não ser incompatível com o kernel Linux e ser menos negativamente impactante que a GPLv3.


TAMANHO DOS BINÁRIOS

 Tenha em mente que, quanto menor o binário, melhor é em todos os sentidos (segurança, desempenho, modularidade e portabilidade). Códigos menores se tornam mais fáceis de manter e serem atualizados. Como mencionado no site do projeto embutils (que infelizmente não entrou para nossa lista), o userland dos Unix geralmente é composto de comandos dos BSDs e do projeto gnu. Na época que surgiram, as técnicas de desenvolvimento eram diferentes; os projetos focavam somente em recurso, mas não na otimização do tamanho.

Most of the typical Unix userland typically comes from either the GNU project or the BSD people. Those sources are ancient and optimized for features, not for small size, and now that computers are fast enough and have lots of RAM, implementations became larger and larger. Features like internationalization eat lots of memory and disk space.

Passe o cursor sobre a imagem para ler a tradução

 No episódio 06 do Linux Link Radio Rob Landley menciona que na época em que era mantenedor do BusyBox curiosamente descobriu que foram  escritas 833 linhas de código apenas para implementar o comando cat... E parece que não mudou muita coisa já que o gnu cat hoje ele possui 805 linhas... Outra coisa bem curiosa que Rob relata é que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k.... Desenvolvedores de embarcados são declaradamente inimigos mortais da glibc.

 Para certos dispositivos como embarcados e até mesmo para o processo de boot, binários tão grandes são simplesmente inviáveis. E parece não fazer sentido, mas mesmo em ambientes como desktop, servidores e até supercomputadores, binários menores também são extremamente importantes pois assim o sistema ocupa menos espaço tanto em memória RAM quanto em dispositivo de armazenamento (óbvio; quanto menor espaço o sistema operacional ocupar, melhor é), é carregado mais rápido pela cache L2 por exemplo e deixa a carga do processador mais livre.

 Há ressalvas a serem feitas durante as avaliações como sua ligação se dinâmica ou estática, quais bibliotecas foram utilizadas, qual compilador e com quais flags e assim por diante. As ressalvas foram feitas em asteriscos (*).

sed implementations binaries size
Tamanho de cada implementação do comandos sed.

*Relembrando aqui que menor significa melhor
**Eu compilei o minised estaticamente a dietlibc.
***Consta no site do busybox que o busybox_SED possui 89K; porém, após baixar, seu tamanho final é de 92K (também likado estaticamente. Baixe aqui para conferir).
**** Eu compilei o sed do toybox dinamicamente para que pudéssemos saber o seu real tamanho.

 VENCEDOR: Neste caso eu deixo três colocados. O toybox sed em primeiro com apenas 36k; o minised em segundo com apenas 44k, e o sbase sed em terceiro com 56K.

minised and toybox sed size comparasion
Comparação de tamanhos entre minised linkado estaticamente e toybox sed linkado dinamicamente

 Você deve estar se perguntando se não seria injusto sendo que o toybox foi ligado dinamicamente enquanto quer o minised estaticamente. E a resposta é que o minised, mesmo ligado dinamicamente, é maior do que toybox sed. Confiram os resultados na imagem abaixo.

Size comparasion between minised statically and dinamikly linked
Comparação de tamanhos entre minised linkado tanto dinamicamente quanto estaticamente

 Além do mais, eu testei as versões binárias do toybox já disponibilizadas pelo próprio projeto que são linkadas estaticamente, e os comandos estão incorporados ao terminal (sendo um deles o sed). Mesmo contendo 231 comandos incorporados a si, o toybox  0.8.7 possui apenas 716K.

Reparem a quantidade de comandos dentro do toybox 0.8.7 em apenas 716k (sendo um deles, o comando sed que está selecionado nesta leu).
Reparem a quantidade de comandos dentro do toybox 0.8.7 em apenas 716k (sendo um deles, o comando sed que está selecionado nesta imagem).


RECURSOS

 É agora que constataremos se o tamanho dos binários fazem jus à quantidade de recursos. Reforçando o que foi dito no tópico anterior, quanto menor o binário, melhor é porém, não vai adiantar muito o binário ser pequeno e enxuto se não conter os recursos necessários para a sua adoção.

 Além do mais, esse é um ponto extremamente importante pois uma regra histórica que não falha é que, mesmo que um programa contenha certos bugs, mas possui os recursos que as pessoas querem (ou precisam), elas aceitam conviver com tais bugs. Tudo uma questão de prós e contras; além do que os bugs podem ser corrigidos ao longo do tempo (ou não, vai saber a complexidade).

 Podemos dizer que neste tópico o gnu-sed dispensa explicações pois um ponto forte das ferramentas do gnu (não por total mérito seu) mas que é mal divulgado pelo próprio projeto é exatamente a parte de recursos possuindo até mesmo extensões próprias. OK para o gnu-sed.

 No arquivo BUG do minised é descrito "Focarão nas conformidades POSIX e pequeno tamanho - extensões do GNU sed provavelmente não serão aceitas". O minised possui um diretório chamado tests que após compilá-lo, podemos executar o script run, conforme descrito em seu arquivo Makefile (cd tests; ./run ../minised) ou bastando executar o comando make check que se encarregará de fazer esse trabalho (realizando o total de 68 testes). Um dos testes falha (especificamente o empty-lhs), mas como descrito no próprio resultado, essa falha é intencional.

minised make check
Testes disponibilizados pelo próprio minised

 O toybox também disponibiliza seus próprios arquivos de teste também dentro do diretório tests. No total, ele realiza 91 testes com o toybox sed.

toybox sed test files
Teste disponibilizados pelo próprio toybox

 O toybox sed possui uma lista dentro do seu próprio código fonte com algumas pequenas pendências a serem ajustados como "fazer y// lidar com delimitadores unicode, lidar com retorno de erro a partir do emit(), error_msg/exit consistentemente", "Qual a coisa certa a se fazer com -i quando escrever as falhas? Skip ou next?". Eu considero uma lista baixa; lógico que prefiro ver estas questões sanadas, mas são consideráveis.


O Busybox sed também possui uma pequena lista comentada em seu código fonte de apenas três de pequenos detalhes a serem acertados. 

 Eu não encontrei algumas pendências tanto no sbase quanto no 9base e não foram ruim nos testes.

 VENCEDOR: Empate geral. Em todos os testes que eu realizei, todas as implementações conseguiram processar com sucesso.


DESCRIÇÃO DE AJUDA

 Descrições de ajuda (--help e manpages) assim como as licenças, parecem ser irrelevantes, porém pense no seguinte cenário; você está administrando o seu sistema, precisa consultar uma opção e sabe que tal comando não possui opção de ajuda. Até aí, tudo bem, basta consultar a manpage... Certo?...

 A resposta é... depende de qual distribuição estamos falando. Distribuições como Alpine Linux ou Porteus não possuem manpages por padrão. E se de repente você não possui acesso a internet? O que você faz?...

 Do que adiante um programa conter todos os recursos necessários sendo que não vem com as informações de como utilizá-los? Seria o mesmo que uma TV não acompanhar manual de instruções. Alias, eu já vi empresas adotarem uma certa distribuição devido a facilidade em encontrar informações e soluções de problemas. Então, por mais que pareça algo irrelevante, descrições de ajuda é algo extremamente importante.

 E aqui vamos nós para a nossa analise. O minised, apesar de possuir uma boa manpage, não possui a opção --help por padrão. Eu acredito que poderia possuir ao menos uma leve descrição assim no sbase e no 9base. Ou melhor, assim como o busybox_SED; enxuta e explicativa.

minised and sbase sed help
Descrição de ajuda do minised e do sbase sed

busybox sed --help
descrição de ajuda do busybox sed

 O gnu-sed e o toybox sed são os que melhores implementam tais descrições. Aqui eu postei apenas uma porção de toda a descrição de ambos.

gnu sed options
Descrição de ajuda do gnu-sed

toybox sed options
Descrição de ajuda do toybox sed

VENCEDOR: Empate entre o toybox sed e o gnu-sed


POSSÍVEIS BUGS

 Já que falamos de recursos, agora vamos tratar de... bugs. O que é uma parte um pouco complicada de se tratar já que difícil constatar a real quantidade de bugs de um programa. Como todos sabem, há relatos de bugs que só foram encontrados mais uma década após sua existência. O bug estava lá mas só foi detectado dois de tanto tempo.

 Então, o que podemos fazer aqui é relatar os que já estão reportados em bug reportsprocurar por informações em man pages, comentários dentro dos códigos, informações nos arquivos README e BUGS ou... da forma mais árdua, testando mesmo assim como já mostrei alguns que reportei e podem ser conferidos no meu canal clicando aqui. O que alias não é o meu interesse.

 Por exemplo, no arquivo BUGS do minised é descrito como não havendo a necessidade de regressão até o momento; porém, como puderam acompanhar no inicio, vale ressaltar que sua base de código é bem pequena (o que é muito vantajoso). Apesar disso, eu encontrei apenas dois comentários de FIXME nos códigos sedcomp.c e sedexec.c (/* FIXME: scan for the brace end */ e /* FIXME: lastep becomes start */).

 O mesmo ocorre no toybox sed (tendo sua base de código ainda menor que do minised). A primeira versão do sed no toybox surgiu na versão 0.5.1 (em Novembro de 2014). De lá para cá, poucos bugs foram encontrados (total de 11 bugs encontrados e corrigidos desde então. Um deles pode ser conferido clicando aqui) e poucos deles eram críticos. O minised teve 12 correções desde a versão 1.3 que podem ser lidos em seu README.

 E que comece o choro e ranger de dentes. O gnu-sed é o que mais podemos encontrar bugs. Em seu próprio git (clicando aqui) ou podem ser conferidos no Debian Bugs clicando aqui apresentam uma lista de bugs conhecidos.

 Já o Busybox_SED possui apenas duas informações de FIXME em seu código mas é possível consultar bugs em seu próprio bug reports clicando aqui.

 No código do sbase sed existem 20 comentários com o dizer FIXME. Estes comentários descrevem correcções que ainda são necessárias. Foi difícil encontrar algo relacionado ao 9base sed, há sim correções ocorrendo e podem ser conferidas no próprio git do plan9port (clicando aqui), mas não é uma lista fácil de encontrar (muito menos especificamente de seu sed).

 VENCEDOR:  Com excessão do gnu-sed, todos os demais apresentaram baixa quantidade de bugs.


DESEMPENHO

 E por fim, a parte que a galera vai para delírio: benchmarks... Parece que a galera pira com essa palavra. Aqui eu considerei analisar tanto o uso de CPU quanto o tempo para a concluir as operações. E obtivemos os seguintes resultados:


 Estranhamente tanto o gnu-sed, o sbase sed, o 9base sed e o busybox_SED se comportam da mesma forma. eles sempre se mantêm na margem de 86-89% de uso de CPU, nunca a menos nem a mais do que isso. Mas não devemos analisar unicamente o uso de CPU pois, de certo forma, isso pode significar tanto algo bom quanto algo ruim; tudo vai depender muito da situação.

 Reparem um exemplo disso na imagem abaixo onde fiz uma analise entre o minised e o gnu-sed sendo eles separados pela faixa azul. Enquanto o gnu-sed manteve o uso de 89% de CPU, o minised desta vez fez uso de 106%. Apesar do uso de CPU do minised ter sido mais alto, o mimised concluiu sua operação em 120ms enquanto que o gnu-sed concluiu a mesma operação em 284ms.

minised and GNU sed comparasion.
Comparação de uso de CPU e tempo de conclusão entre minised e gnu-sed

 Para que o gnu-sed, sbase sed, 9base sed e o busybox_SED consigam concluir as operações no mesmo tempo que o minised, seria necessário que utilizassem entre 136,17% a 161,87% a mais de CPU além dos 89% já utilizado. O que totalizaria entre 225,17% a 250,87% de uso de CPU.

 VENCEDOR: Empate entre o minised (utilizando entre 61% - 76% de CPU porém, com menor tempo de execução) e toybox sed (utilizando entre 50% - 76% de CPU, algumas vezes atingindo 88%). Os demais ficam entre 86% a 89% de uso de CPU e o mesmo tempo de execução.


CONCLUSÃO

 O primeiro lugar fica para o toybox sed com 6 pontos. O minised em segundo com 5 pontos perdendo apenas na descrição de ajuda apesar que possui uma boa manpage. Então poderíamos declarar empate entre os dois já que o minised possui desempenho melhor do que o toybox sed.

 O segundo lugar ficaria empatado entre o busybox_SED com quatro ponto (tamanho, recursos, descrição de ajuda e poucos bugs) e o sbase sed (licença, tamanho, recursos e poucos bugs). O 9base sed teve três pontos (licença, recursos e bugs) e o gnu-sed apenas dois pontos (recursos e descrição de ajuda).

sed implementations analise conclusion
Conclusão da analise das implementações do sed

Existem outras implementações ou comandos semelhantes como é o caso do comando sd , mas não nos interessa para este artigo.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (10) Andriod (15) android (7) artigo (5) aws (1) bc (18) benchmark (5) BSDs (27) btrfs (31) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (26) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (82) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (87) 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 (21) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (6) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (78) 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 (102) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (62) 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 (5) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (149) 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 (83) 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 (61) 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 (12) RISCV (11) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (23) smartphones (3) Software livre e de código aberto (151) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (84) terminal de comandos (12) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) virtualização (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (14) zsh (2)