Dica de uma porrada de cursos baratos:D

Cursos de Bash, Shell Script, Pentest, edição de vídeo, animação, backup, inglês e LPI.

Beleza cambada? Vim dar uma sugestão de cursos bem baratos para todos. são cursos muito bons como de Bash, Shell Script e de Blender que são ministrado por grandes profissionais e que agora estão em uma grande promoção. O EADDiolinux está com descontão em seus cursos a partir de R$24,90 e de quebra tem o de kdenlive na faixa. Mas os cursos baratos do Diolinux não param por aí, pois a DioStore também está com a maioria dos seus cursos com preço muito bom e acessível.

LPI1 CompTIA

O Mateus Müller do canal 4Fasters que compartilha conhecimento relacionado a certificação LPI agora está com um curso na Udemy para todos os que estão interessados a tirar a certificação. Eu e o Mateus já fizemos um vídeo em cada canal trocando uma ideia e de lá para cá o Mateus vem mostrando o seu talento, confiram só o currículo do cara:

Curso do Mateus Müller na Udemy

Ninja Tux e seu curso de Blender

Quem se lembra do Ricardo Graça? A mente brilhando por traz do Ninja Tux:


O ricardo já nos concedeu a enorme  oportunidade de lhe conhecer explicando sua experiencia profissional e porque criou o Ninja Tux. E desta vez o Ricardo está com mais um projeto em sua carreira que é o de ministrar curso de Animação de Personagem 2D com Blender onde aplica toda a sua experiencia profissional (aproveitem porque é apenas por mais quatro dias).



Curso de animacão de personagem 2d com Blender

Bacula - ferramenta livre de backup

Bacula é uma ferramenta que lhe permite realizar backups, verificação e  restauração dados de computadores em uma rede de sistemas mistos.

O Heitor Faria (a autoridade do Bacula) também já nos deu a honra de participar de uma live no canal respondendo a perguntas do pessoal sobre essa poderosa ferramenta de Backup. Foi simplesmente sensacional recebê-lo e já estamos planejando seu retorno:


Confiram o curso de Bacula do grande Heitor Faria na Udemy

Curso de Inglês para Tecnologia da Informação

O Giorgi Bastos que é desenvolvedor Javascript full stack, UI / UX design e também professor de Inglês para TI elaborou um curso de inglês muito interessante focado especificamente em nós :D

Curso de inglês para TI do Giorgi Bastos
Então  é isso, fica a dica aí a todos e bons estudos :)

Estarei no FLISol 2018

flisol 2018

Beleza cambada? Bom, passando somente para deixar o recado de que talvez nesta Quinta e Sábado não teremos vídeo no canal, pois estarei ocupado com a palestra que ministrarei no FLISoL 2018 que acontecerá na faculdade Alfa de Umuarama. O evento ocorrerá neste Sábado, dia 28/04/2018 das 09h às 12h.

Nesta debaterei porque Linux domina tantos mercados sendo que existem tantos outros sistemas operacionais, o que levou para que isso acontecesse.

Atendi ao convite e se caso quiser participar deste evento, o link vai estar na descrição. Então corre que ainda dá tempo.


14º Festival Latinoamericano de instalação de software livre e de código aberto.

http://si.alfaumuarama.com.br/flisol/

Bug no terminal de comandos Bash e comparação entre os pacotes de coleções de comandos

Bom, fiz os vídeos onde demos uma olhada no toybox, Respondemos a comentários interessantes, demos uma olhada no embutils e no 9base. Depois disso me lembrei que no artigo "Android, uma boa alternativa ao Windows no desktop" que escrevi há mais ou menos dois anos atrás e que percebi um bug no Bash. A questão é que na época eu conferia a quanto tempo o android estava em funcionamento tanto pela configuração do sistema operacional quanto pelo comando uptime. Fiz uso na época de alguns terminais (que não me lembro o nome) e um deles era o terminal Bash para o Android. O Bash retornava valor errado de horas em execução pelo comando uptime, não combinava com o relógio do android e nem com dos outros terminais que estavam sendo utilizados. Foi aí que passei a me preocupar se todo resultado obtivermos no terminal são verídicos ou não, e por isso adotei a estratégia de conferir os resultados em dois ou mais terminais de tempos em tempos somente para me certificar.

Consegui recuperar as imagens da época que fiz a analise e aqui estão algumas mostrando a quanto tempo o sistema está em funcionamento tanto pelo sistema de estado do próprio android quanto pelo bash fazendo uso do comando uptime:

