Mostrando postagens classificadas por relevância para a consulta filesystem. Classificar por data Mostrar todas as postagens
Mostrando postagens classificadas por relevância para a consulta filesystem. Classificar por data Mostrar todas as postagens

Experimentando HD Hitachi

 Um habito que eu tenho é de tempos em tempos comprar um novo HD para fazer backup dos meus dados. A ultima vez que eu comprei um HD foi (pelo o que eu me lembre) em 2012. Então esse ano eu resolvi comprar um novo para garantir que meu HD não vai morrer.
Dica SysAdmin: Peque sempre pelo excesso, nunca pela falta*.
* Claro que essa dica fica dentro do limite do orçamento.

 Existem vários fabricantes de HDs: SeaGate, Maxtor (que se tornou uma divisão da Seagate em 2.006), Samsung, Western Digital, me lembro que vi um Mitsichita uma vez no MacBook White do meu irmão, Toshiba e Hitachi. Os dois últimos mencionados são um dos melhores fabricantes de HDs que eu conheço.
 A Hitachi é uma forte aliada ao Linux sendo membro ouro bem ao lado da Google. Outra forte fabricante de HD e também aliada ao Linux, é a Toshiba (que ambas podem ser conferidas mesta imagem):



  Em 2.011, a divisão de HDs da Hitachi foi adquirida pela Western Digital. Não somente isso, mas a Sandisk também é uma corporação da Western Digital (cé bichão mesmo hein Western Digital). A Western Digital é outra que também é aliada ao Linux sendo membro prata (não tanto quanto a Hitachi, mas já está de bom tamanho):


 E por que não comprar um novo SSD? Por questão de confiabilidade. Eu possuo um SSD; ele é muito bom, ocupa menos espaço, a temperatura de um SSD é bem mais baixa (ele é quase frio mesmo em atividade), mas o que mais me atrai em um SSD (e acho que a todo mundo) é o desempenho. Outra coisa que me atrai é ter a maior chance de não perdê-lo em uma queda de energia. Eu já tinha perdido dois HDs com queda de energia e foi aí que então decidi comprar um SSD. Se ocorrer queda de energia novamente, tenho maior probabilidade de não perdê-lo devido não ser um dispositivo mecânico girando um disco com uma agulha gravando em cima.


 Mas tratando-se de backup, SSDs não são confiáveis. Pode-se fazer backups em SSDs, não é esse o problema e o problema não é visto de imediato;  o problema é que os SSDs possuem tempo de vida indeterminado e eles param de funcionar de uma hora para outra (inesperadamente). Não é como a outros dispositivos que vão apresentando falhas ao longo do tempo e aos poucos vão morrendo. Quando eles param de funcionar, param de uma vez só. Outro problema é que os SSDs começam a perder dados com a ausência de energia. Portanto, nessas condições, ainda prefiro confiar nos HDs para os meus backups.

Eu possuo dois HDs da Seagate de 500GBs para fazer meus backups; um com ext4 e outro com XFS.  De tempos em tempos compor um novo HD como prevenção. Quando fui pesquisar sobre HDs para que eu pudesse comprar um novo esse ano, vi um benchmark da empresa Back Blaze, uma das melhores empresas de armazenamento de dados do mundo. Mencionei essa empresa no vídeo "Não viva de boatos (Quebrando paradígmas 2ª parte - Linux VS FreeBSD)" que pode ser conferido logo abaixo se ainda não assistiu:



 E outros gráficos da empresa me convenceram a comprar HD da Hitachi:


 Beleza; então, foi o que eu fiz. Comprei um HD da Hitachi. Primeiro que foi difícil de encontrar; quando encontrei, os caras me enrolaram mais ou menos 10 dias para depois me oferecer um da Western Digital pelo mesmo valor de um da Hitachi (AH, VÃO SE...)

Bom, pedi reembolso e comprei em outro lugar (que foram ninjas na hora de entregar). Chegado em casa, fiquei parecendo criança quando ganha presente novo. O HD é lindão, todo fechado, apesar de ser SATA ele possui dois tipos de portas para alimentação (sendo do novo modelo SATA e do anti IDE, que preferi usar o IDE por ter apresentado melhor desempenho):


Reparem a placa lógica da bagaça
Coloquei dois HDs para comparar a espessura da bagaça. O de baixo é o Hitachi e o de cima o SeaGate.
Se repararem na sua parte traseira, ele possui cabo de alimentação do modelo SATA e do IDE:



utilizei o cabo de alimentação do padrão IDE

 Beleza, conferi no BIOS do meu PC e tudo OK, foi reconhecido.



 Beleza, o próximo passo é fazer ele funcionar no Linux. Bora para o arrebento então (se bem que foi simples, nada de anormal).

 A princípio pode parecer estranho o HD não ter sido reconhecido pelo comando "blkid". A questão é que o comando blkid consulta essas informações no superbloco (bloco que contem informações de tipo de filesystem, tamanho, blocos de dados, blocos livres, inodes e dentre outras coisas); e como o HD ainda não havia sido formatado, logo ele não possuía partições e onde o comando blkid consultar e me retornar informações. Foi onde apliquei o comando "dmesg" com e filtrei para encontrar os dispositivos SATA (e descobrir se o HD havia sido detectado pelo sistema):
