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

Patch que melhorará o desempenho da newlib foi aceito

https://bit.ly/2IyVL8N
Newlib
 Dias atras postei que, se a Sourceware aceitasse um patch enviado por Wilco Dijkstraric da empresa arm.com, a newlib teria seu desempenho melhorado com base no algorítimo Horspool.
Artigo sobre novo patch para a melhoria de desempenho da newlib
 Pois é, depois de revisado e realizadas as devidas correções no patch, o patch foi aceito por Eric Blake (principal engenheiro de software da newlib na Red hat) e incorporado a newlib. Agora é só aguardar o lançamento da versão oficial para usufruir dessas melhorias :)


 Até lá, é possível baixar a nova versão para conferir antecipadamente antes do lançamento oficial clicando no link abaixo:
Baixe a newlib
newlib poderá receber novo patch que melhorará seu desempenho

Se a newlib é tão boa para embarcados, por que não foi adotada pelo Android?

Conheça o Android 9 Pie
Android 9 Pie
 Escrevi ontem a noticia sobre um novo patch para a newlib que irá melhorar seu desempenho significativamente. A newlib foi adquirida pela Red Hat quando esta comprou a cygnus solution. Se buscarmos informações em vários sites, veremos como a newlib é bem mencionada por vários profissionais da área de embarcados.

 Daí, surge a questão:
 "Se newlib é a biblioteca mais indicada por muitos profissionais para embarcados, por que então criaram a Bionic para o Android?"
 A questão é um pouco mais complicada, e para isso temos que entender como a comunidade do Android é regida. A primeira coisa que temos que entender é que há uma política no Android de não haver aplicações sob GPL em seu user space e se houver, você não poderá utilizar o nome Android em seu sistema, vindo a ter que remover o nome Android de todo o sistema operacional que está fornecendo.

 Nesse caso, como quem rege o user space é a biblioteca C e a Bionic está sob clausula 2 da BSD (coisa que a Bionic herdou do freeBSD e do NetBSD uma vez que a Bionic é derivada de porções de bibliotecas dos dois sistemas), acho que fica claro o motivo se cruzarmos os fatos. A ideia por trás disso é evitar problemas futuros com o uso de GPL nas aplicações do Android; problemas que já ocorreram com outros projetos e empresas. Por conta desta politica, a maior parte de suas aplicações em user space estão sob licença Apache e algumas partes sob outras licenças como o próprio kernel que está sob GPL (lembrando, não há problema quanto ao kernel pois ele não atua no user space e sim no kernel space), seu terminal padrão que desde a versão 7 do sistema é o toybox está sob 0BSD e vale mencionar até o microkernel Fuschia roda no processo de boot do Android.

 Há um misto de tecnologias que são utilizadas no desenvolvimento do Android e expliquei neste vídeo aqui:


 E o que isso tudo tem a ver com a newlib? A newlib é uma biblioteca que possui um misto de licenças, sendo uma delas a GPL e com isso, acaba dificultando a adoção da newlib no Android. O que poderia ser feito nesse caso é utilizar as partes que não estejam sob GPL para a criação de algo novo ou até mesmo serem incorporadas a bionic.

 Honestamente eu espero verdade é que a bionic venha a ser substituída pela musl. Agora, se você trabalha em um projeto baseado no Android (uma distribuição baseada no Android) e não se importa quando ao uso do nome, aí tanto faz qual biblioteca e sob qual licença que vai rodar no user space, você só não poderá usar o nome Android. Podem haver outras implicações, mas essa é a maior.

Novo patch para a newlib corrige build para M class semihosting

