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

Diferentes arquiteturas de processadores

Diferentes arquiteturas de processadores

Diferentes arquiteturas de processadores

    Desde o ano passado, um dos assuntos que mais vem ganhando repercução é sobre a Apple migrar de X86 da Intel para seu próprio ARM chamado Apple Silicon, o Linux passar a ter suporte a esse processador da Apple, a NVidia adquirir a arquitetura ARM e o Risc-V passar a ganhar mais notoriedade depois da ultima menção. Depois de tudo o que mencionei, me senti inspirado a escrever este artigo.

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

Arquitetura de Havard

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 CISCRISCEPIC ZISC e Linux é uma fonte abundante para adquirir conhecimento sobre elas.


Arquiteturas que o kernel Linux 5.10 possui suporte

    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 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 experiencias 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 mais 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. 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)

John-Cocke.
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 a microcontroladores 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; Spark da Sun Microsystem (divisão da Oracle); o PowerPC (que foi desenvolvido pela IBM, Motrola e Apple 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), cores vivas e amplas, efeitos de iluminação, semitransparência e objetos passarem uns pelos outros).

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.
ParthusCeva Announces Architecture Standard for Hybrid DSP/RISC-Based System-on-Chip for ARM Environment
    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 
que era planejado para ser lançado em 2017. O desenvolvimento do K12 inspirou a criação do Opteron A1100 e a engenharia do Ryzen (agradeço ao Anderson Rincon por ter me fornecido a informação sobre o K12 e por ter revisado este texto para mim).



PA-RISC

 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 Hexagon e o C6x da 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.

Dando uma olhada na arquitetura dos processadores #1


Como mencionei no vídeo Corei3 e Corei5 vx FX 6300, relatei ali o básico do que todos nós julgamos ser o processador. E no vídeo sobre as vulnerabilidades dos processadores da Intel mencionei que resolvi debater com vocês como é a arquitetura de um processador. Porque ficamos limitados a clock, cache, threads e coisas assim. Vamos então olhar um pouco mais a fundo nos processadores.

A arquitetura dos processadores que utilizamos hoje recebe o nome de a arquitetura de Von Neumann (OK. tem uma parte de ser Turing completo também, mas deixa isso para uma outra hora). E porque esse nome? devido ter sido criado pelo judeu húngaro John Von Neumann na década de 40; o mesmo cara que participou do projeto Manhatan na criação de bombas atômicas e até previu a que altura a bomba iria explodir. Esse é o pai dos computadores que utilizamos hoje. Vale a ressalva de que Einstein não é o único judeu talentoso na história (alias, nem considero Einstein tão gênio como muitos o fazem).

John Von Neumann
Foto de John Von Neumann retirada da Wikipedia

Dentro da arquitetura de Von Neumann temos a ULA (Unidade lógica e aritmética) Que é um circuito digital (ou seja, uma calculadora). Se torna a parte principal por ser quem processa as instruções, recebe instruções de dispositivos de entrada e envia para os dispositivos de saída.

A arquitetura de Von Neumman
A arquitetura de Von Neumann

E dentro da arquitetura de Von Neumann temos também a UC (Unidade de Controle) que é responsável por armazenar os programas na memória. Bom, e essa é a básica da arquitetura de Von Neumann. A coisa é mais longa, mas é basicamente isso. Mas não dá para limitar toda a arquitetura dos processadores a Von Neumann. Os processadores foram recebendo muitos outros recursos depois disso e que continuaremo no próximo capítulo. Logo abaixo, uma forma mais clara de entender a ULA e a UC:


 Há também a arquitetura de Havard que é utilizada geralmente por microcontroladores. A diferença entre a arquitetura de Von Neumann e a arquitetura de Havard é que, na arquitetura de Von Neumann, tanto os programas quanto os dados são armazenados no mesmo tipo de memória. Já na arquitetura de Havard programas e dados são armazenados em diferentes tipos de memórias (por isso alguns microcontroladores utilizarem a arquitetura de Havard. Nesse caso os programas são gravados em ROM enquanto os dados são armazenados em RAM devido a necessidade de serem alterados).


Primeira placa mãe para Linux baseada na arquitetura RISC-V está preparada para ser lançada

A arquitetura RISCV
A arquitetura RISCV
Como ando falando muito de arquiteturas (que inclusive pouco falada aqui no Brasil), resolvi publicar esta noticia. E depois tem um vacilão que falar que o único processador que Linux se sai melhor do que o Windows é no Ryzen e em mais nenhum outro processador no mercado (leitorzinho de tutorial é do caramba viu).