blkid exibindo somente um dispositivo
Comando  "dmesg" exibindo dispositivos SATA durante o processo de boot
Dispositivos sendo exibido através do "ls /dev/sd?"
 Sabendo qual o dispositivo, então, bora formatá-lo. Eu não tenho o hábito de usar o fdisk; geralmente quando formato um dispositivo, eu utilizo o cfdisk:







Esse HD possui suporte a GPT; então aqui vamos nós utilizar GPT.



 Ok. Feito o trabalho de criar as partições em 0x83 (partição Linux), bora formatar:

Desta vez eu resolvi utilizar o BTRFS como filesystem padrão nesse novo dispositivo.


 Beleza; feito isso, é só alegria. Bora fazer backup dos outros HDs para o novo Para eu ter as minhas cópias idênticas.


Exibindo espaço disponível dos dispositivo na ultima linha com o comando df -h
 Tenho que mencionar que achei estranho a principio o fato de HD, além de ser rápido, ser mais silencioso que os HDs convencionais (o que é show de bola).

Uma características do BTRFS é que o filesystem realiza verificação no momento do boot.


 Fiz um teste básico copiando 100 arquivos com tamanhos variados sendo o menor com coisa de 6KBs e o maior, em torno de 80MBs. No primeiro teste, copiei os arquivos do pendrive para o SSD com ext4 e o resultado foi o seguinte:

Levou pouco mais 7 segundos para os arquivos serem copiados

 Em seguida copiei os mesmos arquivos do pendrive para o HD Hitachi com o BTRFS:

O resultado foi surpreendente levando pouco mais de um segundo.

 Testei também com um vídeo que tenho do ZedOS (uma distribuição que é feita por um amigo de Portugal que vou fazer vídeo ainda no canal para ajudar a divulgar) salvo no pendrive:

Esse foi o resultado no HD Hitachi com o BTRFS

Esse foi o resultado no SSD com o Ext4
 Claro que nesse caso o filesystem também tem que ser avaliado. O teste mais correto seria ter testado os dois dispositivos com o mesmo filesystem ou os diferentes filesystems no novo dispositivo, mas pela lógica, o SSD favoreceria o Ext4 pelo fato de HD ser um dispositivo que fica em constante movimento e o SSD um dispositivo solido; mesmo assim o BTRFS mostrou ter desempenho surpreendente bom.

 Sendo franco, eu poderia ter feito isso graficamente, mas não é um hábito que tenho. Não é que fazer isso pelo terminal seja melhor ou pior, é porque basicamente já estou condicionado a fazer pela linha de comando. Qualquer dia desses eu paro para ver como fazer isso pela GUI. Saber tal coisa também é importante para no caso estar preparado para um dia atender um cliente.

Estrutura de sistema de arquivo parte I

Escrevi um artigo tratado de benchmark de filesystems. Por que então não tratarmos desta vez de como um sistema de arquivo é estruturado nos *nix?

Estrutura de sistema de arquivo parte I

 Sistema de arquivo  é o método de armazenar e organizar coleções arbitrária de dados em uma forma utilizável a humanos.
 Quem acompanha o canal Toca do Tux já deve ter assistido o vídeo "Filesystems (vale a pena saber?)" onde narro um pouco sobre o assunto.:


 Antes de dar inicio ao assunto quero fazer um esclarecimento. Vi certa vez um amigo compartilhar em uma rede social como o sistema de arquivo é estruturado e fez o seguinte comentário:

Se notarem, esse meu amigo fez até a observação corrigindo o que afirmam.
 Essa informação não trata da estrutura do kernel. trata-se na verdade, de como os diretórios do sistema são estruturados dentro do sistema de arquivo.
Diretórios são em uma interface gráfica as pastas que visualizamos. O termo pasta foi adotado pela Apple para facilitar para os usuários (ficar algo, digamos, mais amigável).

 As informações sobre para que serve cada diretório podem ser obtidas e lidas na documentação FHS. O FHS (Filesystem Hierarchy Standard) é a documentação que define e descreve a utilidade de cada diretório, quais diretórios são necessários, quais são opcionais e quais são sugeridos nos sistemas Unix (uma herança que os Unix tem em comum).
 Um dos escritores responsáveis pelo FHS foi Rusty Russell (conhecido também por ser o desenvolvedor que originalmente escreveu o Ipchains e o Netfilter/Iptables, iniciou o trabalho de desenvolvimento do Hypervisor Lguest no kernel Linux e em 2009 integrou a equipe do Samba).
Rusty Russell na conferência Australiana linux em Janeiro de 2011
man iptables
 Existe também o Linux Filesystem Hierarchy, que conheci quando a ultima versão do FHS era a 2.1. Hoje em dia FHS é mantido pela Linux Foundation na sua ultima versão, que é a 3.0, o nome de Rusty Russel permanece lá (ele merece os créditos por suas contribuições feitas). É uma documentação que vale a leitura.


Mais informações:

Entendendo a separação dos diretórios /bin, /sbin, /usr/bin, /usr/sbin

Filesystem Hierarchy Standard
Filesystem Hierarchy Standard

Você sabe como Ken Thompson e Dennis Ritchie criaram o Unix em um PDP-7 em 1969? Bem, por volta de 1971 eles atualizaram para um PDP-11 com um par de hard drives.

Entendendo a separação dos diretórios /bin, /sbin, /usr/bin, /usr/sbin

