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

Lançado DragonFly 6.4.2

DragonFly 6.4.2 released

Lançado DragonFly 6.4.2


 Mal foi lançado o DragonflyBSD 6.4.1 e já recebemos a atualização da versão 6.4.2. Esta versão traz poucas mudanças adicionando correções ao instalador que agora lê o tamanho real dos discos e que anteriormente, devido o QEMU reportar (ou ao menos reportava) uma geometria de disco em um estilo antigo (de no máximo 8 gig), o instalador criava um volumes muito pequenos; correções no ipv6 que geravam panics quando utilizado em certas circunstancias, correções em programas userland que criam muitos subprocessos e causavam crashes quando um programa cria um número desses processos, muito constatado no neovim e no Chrome (o que no Chrome não seria nenhuma novidade).


Mais sobre o DragonFlyBSD pode ser conferido clicando aqui

gitweb.dragonflybsd.org Git - dragonfly.git/log

Release v6.4.1 · DragonFlyBSD/DragonFlyBSD

DragonFly BSD - avalon home!

DragonFly BSD - avalon home!

Mais sobre os BSDs aqui no blog

DragonFlyBSD: release64


QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

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

Lançado DragonFlyBSD 6.4.1

Lançado DragonFlyBSD 6.4.1

Lançado DragonFlyBSD 6.4.1


No dia 30 de Abril foi lançada a versão 6.4.1 do sistema operacional DragonFlyBSD, depois de um bom tempo já que a versão 6.4.0 foi lançada em Janeiro de 2023. Para quem não conhece, o DragonFlyBSD é um fork do FreeBSD focado em desempenho. Eu tenho um vídeo no meu canal explicando sobre seu sistema de arquivos e outras coisas que o levaram a ter desempenho similar ao do Linux sendo um deles, o sistema de arquivos Hammer. Foi um vídeo interessante já que respondi a pergunta de um inscrito e desmenti o que foi dito por um dev do FreeBSD no meu canal.


 Apesar de este ser um lançamento com correções de pequenos e duradouros, se trata de um total de 77 correções sendo 41 Aaron LI e 20 do próprio Matthew Dillon. De forma resumida, algumas das novidades entre tantas estão a correção do erro que o pkg update pode excluir o arquivo de configuração df-latetest.conf e que torna o pkg inutilizável; atualizaram o pacote ca_root_nss tornando assim os novos certificados Let's Encrypt mais confiáveis e podendo o pkg trabalhar com repositórios Avalon; correção no vazamento de memória nos drivers legado IDE/NATA que poderiam causar kernel panics; expor o ponto de entrada SMBIOS via kenv para que o dmidecode(8) funcione em UEFI-only.

 Algo que eu ainda espero um dia ver é o DragonFlyBSD portado para a arquitetura ARM.

Mais sobre o DragonFlyBSD pode ser conferido clicando aqui

gitweb.dragonflybsd.org Git - dragonfly.git/log

Release v6.4.1 · DragonFlyBSD/DragonFlyBSD

DragonFly BSD - avalon home!

DragonFly BSD - avalon home!

Mais sobre os BSDs aqui no blog

DragonFlyBSD: release64


pledge() - uma system call do OpenBSD portada para Linux

From OpenBSD to Linux: How Pledge can Enhance Linux Security