A primeira vez que ouvi falar da arquitetura RISC-V foi através do sistema operacional HelenOS quando apresentaram essa arquitetura no FOSDEM. Dois sistemas operacionais que não abro mão são Linux e HelenOS por conta do ganho de conhecimento que ambos me proporcionam, espero que o HelenOS ganhe cada vez mais espaço também pois ele conquistou.

RSICV é um conjunto de instruções de arquitetura de processador com princípios do RISC (que é baseado em um conjunto reduzido de instruções), mas evitando erros e anacronismos possuindo um design limpo.

Existe até mesmo uma distribuição Linux para o RISCV. Esta arquitetura está sob licença BSD ao invés de GPL, possui suporte a modularidade e escalabilidade, suporte nativo a 32 e 64 bits (128 bits no futuro) e não será focado somente em educação e pesquisas. Esta arquitetura (que está sendo financiada pela DARPA, Intel, Microsoft e Google, HP, Lattice, Oracle, lowRISC, Indian Institute, Bluespec e muitas outras empresas e projetos) será usada desde embarcados a grandes computadores.

Processador SoC para a placa mãe que rodará Linux
Processador SoC para a placa mãe que rodará Linux

Em Outubro, a SiFive anunciou o primeiro RISC-V SoC controlado por Linux com quatro núcleos sob o nome de U54-MC Coreplex. A SiFive abriu sua pre-venda no FOSDEM abrindo um financiamento coletivo no site Crowd Supply e já conseguiram arrecadar a grana (faltando pouco mais de 25 dias para acabar a campanha). Agora é esperar para ver no futuro a sua aplicação :)

HiFive da SiFive
HiFive da SiFive

Musl receberá suporte a arquitetura RISCV64

Musl receberá suporte a arquitetura RISC-V64
Musl receberá suporte a arquitetura RISC-V64
 musl já possui suporte a pelo menos quinze arquiteturas (sendo uma delas, RiscV) e vem sendo adotada cada vez mais pelas distribuições Linux. Há planos por exemplo de portar o Debian para a musl (no passado Debian já havia sido portado para outra biblioteca que, como se tratava de um fork da GlibC que fundiram os dois projetos, por esse motivo o Debian acabou retornando para a GlibC). Uma distribuição não fica atrelada a um único projeto tenda a liberdade de escolher outras ferramentas e até de se desvincular do que já tem.
curso-linux-da-migração-a-administração-do-sistema-operacional
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
 Mas mesmo tendo suporte à varias arquiteturas, há um trabalho sendo feito para a biblioteca venha a ter suporte a arquitetura RiscV64 vindo de empresas como a Mforney, a cmpwn, a  SiFive e até a Google.

 Nesta versão a equipe removeu por hora o suporte a riscv32 (já que a ABI de 32 bits ainda não está estável) e portaram a distribuição Alpine Linux para riscv64 sem se depararem com problemas. Atualmente a comunidade Adélie Linux também está envolvida em um trabalho portando musl libc para arquitetura SPARC.

 Aqui você pode assistir um vídeo do canal e conhecer um pouco mais sobre a história e características da biblioteca musl:

Dando uma olhada na arquitetura dos processadores #3

MMU de um Motorola
MMU de um Motorola

Estamos na terceira parte da série Dando uma olhada na arquitetura dos processadores. Na primeira parte da série tratamos da arquitetura de Von Neumann, Na segunda parte tratamos de um recurso muito importante que é a Unidade de Ponto Flutuante e o seu contesto histórico.

Agora continuando dentro dos recursos temos também a MMU (Memory Management Unit ou a Unidade de Gerenciamento de Memória) Que traduz endereços virtuais para endereços físicos. Antigamente era um chip aparte e hoje (assim como o FPU) é comum estar incorporado aos processadores. Se pararmos para ler os e-mails do anuncio do lançamento do kernel Linux, uma das perguntas feita a Linus era se o Linux possuía suporte a MMU.

Esquema de como funciona o MMU
Esquema de como funciona o MMU

DSP (Digital Signal Processor ou Processador de Sinal Digital) é utilizado para processar áudio e vídeo e faz a eliminação de ruídos. Essa tecnologia é utilizada em teclados musicais, mesas de som, mas não é necessariamente utilizado nos processadores que utilizamos hoje. Alguns jogos do super Nintendo como o Super Mario Kart utilizaram essa tecnologia.