Quando o seu root filesystem cresceu demais para se adequar em seu disco (meio megabyte), eles deixaram vazar para um disco RK05 que era maior porém mais lento, que é aonde todos os diretórios user e home era abrigados e é o por que o mount foi chamado /usr. Eles replicaram todos os diretórios do sistema operacional sob o segundo disco (/bin, / sbin, /lib, /tmp...) e escreveram arquivos para aqueles novos diretórios porque seus discos originais não tinha espaço suficiente. Quando obtiveram um segundo disco RK05, eles o montaram no /home e realocaram todos os diretórios de usuário para esse terceiro disco então seu sistema operacional poderia consumir todo o espaço nos primeiros dois discos e crescer para todo os três megabytes.

Claro que eles criaram regrar sobre “quando o sistema bootar, ele tem que subir o suficiente para ser capaz de montar o segundo disco em /usr, então não coloquem as coisas como o comando mount em /usr/bin ou teremos um baita problema para colocar o sistema no ar.” O fato é que seu minusculo disco era muito mais rápido do que um RK05 funcionava lá também: Mover arquivos do /bin para o /usr/bin tinha um impacto de desempenho significante nesse particular PDP-11. Bem direto, e também bem específico para o hardware v6 que o Unix foi desenvolvido 40 anos atrás.

 A divisão do /bin vs /usr/bin (e todos os outros) é um artefato disso, um detalhe na implementação de 1970 que foi levada adiante por décadas por burocratas que nunca questionaram por que eles estavam fazendo coisas. Parou de fazer sentido antes que o Linux fosse inventado por múltiplas razões:
  1. O primórdio sistema de colocar o sistema no ar é a provincia do initrd e do initramfs, que lidava com os problemas do “esse arquivo é necessário antes daquele arquivo”. Já temos um sistema temporário que já inicializa o sistema principal.
  2. Bibliotecas compartilhadas (introduzida pelos caras de Berkeley) impedia você de independentemente atualizar as partes do /lib e do /usr/bin. Duas partições tem que combinar ou eles não funcionarão. Esse não era o caso em 1974; de volta eles tinham um certo nível de independência porque tudo era estaticamente lincado.
  3. Discos rígidos de varejo baratos passavam a marca dos 100 megabytes por volta de 1990, e software de redefinição do tamanho das partições  apareceram em algum lugar por volta daquele tempo (partition magic 3.0 embarcou em 1997).
Claro que uma vez que as divisões existiam, algumas pessoas criaram outras regras para justificá-la. Root era para as coisas do sistema operacional que você obtinha a partir do upstream e /usr era para seus arquivos locais. Então "/" era para as coisas que você obtinha a partir da AT&T e "/usr" era para as coisas que sua distro, como IBM AIX ou Dec Ultrix ou SGI Irix, adicionavam a ela, e "/usr/local" era para os seus arquivos de instalações especificas.

Mais tarde, alguém decidiu que o "/usr/local" não era um bom lugar para instalar novos pacotes, então vamos adicionar "/opt"! Ainda estou esperando o "/opt/local" aparecer... Claro, dados 30 anos para solidificar, essa divisão fez algumas regras específicas interessantes de distros surgirem e seguir adiante novamente, tal como “/tmp" fica limpo entre os reboots, mas "/usr/tmp" não. No Ubuntu, "/usr/tmp" não existia,e no Gentoo, "/usr/ tmp" é um link simbólico para o "/var/tmp", na qual agora possui a regra “ não limpo entre reinicializações (not cleared between reboots)”. Sim, tudo isso precedem o tmpfs. Ele tinha a ver com os read-only root file systems. "/usr" sempre vai ser read-only nesse caso, e "/var" é aonde o seu espaço gravável fica.

Além disso, "/" é mais read-only exceto pelos bits do "/etc", que tentaram mover para o "/var", mas o link simbólico do "/etc" para o "/var/etc" aconteceu mais frequentemente do que não. Padrões burocráticos, como a Linux Foundation (que consumiu o Free Standards Group em seu acréscimo de discos em constante crescimento anos atrás), alegremente documenta e adiciona a esse tipo de complexibilidade sem constante tentar entender porque aquilo estava lá em primeiro lugar. “Ken e Dennis vazaram seu OS no equivalente de home porque o disco root no PDP-11 era pequeno demais" vai silvar nas suas cabeças.
Rob Landley é um geek desde a sua infância, um geek Linux desde 1998, e um geek de Linux em embarcados desde 2001 (nota do tradutor: ano que eu conheci o Linux). Reimpresso com permissão do autor original. Primeira aparição em hn.my/bin (busybox.net).

Redução do kernel Linux e do filesystem para IoT

Essa é uma noticia mais de um mês atrás. mas já que estamos falando sobre o toybox na série "Muito além do GNU" essa semana, porque não estender mais o assunto para conhecer mais sobre a ferramenta?

Na Embedded Linux Conference que aconteceu do dia 21 a 23 de Fevereiro deste ano em Portland, Michael Opdenacker da Free Electrons apresentou a palestra sobre como reduzir o tamanho do sistema (tando o kernel quando o user space) já que Linux estava cedendo espaço na IoT para os RTOSes.

Link para o artigo com o vídeo em linux.com

Nessa, Michael apresentou utilizando ferramentos como o LLVM/Clang  3.8.1 no lugar do GCC (mesmo que o GCC 6.2 tenha apresentado melhoria diante o GCC 4.7 no ARM). Com o GCC podemos utilizar a opção -Os para reduzir o espaço enquanto que o LLVM/Clang faz isso “out of the box sem precisar fazer nada”. O LLVM/Clang compila o kernel também para a otimização de desempenho tornando-se melhor do que o que temos hoje com o GCC LTO hoje.