pledge() - uma system call do OpenBSD portada  para Linux

 Alguns dias atrás eu li o artigo From OpenBSD to Linux: How Pledge can Enhance Linux Security no site It's FOSS e como eu tenho um artigo voltado a system calls do Linux (Linx: Mais do que um Unix), decidi escrever esse para integrar ao assunto.

 pledge(), ou simplesmente Pledge, é uma system call do OpenBSD que foi portada para Linux por Justine Tunney. Na verdade esta implementação para Linux foi inspirada no pledge() do OpenBSD porém fazendo uso dos recursos da API do próprio Linux (já descrito no artigo Linux: Mais do que um Unix sobre a própria API do Linux) SECCOMP BPF (já abordado no meu artigo: Linux: Mais do que um Unix) e Landlock LSM (introduzido no kernel Linux 5.13 para reforçar a segurança). Pledge força os processos a serem executados de forma restrita e limitada dentro de um sandbox (algo que é ótimo para a execução de scripts e ferramentas automatizadas).

 Como descrito por Justine em seu site, "Pledge é como se fosse o fruto proibido que todos nós cobiçamos quando o chefe nos diz para utilizar algo como Linux"... pois ..."Linux nunca possuiu uma camada de segurança que meros mortais conseguissem entender"...; ..."Pledge torna a segurança mais compreensível". Bom, neste ponto não há como discordar de Justine visto como todos nós reclamamos como é trabalhoso configurar o SELinux (muitos até reclamam que a vida é muito curta para utilizar o SELinux) ou a diferença enorme de sintaxe entre iptables do Linux e o packet filter que apesar de muito famoso através do FreeBSD, o packet filter é na verdade do OpenBSD e foi portado para o FreeBSD. Até mesmo a sintax do antigo ipfw que o FreeBSD herdou do MacOSX possui sintax muito mais facil.

 Justine mesmo passou por situação como esta ao utilizar o SECCOMP BPF para implementar pledge:

"Houveram poucos desenvolvedores no passado que tentaram isso. Não vou citar nomes pois a maioria destes projetos nunca foram concluídos.  Quando se trata de SECCOMP, os tutoriais online explicam apenas como inserir lista de permissões das system calls em si, então a maioria das pessoas perdem interesse antes de compreender como filtrar argumentos. Os projetos que foram mais longe também tinham equívocos tal como permitir a alteração de setuid/setgid/sticky bits. Então nenhuma das alternativas atuais deveriam ser utilizadas. Acredito que esse esforço nos deixa muito mais próximos de ter pledge() do que nunca."

 Um apelo que faço a todas as comunidades Linux: Parem de perder tempo com bobeiras de ideologias e filosofias! Nós somos técnicos e não filósofos; deixem a filosofia para os filósofos e gastem tal energia elaborando documentações que inclusive, sejam de fácil compreensão. Vejam aí mais um grande exemplo de problema do Linux demorar ter um grande e tão importante recurso pela simples falta de uma boa documentação.

 Apesar disso, muitos esforços tem sido feitos para sanar tais problemas no Linux e torná-lo produtivo como o próprio e odiado (sem razão lógica) systemd que trás padronizações para as distribuições e torna a configuração dos serviços muito mais fácil; o Btrfs que facilita muito trabalhar com gerenciamento de volumes e outros recursos que, em outros sistemas de arquivos, eram serviços bem mais complexos de se trabalhar; o Netfilter que eu agradeço por nos conceder o nftables com sintaxe tão fácil que se aproxima do BSD pf (além de trazer também vários recursos que anteriormente eram difíceis de implementar no iptables).

 O segundo grande motivo que levou Justine portar Pledge para Linux foi devido a baixa adesão ao OpenBSD. Em 2002 a base de usuário de OpenBSD era de apenas 7.000 usuários tendo seu crescimento sempre baixo. O que nos leva a ideia de usuários não somente migrarem mas como também portar suas ferramentas para outro sistema operacional com maior base de usuários, melhor ecossistema e melhor adesão. Isso vem ocorrendo com a base de usuários do Solaris como relata Brendan Gregg em seu artigo Solaris to Linux Migration de 2017 que está ocorrendo migração e também port de ferramentas do Solaris para Linux como o caso do Dtrace:

 Eu venho portando muitas de minhas ferramentas do DTrace para o bpftrace e cubro estas no meu livro BPF Performance Tools: Linux System and Application Observability, as ferramentas que eu tornei publicas e open source aqui. Brendan Gregg

 Bom, e o terceiro motivo que eu ponho aqui é que Justine havia desenvolvido seu Pledge para ser utilizado como uma solução sandbox para o servidor web de sua própria autoria, o redbean. Justine chegou a conclusão que Pledge é tão robusto e útil que poderia reger outros processos; então, Justine teve uma grade ideia: Ao invés de configurar o Pledge diretamente no código fonte do programa como pode ser visto man page do OpenBSD ou no código do comando cat do OpenBSD

system call pledge sendo utilizado no código fonte: Medium

Justine desenvolveu um pequeno comando para utilizar o Pledge.