SIMD (Single Instruction Multiple Data ou Dados Únicos de Múltiplas Instruções) de forma simples de entender é o que realiza operações em paralelo (assim como o j-core). A sigla MMX da Intel que conhecemos, trata-se exatamente desse SIMD.

Por hora eu vou ficando por aqui, espero que tenham gostado e vamos compartilhando conhecimento :)

Não esqueçam de ajudar o canal e o blog a se manter independente se tornando um padrinho ;)

Dando uma olhada na arquitetura dos processadores #2

Unidade de Ponto Flutuante

Beleza cambada? Depois do vídeo "Minha opinião sobre as vulnerabilidades dos processadores da Intel" iniciei a essa série para olharmos um pouco mais a fundo nos processadores e não ficar simplesmente limitados a clock, cache e threads.

No primeiro capítulo falamos sobre a arquitetura de Von Neumann explicando como funciona sendo dividida entre a Unidade Logica e Aritmética e a Unidade de Controle. Porém não dá para limitar toda a arquitetura dos processadores a Von Neumann uma vez que a arquitetura de Von Neumann também possui as suas limitações.

Foi aí que os processadores passaram a receber muitos outros recursos como a FPU (sigla de Floating Point Unit ou Unidade de Ponto Flutuante em português) que realiza operações matemáticas de representação de dados. A FPU é responsável por realizar cálculos mais complexos ou mais simples que a ULA não é capaz de realizar.

Antigamente a FPU era um chip separado da CPU como na foto abaixo, era um co-processador matemático. Então nós comprávamos os computadores e depois tínhamos que comprar o co-processador matemático aparte. Vale a ressalva que os co-processadores eram caros:


Porém, a partir mais ou menos dos 486 as FPUs passaram a ser incorporados aos processadores e hoje dificilmente não se encontra dentro de um processador como na ilustração abaixo:

Contando algumas curiosidades históricas interessantes sobre a FPU:
  1. Linus juntou uma grana para comprar um novo computador. Como a bagaça era muito cara, então Linus resolveu fazer upgrade na máquina que já tinha adicionando um co-processador matemático e mais memoria.
  2. Um dos fatores de sucesso do Linux quando surgiu (além de ser mais leve e mais rápido que os BSDs) foi exatamente porque o BSD exigia o uso de certo de tipo de hardware para rodar; um deles era o FPU (inclusive FPUs eram caros) e Linux o Linux não.
  3. Em 1994, um professor na universidade de Lynchburg encontrou um bug no FPU do processador Pentium. Eu me lembro que foi dito que esse bug acontecia no Pentium, mas não no 486. Mencionei esse bug no vídeo "Minha opinião sobre as vulnerabilidades dos processadores da Intel".
  4. A AMD adquiriu os direitos do X86 da NexGen, empresa fundada por um ex engenheiro da Intel que tinha direitos sobre algumas tecnologias. Essas tecnologias foram incorporadas ao k6 (que inclusive alguns k6 foram considerados mais rápidos que o pentium II).
  5. Eu li que o FPU dos processadores da empresa VIA possuíam melhor processamento do que os da Intel. 
  6. Uma coisa que eu descobri através de um engenheiro de software da Red Hat que utiliza a zsh é que o terminal Bash precisa de algum(ns) programa(s) programa(s) externo(s) como perl para realizar cálculos em ponto flutuante. Enquanto que o terminal ZSH não há essa necessidade:

Comparação de uso de calculos em ponto flutuante nos terminais ZSH e BASH
Comparação de uso de calculos em ponto flutuante nos terminais ZSH e BASH



Uma Arquitetura para Web of Things (WoT)



Por: Dominique Guinard e Vlad Trifa

Este artigo foi originalmente publicado por IoT Technica Curiosa magazine.

A Internet das Coisas - IoT resumidamente - veio para ficar e com isso mudar o mundo para melhor. Está visão colossal retrata um mundo onde pessoas, construções e até mesmo objetos estão conectados a uma mesma rede. Neste mundo, garrafas de refrigerante, luzes do seu apartamento, carros e todo o resto fornecerão serviços e trocarão dados uns com os outros.