newlibe
newlibe
 Newlib é a biblioteca C mais indicada por várias empresas e projetos para o uso de embarcados. essa bibliteca já apareceu na série Muito além do GNU e em um vídeo sobre um sistema operacional usado como emulador do Dreamcast.


 Tamar Christina da empresa ARM descobriu acidentalmente que os núcleos M class não possuem suporte a v2 mixed mode, o que causa um erro de assembler. Com isso,  Tammar enviou um patch que corrige o problema do patch anterior (não o patch mencionado aqui anteriormente) em multi-lib em qualquer M class build que utilizam instruções semihosting.


 O patch enviado por Tamar foi aceito por Corina e já está disponível na newlib.

Otimização do memcmp na newlib para arquitetura AArch64

newlib
newlib
Otimização, desempenho e ser enxuta não é o forte da gllibc. Geralmente, desenvolvedores de embarcados tendem a ser inimigos mortais da glibc (não fazem ideia de onde ela é otimizada). Wilco Dijkstra da equipe de processadores arm fez uma reescrita completa utilizando algoritimo diferente do memcmp na biblioteca newlib para o AArch64.

Essa otimização melhora o desempenho  de casos alinhados (mutualmente) até 25% e não alinhados até >500% (sim >6 vezes mais rápido) em grande inputs.

