From bfbb12cc9f1c1a14fc0f3989d82dfd1d7bad972e Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Thu, 6 Mar 2014 21:59:52 -0300 Subject: Adding presentation --- doc/hidra.html | 954 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 954 insertions(+) create mode 100644 doc/hidra.html (limited to 'doc/hidra.html') diff --git a/doc/hidra.html b/doc/hidra.html new file mode 100644 index 0000000..e2b81e0 --- /dev/null +++ b/doc/hidra.html @@ -0,0 +1,954 @@ + + + + + O Processo Hidra + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+ +
+ + + +

O Processo Hidra

+ + +
+
+

O Processo Hidra

+

O Processo Hidra

+ +

De relógios a nuvens, de nuvens a hidras.

+
+ + +
+
+

Parte 1: Introdução

+
+

Objetivo da apresentação

O objetivo desta fala é divulgar os estudos em andamento sobre o processo hidra dando espaço para possíveis andamentos:

+ +
    +
  1. +

    Informar os grupos e pessoas que possuem conteúdo hospedado em infraestruturas tecno-sociais comuns sobre o trabalho desenvolvido.

    +
    2. +
  2. +

    Encorajar grupos técnicos existentes para adotarem procedimentos que favoreçam suas infraestruturas a terem comportamento hidra.

    +
    3. +
+ +

Esta apresentação ainda está em processo de concepção e revisão e por isso não está sendo divulgada.

+ + +
+
+

O que é uma Hidra?

+
+

Ser mitológico de múltiplas cabeças regenerativas, destruído por Hércules

+

Hidra mitológica

+
+ + +
+
+

Na biologia moderna, animal aquático que possui capacidades regenerativas

+

Hida biológica

+
+ + +
+
+

O que é o Processo Hidra?

O Processo Hidra é uma descrição de infraestruturas tecno-sociais que apresentam:

+ +
    +
  1. +

    Replicabilidade e escalabilidade.

    +
    2. +
  2. +

    Capacidade de combinação rizomática.

    +
    3. +
  3. +

    Regeneração e reagrupamento após eventos catastróficos.

    +
    4. +
+ +

A Hidra moderna pode resistir a Hércules.

+ + +
+
+

Parte 2: Grupos Técnicos Sociais

Mas antes façamos uma retrospectiva…

+ + +
+
+

Sistemas informacionais sociais

Modelo “clássico” de hospedagem: arquitetura “cliente-servidor”:

+ +
+

Arquitetura cliente-servidor

+
+ + +
+
+

Trabalho técnico informacional em grupos sociais

Características:

+ +
    +
  • +

    Considerado tecnicamente de alta dificuldade e dedicação.

    +
    • +
  • +

    Esforço para provisionamento, configuração e manutenção de sistemas.

    +
    • +
  • +

    Trabalho demorado: escala de meses para alcançar estabilidade.

    +
    • +
  • +

    Suscetível a muitas falhas: escala de horas para que um sistema seja inutilizado.

    +
    • +
  • +

    Pouco tempo disponível para o trabalho.

    +
    • +
  • +

    Dificuldade para a realização de backups e manutenção de procedimentos administrativos.

    +
    • +
  • +

    Baixa mobilização e força de trabalho “tarefeira”.

    +
    • +
  • +

    Custa um bom dinheiro…

    +
    • +
+ + +
+
+

Interlúdio: a destruição das redes

Redes centralizadas e descentralizadas +Rede distribuída

+ +

A cada evento catastrófico, vários grupos são prejudicados com danos à comunicação de difícil cicatrização.

+ + +
+
+

Parte 3: Contra-ataque infraestrutural

Como impedir que uma rede seja destruída mesmo que a remoção de nodos continue?

+ + +
+
+

A divisão em camadas

Observação crucial:

+ +
"Ghost in the shell": o disco e o hardware são intercambiáveis,
+ provisionamento pode ocorrer em múltiplas etapas. É possível
+ manter um estoque de discos pré-instalados e uma reserva financeira
+ para a aquisição de máquinas. Isso e backups permite a reconstrução
+ de sistemas.
+
+ +

Conclusão imediata:

+ +
É necessário "descolar" a camada de serviços (web, streaming, email,
+etc) da camada infraestrutural (máquinas, conexões, etc): filtragem
+de problemas físicos e jurídicos.
+
+ +