Você deve ter percebido que a IoT está mais pra uma Intranet das Coisas: para interagir com dez dispostivos diferentes do seu telefone, você precisa instalar dez aplicativos diferentes. O problema é que não existe uma única forma para se comunicar entre todos e cada objeto. Há literalmente centenas! A pior parte é que a maioria desses protocolos e padrões IoT não são compatíveis entre si e, por esse motivo, esta tecnologia ainda não cumpriu suas promessas (ainda!).

IoT versus WoT.
Conectando todas as coisas a Internet e dar-lhes a cada uma endereços de IP é apenas o primeiro passo para a realização da Internet das coisas. Os dispositivos podem facilmente trocar dados uns com os outros, mas eles não entenderão necessariamente o que esses dados significam.  Isso é o que os protocolos da Web como o HTTP trouxeram para a Internet: uma maneira universal de descrever imagens, texto e outros elementos de mídia para que as máquinas pudessem se "entender". A Web of Things-ou WoT - é simplesmente a próxima etapa desta evolução: usando e adaptando protocolos da Web para conectar qualquer coisa no mundo físico e dar-lhe presença na World Wide Web.

Assim como a arquitetura em camadas OSI organiza muitos protocolos e padrões da Internet, a arquitetura WoT é uma tentativa de estruturar a galáxia de protocolos e ferramentas da Web em uma estrutura útil para conectar qualquer dispositivo ou objeto à Web. A pilha de arquitetura WoT não é composta de camadas em sentido estrito, mas sim de níveis que adicionam funcionalidades extras, conforme mostrado na Figura 1 abaixo. Cada camada ajuda a integrar as coisas na Web de forma ainda mais precisa, tornando esses dispositivos mais acessíveis para aplicações e pessoas.

Figura 1. A arquitetura WoT e suas quatro camadas de aplicativos em cima da camada de rede.
Para ilustrar o que essas camadas trazem para a tabela IoT, deixe-nos apresentar WoT Pi, um dispositivo baseado em framboesa Pi que funciona em na plataforma EVERYTHING em Londres. O WoT Pi está conectado com um monte de sensores (por exemplo, temperatura, umidade) e atuadores (por exemplo, uma tela LCD, LEDs) com os quais você pode interagir através da Internet. Uma câmera conectada à Internet permite que você veja a configuração ao vivo. Confira aqui:


Camada 1: Acesso

Esta camada é responsável por transformar qualquer coisa em uma Web-Thing que pode ser interagida com o uso de solicitações de HTTP, assim como qualquer outro recurso na Web. Em outras palavras, uma Web Thing é uma API REST que permite interagir com algo no mundo real, como abrir uma porta ou ler um sensor de temperatura localizado mundo a fora.

Para ilustrar isso, os sensores de nosso Pi podem ser acessados através de uma simples solicitação HTTP na seguinte:


Vá em frente e tente isso no seu navegador. Você obterá uma representação HTML com links para os sensores. Clique em "temperatura" e você terá a temperatura. O que você está fazendo aqui é navegar pela API RESTful do nosso Pi, assim como você faria se navegasse em uma página da Web. IoT-Things podem ser mapeadas em recursos REST facilmente, como mostra a Figura 2, abaixo:

Figura 2. Recursos REST do nosso Raspberry Pi conectado.
HTML é ótimo para humanos, mas nem sempre para máquinas que preferem a notação JSON. Nosso Pi fornece ambos. Execute o seguinte comando no seu terminal usando o cURL, uma ferramenta para se comunicar com as APIs HTTP:

curl -X GET -H "Accept: application/json" "http://devices.webofthings.io/pi/sensors/humidity/"

Você verá o nível de umidade em nosso escritório de Londres em JSON em seu terminal. Este é o primeiro passo ideal para construir seu primeiro aplicativo que expande a Web para o mundo real!

Isso tudo é muito bom, mas muitos cenários do IoT são em tempo real e / ou conduzidos por eventos. Em vez de sua aplicação pedir continuamente dados ao nosso Pi, você quer que ela notifique você quando algo acontece no mundo real; por exemplo, quando a umidade atinge um certo limiar ou um ruído é detectado em sua casa no meio da noite. É aí que outro protocolo da Web pode ajudar: WebSocket. O código Javascript abaixo é suficiente para que uma página da Web obtenha automaticamente as atualizações de temperatura do WoT Pi. Cole-o no console do seu navegador da Web e você verá o nosso Pi enviando a temperatura em tempo real para o seu navegador.