Opções do comando pledge


 Para executar o comando, basta digitar pledge (ou ./pledge caso ainda não houver salvo o comando dentro de um diretório da variável $PATH) seguido do comando desejado. Pldge é intuitivo, o próprio comando pledge indicará quais systemcalls serão necessárias para executar o comando desejado. Veja no exemplo abaixo a terceira coluna indicando quais syscall necessárias para executar o comando ls com o comando pledge:

syscalls necessárias para executar o comando ls


 A principio eu não consegui um bom resultado após adicionar as syscalls indicadas pelo pledge pois, após seguir o passo a passo de duas formas diferentes, o único resultado apresentado foi a mensagem invalid system call (core dump) e o Gnome reportando erros:
Erro apresentado ao executar o comando ls através do Pledge


 Depois, lendo um pouco mais no site da Justine, percebi que havia faltado a syscall rpath dentro das opções selecionadas e assim consegui executar normalmente. Apesar disso, o comando ls com a opção --l ainda apresentou dois erros sendo uma de permissão (talvez seja esse o motivo pois Justice menciona em seu site que é necessário utilizar pledge como root, algo que acabei não fazendo) e outro de syscall que eu não consegui encontrar nas opções (lgetxattr). Mesmo assim, no final das linha foi apresentado o resultado do comando com sucesso:

O comando ls sendo executado com o pledge de forma mais correta


 Agora resta a mim aprender melhor como utilizar o comando pldge. Eu vou continuar estudando e testando para ver como posso aplicar de forma mais clara.

 Bom trabalho feito pela Justine que merece todos os créditos principalmente pelo desenvolvimento da biblioteca libcosmopolitan (que lhe rendeu um premio do Google em 2023; o premio Open Source Peer Bonus que extremamente difícil de conquistar) e muitos outros recursos; alias, Justine é financiada por mais ou menos uma centena de desenvolvedores no GitHub.

 Apesar que Justine informar que só implementou por enquanto coisas descritas na man page do OpenBSD, ainda precisar trabalhar em materiais primários mas que são providos do pledge do kernel do OpenBSD, também precisam de mais feedback da comunidade.

 Andreas Kling adicionou o suporte a pledge() ao SerenityOS sendo o segundo sistema operacional a adotar os mecanismos pledge() e unveil() do OpenBSD. Talvez Linux é o terceiro sistema operacional a realizar esta façanha. Quem sabe no futuro esta system call faça parte até mesmo da API do Linux? Vantagem para todos nós.


Porting OpenBSD pledge() to Linux

GitHub - jart/pledge: OpenBSD APIs ported to Linux userspace using SECCOMP BPF and Landlock LSM

Toca do Tux: Linux: Mais do que um Unix

Mais sobre o OpenBSD aqui no blog

BSD is dying

From OpenBSD to Linux: How Pledge can Enhance Linux Security


QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

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

ClonOS - Uma alternativa ao Proxmox baseado no FreeBSD

ClonOS - Uma alternativa ao Proxmox baseado no FreeBSD

ClonOS - Uma alternativa ao Proxmox baseado no FreeBSD

 Depois que Xen server passou a ser pago, muitos profissionais passaram a migrar os seus clientes para outra solução como o Proxmox, o xcp-ng, o oVirt e até mesmo o Openshift da Red Hat que possui suporte a virtualização; a Nutanix também entra nesta briga como uma briga como concorrente da VMWare e muitas vem migrando para containers o máximo de aplicações possíveis e que pode gerar economia ainda maior:

 No ano passado, a VMWare foi adquirida pela Boradcom pelo valor de US$ 61 bilhões (uma das mais caras aquisições da indústria de tecnologia). Após esta aquisição, os produtos e serviços da VMWare passaram a ficar mais caros e consequentemente, as empresas que as possuíam, passaram a buscar outras soluções em virtualização. Há empresas que já mantinham outras alternativas de virtualização atuando paralelamente dentro de suas infraestruturas exatamente para se prevenirem de casos inesperados (lógico que tudo isso tem um custo que a curto prazo pode parecer caro, mas não quando necessário remediar a situação). Bom, e no meio de tantas soluções de virtualização no Linux (Linux é o sistema operacional com o melhor suporte a virtualização que existe), uma equipe desenvolvedores de FreeBSD decidiu projetar uma alternativa que a chamaram ClonOS. 