Aqui mostra que o sistema está de pé hà mais de 252 horas
Reparem nas duas primeiras imagens que o android já estava no em funcionamento hà mais de 252 horas (10 dias e meio) enquanto que o bash informa que o sistema está em funcionamento a somente 8 dias e 3 horas.


Reparem agora nesta duas que o android consta mais de 254 horas (e está correto de acordo com o relógio exibido no canto superior direito sendo o total de 10 dias e 14 horas) enquanto que o bash permanece 8 dias e 4:36.


Tudo bem, foram no mesmo dia, então esperei mais um tempo e agora o android consta mais de 273 horas (totalizando de 11 dias e 9 horas e meia) enquanto que o Bash permanece 8 dias e 23:05. Nesta ultima imagem, conferam a data e hora com o comando date que e o bash retornou 21:10 sendo que a hora real era 18:10).

Eu não sou o único que já reparou isso, esta imagem abaixo é de um membro do grupo Linux aprendendo  no Telegram onde relata que a partição /dev/sda4 pelo gparted está em NTFS enquanto que no Bash consta FAT16 a mesma partição. Porém o Windows também reconhece como NTFS:
Confiram o o sistema de arquivos no partição /dev/sda4 fornecida pelo Gparted e pelo Bash. Esta imagem é na distribuição Kali Linux
Esta ultima imagem é outra situação que aconteceu durante o processo de escrever este artigo. Eu utilizei o comando du (disk used) para conferir o tamanho final do binário do toybox após compilá-lo e o bash me retornou que o toybox tinha apenas 56k; repeti a operação e obtive o mesmo resultado. Depois utilizei o comando o du do próprio toybox que tenho instalado na minha máquina, para através dele também conferir o resultado final do tamanho do novo binário que compilei e o resultado foi que o comando du do toybox me retornou que seu tamanho final era de 328k (e não 56k como exibindo pelo du do coreutils...) Quando dos dois então estão certos? Após isso, para desencargo de consciência, resolvi mais uma vez utilizar o comando du do próprio bash que me retornou o valor de 328k e não 56k como ele havia me retornado das duas primeiras vezes... Bem conflitante. Não?
Eu utilizei o comando du (disk used) no bash contra o binário do toybox para conferir o seu tamanho final ao compilá-lo e o bash me retornou que o toybox tinha apenas 56k. Depois usei o du do proprio toybox que me retornou que seu tamanho final era de 328 e depois usei o comando du novamente no bash que me retornou que o tamanho do toybox era de 328...
O comando du utilizado no bash (pacote coreutils) consta que o arquivo toybox é do tamanho de 56k, depois o mesmo comando no toybox e depois o mesmo comando no bash novamente

Esta não é a primeira vez que situação assim acontece e considero até mesmo um alerta para a adoção de outros terminais como Zsh e Fish como terminal de comandos principal. Este é um bug de longa data que volta e meia acabo vendo.

Neste artigo resolvi comparar os pacotes coreutils do GNU, o embutils, o 9base e o toybox para certificar se estes entregam os mesmos resultados ou se retornam valores diferentes, tamanho final do binário, licença e muito mais.

Deu trabalho calcular o tamanho final do 9base uma vez que os comandos ficam todos dispersos estando cada um em seu próprio diretório (diretório = pasta para caso você que esteja lendo seja usuário novo no Linux) e cada diretório não contem unicamente o próprio comando (diferente do embutils que concentra todos os comandos em um único diretório quando compilados). Então criei um diretório, copiei somente os binários para dentro dele e assim calculei o tamanho final dos comandos do 9base.
9base
Diretórios do 9base onde concentram os comandos sepadaramente. Clique na imagem para aumentar o tamanho.

O diretório bin-x86_64 é aonde o embutils concentra todos os comanos após a compilação. Clique na imagem para aumentar o tamanho.
O diretório bin-x86_64 é aonde o embutils concentra todos os comanos após a compilação. Clique na imagem para aumentar o tamanho.
As comparações aqui são feitas entre as licenças utilizadas, se são linkados dinamica ou estaticamente, o tamanho final dos binários, a descrição da saída da opção --help dos comandos para obter informações precisas de como utilizá-los e por fim o resultado das saídas dos comandos.