A camada de serviços pode então ser “congelada” na forma de backups, enquanto que a camada infraestrutural não possui “alma” intrínseca, podendo ser reconfigurada quando necessário. Desse modo, várias máquinas podem ser mantidas no ar para aumentar a tolerância a falhas.

+ +

Mas como um sítio pode estar simultaneamente em várias máquinas?

+ + +
+
+

DNS: colando domínios em máquinas

DNS +Round Robin DNS

+ +

O colamento/descolamento entre camadas é possível mediante mudanças de DNS.

+ + +
+
+

Proxies: distribuindo um sítio entre máquinas

+

App proxy

+
+ + +
+
+

Aplicação descentralizada ou distribuída

+

ICE

+
+ + +
+
+

Tipos de camadas

Informação de um sistema é dividida conforme sua aplicabilidade:

+ +
    +
  • +

    Hardware: manifestações cristalizadas de informação: computadores.

    +
    • +
  • +

    Programas (software): pacotes.

    +
    • +
  • +

    Configuração (módulos).

    +
    • +
  • +

    Chaves e senhas.

    +
    • +
  • +

    Dados (o conteúdo propriamente dito).

    +
    • +
+ +

Tais camadas podem ser empacotadas em sistemas e tais sistemas podem ser agregados em outros sistemas (camadas de camadas de camadas): pode ser uma abstração complicada, mas o ganho conceitual em isolamento de instâncias é importante.

+ + +
+
+

Problemas

O discurso é bonito, porém…

+ +
    +
  1. +

    Hardware é muito heterogêneo para padronizações serem efetivas.

    +
    2. +
  2. +

    Os programas são muito diversos para serem estudados, integrados e desenvolvidos.

    +
    3. +
  3. +

    Configurações são muito complexas e numerosas para serem facilmente separadas e replicadas de forma genérica.

    +
    4. +
  4. +

    São necessárias muitas senhas de boa complexidade, o que torna sua manutenção complicada.

    +
    5. +
  5. +

    Backups são difíceis de serem realizados e recuperados.

    +
    6. +
+ +

Ou seja: o discurso da divisão em camadas é interessante, porém na realidade sua implementação enfrenta diversos problemas. Serão eles impeditivos?

+ + +
+
+

O Plano R*

Rede +Anéis

+ + +
+
+

O Plano R*: email

+

Sistema de email escalável

+
+ + +
+
+

Como é possível?

O segredo está na articulação da força de trabalho com a divisão de camadas. A regra geral é:

+ +
    +
  1. Utilização de ferramentas sólidas e amplamente utilizadas por comunidades de software livre e aberto.
    2. +
  2. Trabalho de desenvolvimento focado na integração de soluções existentes, enviando alterações em código corrente acima sempre que possível.
    3. +
  3. Desenvolvendo código próprio, porém livre, apenas quando não existente ou insuficiente nas comunidades.
    4. +
+ +

Cada um desdes tipos informacionais é distribuído em unidades que por sua vez são agregados em árvores:

+ +
    +
  • Hardware em servidores (canalizadores de fluxos, nodos ou instâncias em nuvens).
    • +
  • Programas em pacotes e distribuições.
    • +
  • Configurações em módulos e repositórios.
    • +
  • Chaves (que são unidades de segredo) em repositórios.
    • +
  • Dados em árvore de backups.
    • +
+ + +
+
+

Divisão artefática

A divisão em camadas é artificial (artefática), porém com importantes consequências quando observada à luz da divisão do trabalho de comunidades de software livre e aberto:

+ +
  /'\          |
+   |          \./
+upstream   downstream
+
+ +
    +
  • Hardware: desenvolvimento caro e complexo; hardware livre e aberto engatinhando; dependência do mercado. Exemplo: disco rígido.
    • +
  • Programas e distribuições: grandes comunidades de desenvolvimento e uso. Exemplo: GNU/Linux, Debian.
    • +
  • Configuração: comunidades mais restritas de desenvolvimento e uso. Exemplo: manuais, howtos, módulos.
    • +
  • Chaves e senhas: restrita ao grupo responsável por manter uma dada infraestrutura. Exemplo: senha de superusuário/a.
    • +
  • Dados: desenvolvidos pelas pessoas e grupos hospedados. Exemplo: texto num wiki.
    • +
+ + +
+
+

Divisão artefática - 2

É possível reconstruir um sistema dados esses elementos. A divisão do trabalho upstream/downstream é favorável à reconstrução, já que as tarefas se tornam mais complexas ao longo da subida da corrente onde usualmente os grandes grupos sociais se reúnem para solucioná-las.