ClonOS: Uma alternativa ao Proxmox Baseada no FreeBSD

 ClonOS é uma plataforma baseada no FreeBSD e no framework CBSD que eu já abordei aqui no blog no artigo CBSD sendo portado para DragonflyBSD. O ClonOS vem com interface web para facilitar o controle, deploy e gerenciamento dos containers jails do FreeBSD e dos ambientes de virtualização tanto do Bhyve quanto do Xen. Além disso, o ClonOS disponibiliza suporte ao 9p (sistema de arquivos do plan9 utilizado o WSL) para ser utilizado no compartilhamento de diretórios do bhyve via virtio-p9; Bhyve management para criar e excluir VMs; conexão com console "físico" de convidado via VNC do navegador ou diretamente pelo sistema; monitoramento em tempo real; acesso a estatísticas de carga através do SQLite3 e beanstalkd; suporte a ZFS; import/export de ambientes virtuais; repositório público com virtual machine templates e ajuda baseada em puppet para a configuração de serviços populares. Há ferramentas que estão em andamento.


Site oficial do ClonOS

Mais sobre virtualização

Mais sobre FreeBSD


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

Lançado OpenVi 7.5.28

Lançado OpenVi 7.5.28

Lançado OpenVi 7.5.28


 No dia 07/04 o desenvolvedor Jeffrey H. Johnson (@johnsonjh) disponibilizou a versão 7.5.28 do editor de texto OpenVi, o Portable OpenBSD vi / ex. sim existem diferente implementações do editor de texto Vi, uma outra é o NeatVI. Poucas mudanças nesta ultima versão versão são

  • Adição da opção de inicialização -C cmd similar a -c mas sempre executa o cmd.
  • Remoção de declarações include duplicadas no arquivo xinstall.c.
  • Adição da opção showfilename para exibir o nome do arquivo.
  • Evita o uso depois de livrar do frp e frp->tname.
  • Correção de fd leaks em erros de caminho.


A versão 7.5.28 do OpenVi pode ser conferida clicando aqui

GEFS sendo portado para os OpenBSD

GEFS sendo portado para os OpenBSD

GEFS sendo portado para os OpenBSD


 Ori Bernstein vem trabalhando no desenvolvimento de um sistema de arquivos chamado GEFS (Good Enough File System). Ainda experimental, EGFS foi desenvolvido para o sistema operacional Plan9 ( que eu já tratei no canal e no blog) tendo a interface de sistema de arquivos 9p no topo de uma floresta copy-on-write Bε trees. O 9p seria utilizado assim como o BtrfsProgs e o XFSprogs.

 E assim temos mais um sistema de arquivos copy-on-write compatível com alguma estrutura tree; porém, não confunda Bε trees com B-tree. De acordo com a FAQ do Bε-tree File System:

"Bε-tree é uma B-tree, aumentada com buffers por nó. As consultas de ponto e intervalo se comportam de maneira semelhante a uma B-tree, exceto que cada buffer no caminho da raiz à folha também deve ser verificado quanto a itens que afetam a consulta."
  • Ser seguro contra colisão (crash-safe)
  • Detecção de corrupção
  • Sistema de arquivos com snapshotting simples e rápido

 Tudo exatamente nesta ordem. Ori explica a motivação para desenvolver o GEFS e portá-lo para o OpenBSD. Uma delas é que o UFS já está ficando datado. Para quem fala inglês, o vídeo abaixo é sua apresentação bem detalhada.


 O GEFS do OpenBSD será um fork da versão do Plan9 onde todas as novidades do Plan9 estarão disponíveis para o OpenBSD. O GEFS já anda apresentando ótimo desempenho, ótimos resultados e agora, cabe a nós esperar para vê-lo em produção.


Lançado DragonFlyBSD 6.4.0

DragonFlyBSD 6.4.0