var socket = new WebSocket('ws://devices.webofthings.io/pi/sensors/temperature/'); socket.onmessage = function (event) { //Called when a message is received var result = JSON.parse(event.data); console.log(result); };

Camada 2: Encontrar


Tornar as coisas acessíveis através de uma API HTTP e WebSocket é excelente, mas isso não significa que os aplicativos realmente podem "entender" o que o dispositivo é, quais dados ou serviços ele oferece, e assim por diante.

É aí que a segunda camada, Encontrar, torna-se interessante. Esta camada garante que o seu dispositivo não só possa ser facilmente usado por outros clientes HTTP, mas também possa ser encontrado e automaticamente utilizado por outros aplicativos WoT. A abordagem aqui é reutilizar os padrões semânticos da Web para descrever as coisas e seus serviços.  Isso permite pesquisar dispostivos através de mecanismos de pesquisa e outros índices da Web, bem como a geração automática de interfaces ou ferramentas de usuário para interagir com os dispositivos. Neste nível, tecnologias como o JSON-LD estão em uso: um idioma para anotar semânticamente o JSON.  Isto também é onde padrões como o Web Things Model e o trabalho do grupo W3C WoT ajudam: eles definem um conjunto abstrato de recursos REST que os dispositivos devem oferecer.


Camada 3: Compartilhe

A Internet das coisas só florescerá se os dispositivos tiverem uma maneira de compartilhar dados com segurança entre os serviços. Esta é a responsabilidade da camada Compartilhar, que especifica como os dados gerados pelos dispositivos podem ser compartilhados de maneira eficiente e segura na Web. Nesse nível, outro lote de protocolos da Web ajuda. Primeiro, há TLS, o protocolo que torna as transações na Web seguras. Então, técnicas como mecanismos de autenticação da Web, como OAuth, podem ser integradas às APIs de nossos dispositivos.

Camada 4: Composição

Finalmente, uma vez que as coisas estão na Web (camada 1), onde elas podem ser encontradas por seres humanos e máquinas (camada 2), e seus recursos podem ser compartilhados de forma segura com os outros (camada 3), é hora de olhar para como construir grandes- escalas de aplicações significativas para a Web of Things. Em outras palavras, precisamos entender a integração de dados e serviços de Dispositivos heterogêneas em um imenso ecossistema de ferramentas da Web, como software analítico e plataformas de mashup. Ferramentas da Web no intervalo de camada de composição dos toolkit's da Web - por exemplo, SDKs de JavaScript que oferecem abstrações de nível superior - para painéis com widgets programáveis e, finalmente, para ferramentas de mashup físico, como Node-RED, conforme mostrado abaixo. Inspirados pelos serviços participativos da Web 2.0 e em particular os mashups da Web, os mashups físicos oferecem uma visão unificada da Web clássica e da Web das Coisas e capacitam as pessoas a criar aplicativos usando dados e serviços da Web Things sem exigir habilidades de programação.

Figura 3. Um mashup físico com Node-RED. Quando um intruso é detectado através do sensor PIR, uma imagem é tirada e enviada para o Twitter.

Conclusão

A Web of Things é um protocolo de aplicativo de alto nível projetado para maximizar a interoperabilidade no IoT. Esperamos que esta breve introdução lhe tenha dado um gosto do seu potencial. As tecnologias da Web são amplamente populares e oferecem toda a flexibilidade e recursos necessários para a maioria das futuras aplicações IoT, incluindo descobertas, segurança e mensagens em tempo real.

Enquanto nós só explanamos sobre as idéias do WoT, esperamos que isso tenha despertado o seu interesse em tornar a IoT Things mais acessível, graças à Web. A arquitetura da Web de coisas está completamente descrita em nosso livro: "Construindo a Web das Coisas". O livro também é embalado com exemplos de código no Raspberry Pi usando a linguagem Node.js. O código é OpenSource e está disponível gratuitamente em: https://github.com/webofthings/wotbook.

Apple e os processadores ARM

Apple e os processadores ARM
Apple e os processadores ARM

Depois que a Apple anunciou a migração de X86 para ARM, muita gente se preocupou quanto a possibilidade de não poder utilizar programas de uma arquitetura em outra. A Apple já fez o processo de transição da arquitetura PowerPC para a X86 sem apresentar trabalhos críticos; desta vez eu acredito que não será diferente. No meu vídeo sobre Ubuntu rodando no meu Power Mac G4 eu explico através do kernel do Mac OS X Leopard como a Apple realizou esse trabalho até que todos os fornecedores pudessem portar os seus programas para X86:


 Migrar para ARM parecia algo previsível; em 2.015 o site Mac Rumors já havia postado a noticia sobre a pretensão da Apple migrar para ARM e a resposta da Intel afirmando que o relacionamento entre as duas empresas ainda era muito forte; em 2.018 a Apple vendeu quase 218 milhões de Iphones e apenas pouco mais de 18 milhões de Macs. As coisas ficaram cada vez mais óbvias com o lançamento do novo Ipad Pro que era mais poderoso que 92% dos desktops acessíveis do mercado da época, rodando Photoshop nativamente, navegando na internet e utilizando Whatsapp ao mesmo tempo (e até arrastando do navegador e soltando no Whatsapp) e termina com a frase "ele é como um computador mas diferente de qualquer computador".

O chip A12X Bionic utilizado no Ipad Pro.
O chip A12X Bionic utilizado no Ipad Pro.
Poderoso o suficiente para photoshop nativo.
Poderoso o suficiente para photoshop nativo.
Mais rapido do que 92% dos desktops acessíveis.
Mais rapido do que 92% dos desktops acessíveis.
Navegando na web e usando chat ao mesmo tempo.
Navegando na web e usando chat ao mesmo tempo.
Arrastando do navegador e soltando no Whatsapp.
Arrastando do navegador e soltando no Whatsapp.
 Por fim a Apple anunciou no mês de Junho que estaria migrando que X86 para ARM. A coisa está feia para o X86, mas parece que somente para a Intel pois a AMD anda ganhando cada vez mais espaço com o núcleo Zen (com mais um console no mercado da Atari) enquanto isso recentemente Linus mandou a real para a Intel desejando uma morte dolorosa ao AVX-512, que a Intel pare de ficar focando em benchmarks com sua Unidade Ponto Flutuante, pare de ficar inventando moda com instruções mágicas e comece a corrigir problemas reais. Para revidar a situação,parece que a Intel está trabalhando em um novo recurso de tecnologia hibrida para o Alder Lake chamado Big-Bigger similar ao design Big.LITTLE da arquitetura ARM.


 Uma coisa que deixou os apaixonados por Mac foi a possibilidade de retrocompatibilidade não somente com Intel, mas também com outras arquiteturas passadas. Um desenvolvedor apaixonado por Macs antigos chamado tenFOURFox escreveu sobre a possibilidade de rodar até cinco arquiteturas em um unico binários (ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 e x86_64) e potencialmente até 17 arquiteturas em  um único binário (ppc750, ppc7400, ppc7450, ppc970, i386, x86_64, x86_64h, armv4t, armv5, armv6, armv6m, armv7, armv7em, armv7k, armv7m, armv7s e todos os outros Macs com AARM.)

 Uma informação que prometi na live que iria pesquisar é qual tecnologia GPU será utilizada nos novos Macs com ARM. A unica coisa que se sabe é que a Apple guarda esse segredo a sete chaves pois parece ser tecnologia própria da empresa.
Imagem aqui
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
DEMAIS, SÓ FINALIZO DIZENDO QUE, SE VOCÊ É UM USUÁRIO DE MAC OS E ESTÁ PENSADO EM MIGRAR PARA LINUX, MEU CURSO É PENSADO TAMBÉM PARA VOCÊ ;)