Esse código está sob licença parecida com a BSD (já que as empresas e projetos estão saindo fora da GPL por questões de burocracia que a licença vem causando e que pode ser conferido no vídeo "Muito além do GNU - toybox):



A licença pode se conferida logo abaixo:

-   Copyright (c) 2013, Linaro Limited
-   Copyright (c) 2017, Samsung Austin R&D Center
-   All rights reserved.
-
-   Redistribution and use in source and binary forms, with or without
-   modification, are permitted provided that the following conditions are met:
-       * Redistributions of source code must retain the above copyright
-         notice, this list of conditions and the following disclaimer.
-       * Redistributions in binary form must reproduce the above copyright
-         notice, this list of conditions and the following disclaimer in the
-         documentation and/or other materials provided with the distribution.
-       * Neither the name of the Linaro nor the
-         names of its contributors may be used to endorse or promote products
-         derived from this software without specific prior written permission.
-
-   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-   HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */
+/*
+ * Copyright (c) 2017 ARM Ltd
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the company may not be used to endorse or promote
+ *    products derived from this software without specific prior written
+ *    permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY ARM LTD ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL ARM LTD BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+ * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Newlibe poderá receber novo patch que trará melhoria em seu desempenho

Newlibe e Red Hat
Newlibe e Red Hat
Wilco Dijkstra da arm.com enviou um patch para a sourceware que se aceito, irá melhorar significativamente o desempenho do memmem que é uma extensão que localiza a primeira ocorrência apontada na memória e que pode ser muito mais rápida que o strstr. Esse patch fornece um novo algorítimo Horpool modificado. Newlib é uma biblioteca C para uso em sistemas embarcados tendo um conglomerado de várias partes e sendo distribuído apenas em forma de código fonte. Essa biblioteca já fez parte da série Muito além do GNU e no vídeo do DreamShell que é um sistema operacional baseado em Unix (não sabem afirma qual mas descobrir que é um port do sistema operacional KallistiOS) que a galera da comunidade Sega gosta de utilizar para emular o Dreamcast:


 O ganho de desempenho oscila entre 6.6 vezes em texto americano no AArch64 e o tamanho foi otimizado sendo reescrito do zero e obtendo um ganho de 2.7 vezes (sim, o tamanho do código influencia no ganho ou perda de desempenho).

 Este patch está sob a licença Cláusula 3 BSD SPDX e está sendo analisado para a aprovação. Se for aceito, a newlib ganhará bem mais em desempenho do que o mencionado, os desenvolvedores de embarcados agradecem e a comunidade Sega também. vamos torcer para que seja aprovado.


A verdadeira face de Richard Stallman

A verdadeira face de Richard Stallman

    Em 2019 Stallman renunciou de seu cargo no MIT e na FSF após manifestar suas opiniões defendendo Jeffrey Epstein que respondia judicialmente por abuso e trafico sexual e pedofilia. Dias depois renunciou também de seu cargo no projeto GNU. Esse ano foi anunciado o seu retorno à FSF, o que ocasionou frustração em muitos  e até mesmo ao imediato corte de financiamento feito pela Red Hat.

    Suas opiniões sempre foram polêmicas (religião, política e questões sexuais). Em 2006 por exemplo Richard Stallman afirmou em seu site pessoal ser 'cético quanto à afirmação de que a pedofilia voluntária causa danos às crianças'. Em 2011 Stallman falou da morte de Steve Jobs em um tom como uma vitória "ficando livre de sua influencia maligna" (foi a partir daí que tomei antipatia dele). E mesmo com todas as suas declarações absurdas, seus assíduos seguidores o defendem como se fosse absoluto. Mas afinal de contas, quem é Richard quando se trata de tecnologia?

    Bom, então vamos ao assunto. Conhecemos Richard Stallman como o criador do GCC, do EMACS, da licença GPL, e de "todo" o projeto GNU que por sua vez fornece todas as ferramentas que utilizamos nas distribuições Linux; o que nada disso é realmente e totalmente verdade. A começar pelo GCC, o que Richard Stallman realmente desenvolveu foi uma extensão para o Amsterdam Compiler Kit (também conhecido como Free University Compiler Kit que é a toolchain que foi desenvolvido por Andrew S. Tanenbaum para o Minix). Stallman pediu autorização a Tanenbaum para utilizar o Amsterdam para a partir do Compiler Kit criar o GCC. Seu pedido foi negado e a partir daí outras pessoas o ajudaram a estender essa extensão a um compilador.

    O que me questiono é: Será que Stallman teria dado créditos ao Minix? Duvido. Basta observar o micro-kernel do projeto GNU, o HURD. Seu nome na verdade é GNU Mach e não HURD. HURD é o nome do conjunto de daemons desse kernel. Este micro-kernel não foi desenvolvido pelo projeto GNU e sim pela universidade de Carnegie Mellon e se trata do mesmo kernel utilizado pela Apple no MacOS, o Mach kernel (pois é... brigam tanto pelo reconhecimento do nome GNU mas quando se trata de dar reconhecimento ao Mach, divulgam o nome do conjunto de daemons...)

    Por que o nome de Guy Steele e Dave Moon não são citados quando se fala de EMCAS já que esses (entre outras pessoas) são os verdadeiros autores? Porque Eben MoglenBrett Smith não são citados quando se fala de GPL? Eben Moglen é o co-autor da GPL e Brett Smith quem fazia a sua execução na FSF (alias, esses são as mentes brilhantes da GPL. Já as quatro liberdades é um termo antigo criado pelo presidente Franklin Delano Roosevelt em 1941 e há até um memorial em seu nome com essas liberdades). Alguém se lembra que Roland McGrath é autor da Glibc? E Brian Fox? Alguém sabe o que ele fez?

Link para esta imagem está disponível clicando aqui

    Já no GCC aconteceu a mesma coisa. No final da década de 90 a administração do desenvolvimento do GCC era frustante e por consequência a FSF já tinha se tornado quase esquecida. Isso levou a Cygnus Solutions (ou Cygnus Support) a criar o EGCS; um fork do GCC que se tornou um sucesso e até substituir a versão oficial do GCC. A Cygnus Solutions criou também a newlib e o binutil; Trata-se do mesmo compilador que menciono da série "Os vários sabores de Linux" que foi usado para compilar o Gentoo devido a bugs no GCC (o EGCS melhorou o desempenho do Gentoo em 10% em todo o sistema) . Depois a Cygnus foi adquirida pela Red Hat e... aqui entra o ponto de ação do projeto GNU. A FSF negociou com a Cygnus para que o nome do EGCS fosse substituído pelo GCC no próximo (a versão 2.95). Pois é, o que você conhece hoje como GCC na verdade é o EGCS. O GCC só é um coleção de compiladores poderosos graças aos esforço de muitos como os BSDs, o Solaris, o Linux, a Intel, o Google e muitos outros.

    A Glibc não fica longe da mesma situação. O mantenedor da glibc Ulrich Drepper, depois de descrever todas as características da nova versão, soltou a seguinte nota: 
E agora para algumas coisas não tão boas.

Stallman recentemente tentou o que eu chamaria de um controle hostil do desenvolvimento da glibc. Ele tentou conspirar pelas minhas costas e persuadiu outros principais desenvolvedores a assumir o controle e assim no final ele está no controle e pode ditar o que for que lhe agrade. Essa tentativa falhou mas ele continuou a persuadir as pessoas em todos os lugares e isso ficou realmente feio. No final eu concordei com a criação de um comitê chamado "steering committee" (SC). O SC é diferente do SC em projetos como o gcc em que ele não toma decisões. Nessa frente nada mudou. A unica diferença é que Stallman agora não possui direito de reclamar mais. desde que o SC que ele queria reconheceu status. Espero que agora ele vá ficar calado para sempre.

 A moral disso é que as pessoas vão perceber quão louco por controle e maníaco o Stallman é. Não confiem dele. Assim que algo não estiver na linha com suas visões ele vai te apunhalar pela costas. *NUNCA* coloque voluntariamente um projeto que você trabalha sob a guarda do GNU desde que isso significa nas opiniões do Stallman que ele tem o direito de tomar decisões pelo projeto.

A situação da glibc é ainda mais assustadora se compreender a história por traz dela. Quando eu comecei a portar a glibc 1.09 para Linux (que eventualmente se tornou a glibc 2.0) Stallman me ameaçou e tentou me forçar a contribuir para o trabalho do Hurd. O trabalho no Linux seria contraproducente para o curso do software livre. Então veio o que seria chamado de abraçar e estender se realizado pelo Mal do Noroeste, e sua reivindicação por tudo que leva ao sucesso do Linux.
    O resto pode ser conferido clicando aqui. Esse foi um dos motivos de não haver a migração do Linux para GPLv3 (e graças a Deus por isso) quando Linus decidiu manter o kernel linux somente como GPLv2 e o Debian ter migrado para a EGLIBC do Debian 5 até o 8.


1998

    Falando do final dos anos 90, 1998 foi o ano onde muitas coisas aconteceram. Estávamos a caminho do kernel 2.2; Linux já possuía suporte a arquiteturas alpha, sparc,mips, m68k e arm e a adoção do Linux havia aumentado 212% depois que a Netscape incentivou desenvolvedores a tal adoção devido ao Java e depois que disponibilizou o código fonte do seu navegador (que veio a se tornar o Firefox). Tudo ia muito bem ATÉ QUE..... Richard Stallman tenta proclamar Linux como propriedade da FSF (essa é a ideia por trás do termo GNU/Linux camuflado de pedir créditos).

    Richard Stallman já havia declarado no passado que o Hurd iria substituir o Linux; porém ao invés de focar em engenharia de software, ele ficou focado demais em idealismos, filosofias e politica e com isso o projeto GNU fracassou em produzir um sistema operacional funcional e utilizável (e te enganaram se te disseram que o kernel a unica coisa que o GNU precisa para ser um sistema operacional completo). Então Richard Stallman resolveu mudar sua estratégia (focar nos novos desenvolvedores de Linux).

    Os novos desenvolvedores não conheciam nada da história do Linux; eles não tinham tempo para perder com história (e faziam até bem) e estavam preocupados na verdade em aprender metodologia de desenvolvimento e conhecimento técnico; e foi aí que Stallman viu a sua oportunidade. Já que os novos desenvolvedores não conheciam a história do Linux, ele os contaria a história da FSF e passaria a reivindicar créditos pelo Linux.
É como o espanhol George Santayana afirmou: "Aqueles que não conseguem se lembrar passado estão condenados a repeti-la."
    O que Richard Stallman ignorou completamente foi todo o trabalho feito não somente por Linus (engana-se se acha que as únicas coisas que Linus Torvalds desenvolveu foram o kernel Linux e o Git), mas também de todas as contribuições feitas pela comunidade Minix (que foi a partir da comunidade Minix que constituiu-se a primeira comunidade Linux), pelos desenvolvedores de Berkley, do projeto Athena do MIT (que Stallman fez uso durante muito tempo para compartilhar o projeto GNU na internet), do manual POSIX da Sun Microsystem que foi utilizado para estudar e desenvolver o Linux e de muitos outros (essa lista entraria em um loop quase infinito).

    Rob Landley (criador do toybox) até tentou explicar marketing para Stallman nesse mesmo ano dizendo que o termo GNU/Linux gerava confusão na cabeça das pessoas pois haviam distribuições como Debian Linux, Red Hat Linux, Suse Linux e etc... mas não havia uma distribuição GNU Linux. O que Rob Landley incentivou foi a criação de uma distribuição Linux do projeto GNU porem, ao invés disso, passaram a promover com mais veemência o termo "GNU/Linux" (algo que Rob landley pede desculpa a todos por considerar isso um transtorno).

    Ano conturbado. Não?...


Conclusão

    Eu sei que os seguidores fieis e assíduos do Stallman vão vir aqui me atacar de todas as formas, mas interessante saber que internamente eles mesmos criticam e atacam o Stallman; eles só não gostam que pessoas de fora do circulo deles façam mesmo.



https://landley.net/notes-2010.html#19-07-2010

e2fsprogs - o pacote de ferramentas do ext2/3/4

e2fsprogs - o pacote de ferramentas do ext2/3/4
e2fsprogs - o pacote de ferramentas do ext2/3/4
 Duas coisas me motivaram a escrever este artigo. A primeira foi que esses dias eu estava analisando um comando do toybox comparando-o com outro (e que inclusive irei ensiná-lo em vídeo aulas exclusivas para patronos Toca do Tux). A segunda é que acabei descobrindo que não há nada em português sobre o pacote e2fsprogs (no máximo o que encontrei foi no site do Debian), nem mesmo a wikipedia disponibiliza o assunto em nosso idioma.

 Essa não é a primeira vez que explico vários pacotes que utilizamos nas distribuições Linux. Comecei com o artigo e vídeo  "Quatro pacotes de comandos que usamos diariamente que não são do GNU" que, como o próprio nome sugere, são pacotes com uma série de comandos que utilizamos no dia a dia e que não tem nenhuma relação com o projeto GNU (e que mesmo assim creditamos ao GNU os méritos de todos os projetos). É possível conferir neste mesmo artigo é possível conferir duas tabelas de comandos sendo uma do pacote core utils (esse sim é do GNU e passível de fácil substituição) e o outro do UtilLinux que é do próprio Linux.


 Depois disso escrevi mais um artigo mostrando o pacote Procps que é a fonte de comandos como top e ps. E por ultimo fiz mais um vídeo apresentando mais dois pacotes:


 Dado o motivo porque quero escrever este artigo, bora para o arrebento falar sobre o e2fsprogs (Ext2 Filesystem Utilities) que fornece as ferramentas necessárias para criar, corrigir, configurar e debugar os sistemas de arquivos ext2/3/4. Foi escrito (ao menos grande parte dele) por Ted T'so, criador da primeira distribuição Linux, primeiro desenvolvedor norte americano do Linux e responsável pela parte de sistema de arquivos no kernel.

 Esse pacote fornece comandos como o dumpe2fs para exibir informações sobre blocos e super blocos no sistema de arquivos, o tune2fs para modificar parametros no sistema de arquivos, o filefrag para realizar desfragmentação (pois é, se você se escandalizou com o brtfs possuir ferramenta para desfragmentar, aqui fica a dica. O ext4 possui a sua própria chamada e4defrag que foi desenvolvido por funcionários na empresa Nec),  o debugfs (o próprio nome já diz tudo e que apesar que foi desenvolvido pelo Ted, não tenho real certeza que faz parte do e2fsprogs), o badblocks para procurar por blocos defeituosos, o resize2fs para redefinir o tamanho do sistema de arquivos (também não tenho real certeza, mas pelo fato de ser escrito pelo Ted, acredito que sim) entre outros.

 Alguns comando são considerados como parte do pacte e2fsprogs, mas isso não é verdade. Os comandos blkid e findfs por exemplo fazem parte do pacote UtilLinux.

 Então, não, as ferramentas que utilizamos no Linux não são unicamente do GNU e sim de uma variedade de fontes (inclusive do próprio Linux). E não, Linux não é somente o kernel do sistema operacional (uma vez que o kernel possui carregador de boot, init system, bibliotecas como a muls, dietlibc e newlibterminal de comandos e comandos separados do terminal como viram aqui nos vários artigos, então já não se trata unicamente de um kernel).

 Aos que veemente defendem o termo "GNU/Linux" sob o argumento de que as ferramentas que utilizamos são do GNU,  Eu duvido que consigam somente com ferramentas GNU criar partições, formatá-las (e não estou falando do Gparted, pois o Gparted é apenas um frontend para os pacotes que mencionei. Link da FAQ do projeto para mais informações), montá-las, reparar o sistema de arquivos quando corromper, configurar a rede, gerenciar processos e carregar drivers modulares  (e fica aí até um desafio ;)
Ferramenta utilizadas pelo Gpaterd e que podem ser conferidas no README do seu GiLab




CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
MAS TAMBÉM NÃO DEIXE DE CONFERIR O MEU CURSO DE MIGRAÇÃO PARA LINUX E TORNE-SE UM VERDADEIRO PROFISSIONAL.

3 SISTEMAS OPERACIONAIS QUE NÃO SÃO ESCRITOS NA LINGUAGEM C

3 SISTEMAS OPERACIONAIS QUE NÃO SÃO ESCRITOS NA LINGUAGEM C
3 SISTEMAS OPERACIONAIS QUE NÃO SÃO ESCRITOS NA LINGUAGEM C

 Esse é mais um artigo que tive inspiração de escrever após o vídeo sobre Solaris e FreeBSD serem superiores a todos os sistemas operacionais... O primeiro artigo foi sobre recursos que somente Linux possui e em mais nenhum outro Unix (e nem a API POSIX). Já esse eu conto três sistemas operacionais que não são escritos em linguagem C. A linguagem C se torna quase padrão quando se trata do desenvolvimento de um sistema operacional, só que aqui mostramos que isso não é necessariamente uma ordem (ou pelo menos, grande parte de OS).

 MenuetOS é um sistema operacional de kernel monolítico pre-emptivo, real-time, multiprocessador e escrito inteiramente na linguagem assembly (vale duas ressalvas; a primeira que seus headers podem ser escritos em qualquer linguagem, a segunda é que o MenuetOS não é um Unix e nem segue a especificação POSIX).

 A ideia e vantagem em se trabalhar com uma linguagem de baixo nível eliminando camadas extras do sistema operacional. O resultado disso é um sistema operacional muito pequeno (uma imagem de apenas 1.4MB), extremamente rápido e evitando certos bugs. Trabalhar com desenvolvimento de baixo nível realmente proporciona melhor desempenho devido estar acesso diretamente ao hardware. O Ninja Build, que já tratei no canal e aqui no blog, é a exata prova disso; foi desenvolvido no Google para substituir o GNU make e acelerar o processo de compilação do port Google-Chrome para Linux. O Mantle da AMD e o Vulkan são outros grandes exemplos práticos de ganho de desempenho por trabalhar em baixo nível.


 O MenuetOS possui suporte a TPC/IP, suporte SMP para 32 CPUs diferentes, multithreading, ring-3 protection, driver gráfico, driver de áudio, biblioteca C, biblioteca de matemática e muito mais.  Conferindo os prints, podemos dizer que é um OS até bonito com bordas semi transparente.





 Não é de hoje que existe sistema operacional escrito em Assembly; o Unics (que depois recebeu o nome de Unix) foi escrito inicialmente em Assembly. Linus Torvalds desenvolveu seu emulador de terminal na linguagem Assembly para poder aprender sobre seu processador.

 O problema e  desvantagem de se escrever um sistema operacional em tal linguagem de baixo nível é que toda vez que utilizá-lo em um computador diferente (mesmo em uma sub arquitetura diferente), será necessário reescreve-lo totalmente do zero. Logo abaixo podemos conferir dois exemplos de "Hello World" em Assembly para dois computadores diferentes (o DEC PDP-8 e o DEC PDP-11).

 Foi aí que Ken Thompson teve a ideia de criar uma linguagem de programação para permitir o reaproveitamento do código entre os computadores diferentes bastando somente compilá-lo. Então Ken se baseou na linguagem BCPL para criar a linguagem B que, com a ajuda de Denis Ritchie, a amadureceram, a aprimoraram e veio a se tornar a linguagem C.

 O sistema operacional está sob licença própria definindo-o somente para uso acadêmico e, se caso quiser utilizar para fins comerciais, deve pedir autorização formal do projeto para isso. Já a versão de 32 bits (que está chegando ao seu fim) está sob GPL (fim da GPL mesmo).

 Há um fork  do MEnuetOS chamado KolibriOS que, honestamente, não entendi a real proposta do projeto.


 Redox é um sistema operacional Unix-like microkernel que não segue as normas POSIX e é escrito na linguagem Rust. Possui os sistemas de arquivos RedoxFS com implementações do TFS (inspirado no ZFS), suporte a compatibilidade de binários Linux, seu proprio XFS, servidor gráfico Orbital e etc...


 Está sob licença MIT como principal, GPLv2 para GNU Unifont, GPLv3 para os ícones Faba e Moka, Open Font License 1.1 para Fira font,  um numero de licenças free software e BSD para a Newlib C library (ou seja, nem tudo do RedoxOS é Rust) e BSD 2-clause para o NASM (e uma parte que não é mencionada em sua docmentação, GPLv2 para a sua parte de isoLinux que é outra parte que não é Rust).

 A ideia por trás do sistema operacional é a inovação tecnológica tendo suas inspirações no Plan9, no Minix, no Linux e nos BSDs. Na verdade suas motivações de coisas que não gosta nesses sistemas operacionais. O time tem como argumento que apesar que o Linux domina o mundo, Linux não é ideal para inovação... Os BSDs lideraram muitas a inovações nas ultimas duas décadas... com coisas como o Jails e o ZFS... Mas como seu kernel também é monolítico, cai no mesmo conceito. O Minix é bem dentro dos mesmos conceitos mas é escrito em C. Se bem que os argumentos apresentados não são tão reais o quanto alegam; confiram no vídeo abaixo que eu debato por que:

 Aqui será aplicado um video que irei gravar para debater o que é verdade ou não sobre o que a comunidade REdoxOS diz em seu Doc:

JX system

 É um sistema operacional microkernel que podemos dizer ser uma prova de conceito, para demonstrar que é possível um sistema operacional completamente em Java mantendo boa qualidade de desempenho. Completamente em partes pois seu microkernel é escrito em C e Assembly (ou Assembler) devido a rotinas de baixo nível que não podem ser fornecidas pela linguagem Java como system initialization após o boot, saving and restoring CPU state, low-level protection-domain management e monitoring.


 Inicialmente o projeto rodava sobre Linux e que depois passaram a portar as ferramentas do Linux para o metaXaOS.

 Em Benchmarks realizados, o JX atingiu entre 40% à100% do desempenho do Linux em file system e em torno de 80% no NFS (fora outros testes realizados).

Benchmarks realizados entre o JX e o Linux.
Benchmarks realizados entre o JX e o Linux.
 Possui licenças mistas como JX Ltd e GPLv2 e bom, se a ideia é ter um sistema operacional que rode Java, o Android já é uma prova disso (só que não por completo) além da Sun Microsystem já ter tido o JavaOS. Moral da história é que não se dá para ter um sistema operacional escrito em uma unica linguagem (nem mesmo os que apresentei são isentos disso). O Linux mesmo é escrito em linguagens diferentes como C, C++, Objective-C, Assembly e outras. O importante mesmo é saber aonde devidamente aplicar cada uma.

Linguagens que o kernel Linux é escrito.
Linguagens que o kernel Linux é escrito.

Open Embedded trabalhando para que systemd tenha suporte a musl

Open Embedded trabalhando para que systemd tenha suporte a musl
Open Embedded trabalhando para que systemd tenha suporte a musl
 Desde antes do lançamento do Debian 8 que eu venho debatendo sobre o systemd, principalmente por terem criado um monte boatos (vergonhosos e mentirosos) para poder criticar o novo init system. De lá para cá eu já fiz videos contando a sua história, debatendo bug encontrado, fiz live debatendo a palestra "A tragédia systemd" feita por um dos desenvolvedores do FreeBSD e fazendo até mesmo parte do meu curso (não deixe de conferí-lo hein ;)

 Há algum tempo atrás eu fiz um vídeo detalhando as criticas tenho a respeito do systemd.  Sim, eu tenho minhas criticas a respeito do systemd assim como tenho a respeito de qualquer outra ferramenta e que não tem nada a ver com os boatos que todos dizem a respeito do init system. Quer saber as minhas criticas? Confere o vídeo aí embaixo:



 Recentemente descobri que a Open Embedded trabalha em um patch para que o systemd passe a ter suporte a musl (clique aqui para conferir) que é algo muito interessante de se ver já que o systemd é também adotado em embarcados. Isso já é um passo e há muito trabalho a ser feito já que a glibc possui incompatibilidade com as várias outras bibliotecas além da musl (dietlibc, uClibc e newlib). Esse é o motivo da musl não ter sido adotada ainda como biblioteca padrão no Debian mesmo havendo planos para isso. Há muito trabalho ainda a ser feito por parte da Open Embedded e dos colaboradores no desenvolvimento da musl, mas o futuro desta biblioteca é muito promissor (principalmente por sua qualidade de código e resultado no tamanho final dos binários).

 Mas ainda espero que o systemd também venha a ter suporte ao LLVM/Clang e longa vida ao systemd.
Mais sobre o systemd
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

















É 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.

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 (30) desenvolvimento (55) desktop (17) DevOps (1) DevSecOps (1) dic (1) Dica de leitura (57) 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 (5) filesystem (60) 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 (99) I.A (1) init system (7) Intel (15) IoT (1) ispconfig (1) jogos (33) kernel (116) lançamento (43) leis (1) LFCS (1) licenças (7) Linus (15) linus torvalds (1) Linux (190) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) meetup (1) mesa redonda (27) microsoft (3) microst (1) muito além do GNU (121) 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 (26) professor Augusto Manzano (11) Programação (40) propagandas com Linux (8) Red Hat (16) 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 (15) servidores (1) shell (1) sistema operacional (19) Software livre e de código aberto (150) sorteio (3) Steam (8) Steam no Linux (6) supercomputadores (4) suse (6) systemd (7) terminal (74) toca do tux (1) toybox (15) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (3) wayland (2) whatsapp (1) Windows Subsystem for Linux (1) wine (12) WoT (1) ZFS (9)