Utilizamos aqui os comandos df e du -s para verificar se os resultados coincidem; o único comando que não utilizamos no 9base foi o df, pois o 9base não possui tal comando. Os testes (básicos) aqui realizados usando comandos como du, foram feitos em diretórios como meu próprio home. No meu home mesmo por exemplo, enquanto o 9base retornou o resultado 12111218d (12113235d com a opção -sh... tipo... hein?), todos os outros retornaram o resultado 12244176 (12G com a opção -sh).
Clique na imagem para aumentar o tamanho.
Os resultados pode ser conferidos logo abaixo:
comparacao-entres-os-pacotes-de-comandos-coreutils-embutils-9base-e-o-terminal-de-comandos-toybox
Clique na imagem para aumentar o tamanho e conferir o resultado dos pacotes.
Há quem vá dizer que não acha justo incluir o Bash nessa história; não seria então incluir o toybox também. Ou vai haver quem diga que não é justo incluir o toybox nesta comparação; a questão é que o toybox concentra todos os comandos dentro de si, e não dispersos. Fora que ele fez parte da série, dando uma olhada ;)

Vale Lembrar também que o tamanho final dos arquivos pode variar por filesystem conforme descreve no artigo Benchmark de filesystems.

De todos, o que menos me agradou foi literalmente o 9base. Não adianta o 9base estar sob a licença MIT (que é uma licença que vem tendo sua adição cada vez mais crescente) mas gerar binários exageradamente enormes, ter fracas descrições com a opção --help e ainda apresentar resultados duvidosos e de difícil leitura (digitem o comando ls do 9base e confiram que desastre).

Porém, também não adianta o embutils ser tão pequeno (apesar que isso é muito bom :), tão exulto (admirável demais isso) e ter as mesmas fracas descrições na opção --help que o 9base... (apesar que possuem manpages para os dois, essas descrições se tornam problemas fáceis de serem solucionados) e também adotar a GPL mesmo que seja a versão 2. Poderia ao menos ter adotado a MPL. Ao menos seu resultado não é duvidoso.

Também não adianta o coreutils ter boas descrições com a opção --help mas ter binários grandes (o coreutils não fica longe do 9base se consideráramos que o coreutils ser dinamicamente lincado) e adotar a GPLv3 (versão totalmente conflitante com ao GPLv2 e GPLv2+). Fora seus resultados poderem ser bem duvidosos.

O que apresentou melhores resultados foi o realmente o toybox podendo reunir as melhores características de cada um:
  • Licença flexível para uma época onde a GPL se torna fragmentável
  • tamanho final do binário bem enxuto (melhor que o próprio embutils)
  • Pensado na segurança, estabilidade e desempenho
  • Boa descrição de informações (de forma mais alinhada que do próprio Bash+coreutils)
  • Resultado da saída do comando confiável
Uma pena ainda não ser possível utilizar o toybox como terminal de comandos padrão como no caso do Android, mas espero que não demore muito a se tornar uma opção para as distribuições que utilizamos (em especial o Alpine Linux), o que é algo que a comunidade toybox trabalha para que aconteça. Porque, ficar digitando o comando toybox toda vez que quero usar um comando é desagastante. Na verdade ainda não abandono (de forma alguma) o Zsh e está espero que venha a se tornar o terminal de comandos padrão nas distribuições.

Já perceberam que não coloquei o coreutils como vilão da história como muitos ACHAM que eu odeio GNU. Porque a paixão excessiva por parte dos amantes do Gnu em suas cabeças é tão grande que isso não permite que eles vejam que estou fazendo analise técnica. Porém também não estou escrevendo este artigo para desmoralizar o 9base. Somente não o adotaria hoje por não atender nenhuma das expectativas em um conjunto de comandos. Quando adotarem um terminal, pesem na balança se o que obtemos é real ou não. pretendo ainda fazer uma análise ainda um pouquinho maior sobre esse comandos. Vamos ver o que teremos de resposta ;)

E o estudo não para por aqui. Depois de quase concluído este artigo, descobri novas coisas que gerarão outro estudo. Até o próximo artigo.

Agradeço ao Hilton Vasconcelos pela imagem fornecida do Kali Linux mostrando a partição /dev/sda4 no Gparted e no bash.

É possível deixar o kernel Linux menor se usarmos a diet libc ao invés da glibc?


Talvez depois do vídeo sobre o embutils tenha surgido a seguinte duvida: Se compilar programas utilizando a diet libc torna os programas menores, será então que é possível compilar o meu kernel utilizando a diet libc e torná-lo também menor?

A diet libc é uma biblioteca C que focada na otimização de tamanho dos programas (mesmo sendo utilizada estaticamente).