+ + +
+
+

Economia de trabalho

Assim, é possível economizar muita força de trabalho.

+ +
    +
  1. +

    Enviar um desenvolvimento corrente acima (upstream) libera o grupo técnico de uma manutenção posterior, pois o trabalho passa a ser de responsabilidade da comunidades mais ampla.

    +
    2. +
  2. +

    Quanto mais específica for a informação, mais abaixo da corrente (downstream) ela deve ser mantida.

    +
    3. +
  3. +

    Naquilo que não houver desenvolvimento corrente acima, atuar como fonte (ou seja, agir como upstream) e fornecer para a comunidade.

    +
    4. +
+ + +
+
+

Tipos de salvaguarda

Para todas as camadas divididas anteriormente é possível criar algum tipo de salvaguarda contra perdas:

+ +
    +
  • +

    Dinheiro: armazenamento e replicação de força de trabalho (potencial de trabalho armazenado).

    +
    • +
  • +

    Estoque: hardware hoje é commodity, podendo ser minimamente estocado ou mantido online em diversos locais.

    +
    • +
  • +

    Repositórios: programas, pacotes, distribuições e configurações.

    +
    • +
  • +

    Backups: manutenção de dados ou coisas sobressalentes.

    +
    • +
+ + +
+
+

Parte 3: contexto brasileiro

+
+

Orçamento e infraestrutura

Custos:

+ +
    +
  • Plano R*: EUR 10.000 anuais.
    • +
  • No Brasil, é praticamente a despesa anual de um centro social alugado e muito mais do que a receita da maioria dos grupos.
    • +
+ +

Conexão:

+ +
    +
  • Nos EUA e na Europa, a conexão é rápida e barata. Datacenters corporativos são acessíveis.
    • +
  • No Brasil, a conexão é lenta, cara e o preço dos datacenters é exorbitante.
    • +
+ +

Repressão:

+ +
    +
  • Criminalização dos movimentos sociais (entulho jurídico).
    • +
  • Polícia violenta.
    • +
+ +

Estaremos impossibilitados/as de mantermos servidores no país?

+ + +
+
+

Por outro lado

    +
  • +

    A legislação, a jurisprudência, cultura e valores brasileiros são muito mais favoráveis à preservação da privacidade que nos EUA ou na Europa (fator Dantas).

    +
    • +
  • +

    Honorários advocatícios não são tão altos quanto no exterior (?).

    +
    • +
  • +

    O câmbio é favorável a doações internacionais.

    +
    • +
+ + +
+
+

O caso Satangoss

“O que demorou quatro anos para juntarmos nos foi arrebatado num único dia.”

+ +
    +
  • +

    Agosto de 2008: polícia civil apreende o servidor do Saravá sem mandado judicial.

    +
    • +
  • +

    Mais de cem sítios fora do ar.

    +
    • +
  • +

    Não havia backup remoto e nem medidas de contingência estabelecidas.

    +
    • +
  • +

    Todos os ovos estavam na mesma cesta.

    +
    • +
  • +

    Grande desmobilização.

    +
    • +
  • +

    Análise do caso: http://www.sarava.org/node/44

    +
    • +
+ +

Como reverter a crise num novo ciclo de mudança e amadurecimento?

+ + +
+
+

Parte 4: O Processo Hidra

+

Regeneração

+
+ + +
+
+

Regeneração

Hidra: toda célula pode ter o germe da própria organização. Múltiplas cabeças, células tronco que podem adquirir especialização conforme a necessidade.

+ +
+

Regeneração da hidra

+
+ + +
+
+

Hidra em processo

+

Regeneração da Hidra

+
+ + +
+
+

Hidra em processo - 2

+

Regeneração da Hidra

+
+ + +
+
+

Topologias

"[To] keep our sources safe, we have had to spread assets, encrypt everything,
+and move telecommunications and people around the world to activate protective
+laws in different national jurisdictions," Mr Assange said told the BBC earlier
+this year.
+
+ +

Fonte: http://www.bbc.co.uk/news/world-11047811

+ +

Possíveis montagens: anel, estrela, rizomática, etc. Frontends e backends.

+ + +
+
+

