Linguagem Go utilizada para rodar Diablo no Dreamcast
O Gerente de engenharia de software da Red Hat, Panagiotis Georgiadis escreveu eu seu perfil no X:
"Eu tornei possível escrever código golang para o Sega Dreamcast. Sim, o console de 1999. Sim, Go de verdade com gorotines e channels. Aqui está uma intro de Diablo rodando no hardware real."
Panagiotis descreve que Golang para Dreamcast fornece as mesmas características (garbage collection, goroutines, channels e as funções do core runtime) mas que substituiu o runtime padrão do Go por um uma implementação mínima (o libgodc) projetada especificamente para o Dreamcast de acordo com as especiações: e sem sistema operacional¹.
Limitações
Panagiotis disponibilizou uma documentação sobre as limitações da biblioteca libgodc que é essencial entender para escrever programas Go para Dreamcast.
Algumas de suas limitações estão relacionadas no total de memória RAM (apenas 16MB de RAM sendo distribuídos para o KOS, seus drivers e malloc; GC; pilhas; seu código. Ele não possui memória virtual, não possui swap, e não possui segunda chance e caso ocorra de ultrapassar esse limite, o jogo crasha), o processador ser single-core SH-4 operando a 200MHz; os tempos de pausa que o garbage collection podem levar cada frame leve 16.6ms ou até causar stutter; pilhas fixas a 64k; sem Parallelismo (M:1); é Cooperative e não preemptive; alguns recursos não implementados ou algumas implementações limitadas. Há mias detalhes sobre limitações que podem ser lidos aqui, mas apesar destas diferenças, podemos escrever código go normal, as rotinas go funcionam, channels, mapas, slices, interfaces funcionam.
O Go runtime para Dreamcast depende do gccgo e do KOS (KallistiOS).
O Go para Dreamcast está disponível sob a clausula 3 BSD porém, algumas partes estão sob outras licenças como o brkout (que é um port Go do jogo original desenvolvido por Jim Ursetto) que está sob GPLv2.
Eu como um apaixonado por Dreamcast fico muito feliz de ver a galera de Linux envolvida com o console.
Muito além do GNU: Os vários sabores de bibliotecas C
Alguns dias atrás me deparei com o link do site osdev.org sobre implementações de biblioteca C; trata-se de um artigo bem interessante mas muito curto. Como eu já fiz vídeos e artigos relacionados ao tema para a minha série Muito além do GNU(lembrem-se que tudo no Linux é uma questão de escolha. Escolha diz mais respeito a liberdade do que uma ideologia ou uma simples licença), eu resolvi então explorar este texto fazendo minhas observações sobre cada uma delas acrescentando mais informação e adicionando outras.
As bibliotecas C mais populares são a glibc, uclibc, musl e dietlibc; mas há um mundo muito mais vasto e amplo do que você pode imaginar e aqui vou eu abordar muitas outras. No total, até o momento eu cataloguei por volta de 18 diferentes implementações de biblioteca C.
Eu não pretendo seguir na mesma ordem que está descrita no artigo e sim na minha própria ordem; basicamente, a ordem que eu conheci ou de forma que eu considero mais coerente de explicar.
De autoria de Roland McGrath e graças aos esforços de vários projetos e empresas que a mantem para que possam utilizá-la no Linux, é uma biblioteca absolutamente completa e possui suporte a quase todas as arquiteturas. Uma observação muito interessante feita no site:
"Ela não é escrita com nada além do Linux em mente, tornando-a um port difícil."
Sim, apesar de a glibc ser uma biblioteca do projeto GNU, tecnicamente a glibc é uma biblioteca do Linux. Isso ocorreu porque no inicio dos anos 90 os desenvolvedores de Linux perceberam que glibc carecia de muitos recursos necessários para Linux e assim eles criaram um fork da versão 1.x que foi nomeada simplesmente libc e que conhecemos como libc4 que foi a ultima com suporte ao padrão a.out, a libc5 (/lib/libc.so.5 a primeira a ter suporte ao padrão ELF no lugar do a.out. Há algumas fontes que afiram que havia código da bibliotecas C do 4.4BSD, mas o link do projeto gnu não está mais disponível) e libc6 (/lib/libc.so.6) e foram o padrão nas distribuições Linux durante um bom tempo. A glibc 2.0 surgiu da libc6 e com o tempo, por uma questão de padronização, as distribuições voltaram a utilizar a glibc. Mais informações da libc5 e libc6 podem ser lidos clicando aqui. Já para saber mais sobre libc4, libc5 e libc6 consulte a manpage (man 7 libc).
Houve também a Eglibc que foi uma variante da glibc fortemente focada em embarcados e com uma série opções e de suporte a arquiteturas que a glibc não possuía (especialmente PowerPC). A Eglibc foi a biblioteca padrão do Debian 5 e possuía suporte de um consorcio. O código da Eglibc foi fundido ao código da glibc na versão 2.20.
No final das contas a GlibC se beneficiou muito do Linux assim como quase todas as ferramentas do projeto GNU. É difícil prever a linha do tempo das ferramentas GNU sem o Linux.
Uma das grandes desvantagens da glibc podemos mencionar é o fato de gerar binários muito grandes. no artigo Analisando 6 diferentes implementações do comando sed eu descrevo uma curiosidade relatada por Rob Landley que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k... Não é a toa que os desenvolvedores de embarcados se declaram inimigos mortais da glibc.
E a outra desvantagem é estar sob a licença GPL que está em decadência desde 2007por ser uma licença muito restritiva (até hoje não entendo o conceito de liberdade em algo tão restritivo. Algo totalmente incoerente).A criação da GPLv3 foi uma corda no pescoço da licença e já houveram planos no passado para migra a glibc para a terceira versão. Ainda bem que isso não ocorreu pois geraria um grande colapso nos projetos.
uClibc (pronuncia-se yew-see-lib-see) é uma biblioteca para Linux em embarcados no projeto µClinux. Bem menor do que a glibc porém com suporte a quase todas as suas aplicações e quase todas as arquiteturas (alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC e v850).
Foi escrita do zero por Erik Andersen, ex mantenedor do Busybox (que passou a bola para Rob Landley, autor do terminal de comandos toybox), iniciando em 1999 tendo apenas algumas partes de código derivados da glibc como pthreads (threads do Linux, o mesmo recurso que querem fazer uso dentro do sistema operacional RTOS X5) e o suporte a números randomicos.
O uClibc foi descontinuada por volta de 2012 e criaram um fork chamado uClibc-ng. Aé aonde se sabe, existem poucos mantenedores da uClibc-ng, ou talvez somente um, sob o argumento que é a única que possui suporte a algumas plataformas de hardware antigos.
Musl já apareceu várias vezes tanto aqui no blog quanto no canal. É construída sobre a API do Linux e a API POSIX e tem como princípios a simplicidade, eficiência de recursos, atenção em correções, segurança sob exaustão de recurso, fácil deploy e suporte de primeira classe para textos UTF-8/multilingual. A musl permite gerar binários menores (mesmo linkados estaticamente) e rápidos. Rich Felker criou o conceito Quality Safe Code; o que leva a biblioteca a ser correta no quesito conformidade e segurança.
Com o fim da uClibc e depois de ter péssima experiência com programas linkados a outras bibliotecas (seja de forma dinâmica ou estática) que apresentaram falhas, Rich Felker desenvolveu a musl como uma alternativa a glibc e a Uclibc para oferecer melhor experiência no uso de aplicações linkadas estaticamente (tanto no conceito de segurança quanto eficiência) em embarcados, servidores de desktops.
Inicialmente esteve sob a licença GPL porém, depois de conversa com Rob Landley (autor do toybox) passou a disponibilizar a musl sob a licença MIT. Hoje a musl é utilizada como padrão nas distribuições Alpine Linux que é inclusive utilizada nas imagens Docker; Adelie Linux que é baseada no Gentoo Linux e eu pretendo fazer um vídeo de Os vários Sabores de Linux; Void Linux que foi criada para implementar os gerenciador de pacotes xbps (haja coragem); Alpaquita Linux criada pela empresa Bell soft para a execução de aplicações Java; Glaucus Linux que, diferente da distribuição Alpine Linux, faz uso do toybox como userspace ao invés do busybox (tive a honra de receber seu autor no meu canal) e há planos para a sua adoção no Debian e no Android.
Possui em torno de 1200 funções além de todo um conjunto de funções matemática e de printf, porém ainda faltam system calls para serem implementadas. Natanael Copa, autor da distribuição Alpine Linux descreve em sua palestra o que é necessário para substituir a glibc pela musl. Foi a primeira biblioteca a adotar mutexes safe que o pessoal considera incrível, condvars e a primeira a ter working thread cancellation sem race conditions (todos recursos que foram ignorados por outras implementações).
De autoria do alemão Felix von Leitner, foi criada com foco em otimização de tamanho dos binários assim como a musl e cumpre muito bem esse papel. Eu mesmo já fiz analises tanto no canal quanto aqui no blog compilando o embutils, o minised e o init systemrunit e os resultados de sua otimização de binários são surpreendentes. Há um vídeo no meu canal onde relato a sua história e recursos interessantes.
skalibs é um pacote que centraliza bibliotecas C pequenas e seguras utilizadas para a construção de todos programas da skarnet.org. A ideia é não ter que baixar e compilar bibliotecas grandes e se preocupar com problemas de portabilidade. skalibs está sob a licença ISC e pode ser baixada através do comando
Newlib é uma biblioteca fortemente focada em embarcado. Alias, essa é uma das bibliotecas mais amada pelos desenvolvedores de embarcados. É utilizado até mesmo pelos amantes de Dreamcast (e eu não gosto, né). Ela conglomera várias partes de biblioteca sob licenças open-source. e em seu site oficial só é disponibilizada na forma de código fonte.
Possui suporte a mais ou menos 400 funções e requer threading. Nesse embalo surge a Relibc.
relibc é uma biblioteca C POSIX escrita em Rust. De origem do sistema operacional redoxOS e possui port para Linux. Foi desenvolvida para ser uma alternativa a newlib (por isso coloquei nessa ordem) no RedoxOS e também possuir suporte a system calls do Linux (se system calls Linux tem muito bem) por meio do sc crate.
Bionic é a principal biblioteca do Android; foi construída com porões de bibliotecas do NetBSD, do OpenBSD, porções de bibliotecas de FreeBSD e partes próprias. Está sob a licença BSD para evitar os conflitos que vem ocorrendo com a GPL; existe até uma política do Android de não haver programas sob GPL no user space do Android.
Possui suporte a arquiteturas ARM e depois foi estendida a x86 além de suporte a interfaces do kernel Linux. existem algumas limitações como não possuir suporte a locales (até aonde me lembro, a musl também não possui quando tentei compilar o htop que descobri isso), a libthread_db ou libm e possui sua propria implementação pthreads baseada nos futexes do Linux. Existe um relato do Rob Landley que para poder executar o X11 no Android, seria necessário reescrever várias parte do X11 para ser compatível com a Bionic.
olibc (Another C Library optimized for Embedded Linux) derivada da bionic, o objetivo da olibc é fundir as melhorias feitas por várias empresas de SoC como a Qualcomm, Texas Instruments, Linaro, etc. A olibc pode se beneficiar de recursos do ARMv7 como NEON, Thumb-2, VFPv3/VFPv4 e as ultimas otimizações de recentes versões dos compiladores.
PDCLib (ou The Public Domain C Library) visa fornecer uma implementação completa do padrão C99 (nada mais, nada menos do que definido no ISO/IEC 9899. Nem mesmo outras extensões como POSIX) sob a licença CC0 ("No rights reserved").
Foi desenvolvida originalmente por Martin “Solar” Baute em 2002 e depois de 10 anos, Erin Shepherd assumiu o desenvolvimento até 2018 que implementou muitos recursos significativos (o currículo da Erin é incrível). Em 2018, Martin retornou ao desenvolvimento da PDClib.
Não confunda PDCLIB (The Public Domain C Library visto anteriormente) com a PDPCLIB (Public Domain Project C Library. Um P a mais e pode confundir dois projetos). Essa biblioteca faz parte do projeto PDOS (Public Domain Operating System) que se trata (digamos) de um clone antigo MSDOS. (mas com suporte tanto a 32 bits do Windows e do MSDOS. Há uma de suas distribuições com suporte a API MVS API em AMODE de 24, 31, 32 e 64 bit).
A PDPCLIB é biblioteca do PDOS que visa ser uma biblioteca C que visa junto ao GCCMVS (um port do GCC para mainframes da IBM) produzir binários sem restrições devido a sua licença (domínio público). A PDPCLIB segue os padrões da ISO/IEC 9899:1990 (aka ANSI X3.159-1989 aka C90 aka C89) e funciona não somente no MSDOS, no Win32 e no PDOS/386 mas também no OS/2, MVS (mainframe), CMS, VSE e AmigaOS.
Escrita em C++, mlibc tem como foco ser totalmente portável e na modularidade. mlibc possui uma variedade de recursos POSIX/Linux/ANSI e é capaz de executar vários programas como Weston, GCC, LLVM, Bash, GTK2/3 e muitos outros mas sem perder o foco na portabilidade (assumindo poucas systemcalls do sistema operacional hospedeiro). Está sob a licença MIT.
Como o próprio nome já menciona, é focada em ser escrita totalmente na implementação do padrão C11 (ISO/IEC 9899:2011) e nada mais. Está sob a licença unlicense (public domain), teve seu inicio em 2014 porém seu desenvolvimento anda bem parado. Seu antigo site (http://libc11.org/) está fora do ar, mas existem alguns repositórios git que podem ser encontrados.
Na computação, klibc é um subconjunto minimalista da biblioteca C padrão desenvolvida por H. Peter Anvin. Ele foi desenvolvido principalmente para ser usado durante o processo de inicialização do Linux e faz parte do espaço inicial do usuário, ou seja, componentes usados durante a inicialização do kernel, mas que não são executados no modo kernel.
Essa é uma biblioteca do kernel Linux. Foi adicionada ao kernel 5.0 no commit 66b6f755ad45como umabiblioteca mínima que fornece emulação de baixo nível quando o Linux for inicializado somente para executar um único e minúsculo programa.
Foi criado por Paul McKenney ao trabalhar para reduzir o tamanho do initrd (que é de 40MB) e do initramfs (que é 10MB) gerados pelo comando mkinitramfs e pelo dracut onde a maioria das coisas eram inúteis. Assim, eliminando o que não era necessário para o dash (e a maioria eram coisas relacionadas a biblioteca), Paul conseguiu reduzir para ~2MB.
Neatlibc foi desenvolvida pelo iraniano Ali Gholami Rudi para focar principalmente em bootstrapping de seu compilador neatcc. a neatlibc possui suporte as arquiteturas x86, x86_64, ARM de 32 bits; há muitas funções que não são implementadas na neatlibc mas a maioria dos programas desenvolvidos por Ali (http://litcave.rudi.ir/) podem ser compilados com o neatcc e linkados a neatlibc.
Escrita do zero para o sistema operacional Sortix OS, foi implementada grandes partes do padrão POSIX que permite ter suporte a ~70 partes de software de terceiros.
Libslack é uma pequena biblioteca de utilidades gerais que foi projetada com uma coleção de módulos e várias funcionalidades para torar a programação no UNIX/C um pouco mais fácil. A principio foi implementada para ser parte do programa daemon embora alguns códigos datam de antes do do daemon. A libslack possui vários recursos que podem ser conferidos clicando aqui. Está sob a licença GPLv3 e disponível para Linux, Solaris/OpenSolaris,OpenBSD, FreeBSD, NetBSD, MacOSX/macOS, kFreeBSD e GNU/Hurd.
MyOS libc
E por ultimo temos a myOS libc que resumidamente seria você mesmo desenvolver sua própria biblioteca C. A ideia é servir como uma das soluções mais óbvias implementando os recursos personalizados que precisa a seu kernel e ao resto do sistema operacional sem camadas de portabilidade. Outra parte interessante seria a melhor integração com funcionalidades do seu hardware.
O artigo não inclui o link para o desenvolvimento da biblioteca, então eu resolvi adicionar por conta própria.
Eu já escrevi uma série chamada "Dando uma olhada na arquitetura dos processadores" onde debato como o processador é constituído internamente (andei até mesmo dando uma atualizada tratando da arquitetura de Havard mostrando em que se difere da arquitetura de Von Neumann e pretendo adicionar mais coisas. Mas vamos deixar isso para o futuro Deus permitindo que eu faça).
O que é arquitetura de processador?
De acordo com o Dicionario de Termos da computação e da Internet (Dictionary of Computer and Internet Terms) arquitetura de processador é um conjunto de instruções que decodificam e executam operações aritméticas e lógicas. Esse conjunto de instruções são denominados ISA (Instruction Set Architecture) e, nas minhas palavras, arquitetura dos processadores é a forma como essas instruções são organizadas. Apesar de popularmente acabarmos tendo contato com apenas com X86, existe uma boa variedade de arquiteturas como CISC, RISC, EPIC e ZISC e Linux é uma fonte abundante para adquirir conhecimento sobre elas.
Dentro das arquiteturas existe uma gama de fabricantes diferentes. Então agora vamos estudar um pouco sobre as arquiteturas, suas variedades e aonde geralmente são aplicadas.
CISC
CISC (Complex Instruction Set Computers) é uma arquitetura construída com muitas instruções de linguagens de máquina diferentes. Tem como objetivo em seu design completar uma tarefa em poucas linhas de código assembly fazendo com que o compilador tenha pouco trabalho para traduzir o código de alto nível. O problema disso é que as suas tarefas acabam exigindo múltiplos ciclos, fazendo com que leve pelo menos duas vezes mais tempo para executá-las.
Ressalva, não confunda CISC com CICS. CICS (Costumer Information Control System) é uma extensão da IBM utilizada no IBM System Z que tem como objetivo tornar fácil escrever programas e permitir usuários entrar, recuperar e atualizar dados através do seu terminal (fortemente utilizado em sistemas de pontos de venda, reservas de hotel e sistemas de cobrança).
Popularmente conhecemos a arquitetura CISC devido aos x86 da Intel, da AMD e da Via (após ter adquirido a antiga Cyrix); mas há outras empresas que também já fabricaram processadores CISC difrentes de x86 como o VAX, o IBM System/370 e o s390 e houve também o Motorola 6800 (também conhecido como m68k ou simplesmente 68k) na década de 80 que foi o primeiro processador de 32 bits amplamente utilizado e foi o processador do vídeo game Mega Drive, do Macintosh (pois é, a migração de PowerPC para Intel e depois de Intel para ARM não são as únicas experiências que a Apple já teve em sua história), dos computadores da HP e da Sun Microsystem. Falando em Sun Microsystem, foi devido o Motorola 6800 que os desenvolvedores de SunOS tornaram o GCC funcional para uso em produção (o que até então, era simplesmente um compilador inviável).
Parece estranho afirmar, mas deve ser dito. Foi o x86 que tornou os PCs interessantes (especificamente o 386 a partir de 1986); mas historicamente o x86 parou de fazer sentido para o mercado há algum tempo. Basta repararmos como exemplo Apple em 2018 que vendeu 217.7 milhões de Iphones e 18.2 milhões de Macs (mais de 10 vezes mais dispositivos ARM, o que a chamou a sua atenção para abandonar o x86).
Abreviação de Reduced Instruction Set Computer (Computador com conjunto de instruções reduzidas) é a arquitetura que realiza processos de forma simplificada e que foi projetada para desempenho. Devido haver poucas instruções a serem escolhidas, ela leva menos tempo para identificá-las tornando os resultados mais eficientes e executando os processos mais rapidamente e alocando somente as instruções necessárias por clock. Foi criada inicialmente na IBM por John Cocke e sua equipe de pesquisadores em 1.974 como controlador de central telefônica (a telefonia sempre tendo importância na computação). Essa arquitetura levou à uma corrida do ouro dos processadores para concorrer contra o CISCI da Intel.
John Cocke e o primeiro protótipo de computador RISC que o garantiu os premios Turing Award em 1987, the US National Medal of Technology em 1991 e o the US National Medal of Science em 1994.
A arquitetura RISC é tão interessante que há um ditado que diz que "O mundo é RISC". E não é de se duvidar já que a arquitetura é utilizada desde Supercomputadores como é o caso do Fugaku da Fujistu a micro controladores como o H8/300 da Hitachi.
Alguns exemplos de processadores RISC são o Dec Alpha (primeiro processador de 64 bits e primeira arquitetura que Linux foi portado em Novembro de 1994); ARM que é muito famoso em dispositivos móveis devido a seu baixo consumo de energia conservando a bateria por mais tempo (diferente do sparc que, apesar de também ser RISC, consome muita energia e não é tão eficiente no uso de memória); Spark da Sun Microsystem (divisão da Oracle) criado para substituir o m68k; o PowerPC que foi desenvolvido pela IBM, Motorola e Apple quando Steve Jobs saiu da Apple e fundou a NeXT e a Pixar no "Project Pink" para competir com a Intel e foi especialmente projetado para emular programas outros tipos de CPU eficientemente. Foi utilizado também no PlayStation 3, no Xbox 360 e consoles da Nintendo como Game Cube, Nintendo Wii e Nintendo Wii U e pelo sistema operacional OS/2); o MIPS, o Cris (utilizado em dispositivos de rede) e até mesmo a série de chips Super FX da empresa britânica Argonaut Games (adquirida pela Synopsy) que foi utilizado em jogos do Super Nintendo como o StarFox e Yoshi's Island possibilitando a renderização de centenas de polígonos 3D simultaneamente e desenhando efeitos em 2D.
Em Mario World 2: Yoshi's Island foi utilizado o chip Super FX 2 que é um Risc customizado e que possibilitou ao jogo ter elementos 3D e 2D (sim, o jogo é 2.5D), polígonos, cores vivas e amplas, efeitos de iluminação, semitransparência e camadas para que objetos possam passar uns pelos outros.
No Japão surgiu o SuperH após a Motorola processar a Hitachi por questões de licenças do m68k. Então, os engenheiros da Hitachi desenvolveram sua própria arquitetura como substituta. Esse processador foi utilizado nos consoles Sega 32x, Sega Saturn, Dreamcast e fliperamas além de também ser utilizado na indústria automotiva no Japão como robôs que montam carros. Durante a crise asiática, as patentes do SuperH foram transferidas para a empresa Renesas. Há um conjunto de instruções do SuperH chamado Thumb que é utilizado até hoje nos smartphones baseados em ARM. Durante um tempo a ARM pagava à Renesas pelo direito de uso desse conjunto de instruções e como a Renesas não renovou suas patentes, eles passaram a ser utilizados gratuitamente.
RISC VS CISC
Ambos possuem vantagens e desvantagens e ambos conseguem executar os mesmos tipos de programa; o que vai diferenciar é como é o código de máquina do programa. A principio da leitura deste artigo, o RISC aparenta ser superior ao CISC, mas nem tudo são as mil maravilha.
RISC tende a ser mais rápido que CISC SE o acesso a memória for muito rápido; do contrário (se o acesso a memória for relativamente lento) o CISC tende a ser mais rápido que RISC. Além do mais, máquinas RISC tendem a buscar mais instruções da memória para realizar o mesmo trabalho que CISC (ou seja, utiliza-se mais RAM que CISC).
RISC híbrido
RISCs puros utilizam uma instrução por ciclo de clock. Foi aí que eu conheci a geração de RISCs hibridos que utilizam correção nas instruções de comprimento de 16 bits com registradores e endereço de espaço de 32 bits. Isso torna mais fácil para os compiladores gerarem melhores códigos RISC e retomam grande parte da densidade de código dos projetos CISC. Mais informações sobre chips híbridos podem ser conferidos clicando nesses dois links da Renesas e da Design & Recue.
A maioria dos fabricantes hoje tentam combinar as vantagens de cada arquitetura dentro dos seus processadores. A Intel por exemplo, introduziu através do Pentium a possibilidade de seu processador traduzir internamente instruções CISC em RISC (podendo executar duas instruções por ciclo assim como o RISC) e o J64 que planejam uma aproximação do x86-64 ao j4 com compatibilidade a 32 bits (seu design foi elaborado no ano passado). Portanto, dificilmente temos CISCs puros quanto RISCs puros assim como dificilmente encontramos kernel totalmente monolítico quanto totalmente micro-kernel.
A AMD também tinha um projeto de ARM chamado K12 focado em eficiência energética
Foi uma arquitetura RISC desenvolvida pela HP tendo uma ideia de arquitetura mais precisa (daí o PA do seu nome que é a silga de Precision Architecture) porém esse processador foi substituído pela arquitetura EPIC.
Abreviação de Explicitly Parallel Instruction Computing (Computação com instrução explicitamente paralela), foi criada em parceria entre a HP e a Intel para a criação da família Itanium (também conhecida como IA-64) para substituir o PA-RISC. Itanium foi desenvolvido como uma arquitetura de alto desempenho extremamente paralela realizando tal tarefa ao passar as instruções para o compilador que reorganiza o código para o máximo de paralelismo possível enquanto que o hardware foca em executar as instruções. E aqui mora o grande problema, nos compiladores que foi mais critico implementar do que a Intel esperava; o que resultou em um hardware muito caro e com baixa quantidade de software disponível para a arquitetura.
ZISC
ZISC (Zero instruction set computer) é uma arquitetura que se baseia nos princípios de correspondência de padrões e ausência de microinstruções. De acordo com documento de patentes do Google sobre circuito neural (ou neurochip ou redes neurais), essa é a arquitetura talvez mais apropriada para as tecnologias neurais devido a forma como trabalha.
DSP
DSP trata-se na verdade de um processador de sinal de digital (daí o seu nome Digital Signal Processor) que é utilizado para processar áudio (até redução de ruído) e vídeo e é fortemente utilizado em mesas de som e instrumentos musicais. Mas também foi utilizado em cartuchos do Super Nintendo para processar jogos como Super Mario Kart.
Talvez você deva estar pensando por que estou falando deste tipo de chip como uma arquitetura. Bom, a minha ideia era falar sobre DSP no mesmo artigo "Dando uma olhada na arquitetura de processadores" porque, assim como FPU que era chip separado e hoje é incorporado aos processadores, o mesmo pode ocorrer com os DSPs podendo o seu processador possuir instruções DSP adicionadas a ele. De acordo com informações do J-Core (que é um processador que eu acompanho bastante o seu desenvolvimento) as instruções DSP podem quebrar a pipeline do estilo do RISC e eles possuem um novo design de DSP em desenvolvimento.
alguns exemplos de DSP que o Linux possui suporte são o Hexagone o C6xda Texas Instrument.
Bom, finalizo este artigo por aqui acreditando já estar bom por enquanto dado uma boa base de estudo para todo mundo. Pode ser que eu venha atualizá-lo no futuro assim como faço com os demais artigos.
Conheça o Pi-Hole e recupere o controle sobre sua rede
O Raspberry Pi e outros pequenos computadores dominaram o mundo dos hobbystas
em tecnologia, robótica e projetos caseiros. Pequenos, relativamente baratos, e com alta performance energética, os dispositivos conseguem rodar versões completas do Linux e interagir com diversos periféricos e hardware adicional, ou seja, essencialmente, não há limites nas interações e automatizações que o Raspberry Pi pode fazer.
Muitos usuários comuns, que ainda não estão familiarizados com o Linux, já embarcaram no mundo do Raspberry Pi para criar centrais multimídia usando software como o Kodi, criar sistemas de segurança IoT, adicionar uma central de emuladores retro para jogar na TV, e muito mais, graças à abundância de tutoriais e recursos para ajudar no caminho.
A mais nova utilidade dos pequenos computadores é possibilitar o controle total em sua rede. Imagine todos os sites fraudulentos, anúncios inconvenientes, e tudo o que considerar indesejado, automaticamente bloqueado em todos os dispositivos de sua rede, sem latência perceptível e sem o gasto de CPU que uma extensão de navegador adicionaria. Ficou interessado? Então aprenda a configurar o Pi-Hole!
Vale notar, antes de tudo, que o Pi-Hole funciona como uma versão “melhorada” e personalizável de um servidor de DNS, ou seja, pode bloquear diversos domínios e otimizar o trajeto da conexão, mas ele não é capaz de criptografar os dados em trânsito, então para quem precisa de uma camada extra de segurança ou privacidade, é preciso configurar uma VPN antes de investir em um Raspberry Pi.
O que é DNS
Para entender o funcionamento do Pi-Hole que será instalado na distro Linux de seu Raspberry Pi, precisamos compreender o papel do DNS em nossa rede:
Quando acessamos um site ou servidor, estamos nos conectando através de uma série de protocolos de rede até um endereço IP externo, por exemplo, “172.217.29.46”. Acontece que lembrar uma sequência de números para cada site seria pouco amigável para os usuários e confuso, assim, usamos um endereço como “www.google.com”.
Dessa forma, nossos dispositivos precisam traduzir o endereço amigável em um endereço IP utilizável. O DNS é o serviço responsável por essa transição, mantendo uma lista atualizada de endereços e IPs de destino, fornecendo aos dispositivos sempre que necessário. Geralmente, nosso roteador usa o DNS da Google ou, mais frequentemente, o DNS da própria operadora.
Agora que entendemos como funciona o DNS, podemos entender o Pi-Hole. O software roda em segundo plano em qualquer sistema Linux, mas é otimizado para o baixo consumo de energia do Raspberry Pi. Uma vez instalado, o programa se torna o DNS para toda a sua rede, ou seja, seus computadores, celulares, consoles, TVs, e qualquer aparelho conectado, irão perguntar ao Pi-Hole quando tentarem se conectar a algum site.
Essa interceptação do DNS permite que o Pi-Hole bloqueie certos endereços, por exemplo, um servidor de coleta de dados para anúncios ou uma URL de um site de golpes. Como isso é feito a nível de DNS, os dados sequer chegam ao computador, assim, não é necessário bloquear elementos ou usar JavaScript para controlar a página, como uma extensão faria.
Da mesma forma, por mediar toda a rede, qualquer dispositivo conectado estará protegido pelo controle, sem a necessidade de manualmente instalar uma solução em cada aparelho. Além disso, o Pi-Hole terá efeito em dispositivos onde normalmente não encontramos programas para bloquear anúncios ou phishing, como é o caso de consoles de videogame.
Como instalar o Pi-Hole no Raspberry Pi
As instruções de instalação servem para qualquer distro Linux, e são fáceis para quem já usou o sistema. Para instalar o Pi-Hole, abra uma janela do Terminal e insira os comandos:
Pronto, o Pi-Hole em sua versão mais recente estará instalado e rodando em segundo plano. Se tudo deu certo, os dispositivos de sua rede já usarão o DNS falso assim que forem reiniciados, mas caso não tenha efeito, basta verificar o IP local de seu Raspberry Pi e usar como valor DNS nas configurações de redes de todos os dispositivos.
O Pi-Hole possui uma série de configurações opcionais, como listas de domínios para permitir ou bloquear, opções para controlar JavaScript, entre outras. Abrir o arquivo “/etc/dnsmasq.d/01-pihole.conf” com um editor de texto permite alterar muitas das configurações do seu Pi-Hole.
Agora, sua rede já está pronta para bloquear domínios indesejados usando o Raspberry Pi, e o melhor, o Pi-Hole não é pesado e permite que outros recursos do Linux sejam usados simultaneamente. Assim, seu emulador na televisão ou central de mídia podem continuar em execução. Gostou? Então confira o emulador ReDream para Raspberry Pi e jogue os clássicos do Dreamcast.