Tenho dois vídeos sobre a diet libc, um contando sua história e o ultimo sobre o embutils, uma vez que a diet libc é uma dependência do embutils. No primeiro vídeo também explico suas características e acredito que é uma grande solução:

Q: Por que ela não é compatível com a glibc? Eu achei que a interface fosse um padrão?
A: sim, a interface é, mas um monte de detalhes estão faltando. Por exemplo, a diet libc utiliza um layout de "struct stat" diferente da glibc. Nós utilizamos uma do kernel, glibc utiliza uma própria e linka translation code (código de tradução). Essa é a parte da razão porque a glibc é tão grande e tão feia. Se tivéssemos suporte a tudo isso, terminaríamos inchados quanto a glibc.
A glibc sempre teve esse grande defeito de gerar binários grandes demais e a equipe do projeto GNU nunca se importou com isso. O raciocínio apresentado por eles é basicamente o seguinte: "Com a quantidade crescente do poder do hardware, porque devemos nos preocupar com isso?"
E esse é até mesmo um erro cometido pela comunidade GNU. O projeto GNU e BSDs são muito bom no quesito recursos, porém não no resultado final de binários quando o quesito é tamanho. Tanto que antes de diet libc já havia surgido a uClibC para que pudessem estender Linux ao uso de embarcado (uma vez que é quase impossível utiliza glibc em embarcados).

Mais uma coisa que deve ser escolarecida sobre a diet libc é que já dizerem que a esta biblioteca originou do FreeBSD e foi portado para Linux. Na verdade não, essa biblioteca também é própria do Linux como descrito na mesma FAQ:
Porgunta: Pode portar a diet libc para FreeBSD/Solaris/Windows, por favor?
Resposta: Não.
Resposta grosseira; não? Mas no próprio site da diet libc consta em sua descrição que ela pode ser utilizada para criar para Linux binários pequenos lincados estaticamente nas arquiteturas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc e x86_64.

Bom, eu já postei um artigo complementar no blog Diolinux que vale a pena conferir, pois faço um complemento ao vídeo abaixo e até mesmo mostro o mesmo comando uname que mostra em sua saída o termo "GNU/Linux" assim como no toybox:


Bom, puderam ver como os binários ficam pequenos mesmo tendo biblioteca estaticamente linkada. Surge então a pergunta após ficarmos impressionados com isso. Isso significa que é possível compilar meu kernel Linux com a diet libc ou outra biblioteca do Linux e obter como resultado um kernel menor? Na FAQ mesmo menciona que utilizam um layout do kernel; logo significa que é possível?
A resposta: NÃO!
POR QUE? :(

Bora responder a pergunta. Como descrito na própria FAQ da diet libc:
Pergunta: Devo compilar meu kernel com a diet libc?
Resposta: O kernel não é lincado a nenhuma libc. De fato, a libc é a interface do user space para o kernel. Então, a não ser que você esteja falando sobre o "user mode linux" (que é uma versão especial do kernel que ocorre ser um programa user space), você não consegue lincar o kernel a diet libc.  Lincar o user space Linux com a diet libc deve ser possível em teoria, mas eu não acho que alguém já tentou de verdade.
Explicando melhor a função das bibliotecas C pode ser lido também na FAQ da Musl que descreve o seguinte:
musl é uma “libc”, uma implementação de funcionalidade de biblioteca padrão descritos na ISO C e nos padrẽos POSIX, mais extensões comuns, destinadas a uso em sistemas baseados em Linux. Onde o kernel (Linux) governa acesso ao hardware, memória, filesystems, e privilégios para acesso desses recursos, a biblioteca C é responsável por fornecer as aplicações reais do userspace das interfaces da função C e para a construção de bufferd stdio de alto nível, gerenciamento de alocação de memória, operações de criação de thread e sincronização e assim por diante utilizando interfaces de baixo nível que o kernel fornece, assim como para a implementação puras rotinas de biblioteca da linguagem C como strstr, snprintf, strtol, exp, sqrt, etc.
Passe o cursos do mouse para ler a tradução do texto

Então sempre tenhamos em mente, a biblioteca é para os programas que utilizamos no user space, não para o kernel. O kernel é independente da biblioteca. Linux é um kernel que cresceu e evoluiu para mais do que um kernel tendo bibliotecas, comandos, terminais, init systems e muito mais. Exemplos de bibliotecas do Linux além da diet libc temos a Bionic do Android, a musl, a UclibC, a  newlib e klibc.

Compre na imago brinquedos

Compre na imago brinquedos
Utilize o cupom de desconto TOCADOTUX e ecnomize 5% na sua compra