Red Hat e VMware trabalhando juntas no Openshift

Red Hat e VMware trabalhando juntas no Openshift
Red Hat e VMware trabalhando juntas no Openshift
 Red Hat e VMware estão trabalhando para criar uma arquitetura de referencia do VMware  para o OpenShift. Já não é de hoje que ambas possuem parceria trabalhando em soluções para atender seus clientes. Há muitos anos a Red Hat é certificada VMware vSphere e possui suporte VMware NSX-T networkingVMware vSAN baseada nas contribuições do Kubernetes do VMware.
 CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
 Como a demanda por nuvem hibrida (hybrid cloud) cresce cada vez mais no ambiente corporativo e a Red Hat sendo pioneira em tal serviço, a Red Hat e a VMware se uniram para trabalhar juntas para implantar a plataforma OpenShift Container da Red Hat e ajudá-los assim a implantar aplicações cloud-native com containers e Kubernetes.


 Parceiras há longos anos, agora ambas trabalham em uma arquitetura para trazer o Red Hat OpenShift ao pilha SDDC da VMware e poupar seus clientes de ter todo o trabalho que tem hoje de ter que customizar todo o seu serviço para integrá-los ao VMware vSphere, NSX-T e vSAN com o Red Hat OpenShift e o Red Hat Enterprise Linux.


 Por hora, tal serviço ainda não é possível, mas acredito que essa união não demorará para trazer tais ferramentas muito em breve.