Parte 5: O Processo Hidra Saravento

    +
  1. +

    Apresenta Padrão Saravá (Sarava Pattern, http://padrao.sarava.org).

    +
    2. +
  2. +

    Utiliza Resource Sharing Protocol (RSP, http://rsp.sarava.org).

    +
    3. +
  3. +

    Considerando a adoção de padrões definidos de política de segurança e privacidade.

    +
    4. +
  4. +

    Organiza-se de acordo com protocolos (http://protocolos.sarava.org).

    +
    5. +
+ +

Na Hidra Saraventa, cada célula é chamada de “nodo”:

+ +
    +
  • +

    Nodos físicos com servidores virtuais com fins específicos.

    +
    • +
  • +

    Nodos virtuais em diversos locais (inclusive hospedados por terceiros).

    +
    • +
+ +

Baseada no seguinte pricípio: quais problemas solucionaremos, quais não.

+ + +
+
+

O Padrão Saravá

O Padrão Saravá é uma sistematização de configuração de servidores, gerenciadores de conteúdo e aplicações diversas usados pelo Grupo Saravá. O padrão foi desenvolvido para:

+ +
    +
  • +

    Ter controle dos pacotes utilizados, arquivos de configuração e serviços em uso.

    +
    • +
  • +

    Uniformidade de administração.

    +
    • +
  • +

    Sistema de gerenciamento de backups comum para que as máquinas de um projeto possam trocar dados.

    +
    • +
  • +

    Que um servidor seja configurado apenas uma vez e que suas configurações possam ser aproveitados para outras máquinas.

    +
    • +
  • +

    Que sites e serviços sejam armazenados de maneira regular para facilitar atualizações e migrações.

    +
    • +
  • +

    Manter projetos e serviços isolados uns dos outros através de servidores virtuais.

    +
    • +
  • +

    Tornar a instalação dos servidores facilmente replicável.

    +
    • +
+ +

Dinâmica de desenvolvimento:

+ +
Documentação wiki -> Configurações pré-gravadas -> Software
+
+ + +
+
+

Puppet

Puppet: topologia +Puppet: diagrama de sistema

+ + +
+
+

Puppet: compartilhando configuração

Código puppet:

+ +
file { '/etc/passwd':
+    owner => root,
+    group => root,
+    mode  => 644,
+}
+
+ +

Módulos compartilhados:

+ + + + +
+
+

Git e gitosis

VCS +VCS distribuído

+ + +
+
+

O Protocolo de Compartilhamento de Recursos

"The Resource Sharing Protocol (RSP) is a set of metadata intended to help free
+software groups
+
+    * Share their available resources and also Find groups that can host
+    * services for them given their needs and requirements.
+
+The RSP splits each resource in a layer or set of service layers. You can think
+of service layers something very general, ranging from servers, databases,
+websites. If you need to, you can even consider stuff such as tables and
+bicycles as layers that provide some kind of service to a hosted group. ;)"
+
+-- http://rsp.sarava.org
+
+ + +
+
+

Orquestração

Para complementar a Configuração de sistemas padronizada e centralizada, procedimentos como

+ +
    +
  1. Atualização de pacotes.
    2. +
  2. Atualização de código de gerenciadores de conteúdo.
    3. +
  3. Carga de bancos de dados.
    4. +
+ +

podem ser codificados de forma a serem facilmente aplicados a múltiplas camadas de forma simultânea.

+ +

Exemplos:

+ + + + +
+
+

Ikiwiki

O Ikiwiki (http://ikiwiki.info) é um software de wiki que usa um sistema de controle de versão e arquivos de texto, possibilitando:

+ +
    +
  1. A existência de múltiplas cópias integrais do wiki (online e offline).
    2. +
  2. Desenvolvimento distribuído de documentação.
    3. +
+ +

O ikiwiki é muito útil para reunir documentação de sistemas, já que não necessita de nenhum sistema web funcional para abrigá-la.

+ + +
+
+

Virtualização

Virtualização através de Linux-VServer (existem outras implementações possíveis):

+ + + +

Principais vantagens:

+ +
    +
  • +

    Permite diversos grupos compartilharem uma mesma máquina presevando sua autonomia.

    +
    • +
  • +

    Grupos podem hospedar mutuamente instâncias virtuais. Exemplo: se existem 5 grupos com uma máquina cada um, se cada um deles hospedar um vserver para cada grupo, teremos 4 locais remotos de hospedagem por grupo, aumentando assim as possibilidades de salvaguarda e escalabilidade.

    +
    • +
+ + +
+
+

Keyringer e monkeysphere

O Keyringer (http://git.sarava.org/?p=keyringer.git;a=summary) é um repositório distribuído de senhas/chaves baseado em GPG e git.

+ +

O monkeysphere (http://web.monkeysphere.info) é um programa que permite a verificação de hosts SSH e usuários/as através da Teia de Confiabilidade do OpenPGP. Com ele, o gerenciamento de fingerprints fica mais fácil e evita que páginas como esta centralizem informações que possam se desatualizar.

+ + +
+
+

Tecnologia bootless

Muitos esquemas de criptografia em disco se baseiam na proteção das partições de dadados e da área de troca, porém dependem da existência de ao menos uma partição de inicialização com as imagens do sistema e de um setor de inicialização.

+ +

Com acesso físico à máquina, é possível infectar tais dados de inicialização e comprometer a criptografia de todo o sistema.

+ +

Para mitigar a situação, o esquema Bootless é um repositório git que contém as imagens de inicialização e a configuração necessárias para o procedimento de partida.

+ +

Assim, é possível manter a parte de inicialização fora da máquina, por exemplo em chaveiros USB.

+ +

Projeto similar: http://lfde.org

+ + +
+
+

Monitoramento: nagios

+

Nagios

+
+ + +
+
+

Monitoramento: munin

+

Munin

+
+ + +
+
+

Backups

Estratégia:

+ +
    +
  1. Backups locais criptografados com duplicity: +
      +
    • Incluindo apenas /etc, /var, /home.
      • +
    • Excluindo logs, cache e backups remotos.
      • +
    +
    2. +
  2. Backups remotos apenas do backup local em duplicity, via rdiff ou rsync.
    3. +
  3. Nodos designados para armazenamento de backups.
    4. +
  4. Incrementos locais e remotos para aumentar consistência dos dados.
    5. +
  5. Procedimento integrado de restore e ativação de nodo.
    6. +
+ + +
+
+

Hardware e custos

    +
  • Servidor mini-ITX Atom dual core + 2GB RAM + 1TB: R$680.00.
    • +
  • Nobreaks APC: +/- R$500,00.
    • +
  • Banda larga ADSL/cabo: R$80,00 a R$200,00.
    • +
  • Energia: 180W (mini-ITX) máx.
    • +
  • Sistema pode ser instalado inclusive em memórias de estado sólido (microSD por exemplo).
    • +
+ +
+

Mini ITX

+
+ + +
+
+

Utilidades: adaptador para discos

+

Adaptador SATA

+
+ + +
+
+

Utilidades: chave de entropia

Entropy key +Entropy graph

+ + +
+
+

Segurança

Acesso remoto:

+ +
    +
  • +

    Contas SSH administrativas em todos os nodos.

    +
    • +
  • +

    Contas SSH de backup para nodos de backup.

    +
    • +
  • +

    Contas SSH de tunelamento para nodos diversos.

    +
    • +
+ +

Análise:

+ +
    +
  1. +

    É importante isolar o máximo a capacidade de acesso para contas de nodos de backup ou que tunelem conexões.

    +
    2. +
  2. +

    Administradores/as precisam ter boas medidas de segurança:

    +
      +
    • Pasta criptografada.
      • +
    • Senhas e chaves seguras.
      • +
    +
    3. +
+ + +
+
+

Protocolos sociais

    +
  • Protocolo de Ação Coletiva: http://protocolos.sarava.org.
    • +
  • Outros protocolos e metodologias (contabilidade, acesso à informação, relação com grupos, etc).
    • +
  • +

    Uso de um sistema de gestão de processos (trac ou similar).

    + + 
         .------------------->-----------------.
+    /  .----------<--------------<-------.  \
+   |  '                                   \  \
+   |  |               .------>-----.       \  \
+   |  |              |              \       \  \
+  Proposta -----> Discussão ->--.    \       \  \
+     |  ^            |           \    \       \  \
+     |  |            |            \    \       \  \
+     |   `----<-----'             |     \       \  \
+     |                            |      |       \  \
+      `------>------ Decisão --<--'      |        \  \
+                       | |               |         \  \
+                       | |               |          | |
+   Atribuição de --<---' '---> Arquivamento --->---'  ;
+ Responsabilidades ----->-------'   ^    \           /
+      ^  |              ___________/      `---<-----'
+      |   \           .'
+      |    `--> Realização -->--.
+      |           |  |           \
+      |           |  |           /
+       `----<-----'   `-----<---'
+
    +
    • +
+ + +
+
+

Resumo: Estratégia de gestão

    +
  • +

    Facilitar instalação, manutenção e gestão de dados.

    +
    • +
  • +

    Manter backups em máquinas prontas para serem inicializadas.

    +
    • +
  • +

    Manter nodos master prontos para assumirem o posto de “cabeça ativa”.

    +
    • +
+ + +
+
+

Parte 6: A Confederação das Hidras Unidas

+

Hidra Cluster

+
+ + +
+
+

A Confederação das Hidras Unidas

    +
  • +

    Hidra é um processo, não uma tecnologia, implementação, sistema ou serviço.

    +
    • +
  • +

    Assim, é possível ter hidras menos sistematizadas e com diferentes formas de organização. O processo já ocorre em vários locais.

    +
    • +
  • +

    Havendo várias hidras, se elas se integram passa a existir a Confederação das Hidras Unidas.

    +
    • +
  • +

    Importante questão do licenciamento: AGPL 3.0 para garantir o máximo possível da disponibilização de código e documentação.

    +
    • +
  • +

    Não é estritamente necessária a criação de uma “confederação”, já que a cultura de hidras pode ser não-coordenada.

    +
    • +
+ + +
+
+

Parte 7: Nuvens e Hidras

Hidras são nuvens (cloud computing)?

+ +
    +
  • +

    Cloud computing foca apenas nas instâncias e como estas são integradas por aplicações (IaaS, SaaS, PaaS) e no seu uso sob demanda.

    +
    • +
  • +

    Cloud computing é uma iniciativa do mercado e uma tendência à terceirização total das atividades.

    +
    • +
  • +

    A Hidra leva em consideração a organização social que suporta a infraestrutura computacional.

    +
    • +
  • +

    A Hidra é uma nuvem na qual certos nodos desempenham papéis determinados, porém contendo o germe de toda a organização.

    +
    • +
  • +

    Outra classe de nuvens: botnets.

    +
    • +
+ + +
+
+

Nuvens: diagramas

Camadas +Arquitetura

+ + +
+
+

Tipos de nuvens

+

Tipos de nuvens

+
+ + +
+
+

Parte 8: Futuro

    +
  • Hidra Saraventa: ainda em intenso desenvolvimento, porém já em estágio maduro. Falta (em agosto/2010): +
      +
    • Melhoria no procedimento de bootstrap.
      • +
    • Integração com DNS.
      • +
    • Sistema de proxy para balanceamento de carga.
      • +
    • Melhoria de procedimentos de sunsetting de sítios, plataformas e contas.
      • +
    • Longuíssimo prazo, caso realizável: possibilidade de um nodo ser convertido de uma classe para outra.
      • +
    • Procedimentos para suporte jurídico.
      • +
    • Nodos em conexões DSL e cabo: IP dinâmico, DNS reverso, etc.
      • +
    • VPN entre os nodos, Puppet Dashboard?, External node tool?
      • +
    • Migrar para Linux Containers (lxc).
      • +
    • Melhoria da documentação e representações gráficas do processo.
      • +
    • Storage de dados distribuído.
      • +
    +
    • +
  • Hidras via Rádio.
    • +
  • Hidras em outros tipos de organizações sociais.
    • +
+ + +
+
+

Parte 9: Conclusões

    +
  • +

    Resolver a replicação e escalabilidade primeiro na infraestrutura (máquinas, configurações e backups), depois nas camadas superiores (CMSs, por exemplo)

    +
    • +
  • +

    Não importa tanto se a rede é centralizada, descentralizada ou distribuída se antes de tudo ela for regenerativa. No entanto, em geral são as redes distribuídas e descentralizadas que possuem fatores de regeneração maiores do que no caso centralizado.

    +
    • +
  • +

    Número grande de máquinas é interessante: várias podem estar sem funcionar num dado momento, mas as que estiverem funcionando podem dar conta da demanda.

    +
    • +
  • +

    A hidra é indestrutível? Essa questão faz sentido? Positivismo, revoluções e cataclismas: o limite da hidra por ter uma relação e abertura e fechamento (autonomia dependente).

    +
    • +
+ + +
+
+

Parte 10: Referências

+
+

Referências: imagens usadas

+
+ + +
+ + \ No newline at end of file -- cgit v1.2.3