Lançado DragonFlyBSD 6.4.0


 No dia 30 de Dezembro foi lançada a série 6.4 que trás muitas novidades como novo suporte a hypervisor type-2 com NVMM, driver GPU da AMD, correções de segurança e novo recuso (experimental) no remote-mount de volumes do HAMMER2.

 O Hammer2 ainda recebeu sete correções de bug e muitas limpezas de sintax além de mais alguns novos recursos como Report critical bulkfree transitions que não devem acontecer, Validação de número de inode on-media, Definição mais correta da flag read-only em montagem e falha ao montar se o volume root não for especificado. Houveram melhorias de desempenho, correções e novos recursos também no tmpfs, msdosfs e no ext2fs. O comando makefs agora possui suporte ao HAMMER2, alocação extra de inodes quando deixar espaço livre em imagens UFS e correção de calculo de tamanho de arquivos enquanto que o comando newfs_hammer2 - recebeu uma correção na opção "-V 1".

 O kernel do DragonflyBSD recebeu 10 correções sendo algumas criticas permitindo até exploit local. Mas também recebeu novos recursos como mlockall()'s MCL_CURRENT que correspondem com às expectativas do tipo linux ; suporte a API gtaskqueue do FreeBSD entre outros recursos.

Na parte de redes houveram correções no ipfw, no pf, no IPV6 e no if_bridge. O utrwn agora possui suporte a if_bridge e o jail permite allow_raw_sockets. A parte gráfica também recebeu correções e melhorias no drm e no evdev.

 Melhorias e correções no userspace como nos comandos date, lpr, last, /bin/sh, xargs (Sync com FreeBSD) e fetch; correções e melhorias em bibliotecas (o total de 17) e atualizações de comandos de terceiros como os comandos awk, less e file.


Framework Rump kernel do NetBSD como uma solução para o Hurd

Framework Rump kernel do NetBSD como uma solução para o Hurd

Framework Rumpkernel do NetBSD como uma solução para o Hurd

 Em fevereiro deste ano Damien Zammit apresentou no FOSDEM uma solução para o Hurd*. A ideia é adotar o framework rump kernel do NetBSD; o que não é nenhuma novidade já que o Rump kernel já está presente no Hurd desde 2015 implementando seus recursos de USB e de áudio.

 Outras fontes também estão presentes no Hurd como partes do próprio Linux como servidor de arquivos ext2fs, servidor de rede pfinet, NIC, drivers de disco e muito mais. Algumas versões possuem suporte para execução de rede Linux 2.6.xe e drivers de disco no modo de usuário através da camada de compatibilidade DDE.

 A vantagem de utilizar o Rump kernel no Hurd é que o framework traria mais drivers com uma interface estável sem a necessidade de ficar reinventando a roda e debugar processos e drivers de forma pratica. Como o Hurd é um microkernel, os recursos do Rump kernel (gerenciamento ACPI e PCI e driver) vão rodar em processos separados como servidores.

 Pode ser que o Rump kernel realmente traga vantagens ao Hurd  uma vez que o Hurd possui suporte a hardware muito limitado (até hoje limitado a i386), apresenta muitas falhas (inclusive de kernel panic com muita frequência, muito maior do que o Windows apresenta tela azul) e não há (como nunca houve) previsão de lançamento de uma versão estável que possa ser utilizado em produção.

Hurd source code

O código fonte do Hurd e suas limitações podem ser conferido clicando aqui

GNU/Hurd takes 5 minutes to boot up on a AMD ThreadRipper
Depoimento do GNU/Hurd levando 5 minutos para bootar em um AMD ThreadRipper de 48 núcleos.

 É como já mencionado por Henrik Ingo em seu livro livro Open Life escrito em 2006 e traduzido para inglês pela própria irmã do Linus, Sara Torvalds:
"Uma ironia é que o projeto GNU mencionado por Linus ainda não conseguiu concluir seu próprio ‘grande e profissional’ kernel Hurd. Todo o crédito a eles por não terem desistido, no entanto. Eu venho acompanhando o desenvolvimento do Linux de perto há meia década e durante todo esse tempo o Hurd esteve quase completo. De alguma forma, é divertido ver que a situação deles era a mesma há treze anos, quando o Linux nasceu."
 Dezessete anos depois que o livro Open Life foi escrito pela primeira vez (sua primeira edição em 2.005) e o Hurd ainda não apresenta sinais de que terá uma versão estável. Honestamente não acredito que um dia o Hurd venha a se tornar funcional (há até mesmo piadas na gringa referentes ao Hurd onde a humanidade vai entrar em extinção em 2.050 enquanto que o hurd vai ficar pronto somente depois de 2.060). Há outras versões de microkernel muito mais interessantes que o Hurd e que eu relato no meu artigo 5 diferentes modelos de kernel.