Dando uma olhada na arquitetura dos processadores #4

uma placa do super computador Titan: 4 Opteron AMD (16 núcleos) + 4 NVIDIA Tesla K20X
uma placa do super computador Titan: 4 Opteron AMD (16 núcleos) + 4 NVIDIA Tesla K20X

Além do que acabamos de falar, existem ainda algumas medidas além dos famosos Hertz (Kilohertz, Megahertz e Gigahertz) que estamos obituadas a ver. Por exemplo existe a medida MIPS (Mega Instructions Per Second) que vale a ressalva, não confunda esse MIPS que estamos falando aqui com a arquitetura MIPS da empresa MIPS Technologies Inc. Nesta arquitetura, MIPS significa Microprocessor without interlocked pipeline stages (microprocessador sem estágios
de pipeline intertravados). O MIPS que abordamos aqui trata-se de milhões de instruções por segundo. O SH4 do Dreamcast por exemplo fazia 230 a 360 MIPS a 200MHZ. Já um Corei5 da intel faz em torno de 83 mil MIPS a uns 3.3GHZ. E o um FX da AMD faz muito mais de 90.000 MIPS a mais ou menos 3.5GHZ.


FLOPS (Giga Floating-point Operations Per Second) que é uma medida muito usada em computação cientifica fazendo uso do FPU. O desempenho de um supercomputador é medido em FLOPS, e não em MIPS. Daí os caras medem em:
  • kiloFLOPS kFLOPS 103
  • megaFLOPS MFLOPS 106
  • gigaFLOPS GFLOPS 109
  • teraFLOPS TFLOPS 1012
  • petaFLOPS PFLOPS 1015
  • exaFLOPS EFLOPS 1018
  • zettaFLOPS ZFLOPS 1021
  • yottaFLOPS YFLOPS 1024
Mais do Titan, os canos de metal transportam refrigeração para o supercomputador.

MOPS (Mega Operations Per Second) é utilizada inclusive na taxa de reprodução de áudio e vídeo ao invés de TOPS (Tera Operations Per Second) de acordo com o livro Digital Signal Processing for Multimedia Systems.

Novatec Editora lança livro “Aprendendo padrões de projeto em Python”

Aprendendo-padrões-de-projeto-em-Python
Aprendendo padrões de projeto em Python
Título ensina a aproveitar a eficácia dos padrões de projeto em Python para resolver problemas de arquitetura e design de software

É importante que arquitetos de software pensem em otimizações na criação de objetos, na estrutura do código e na interação entre objetos nesses níveis, pois isso garante que o custo da manutenção de software seja baixo e o código seja facilmente reutilizado ou adaptado a mudanças.
O livro Aprendendo padrões de projeto em Python, lançado pela Novatec Editora, ensina a implementar cenários do mundo real com a versão mais recente de Python, a v3.5. Indicado para desenvolvedores Python e interessados no assunto, o livro começa apresentando padrões de projeto do ponto de vista de Python, e então parte para os padrões Singleton, Factory e Façade em detalhes. Ensina também como controlar o acesso a objetos com o padrão Proxy e inclui padrões Observer, Command e Compound. Ao final, o leitor terá melhorado suas habilidades profissionais em arquitetura, design e desenvolvimento de software.
•     Aperfeiçoar suas habilidades para criar uma arquitetura melhor de software.
•     Entender soluções eficazes para problemas de design comuns.
•     Explorar os princípios de design que formam a base do design de software, como baixo acoplamento, o princípio de Hollywood e o princípio do aberto/fechado, entre outros.
•     Aprender como os conceitos de programação orientada a objetos são usados em aplicações de software.
•     Desenvolver uma compreensão sobre os padrões de projeto de criação bem como os diferentes métodos de criação de objetos que ajudam a resolver problemas em desenvolvimento de software.
•     Utilizar padrões de projeto estruturais e descobrir de que maneira os objetos e as classes interagem na construção de aplicações maiores.
•     A interação entre os objetos com os padrões Command e Observer.
•     Melhorar a produtividade e a base de código de sua aplicação usando padrões de projeto com Python.

Para conferir o livro, clique aqui

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)