Chegaram a sugerir patches de melhoras para o GCC, mas os patches causaram novos problemas e os desenvolvedores temeram que isso criaria novos bugs dificeis de serem rastreados e por isso os patches não foram aceitos.

Outras tecnicas foram aparesentadas para utilizar com o GCC como a opção -mthumb (que no compilador do Ubuntu vem por padrão) para fazer uma mescla de instruções de 16 e 32 bits aos invés de somente 32 em procedores ARM, a opção “make tinyconfig” que é utilizada desde o kernel 3.18, para combinar junto ao “make allnoconfig” com mais algumas configurações e assim reduzir o tamanho dos binários 
“ela utiliza gcc optimize for size, assim o código pode ser mais lento mas se torna menor”
“Você habilita a compressão XZIP do kernel, e você economiza entre 6 a 10KB.”
Habilitar a opação obj-y no kernel Makefiles podendo compilar o kernel sem a necessidade do ptrace o tempo todo, que em ARM consome 14KB. 

no lado do user space, foram sugeridas ferramentas como o próprio toybox:

Site oficial to toybox

“Toybox possui as mesmas aplicações e a maioria dos mesmos recursos que o busybox, mas utiliza somente 84KB ao invés de 100KB,”
“Se você quiser um shell com apenas algunas algumas utilidades na linha de comando, toybox poderia lhe economizar milhares de bytes, embora ele seja menos configurável."
O uso da Musl que utiliza menos espaço do que glibc (sem duvida) ou que a uclibc foi outra opção sugerida por Michael. apresentando um teste de comparação entre bibliotecas compilando um programa hellho.c com o GCC 6.2, o resultado final com a musl foi de 7.3kb,  67KB com a uclibc-ng 1.0.22 e 49KB com a glibc.

Para reduzir o filesystem, Michael sugeriu o uso do initramfs que lhe permite realizar boot mais rápido uma vez que não inicializa um filesystem e drivers armazenados. Para sistemas com mais RAM, Michael sugere o uso de filesystems mais compactos com o squashfs, JFFS2 ou ZRAM. Michael conclui que ainda há melhorias significativas a serem feitas no kernel space e no userspace. Daí eu imagino:

Se Linux já é bom, imagina tendo essas melhorias. Espero ainda ver isso =)

Benchmark de Filesystems

No meu vídeo "Filesystem (vale a pena saber?)" mencionei que iria disponibilizar uma lista de alguns teste básicos que podem ser realizados na escolha de um sistema de arquivo. Então, vamos para o arrebento e verificar o resultado do benchmark realizado.


Benchmark de sistema de arquivos


 Tudo beleza galera?
 No meu antigo blog eu cheguei a escrever um artigo sobre filesystems com o título de "Qual O Melhor Sistema de Arquivos?", tenho até uma foto com Ted T'so lá, porém acho que é um artigo que ficou incompleto e por fim desta vez fiz o vídeo para melhor abordar o assunto (ou abortar como um cara me falou semanas atras kkkkkk. Está certo que meu português não é lá essas coisas, mas convenhamos né).
 Caso ainda não tenha assistido o vídeo, ele pode ser verificado logo abaixo:





















 Como havia prometido no meu vídeo sobre "Filesystem (vale a pena saber?)" realizei alguns testes comparativos com alguns filesystems mais presentes em desktop para que todos possam saber o que cada um desses tem a oferecer. Vale repetir que realizei esses testes somente com alguns que são populares em desktop (populares não somente em desktop, mas fica entendido), mas eles podem muito bem ser realizado com qualquer filesystem (além de verificar quais resursos cada sistema de arquivo proporciona).


Para que tais testes sejam realizados, deve-se levar em consideração tudo: Seu hardware, distribuição que está sendo utilizada (não estou tratando aqui que uma é melhor do que a outra, mas tais coisas devem ser levadas em consideração).

 Então, levando tal em consideração, utilizei o seguinte:
  •  Intel Core2Duo E8400 de 3.0GHz
  •  8 Gigabytes de RAM
  •  Placa mãe ASUS (barramento 1333)
  •  Pendrive Kingston Technology DataTraveler 101 II de 8 Gigabytes.
  •  Distribuição Debian 8.1 (codenome Jessie), versão de 64 bits e a interface Mate.
  •  Os sistemas de arquivo que foram utilizados neste teste foram: Ext2/3/4, XFS, FAT e o NTFS.
  •  Utilizei dois tipos de arquivos, um grande e um pequeno. Sendo que considero aqui o arquivo grande uma imagem iso (a mesma que utilizei no vídeo) e o arquivo pequeno um arquivo odt de 188 kilobytes (padrão ODF que é um XML zipado como menciono no meu artigo "A Ameaça Que Os Arquivos Fechados Podem Causar").
  • Os comandos utilizados aqui no teste foram: wipefs (em alguns momentos para limpar a assinatura do dispositivo e evitar problemas), cfdisk ou fdisk para criação de partição no dispositivo, mkfs (para criar o sistema de arquivo a ser testado), df (para verificar o tamanho final de armazenamento da mídia removível), tune2fs -l ou dumpe2fs (para verificar a  quantidade de inodes disponíveis e o tamanhos dos blocos dos filesystems. Com esses dois comandos você pode verificar tudo sobre o sistema de arquivo), time seguido dos comandos cp/rm (para medir o tempo de gravação ou exclusão do arquivo), du (para verificar tomando do arquivo após gravação do arquivo em mídia).

 Todo os testes aqui realizados foram feitos não havendo mais nada em execução no sistema, somente um pts (um Pseudo Terminal de comandos que é invocado através da interface gráfica. Tudo deve ser levado em consideração durante um teste).

 Realizados os testes, gerei em uma planilha os seguintes resultados obtidos:

os resultados podem ser verificados a seguir.

 Podemos verificar nos resultados que cada um ofereceu uma certa vantagem em algum momento.
 Na ocupação em mídia após formatação do XFS que ficou em segundo lugar por pouco mais de 10 Mega Bytes (10236 para ser mais específico). Esses são resultados do tamanho total; ainda devemos considerar a parte do que o sistema de arquivo ocupa por sim devido aos seus recursos, como o EXT4 que ocupou pouco mais de 17 megabytes enquanto que o XFS ocupou pouco mais de 33 Megabytes.

Na parte de tamanho de blocos todos tiveram o mesmo resultado, porém essa foi uma formatação padrão. Na quantidade de inodes disponíveis todos também empataram.

No questão de tempo de gravação de arquivo (grande) em mídia (relevando que considerei um arquivo de 4.4GB como um arquivo grande nessa ocasião), o EXT4 foi o melhor, vindo a ganhar do XFS em pouco mais de 18 segundos. Ja se notarem o NTFS, ele levou absurdos (pasmem) quase 54 minutos para gravar o mesmo arquivo. Não estou brincando não e não estou tentando boicotar a Microsoft. Eu printei a tela para que possam conferir:

Esse foi o resultado do tempo de gravação do arquivo grande com o NTFS.

Fora isso, filmei o vídeo onde o pendrive estava em execução o tempo todo sendo que não havia nada em operação):





No tamanho final de arquivo o FAT foi o que apresentou menor tamanho de arquivo no final, porém isso não conta pois o FAT grava no máximo quase 4.2GB. Hoje em dia existe o ExFAT que não possui suporte a journaling, mas que permite gravação de arquivos maiores. O XFS e o NTFS foram os que apresentaram melhor aproveitamento nesta ocasião (mas mínima coisa em comparação ao EXT4. Coisa de 4K).

Na questão Tempo de remoção de arquivo (grande), o NTFS apresentou o melhor resultado que não foi lá assim grande coisa comparado ao XFS).

Passando para a o teste realizado com um arquivo pequeno (considero aqui um arquivo de 188K pequeno). No tempo de gravação de arquivo, o EXT3 apresentou o melhor resultado. No tamanho final em mídia, quase todos apresentaram o mesmo resultado (menos o EXT2 e o 3 que tiveram o arquivo do tamanho de 192K). No tempo de remoção do arquivo, todos apresentaram empate.

 A parte de remoção de arquivo em um sistema funciona da seguinte forma, quando excluímos um arquivo, o que acontece na verdade é que o sistema exclui somente seu cabeçalho. Logo o arquivo ainda está lá, porém ele fica ilegível (inacessível).
 Existe o comando lsattr em que podemos verificar os atributos dos arquivos e o comando chattr que podemos alterar esses atributos. Se alterarmos o atributo de um arquivo com opção -s no comando chattr, o comportamento de exclusão do arquivo se torna diferente, pois não é excluído somente seu cabeçalho. O que ocorre nessa ocasião é que o sistema enche o arquivo de zeros; logo ele é literalmente excluído.
 É possível ainda sim recuperar o arquivo por alguns meios, mas isso é outro assunto; o que quero notar aqui é o sistema de arquivo precisa ter esse recurso disponível para que isso seja realizado.

 Eu espero que tenham gostado e aprendido bastante. Não deixem de verificar o manual online do chattr e do lsattr:

man chattr
man lsattr

 Até a próxima. :-)

POLEMICA - Linux ou BSD? Qual o melhor?

Linux ou FreeBSD?
Linux e FreeBSD.
A verdade é que não há melhor ou pior! Cada um é bom nas áreas em que se especializaram ou que atuam (nada impedindo-os que cada um as ampliem).

Recentemente postaram em um grupo em uma rede social tal pergunta, então peguei exatamente este título escrito na rede social e resolvi fazer uma analise sobre os BSDs para poder responder sobre o assunto, pois não somos xiitas ao ponto de não utilizar e/ou testar outros sistemas operacionais (mas talvez não seja um assunto que eu queira mais abordar. Quero focar mais em Linux desde que já expliquei sobre esse assunto anteriormente no artigo sobre as diferenças entre os dois sistemas que traduzi do distrowatch). Alias, uma das qualidades que Linux proporciona aos seus usuários é o amplo conhecimento (mais uma das liberdades que existem dentro do mundo Linux e que muitos exploram pouco): Outras arquiteturas, que dentro do próprio kernel é possível notar quantas arquiteturas são suportadas (e tem gente ainda achando que Linux só é para servidores ou que só exista x86...), outros filesystems (por que para técnico em Windows é assim, tudo para eles é partição: Partição FAT, partição NTFS... Conhecimento proporcional = 0; por que partições e filesystems são coisas totalmente diferentes), outros sistemas operacionais, outras licenças.
Arquiteturas dentro do kernel Linux.
Arquiteturas dentro do kernel Linux