Quando o hurd ficará pronto? Quando mais ninguém precisar?
Quando o hurd ficará pronto? Quando mais ninguém precisar?

 *O nome original deste microkernel é Mach e não Hurd; Hurd é o nome do seu conjunto de daemons (incrível como brigam tanto pelo reconhecimento do nome GNU querendo forçar todos a chamar Linux de GNU/Linux mas quando se trata do nome do microkernel Mach, eles enfatizam o nome do conjunto de daemons...). O Mach não foi desenvolvido pelo projeto GNU e sim pela universidade Carnegie Mellon e trata-se do mesmo microkernel utilizado pela Apple para o desenvolvimento do MacOSX (a junção do Mach kernel com o kernel FreeBSD,  do 4.4BSDLite e do NetBSD forma-se o XNU kernel base que dá origem ao sistema operacional Darwin, ou simplesmente, o MacOSX). E assim continuam a incansável luta para um dia tentar tornar o Hurd funcional.

A junção de microkernel Mach com porções de kernel como do FreeBSD, do NetBSD e do 4.4BSDLite formam o kernel hibrido XNU, base do sistema operacional Darwin (o MacOS X)
A junção de microkernel Mach com porções de kernel como do FreeBSD, do NetBSD e do 4.4BSDLite formam o kernel hibrido XNU, base do sistema operacional Darwin (o MacOS X)

 O site oficial o Mach pode ser conferido aqui.

Marcadores

A pior história sobre Linux que já ouvi (6) A.I (2) ambiente gráfico (19) AMD (14) analise (10) Andriod (16) android (7) Apple (1) arm (5) artigo (5) aws (1) bc (23) benchmark (6) BetrFS (1) blackhat (1) BSDs (34) btrfs (32) bugs (2) Caixa de Ferramentas do UNIX (18) canonical (1) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (33) comp (1) compressores (9) consoles (1) container (8) CPU (19) cracker (1) criptografia (5) crowdfunding (9) cursos (24) daemons (14) Debian (31) desempenho (2) desenvolvimento (104) desktop (19) DevOps (3) DevSecOps (4) dic (1) Dica de leitura (91) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (4) diocast (1) dioliunx (3) distribuições Linux (14) Docker (13) DragonflyBSD (24) driver (2) dropbear (3) 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 (11) filesystem (82) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (21) Funtoo Linux (13) games (95) garbage collector (1) gerenciadores de pacotes (4) glaucus (8) GOG (3) google (9) gpu (3) hacker (2) hardware (104) hash (1) helenos (3) I.A (1) init system (13) Intel (15) inteligencia artificial (2) IoT (1) ispconfig (1) jogos (39) kde (1) kernel (142) lançamento (64) leis (1) LFCS (1) libs (2) licenças (10) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (4) lkgr (1) 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 (180) musl (3) não viva de boatos (9) navegadores (5) NetBSD (7) newlib (1) nim (12) nimlang (4) nintendo (1) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) ONLYOFFICE (5) open source (85) OpenBSD (8) OpenShift (1) oracle (1) os vários sabores de Linux (46) padrim (2) palestras e eventos (5) partições (6) pentest (8) performance (1) pipewire (1) plan9 (3) playstation (1) processadores (30) professor Augusto Manzano (11) Programação (72) promoção (1) propagandas com Linux (8) ps4 (1) real-time. (1) Red Hat (23) 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 (16) Sega (1) Sega Saturn (1) segurança digital (28) servidor web (2) servidores (3) shell (11) shell script (8) sistema operacional (25) skarnet (2) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (10) Steam no Linux (8) supercomputadores (4) suse (7) systemd (9) terminal (90) terminal de comandos (21) toca do tux (1) toybox (30) tutorial (6) Tux (3) ubuntu (1) unboxing (7) UNIX (17) UNIX Toolbox (13) vartroy (1) vga (1) virtualização (3) vulnerabilidade (7) wayland (5) web (1) whatsapp (1) whitehat (1) Windows Subsystem for Linux (2) wine (14) WoT (1) yash (1) ZFS (16) zsh (3)