Filesystem no kernel Linux.
Filesystem no kernel Linux.

Não vou narrar aqui a história do BSD, por que já a abordei inesperadamente no vídeo "Não viva de boatos"; aconselho a dar uma olhadinha logo abaixo:



Mas uma coisa que vale a pena mencionar é que BSD é o nome dos sistemas derivados desta família, da licença e do próprio layout criado para o BSD. Layout B
Layout BSD no Porteus
Layout BSD no Porteus.

 Já que teve gente quem criticasse a imagem que aqui utilizei do Porteus Linux para mostrar o Layout BSD (que no Layout SystemV é diferente, utilizando /etc/init.d/serviço) fazendo a afirmação de que eu mencionei que o runlevels do BSDs vão de 0-6 (o que não afirmei em momento algum) então estou postando hoje (lembrando, este artigo foi publicado no dia 26/02/2015 e estou inserido este parágrafo no dia 03/03/2015 ) o manual do Arch Linux que eu já havia postado no vídeo "Não viva de boatos" logo acima, pois assim como o Slackware, essa é outra distribuição que utiliza esse layout para controlar seus serviços. Caso queiram, verifiquem na página 4 para entenderem a diferença entre os dois padrões.
De opinião própria, o que cada um oferece de melhor seria que o Linux é muito interessante na parte de multi-processamento (invejável), desempenho (invejável também) e virtualização. Enquanto os BSDs são muito bons em Firewall (o firewall do Linux, no caso o Netfilter, também é muito bom, porém os BSDs possuem o firewall mais poderoso do mundo o Package Filter).
Assim como no mundo Linux, que possui quatro distribuições como principais (apesar que o Arch anda ganhando muita notoriedade): Slackware (forte no aprendizado de Linux bem na essência. Nesse aspecto o LFS também merece esse crédito), Debian (focado na segurança e estabilidade), Redhat (ótimo em soluções empresariais) e Gentoo (forte em otimização de desempenho); os BSDs também possuem quatro principais e cada uma delas voltada á um foco principal. Todas as demais (digamos assim) distribuições BSDs derivam dessas quatro:
Beastie
  • FreeBSD É focada em robustez e eficiência tanto para ambientes servidores quanto para desktop para plataformas Intel e AMD (hoje portado para várias arquiteturas). Seu lema é "The power to serve" (O poder para servir"). Seu mascote é um demônio chamado Bestie. Esse é o BSD mais utilizado entre todos os outros. 
  • NetBSD Focada em rodar no maior número de plataformas possíveis tornando-o o OS mais portável do planeta; tanto que seu lema é “Of course it runs NetBSD” (É claro que roda NetBSD!). Roda em tudo essa bagaça.
  • OpenBSD é focado primariamente em segurança e nos tópicos relacionados (forte integração de segurança, criptografia a um nível TOP LEVEL. Esse é o sistema operacional mais seguro do mundo). Seu mascote é um peixe que mais parece... com... um baiacu.
  • DragonFlyBSD Com muitos conceitos inspirados do AmigaOS (que, alias, Mathhew Dillon é conhecido por criar o compilador C DICE no Amiga) e com recursos similares ao do Linux, é focado em proporcionar uma infraestrutura SMP compatível que seja fácil de entender, manter e de desenvolver. Esse foi o que mais utilizei, Então, vou basear a minha experiência nele. Gravei a imagem iso em um pendrive com um simples comando dd conforme descreve no meu manual Caixa de Ferramentas do Unix, criptografa tudo no momento da instalação (dispositivo, filesystem, home... até cansa na hora de bootar e ter que ficar digitando senha, mas garante ótima segurança), utiliza os filesystems UFS ou HAMMER (H.A.M.M.E.R foi desenvolvido pelo próprio Matt Dillon para suportar HDs de 4 teras  ou até storages acima de um exabyte e tem uma pancada de recursos), vem no caso como o FreeBSD (sem interface gráfica). Bom, gostei dele até demais. Uma coisa que Matt Dillon merece crédito foi o fato de ter descoberto bug no processador da AMD onde foi até convocado pela própria AMD para ajudar na correção de tal erro.
Cada um desses quatro surgiram de alguma forma como fork: o FreeBSD e o NetBSD como fork do 386BSD iniciado como patchkit em 1993; depois o OpenBSD como fork do NetBSD em 1995 devido intrigas internas entre os desenvolvedores; e depois o DragonFlyBSD como fork do FreeBSD em 2003 quando o desenvolvedor do FreeBSD, Matt Dillon  entrou em desacordo com ao comunidade do FreeBSD ao propôr melhorias na parte de clustering no kernel entre outras coisas. Alias, essa é uma coisa que não concordo quando foi dito em outro artigo que traduzi sobre a definição Unix-Like onde afirmaram que os BSDs são clones do UNIX.
Principais distribuições BSD
Principais distribuições BSD
Os BSDs estão sob a licença chamada... BSD em que reza mais ou menos o seguinte: "Do whatever the hell you want with the code, just give us credit for writing it" (Faça seja o que for que quiser fazer com o código, dê-nos apenas crédito por escrevê-lo). Caso queiram saber mais sobre a diferença entre as licenças, sugiro a leitura do artigo "Definição sobre software livre".
Todos os BSDs se preocupam com segurança (apesar que cada um tem um nível diferente do outro). Muitos desenvolvedores trabalham em mais de  um sistema
Diferença de segurança entre OpenBSD e FreeBSD
Diferença de segurança entre OpenBSD e FreeBSD


 Os BSDs possuem uma família de grande também (alguns descontinuados, outros forks e assim segue) que podem ser acompanhados no wikipedia.
 Moral da história, é que eu acho que os dois sistemas devem sempre andar em harmonia e não ficar com diferenças que geram intrigas (não gosto dessas brigas que não levam a nada). Acho que ambos os sistemas deveriam ser mais unidos; ambos cresceriam até mais rápido ao meu ver.

Atualizações do Btrfs 5.6


Atualizações do Btrfs 5.6
Atualizações do Btrfs 5.6
 Btrfs é sistema de arquivos (ou filesystem) copy-on-write, moderno e de proposito geral e que possui uma gama de recursos proporcionando vantagens ao Linux. Eu venho comentando sobre o Btrfs no meu canal e no meu blog há anos e no ano passado, esse sistema de arquivos passou a ser exigência na própria LPI.  Esse no caso foi o primeiro que eu resolvi fazer e que depois se tornou uma playlist:


 Mas falando da nova versão, Nn dia 27 de Janeiro, David Sterba da Suse anunciou as atualizações para a versão 5.6 do Btrfs que recebeu os seguintes recursos:
  • async discard
  • Habilitação do "mount -o discard=async"
  • freed extents (extensões liberadas) não são descartadas imediatamente, mas agrupados e aparados depois, com IO rate limitante.
  • O "sync" mode submete short extents que poderiam ter sido ignorados completamente pelo dispositivo, para SATA anterior a 3.1 as requisições não são  enfileiradas e possuem um grande impacto no desempenho.
  • As actual discard IO requests foram mudadas da transaction commit para uma worker thread, melhorando a latência do commit.
  • IO rate e request size podem ser ajustadas pelos arquivos do sysfs, por hora habilitada somente com CONFIG_BTRFS_DEBUG já que poderíamos precisar adicionar/excluir os arquivos e não ter uma ABI estável para uso geral, padrões são conservativos
  • export device state info no sysfs, ex.: missing, writeable
  • no discard de extents conhecidos por serem intocados no dispositivo de armazenamento (ex.: depois de ser reservado)
  • Logo do device stats reset como nome de processo e PID que chamavam o ioctl
 Além da nova atualização com novos recursos, a versão conta também com mais cinco correções e oito alterações.

 Um novo recurso que pode ser implementado na próxima versão (ou na próxima atualização da mesma versão) é a DRW lock [(D)ouble (R)eader (W)riter lock] que foi sugerido por Nikolay Borisov (também da Suse). DRW lock é uma técnica antiga de locking primitive que permite ter múltiplos readers ou writers mas não múltiplos readers e writers simultaneamente. O código é consignado a partir do open-coded locking scheme utilizado para excluir snapshots pendentes do nocow writers e vice-versa. A implementação atual favorece os Readers (que é criador de snapshot) para os writers (nocow writers do filesystem).

Mais um pacote não GNU - Procps-ng

comando-top-que-faz-parte-do-pacote-procps
Comando top que faz parte do pacote Procps
Pois é, parece que esse assunto não tem fim. Essa semana mostrei quatro pacotes que possuem conjunto de comandos que utilizamos diariamente/frequentemente e que não tem vinculo com o projeto GNU. Mas como não me contentei somente com esses quatro pacotes, resolvi mostrar mais um aqui que pertence ao Linux (e não ao GNU ;). Antes de continuar falando sobre o pacote, confiram o vídeo sobre os quatro pacotes anteriores caso ainda não tenha visto:


Esse é o procps, que possui os comandos que utilizamos para manipular os processos (apesar que o kill se encontra no Util-Linux). Vou me ater apenas a tradução do que já está escrito no próprio site oficial do projeto.

procps é um conjunto de utilidades de linha de comando e tela-cheia que fornece informações fora do pseudo-filesystem mais comumente localizado em /proc. Esse filesystem fornece uma simples interface as estruturas de dados do kernel. Os programas do procps geralmente concentram nas estruturas que descrevem os processos rodando no sistema.

Os seguintes programas são encontrados no procps:
  • free - Reporta de memória livre e utilizada no sistema
  • kill - Envia um sinal para um processo baseado no PID
  • pgrep - Lista processos baseados no nome ou ouros atributos
  • pkill - Envia um sinal para um processo baseado no nome ou outros atributos
  • pmap - Reporta mapa de memória de um processo
  • ps - Reporta informações de processor
  • pwdx - Reporta diretórios atuais de um processo
  • skill - Versão obsoleta do pgrep/pkill
  • slabtop - Exibe informações do kernel slab cache em tempo real
  • snice - da um renice em um processo
  • sysctl - Lê ou escreve parâmetros do kernel em tempo de execução
  • tload - Representação gráfica da media de carregamento do sistema
  • top - Visualização dinâmica em tempo real de processos em execução
  • uptime - Exibe há quanto tempo o sistema está rodando
  • vmstat - Reporta estatísticas da memória virtual
  • w - Reporta usuários logados e o que eles estão fazendo
  • watch - Executa um programa periodicamente, exibindo saída em tela cheia

Morre Aboriginal Linux :(

Turtle Board testada com o FPGA
Turtle Board testada com o FPGA antes do primeiro cilicio do J2 ser lançado
Ok, esse título foi somente para chamar a atenção mesmo, mas que o Aboriginal Linux morreu, isso sim aconteceu. apesar que isso não é uma noticia nova. O Aboriginal Linux chegou ao seu fim em no dia 30 de Abril deste ano. Isso aconteceu para dar inicio ao projeto mkroot feito pelo próprio Rob Landley (criador do Toybox, do propŕio Aboriginal Linux e contribuidor no desenvolvimento do processador J-core). Então, a distribuição em si mesmo não morreu; ela só está se metamorfoseando em algo melhor.

O Aboriginal Linux foi a primeira distribuição a rodar com a biblioteca UclibC ao invés da GlibC e o Busybox ao invés do Bash. O motivo original do Aboriginal Linux foi que Knoppix era única distribuição que realmente dava atenção aos desktops por volta de 2002 (entenderam o porque da minha não adoção ao Linux em 2001?) e os 700 megabytes do Live CD do Knopix incluíam os mesmo 100 Megabytes dos pacotes do Linux From Scratch que proporcionavam quase a mesma experienciaria que o tomsrbt (que rodava em apenas 1.7 Megabytes; ou seja, um disquete).

tomsrbt
Imagem da distribuição tomsrbt
Mais uma coisa foi a prova de conceito de que Linux não era obrigado a ser chamado de GNU/Linux ou LiGNUx ou sei lá que bobeira mais.

Com o mkroot, você pode Compilar um root filesystem e o kernel Linux baseados no toybox que podem ser bootados sob o qemu.

A diferença entre o Aboriginal Linux e o projeto mkroot é a da substituição da UcLibC pela biblioteca Musl e do Busybox pelo Toybox sobre o kernel Linux. Ambas (tanto biblioteca quanto terminal) estão sob licenças diferentes que não sejam GPL. A Musl está sob a licença MIT (me lembro de ser o meu primeiro contato de uso real desta licença) e o toybox que está sob a clausula 0 da licença BSD (0BSD). Mais um motivo está em torno do melhor código de ambos os projetos adotados. Parece que pretendem  adotar o compilador tcc no futuro também. O Toybox já é utilizado por padrão no Android ao invés do Busybox como pode ser visto no vídeo abaixo. Espero que também venha a fazer parte do boot do Linux substituindo do Linux e também seja adotada por padrão na distribuição alpine Linux:


A principio o mkroot fazia (ou ainda faz) uso em partes do Busybox por uma questão de dependências que ainda podem não ter sido  supridas no Toybox, mas que trabalham nisso ao longo do tempo. Me lembro de ter visto links simbólicos dentro do mkroot quando baixei para testar e gerando um root filesystem.

Hoje o mkroot recebeu atualização para o kernel 4.14 kernel, está disponpivel para muitas arquiteturas como arm64 powerpc64 funcionando, já testado tudo com o gcc 7.2, estão atualmente testando com a futura versão da musl-libc, thalheim no freenode utilizou o script mcm-buildall.sh de Rob e postou os resultados dos binários compilados em:
http://b.zv.io/mcm/bin/
Se conseguirem construir o kernel para o processador SH2, não precisarão de emulação para a placa turtle/numato.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (15) AMD (14) analise (9) Andriod (8) artigo (5) benchmark (3) BSDs (20) btrfs (12) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (6) Código Fonte (50) comandos (17) comp (1) compressores (4) container (1) CPU (18) criptografia (2) crowdfunding (9) cursos (21) daemons (13) Debian (29) desenvolvimento (55) desktop (17) DevOps (1) DevSecOps (1) dic (1) Dica de leitura (52) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (7) DragonflyBSD (15) ead Diolinux (2) edição de vídeo (4) EMMI Linux (4) emuladores (5) endless (5) English interview (2) Enless OS (2) entrevista (16) espaço aberto (83) evento (4) facebook (1) Fedora (4) filesystem (59) financiamento coletivo (2) fork (3) fox n forests (4) FreeBSD (12) Funtoo Linux (13) games (87) gerenciadores de pacotes (2) GOG (3) google (8) gpu (3) hardware (98) I.A (1) init system (7) Intel (15) IoT (1) ispconfig (1) jogos (33) kernel (114) lançamento (43) leis (1) LFCS (1) licenças (7) Linus (15) linus torvalds (1) Linux (188) linux foundation (3) linux para leigos (1) live (4) LPI (8) LTS (1) machine learning (1) meetup (1) mesa redonda (27) microsoft (3) microst (1) muito além do GNU (120) não viva de boatos (9) navegadores (3) NetBSD (3) novatec (17) o meu ambiente de trabalho (3) off-topic (12) open source (79) OpenBSD (3) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (3) partições (6) pentest (6) processadores (25) professor Augusto Manzano (11) Programação (40) propagandas com Linux (8) Red Hat (13) redes (2) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (1) runlevel (2) Secomp (1) segurança digital (14) servidores (1) shell (1) sistema operacional (18) Software livre e de código aberto (148) sorteio (3) Steam (8) Steam no Linux (6) supercomputadores (4) suse (5) systemd (7) terminal (73) toca do tux (1) toybox (15) tutorial (6) Tux (3) unboxing (7) UNIX (15) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (3) wayland (2) whatsapp (1) Windows Subsystem for Linux (1) wine (12) WoT (1) ZFS (9)