A Catedral e o Bazar - Cypherpunks Brasil\nFeb 8, 2002 50 min read Eric S. RaymondLinuxSoftwareCódigo aberto\nVersão 3.0 – 2 de agosto de 2002 (Originalmente publicado em 2000)\nEu analiso um projeto bem sucedido de código livre, o Fetchmail, que foi executado como um teste deliberado de algumas teorias surpreendentes sobre a tecnologia de programação sugerida pela história do Linux. Eu discuto estas teorias nos termos de dois estilos fundamentais diferentes de desenvolvimento, o modelo “catedral” da maior parte do mundo comercial contra o modelo “bazar” do mundo do Linux. Eu mostro que estes modelos derivam de suposições opostas sobre a natureza da tarefa de depurar o software. Eu faço então um argumento sustentado na experiência do Linux para a proposição que “Dados bastante olhos, todos os erros são triviais”, sugiro analogias produtivas com outros sistemas auto-corrigíveis de agentes egoístas, e concluo com alguma exploração das implicações desta introspeção para o futuro do software.\n1. A Catedral e o Bazar\nLinux é subversivo. Quem pensaria mesmo há cinco anos atrás que um sistema operacional de classe mundial poderia surgir como que por mágica pelo tempo livre de milhares de colaboradores espalhados por todo o planeta, conectado somente pelos tênues cordões da Internet?\nCertamente não eu. No tempo que o Linux apareceu em minha tela-radar no início de 1993, eu já tinha me envolvido no desenvolvimento de Unix e de código aberto por dez anos. Eu fui um dos primeiros contribuintes para o projeto GNU nos meados de 1980. Eu tinha liberado bastante do software livre na rede, desenvolvendo ou co-desenvolvendo diversos programas (nethack, Emacs em modo VC e GUD, xlife, e outros) que estão ainda em largo uso hoje. Eu pensei que eu sabia como isso era feito.\nO Linux ultrapassou muito o que eu pensei que sabia. Eu estava pregando o modo Unix de uso de pequenas ferramentas, de prototipagem rápida e de programação evolucionária por anos. Mas eu acreditei também que havia alguma complexidade crítica, acima da qual uma aproximação mais centralizada, mais a priori era requerida. Eu acreditava que os softwares mais importantes (sistemas operacionais e ferramentas realmente grandes como Emacs) necessitavam ser construídos como as catedrais, habilmente criados com cuidado por mágicos ou pequenos grupos de magos trabalhando em esplêndido isolamento, com nenhum beta para ser liberado antes de seu tempo.\nO estilo de Linus Torvalds de desenvolvimento – libere cedo e freqüentemente, delegue tudo que você possa, esteja aberto ao ponto da promiscuidade – veio como uma surpresa. Nenhuma catedral calma e respeitosa aqui – ao invés, a comunidade Linux pareceu assemelhar-se a um grande e barulhento bazar de diferentes agendas e aproximações (adequadamente simbolizada pelos repositórios do Linux, que aceitaria submissões de qualquer pessoa) de onde um sistema coerente e estável poderia aparentemente emergir somente por uma sucessão de milagres.\nO fato de que este estilo bazar pareceu funcionar, e funcionar bem, veio como um distinto choque. Conforme eu aprendia ao meu redor, trabalhei duramente não apenas em projetos individuais, mas também tentando compreender porque o mundo do Linux não somente não se dividiu em confusão mas parecia aumentar a sua força a uma velocidade quase inacreditável para os construtores de catedrais.\nEm meados de 1996 eu pensei que eu estava começando a compreender. O acaso deu-me uma maneira perfeita para testar minha teoria, na forma de um projeto de código aberto que eu poderia conscientemente tentar executar no estilo bazar. Assim eu fiz – e foi um sucesso significativo.\nNo resto deste artigo eu contarei a história desse projeto, e eu irei usá-la para propor alguns aforismos sobre o desenvolvimento eficaz de código aberto. Nem tudo eu aprendi primeiramente no mundo do Linux, mas nós veremos como o mundo do Linux lhe dá um ponto particular. Se eu estiver correto, eles o ajudarão a compreender exatamente o que é que faz a comunidade do Linux ser uma fonte de software bom – e ajuda a você a se tornar mais produtivo.\n2. O correio deve ser entregue\nDesde 1993 eu venho cuidando da parte técnica de um pequeno Provedor de Acesso Internet de acesso gratuito chamado Chester County InterLink (CCIL) em West Chester, Pensilvânia (eu fui co- fundador do CCIL e escrevi nosso software multiusuário de BBS – você pode observá-lo executando um telnet para locke.ccil.org. Hoje suporta quase três mil usuários em trinta linhas.) O trabalho permitiu-me o acesso 24 horas por dia à rede através da linha de 56K do CCIL – de fato, praticamente exigiu!\nConsequentemente, eu fiquei acostumado a acesso instantâneo ao correio Internet. Por razões complicadas, era difícil fazer o SLIP funcionar entre minha máquina de casa (snark.thyrsus.com) e o CCIL. Quando eu finalmente consegui, eu achei incômodo ter que executar telnet periodicamente para o locke para verificar meu correio. O que eu queria era que ele fosse enviado para o snark de modo que eu fosse notificado quando uma mensagem chegasse e pudesse manuseá-lo usando todas as minhas ferramentas locais.\nO simples reenvio do sendmail não funcionaria, porque minha máquina local não está sempre na rede e não tem um IP estático. O que eu precisava era um programa que pegasse meu correio através da conexão SLIP e o entregasse localmente. Eu sabia que tais programas existiam, e que a maioria deles usava um protocolo de aplicação simples chamado POP (Post Office Protocol). E, realmente, já havia um servidor POP3 incluído com sistema operacional BSD/OS do locke.\nEu precisava de um cliente POP3. Então eu procurei na Internet e encontrei um. Na verdade, eu encontrei três ou quatro. Eu usei o pop-perl por algum tempo, mas faltava o que parecia uma característica óbvia, a habilidade de alterar os endereços no correio recebido para que as respostas fossem enviadas corretamente.\nO problema era este: suponha que alguém chamado joe no locke tenha me enviado uma mensagem. Se eu capturasse o correio para o snark e tentasse então lhe responder, meu programa de correio tentaria alegremente enviá-lo a um joe inexistente no snark. Editar manualmente os endereços de resposta para adicionar ‘@ccil.org’ rapidamente tornou-se um tormento.\nIsto era claramente algo que o computador teria que fazer para mim. Mas nenhum dos clientes POP existentes sabiam como! E isto nos traz à primeira lição:\n1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador.\nTalvez isto deveria ter sido óbvio (um antigo provérbio diz que “necessidade é a mãe da invenção”) mas muitas vezes os programadores gastam seus dias buscando retorno em programas que eles não necessitam nem gostam. Mas não no mundo do Linux – o que pode explicar porque a qualidade média do software originada na comunidade de Linux é tão alta.\nAssim, eu me lancei imediatamente com o ímpeto de codificar um novo cliente POP3 para competir com os existentes? De maneira alguma! Eu olhei com cuidado os utilitários POP que eu tinha à disposição, perguntando-me “qual deles é o mais próximo do que eu quero?”. Porque…\n2. Os programadores bons sabem o que escrever. O grandes sabem o que re-escrever (e reusar).\nEmbora eu não me considere um grande programador, eu tento me passar por um. Uma importante característica dos grandes é a preguiça construtiva. Eles sabem que você ganha um ‘A’ não por esforço, mas por resultados, e é quase sempre mais fácil partir de uma boa solução parcial do que do nada.\nLinus Torvalds, por exemplo, não tentou realmente escrever Linux do nada. Ao contrário, ele começou re-usando código e idéias do Minix, um pequeno sistema operacional Unix-like para máquinas 386. Eventualmente todo o código Minix se foi ou não completamente rescrito – mas quando estava lá, forneceu as bases para o infante que se transformaria no Linux.\nCom o mesmo pensamento, eu fui procurar um utilitário POP que fosse razoavelmente bem codificado, para usar como uma base de desenvolvimento.\nA tradição do mundo Unix de compartilhar o código fonte foi sempre amigável para a reutilização de código (esta é a razão porque o projeto de GNU escolheu o Unix como sistema operacional base, apesar das sérias reservas sobre o mesmo). O mundo Linux tem levado esta tradição quase a seu limite tecnológico; tem terabytes de códigos abertos amplamente disponíveis. Assim gastando tempo procurando algum software quase-bom-o-bastante feito por alguém é mais provável dar a você mais bons resultados no mundo Linux do que em qualquer outro lugar.\nE fez para mim. Com aqueles que eu achei antes, minha segunda busca compôs um total de nove candidatos – fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail e upop. O primeiro que eu trabalhei primeiramente era o ‘fetchpop ’ por Seung-Hong Oh. Eu pus o meu código de reescrita de cabeçalho nele, e fiz várias outras melhorias que o autor aceitou em sua versão 1.9.\nAlgumas semanas mais tarde, entretanto, eu tropecei pelo código do ‘popclient’ desenvolvido por Carl Harris, e descobri que eu tinha um problema. Embora o fetchpop tenha tido algumas idéias boas e originais (tal como o modo daemon), podia somente trabalhar com POP3 e foi codificado de uma maneira um tanto amadora (Seung-Hong era um programador brilhante porém inexperiente, e ambas as características ficaram evidentes). O código de Carl era melhor, bastante profissional e sólido, mas em seu programa faltou diversas características importantes e complicadas de serem implementadas do fetchpop (incluindo aquelas que eu implementei).\nFicar ou trocar? Se eu trocasse, eu estaria jogando fora o código que eu já havia feito em troca de uma base melhor do desenvolvimento.\nUm motivo prático para trocar era a presença de suporte para vários protocolos. POP3 é o protocolo mais comumente utilizado de todos os protocolos de correio dos servidores, mas não o único. Fetchpop e os outros concorrentes não faziam POP2, RPOP ou APOP, e eu estava realmente tendo alguns pensamentos de talvez adicionar ou Protocolo de Acesso a Mensagem da Internet, o mais recente e poderoso protocolo de correio desenvolvido) só para me divertir.\nMas eu tinha uma razão mais teórica para pensar que trocar seria uma boa idéia, alguma coisa que eu aprendi muito antes do Linux.\n3. “Planeje jogar algo fora; você irá, de qualquer maneira.” (Fred Brooks, “The Mythical Man-Month”, Capítulo 11)\nOu, colocando de outra forma, você freqüentemente não entende realmente o problema até depois da primeira vez que você implementa uma solução. Na segunda vez, talvez você saiba o suficiente para fazer corretamente. Então se você quer fazer algo certo, esteja preparado para começar tudo novamente pelo menos uma vez.\nBem (eu disse para mim mesmo) as mudanças no fetchpop foram a minha primeira tentativa. Então eu troquei.\nDepois que eu mandei meu primeiro conjunto de alterações para Carl Harris em 25 de junho de 1996, eu percebi que na verdade ele perdera o interesse pelo popclient há algum tempo até então. O código era um pouco empoeirado, com pequenos erros. Eu tinha muitas mudanças para fazer, e nós rapidamente concordamos que o lógico para eu fazer era tomar conta do programa.\nSem perceber, o projeto havia se intensificado. Eu não estava mais contemplando somente pequenos consertos para um cliente POP existente. Eu estava mantendo um cliente completo, e havia idéias borbulhando na minha cabeça que eu sabia iriam provavelmente levar a importantes mudanças. Em uma cultura de software que encoraja a troca de código, isto é um caminho natural para um projeto evoluir. Eu estava representando isto:\n4. Se você tem a atitude certa, problemas interessantes irão encontrá-lo.\nMas a atitude do Carl Harris foi ainda mais importante. Ele entendeu que\n5. Quando você perde interesse em um programa, sua última obrigação a fazer com ele é entregá-lo a um sucessor competente.\nSem ao menos ter que discutir isso, Carl e eu sabíamos que nós tínhamos um objetivo em comum de ter a melhor solução disponível. A única questão para nós foi se eu poderia me estabelecer como um par de mãos seguras para isso. Uma vez que eu tenha feito isso, ele agiu com cortesia e rapidez. Eu espero que eu aja assim quando chegar a minha vez.\n3. A importância de ter usuários\nE então eu herdei o popclient. Tão importante quanto, eu herdei os usuários do popclient. Usuários são ótimas coisas para se ter, e não somente porque eles demonstram que você está satisfazendo uma necessidade, que você fez algo certo. Cultivados de maneira adequada, eles podem se tornar co-desenvolvedores.\nOutra força da tradição do Unix, uma que o Linux tem levado a um alegre extremo, é que muitos usuários são desenvolvedores também. E porque o código fonte está disponível, eles podem ser desenvolvedores eficazes. Isto pode ser tremendamente útil para reduzir o tempo de depuração. Com um pouco de estímulo, seus usuários irão diagnosticar problemas, sugerir correções e ajudar a melhorar o código muito mais rapidamente do que você poderia fazer sem ajuda.\n6. Tratar seus usuários como co-desenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz.\nO poder deste efeito é fácil de se subestimar. De fato, todos nós do mundo do código aberto subestimamos drasticamente como isto iria incrementar o número de usuários e diminuir a complexidade do sistema, até que Linus Torvalds nos mostrou de outra forma.\nDe fato, eu penso que a engenhosidade do Linus e a maior parte do que desenvolveu não foram a construção do kernel do Linux em si, mas sim a sua invenção do modelo de desenvolvimento do Linux. Quando eu expressei esta opinião na sua presença uma vez, ele sorriu e calmamente repetiu algo que freqüentemente diz: “Sou basicamente uma pessoa muito preguiçosa que gosta de ganhar crédito por coisas que outras pessoas realmente fazem.” Prequiçoso como uma raposa. Ou, como Robert Heinlein teria dito, muito preguiçoso para falhar.\nEm retrospecto, um precedente para o sucesso e métodos do Linux pode ser observado no desenvolvimento da biblioteca do GNU Emacs Lisp e os repositórios de código Lisp. Em contraste com o estilo de desenvolvimento catedral do núcleo do Emacs C e a maioria das outras ferramentas da FSF, a evolução do grupo de código Lisp foi fluída e bastante dirigida ao usuário. Idéias e protótipos foram freqüentemente re-escritos três ou quatro vezes antes de atingirem uma forma estável final. E colaborações permitidas pela Internet, a la Linux, foram freqüentes.\nRealmente, minha mais bem sucedida codificação anterior ao fetchmail foi provavelmente o modo Emacs VC, uma colaboração do tipo do Linux por email com três outras pessoas, somente uma das eu conheci pessoalmente até hoje. Foi um front-end para SCCS, RCS e posteriormente CVS pelo Emacs que oferecia operações de controle de versão “um toque”. Evoluiu de um pequeno e grosseiro modo sccs.el que alguém havia escrito. E o desenvolvimento do VC foi bem sucedido porque, ao contrário do próprio Emacs, o código do Emacs Lisp poderia ir por gerações de lançamento/teste/aperfeiçoamento muito rapidamente.\n4.Libere cedo, libere freqüentemente\nLiberações novas e freqüentes são uma parte crítica do modelo de desenvolvimento do Linux.\nA maioria dos desenvolvedores (incluindo eu) costumava acreditar que esta era uma má política para projetos maiores que os triviais, porque versões novas são quase por definição cheias de erros e você não quer acabar com a paciência dos seus usuários.\nEsta crença reforçou o compromisso de todos com o estilo de desenvolvimento catedral. Se o principal objetivo era o de usuários verem menos erros quanto possível, por que então você iria somente lançar um em cada seis meses (ou freqüentemente menos), e trabalhar como um cachorro depurando entre as liberações. O núcleo do Emacs C foi desenvolvido desta forma. A biblioteca Lisp, de fato, não foi – porque havia repositórios Lisp ativos fora do controle da FSF, aonde você poderia ir para achar versões novas e em desenvolvimento, independentemente do ciclo de liberação do Emacs.\nA mais importante destas, o repositório elisp do Estado de Ohio, antecipou o espírito e muitas das características dos atuais grandes repositório de Linux. Mas pouco de nós realmente pensou muito sobre o que estávamos fazendo, ou sobre o que a existência deste repositório sugeriu sobre problemas no modelo de desenvolvimento catedral da FSF. Eu fiz uma séria tentativa por volta de 1992 para ter bastante código de Ohio formalmente fundido na biblioteca oficial do Emacs Lisp. Encontrei problemas políticos e fui muito mal sucedido.\nMas um ano depois, visto que o Linux se tornou amplamente conhecido, ficou claro que alguma coisa diferente e muito saudável estava acontecendo. A política de desenvolvimento aberta do Linus era exatamente o oposto do modelo de desenvolvimento catedral. Os repositórios sunsite e tsx-11 estavam germinando, múltiplas distribuições estavam surgindo. E tudo isto foi guiado por uma freqüência desconhecida de liberações de núcleo de sistemas.\nLinus estava tratando seus usuários como co-desenvolvedores na maneira mais eficaz possível:\n7. Libere cedo. Libere freqüentemente. E ouça seus fregueses.\nIsso não era muito a inovação do Linus (algo como isso estava sendo a tradição do mundo Unix por um longo tempo), mas em elevar isto até um grau de intensidade que alcançava a complexidade do que ele estava desenvolvendo. Nestes primórdios tempos (por volta de 1991) não era estranho para ele liberar um novo kernel mais de uma vez por dia! E, porque ele cultivava sua base de co-desenvolvedores e incitava fortemente a Internet por colaboração como nenhum outro, isto funcionou.\nMas como isto funcionou? E era isto algo que eu poderia duplicar, ou era algo que dependia da genialidade única de Linus Torvalds?\nEu não pensei assim. Reconhecidamente, Linus é um excelente desenvolvedor (quantos de nós poderia planejar um kernel completo de um sistema operacional de qualidade de produção?). Mas o Linux não representou nenhum salto conceitual impressionante a frente. Linus não é (ou pelo menos, ainda não) um gênio inovativo de projeto do estilo que, por exemplo, Richard Stallman ou James Gosling (do NeWS e Java) são. Ao contrário, para mim Linus parece ser um gênio da engenharia, com um sexto sentido em evitar erros e desenvolvimentos que levem a um beco sem saída e uma verdadeira habilidade para achar o caminho do menor esforço do ponto A ao ponto B. De fato, todo o projeto do Linux exala esta qualidade e espelha a abordagem conservadora e simplificada de planejamento do Linus.\nEntão, se liberações rápidas e influenciar a Internet a todo custo não foram acidentes mas partes integrantes da perspicácia do gênio de engenharia do Linus para o caminho do menor esforço, o que ele estava enfatizando? O que ele estava maquinando?\nPosto desta forma, a questão responde a si mesma. Linus estava mantendo seus usuários/desenvolvedores constantemente estimulados e recompensados – estimulados pela perspectiva de estar tendo um pouco de ação satisfatória do ego, recompensados pela visão do constante (até mesmo diário) melhoramento do seu trabalho.\nLinus estava diretamente direcionado a maximizar o número de pessoas-hora dedicadas a depuração e ao desenvolvimento, mesmo com o possível custo da instabilidade no código e extinção da base de usuários se qualquer erro sério provasse ser intratável. Linus estava se comportando como se acreditasse em algo como isto:\n8. Dada uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém.\nOu, menos formalmente, “Dados olhos suficientes, todos os erros são triviais.” Eu chamo isso de: “Lei de Linus”.\nMinha formulação original foi que todo problema “será transparente para alguém”. Linus objetou que a pessoa que entende e conserta o problema não é necessariamente ou mesmo freqüentemente a pessoa que primeiro o caracterizou. “Alguém acha o problema,” ele diz, “e uma outra pessoa o entende. E eu deixo registrado que achar isto é o grande desafio.” Mas o ponto é que ambas as coisas tendem a acontecer rapidamente.\nAqui, eu penso, é o centro da diferença fundamental entre os estilos bazar e catedral. Na visão catedral de programação, erros e problemas de desenvolvimento são difíceis, insidiosos, um fenômeno profundo. Leva meses de exame minucioso por poucas pessoas dedicadas para desenvolver confiança de que você se livrou de todos eles. Por conseguinte os longos intervalos de liberação, e o inevitável desapontamento quando as liberações por tanto tempo esperadas não são perfeitas.\nNa visão bazar, por outro lado, você assume que erros são geralmente um fenômeno trivial – ou, pelo menos, eles se tornam triviais muito rapidamente quando expostos para centenas de ávidos co-desenvolvedores triturando cada nova liberação. Consequentemente você libera freqüentemente para ter mais correções, e como um benéfico efeito colateral você tem menos a perder se um erro ocasional aparece.\nE é isto. É o suficiente. Se a “Lei de Linus” é falsa, então qualquer sistema tão complexo como o kernel do Linux, sendo programado por tantas mãos quantas programam o kernel do Linux, deveria a um certo ponto tido um colapso sob o peso de interações imprevisíveis e erros “profundos” não descobertos. Se isto é verdade, por outro lado, é suficiente para explicar a relativa falta de erros do Linux.\nE talvez isso não deveria ser uma surpresa, mesmo assim. Anos atrás, sociologistas descobriram que a opinião média de uma massa de observadores especialistas (ou igualmente ignorantes) é um indicador mais seguro que o de um único observador escolhido aleatoriamente. Eles chamaram isso de o “efeito Delphi”. Parece que o que o Linus tem mostrado é que isto se aplica até mesmo para depurar um sistema operacional – que o efeito Delphi pode suavizar a complexidade do desenvolvimento até mesmo em nível de complexidade do kernel de um sistema operacional.\nEu sou grato a Jeff Dutky por apontar que a lei de Linus pode ser refeita como “Depurar é paralelizável”. Jeff observa que embora depurar requer que depuradores se comuniquem com algum desenvolvedor coordenador, não requer coordenação significante entre depuradores. Assim não cai vítima para a mesma complexidade quadrática e custos de gerência que faz ser problemático adicionar desenvolvedores.\nNa prática, a perda teórica de eficiência devido a duplicação de trabalho por depuradores quase nunca parece ser um problema no mundo do Linux. Um efeito da ``política libere cedo e freqüentemente" é minimizar esta duplicação propagando consertos rapidamente.\nBrooks até mesmo fez uma observação improvisada relacionada à observação de Jeff: “O custo total de manter um programa amplamente utilizado é tipicamente 40 porcento ou mais o custo de desenvolvê-lo. Surpreendentemente este custo é muito afetado pelo número de usuários. “Mais usuários acham mais erros”. (minha ênfase).\nMais usuários acham mais erros porque adicionar mais usuários adiciona mais maneiras diferentes de testar o programa. Este efeito é amplificado quando os usuários são co- desenvolvedores. Cada um aborda a tarefa de caracterização de erro com um conjunto perceptivo ligeiramente diferente e ferramenta analítica, um ângulo diferente do problema. O “efeito Delphi” parece funcionar precisamente por causa desta variação. No contexto específico da depuração, a variação também tende a reduzir o feito da duplicação.\nEntão adicionar mais beta-testers pode não reduzir a complexidade de um erro “profundo” corrente do ponto de vista do desenvolvedor, mas aumenta a probabilidade que a ferramenta de alguém irá de encontro ao problema de uma maneira tal que o problema será trivial para esta pessoa.\nLinus cobre suas apostas. Caso haja erros sérios, as versões do kernel do Linux são numeradas de forma que usuários em potencial podem fazer a escolha de executar a última versão designada “estável” ou correr o risco de encontrar erros para obter novas características. Esta técnica não é ainda formalmente imitada pela maioria dos desenvolvedores usuários do Linux, mas talvez devesse; o fato de que ambas as escolhas estejam disponíveis faz delas mais atraentes.\n5. Quando uma rosa não é uma rosa\nTendo estudado o comportamento do Linus e formado uma teoria sobre como ele foi bem sucedido, eu fiz uma decisão consciente para testar esta teoria em meu novo (reconhecidamente muito menos complexo e ambicioso) projeto.\nMas a primeira coisa que eu fiz foi reorganizar e simplificar bastante o popclient. A implementação do Carl Harris era muito atrativa, mas exibia um tipo de complexidade desnecessária comum a vários programadores em C. Ele tratou o código como centro das atenções e as estruturas de dados como suporte para o código. Como resultado, o código era muito bonito mas o projeto da estrutura de dados era ad-hoc e um tanto feio (pelo menos pelos altos padrões deste velho desenvolvedor de LISP).\nEu tinha outro propósito para re-escrever além de aperfeiçoar o código e o projeto da estrutura de dados, entretanto. Era evoluí-lo para algo que eu entenderia completamente. Não é nada agradável ser responsável por consertar erros em um programa que você não entende.\nMais ou menos durante o primeiro mês, então, eu estava simplesmente seguindo as implicações do projeto básico do Carl. A primeira mudança séria que fiz foi adicionar suporte ao IMAP. Eu fiz isso reorganizando as rotinas de protocolos em um driver genérico e três tabelas de métodos (para POP2, POP3 e IMAP). Esta e as mudanças anteriores ilustram o princípio geral que é bom para os programadores manterem em mente, especialmente em linguagens como C que não implementam naturalmente tipagem dinâmica:\n9. Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário.\nBrooks, Capítulo 11: “Mostre-me seu código e esconda suas estruturas de dados, e eu poderei continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente não necessitarei do seu código; ele será óbvio."\nDe fato, ele disse “gráficos” e “tabelas”. Mas considerando trinta anos de terminologias/mudanças culturais, é praticamente o mesmo ponto.\nNeste ponto (quase Setembro de 1996, mais ou menos seis semanas desde o início) eu comecei a pensar que uma mudança de nome deveria ser adequada – afinal de contas, não era mais somente um cliente POP. Mas eu hesitei, porque ainda não havia ainda nada genuinamente novo ainda no projeto. Minha versão do popclient ainda teria que desenvolver uma identidade própria.\nIsto mudou, radicalmente, quando o fetchmail aprendeu como reenviar mensagens recebidas para a porta SMTP. Eu irei a este ponto em um momento. Mas primeiro: Eu disse acima que eu decidi usar este projeto para testar minha teoria sobre o que Linus Torvalds fez corretamente. Como (você pode perguntar) eu fiz isto? Desta forma:\n1. Eu liberei cedo e freqüentemente (quase nunca menos que uma vez a cada dez dias; durante períodos de desenvolvimento intenso, uma vez por dia).\n2.Eu aumentei minha lista de beta testers adicionando a ela todo mundo que me contatava sobre o fetchmail.\n3.Eu mandei extensos anúncios à lista de beta testers toda vez que eu liberava, encorajando as pessoas a participar.\n4. E eu ouvia meus beta testers, questionando-os sobre decisões de desenvolvimento e incitando-os toda vez que eles mandavam consertos e respostas.\nO retorno destas medidas simples foi imediato. Desde o início do projeto, eu obtive relatórios sobre erros de uma qualidade que a maioria dos desenvolvedores morreria para ter, muitas vezes com ótimos consertos incluídos. Eu obtive críticas severas, obtive mensagens de fãs, obtive sugestões inteligentes de características. O que leva a:\n10. Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso.\nUma medida interessante do sucesso do fetchmail é o simples tamanho da lista de beta testers, amigos do fetchmail. Ao escrever este texto ela possuía 249 membros e são adicionados dois ou três por semana.\nDe fato, conforme eu reviso ao final de Maio de 1997, a lista está começando a perder membros depois do pico de aproximadamente 300 pessoas por uma razão interessante. Muitas pessoas têm me pedido para excluí-las da lista porque o fetchmail está trabalhando tão bem para elas que elas não precisam mais ver o tráfego da lista! Talvez isto seja parte do ciclo de vida normal de um projeto maduro do estilo bazar.\n6. Popclient transforma-se em Fetchmail\nPor muitas semanas eu fiquei customizando o fetchmail de maneira incremental enquanto percebia como o projeto de interface estava aproveitável mas feio – não estava elegante e com muitas pequenas opções por toda parte. As opções para extrair mensagens coletadas para um arquivo de mensagens ou saída padrão particularmente me aborreciam, mas eu não conseguia descobrir por que.\nHá várias lições aqui. Primeira, esta idéia de reenvio por SMTP foi o primeiro grande retorno que eu obtive por tentar conscientemente emular os métodos do Linus. Um usuário me deu esta idéia brilhante – tudo que eu tive que fazer foi entender as implicações.\n**11. A melhor coisa depois de ter boas idéias é reconhecer boas idéias dos seus usuários. **As vezes a última é melhor.\n(Quando eu mostrei este documento na conferência de Perl em Agosto de 1997, Larry Wall estava na primeira fila. Quando eu li a última linha acima ele gritou fervorosamente, em um estilo religioso nostálgico, “Diga, diga, irmão!”. Toda a audiência riu, porque eles sabiam que isso também funcionou para o criador do Perl.)\nQuando você atinge uma parede ao desenvolver – quando você dificilmente se encontra pensando em algo depois do próximo patch – é freqüentemente tempo para perguntar não se você tem a resposta certa, mas se você está perguntando a pergunta correta. Talvez o problema precise ser reformulado.\nMas quando eu a fiz, os benefícios provaram-se altos. As partes obscuras do código do driver sumiram. A configuração ficou radicalmente mais simples – não mais rastejar à volta atrás do MDA do sistema e da caixa de correio do usuário, não mais preocupações sobre se o sistema operacional suportava locking de arquivo.\n13. “A perfeição (em projetar) é alcançada não quando não há mais nada a adicionar, mas quando não há nada para jogar fora”.\n7. Fetchmail cresce\nLá estava eu com um projeto elegante e inovador, um código que eu sabia que funcionava bem porque eu usava todos os dias, e uma crescente lista de beta testers. E gradualmente eu percebia que eu não estava mais ocupado com uma trivial codificação pessoal que porventura poderia se tornar útil para algumas pessoas. Eu tinha em minhas mãos um programa que todos os usuários de um sistema Unix com uma conexão de correio SLIP/PPP realmente precisavam.\nCom a característica de reenvio por SMTP, ele passou muito à frente da competição para potencialmente se tornar um “category killer”, um destes programas clássicos que preenchem seu nicho tão completamente que as alternativas não são somente descartadas como também esquecidas.\nEu penso que você não pode realmente almejar ou planejar um resultado como este. Você tem que ser atraído para isso por idéias de projeto tão poderosas que posteriormente os resultados parecem inevitáveis, naturais, mesmo predestinados. A única maneira de tentar idéias como esta é tendo muitas idéias – ou tendo o julgamento de engenharia para levar as boas idéias das outras pessoas além do que estas que as tiveram pensariam que elas poderiam ir.\nAndrew Tanenbaum teve a idéia original de construir um Unix nativo simples para o 386, para uso como uma ferramenta de ensino. Linus Torvalds levou o conceito do Minix para além do que Andrew provavelmente pensou que poderia ir – e cresceu para algo maravilhoso. Da mesma forma (embora em uma menor escala), eu peguei algumas idéias de Carl Harris e Harry Hochheiser e dei um empurrão. Nenhum de nós foi ‘original’ no sentido romântico que as pessoas pensam é um gênio. Mas a maioria do desenvolvimento de software científico e de engenharia não é feita por um gênio original, a mitologia desenvolvedor ao contrário.\nOs resultados foram todos sempre muito precipitados – de fato, o tipo de sucesso que qualquer desenvolvedor está sempre procurando! E eles significaram que eu teria que definir meus padrões ainda mais altos. Para fazer o fetchmail tão bom como eu então achava que poderia se tornar, eu teria que escrever não somente para minhas próprias necessidades, mas também incluir e suportar características necessárias para outros fora do meu relacionamento. E fazer isto mantendo o programa simples e robusto.\nA primeira e mais importante esmagadora característica que eu escrevi depois de perceber isto foi o suporte a multidrop – a habilidade de capturar correio de caixas de correio que acumularam todas as mensagens para um grupo de usuários, e então destinar cada pedaço de correio para seus destinatários individuais.\nEu decidi adicionar o suporte ao multidrop em parte porque alguns usuários estavam pedindo por isto, mas principalmente porque eu pensei que isto iria retirar os erros do código para o envio simples me forçando a manipular o endereçamento de um modo geral. E assim se provou 822 me tomou um tempo consideravelmente longo, não porque qualquer pedaço dele é difícil mas porque envolvia uma pilha de detalhes interdependentes e elaborados.\nMas o endereçamento multidrop se tornou uma decisão de projeto excelente. Aqui está como eu soube:\n**14. Qualquer ferramenta deve ser útil da maneira esperada, mas uma ferramenta verdadeiramente **boa leva ela própria a usos que você nunca esperou.\nO uso inesperado para o multidrop do fetchmail é executar mailing lists com a lista mantida, e expansão de apelidos feita, no lado do cliente da conexão SLIP/PPP. Isto significa que alguém executando uma máquina pessoal por uma conta ISP pode administrar uma mailing list sem acesso contínuo aos arquivos de apelidos do ISP\nOutra importante mudança solicitada pelos meus beta testers foi suporte para operação MIME 8-bit. Isto foi muito fácil de fazer, porque eu estava sendo cuidadoso mantendo o código pronto para 8-bit. Não porque eu antecipei a demanda para esta característica, mas em obediência a outra regra:\n**15. Quando escrevendo um software gateway de qualquer tipo, faça tudo para perturbar o conjunto de dados o menos possível – e nunca jogue fora informação a não ser que o **destinatário force você a isto!\nSe eu não tivesse obedecido esta regra, o suporte a MIME 8- bit teria sido difícil e cheio de erros. Como estava, tudo o que tive 1652 e adicionar um pouco de lógica trivial para a geração de cabeçalho.\nAlguns usuários Europeus insistiram para que eu adicionasse uma opção para limitar o número de mensagens recebidas por seção (de maneira que eles poderiam controlar custos das suas caras redes de telefone). Eu resisti por um longo tempo, e ainda não estou inteiramente alegre sobre isto. Mas se você está escrevendo para o mundo, você tem que ouvir os seus clientes – isto não muda somente porque eles não estão pagando dinheiro a você.\n8. Algumas lições a mais do Fetchmail\nAntes de voltarmos ao assunto de engenharia de software em geral, existem algumas lições a mais da experiência do fetchmail para ponderar.\nA sintaxe do arquivo rc inclui palavra-chaves ‘ruidosas’ opcionais que são inteiramente ignoradas pelo analisador. A sintaxe parecida com o Inglês que elas permitem é consideravelmente mais inteligível que os concisos pares tradicionais palavra-chave-valor que você obtém quando as retira.\nEstas começaram como um experimento posterior quando eu percebi como as declarações do arquivo rc estava começando a lembrar uma mini-linguagem imperativa. (É por isto também que eu mudei a palavra-chave original ‘server’ do popclient para ‘poll’).\nParecia para mim que tentar fazer esta mini-linguagem imperativa parecer mais como o Inglês poderia torná-la mais fácil de ser usada. Agora, embora eu seja um convencido adepto da escola de projeto “faça isso uma linguagem” como exemplificado pelo Emacs e HTML e muitos sistemas de banco de dados, eu normalmente não sou um grande fã das sintaxes “English-like”.\nProgramadores tradicionais tendem a serem a favor de sintaxes de controle que são muito precisas e compactas e não contém redundância alguma. Isto é um legado cultural de quando os recursos computacionais eram caros, então os estágios de análise tinham que ser tão baratos e simples quanto possíveis. O Inglês, com redundância de aproximadamente 50%, parecia ser um modelo muito impróprio.\nEsta não é minha razão para normalmente evitar sintaxes no estilo do Inglês; eu menciono isto aqui somente para arrasá-la. Com ciclos e núcleos baratos, concisão não deve ser ela mesma um fim. Hoje em dia é mais importante para uma linguagem ser conveniente para humanos do que ser barata para o computador.\nHá, entretanto, boas razões para ser cauteloso. Uma é o custo da complexidade do estágio de análise – você não quer aumentá-lo ao ponto onde é uma fonte significativa de erros e confusão de usuários. Outra é que tentar fazer a sintaxe de uma linguagem English-like freqüentemente demanda que o “Inglês” que é falado seja seriamente propenso a ser fora de forma, tanto como a semelhança superficial com a linguagem natural é tão confusa como a sintaxe tradicional seria. (Você vê isso em várias linguagens chamadas de “quarta geração” e em linguagens de consulta de banco de dados comerciais.)\nA sintaxe de controle do fetchmail parece evitar estes problemas porque o domínio da linguagem é extremamente restrito. Não é perto de uma linguagem de uso geral; as coisas que ela diz simplesmente não são muito complicadas, então há pouco potencial para confusão em mover mentalmente entre um pequeno conjunto do Inglês e a real linguagem de controle. Eu acho que há uma lição mais abrangente aqui:\n16. Quando sua linguagem não está perto de um Turing completo, açúcar sintático pode ser seu amigo.\nOutra lição é sobre segurança por obscuridade. Alguns usuários do fetchmail me pediram para mudar o software para guardar as senhas encriptadas no arquivo rc, de maneira que bisbilhoteiros não poderiam casualmente vê-las.\nEu não fiz isso, porque isto não adiciona realmente proteção. Qualquer pessoa que adquira permissões para ler seu arquivo rc poderá executar o fetchmail como você de qualquer maneira – e se é a sua senha o que eles procuram, poderiam retirar o decodificador do próprio fetchmail para consegui-la.\nTudo o que a encriptação de senha do arquivo .fetchmailrc faria seria dar a falsa impressão de segurança para pessoas que não pensaram bem sobre este assunto. Aqui a regra geral é:\n17. Um sistema de segurança é tão seguro quanto é secreto. Esteja atento a pseudo-segredos.\n9. Pré-condições necessárias para o estilo Bazar\nOs primeiros leitores e audiências para este documento seguidamente levantaram questões sobre as pré-condições para o desenvolvimento bem-sucedido do estilo bazar, incluindo as qualificações do líder do projeto e o estado do código ao tempo em que se torna público e começa a tentar construir uma comunidade de co-desenvolvedores.\nEstá claro que ninguém pode codificar desde o início no estilo bazar. Alguém pode testar, achar erros e aperfeiçoar no estilo bazar, mas seria muito difícil originar um projeto no estilo bazar. Linus não tentou isto. Eu também não. A sua comunidade nascente de desenvolvedores precisa ter algo executável e passível de testes para utilizar.\nQuando você começa a construção de uma comunidade, o que você precisa ter capacidade de apresentar é uma promessa plausível. Seu programa não precisa funcionar particularmente bem. Ele pode ser grosseiro, cheio de erros, incompleto, e pobremente documentado. O que não pode deixar de fazer é convencer co-desenvolvedores em potencial de que ele pode evoluir para algo realmente elegante em um futuro próximo.\nTanto o Linux quanto o fetchmail se tornaram públicos com projetos básicos fortes e atraentes. Muitas pessoas pensando sobre o modelo bazar como eu tenho apresentado têm corretamente considerado isto como crítico, então concluíram a partir disso que um alto grau de intuição e inteligência no líder do projeto é indispensável.\nMas Linus obteve seu plano do Unix. Eu obtive o meu inicialmente do ancestral do popclient (embora iria posteriormente mudar bastante, muito mais proporcionalmente falando do que mudou o Linux). Então é necessário realmente para o líder/coordenador de um empenho no estilo bazar ter um talento excepcional para planejamento, ou ele pode conseguir o mesmo efeito coordenando o talento de planejamento de outras pessoas?\nEu penso que não é crítico que o coordenador seja capaz de originar projetos de excepcional brilho, mas é absolutamente crítico que o coordenador seja capaz de reconhecer boas idéias de projetos de outras pessoas.\nTanto os projetos do Linux quanto o do fetchmail mostram evidências disso. Linus, não sendo (como previamente discutido) um planejador espetacularmente original, mostrou uma habilidade poderosa de reconhecer um bom projeto e integrá-lo no kernel do Linux. E eu já descrevi como a idéia de projeto mais poderosa do fetchmail (reenvio por SMTP) veio de outra pessoa.\nOs primeiros leitores deste documento me elogiaram sugerindo que eu sou propenso a subestimar a originalidade do planejamento de projetos no estilo bazar porque eu tenho muito disso em mim mesmo, e portanto suponho isto. Pode haver alguma verdade nisto; projetar (como oposto a codificar ou depurar) é certamente minha mais forte habilidade.\nMas o problema em ser inteligente e original no planejamento de software é que isto se torna um hábito – você começa reflexivamente a fazer coisas atraentes e complicadas quando você deveria mantê-las robustas e simples. Eu tive projetos que falharam porque eu cometi este erro, mas eu administrei para que não acontecesse o mesmo com o fetchmail.\nEntão eu acredito que o projeto do fetchmail foi um sucesso em parte porque eu impedi a minha tendência a ser engenhoso; isto vai contra (pelo menos) com o fato de a originalidade em projetar ser essencial para projetos bem-sucedidos no estilo bazar. E considere o Linux. Suponha que Linus Torvalds estivesse tentando levar a cabo inovações fundamentais no projeto de sistemas operacionais durante o desenvolvimento; pareceria que o kernel resultante seria tão estável e bem-sucedido como é?\nUm certo nível básico de habilidade de projetar e codificar é requerido, claro, mas eu suponho que praticamente qualquer um que pense seriamente em lançar um esforço no estilo bazar estará acima do mínimo necessário. O mercado interno da comunidade de software aberto, por reputação, exerce uma sutil pressão nas pessoas para que não lancem esforço de desenvolvimento que não sejam competentes para manter. Até agora isto parece ter funcionado muito bem.\nHá outro tipo de habilidade que não é normalmente associada com o desenvolvimento de software que eu penso é tão importante quanto a engenhosidade em planejar projetos no estilo bazar – e isto pode ser mais importante. Um coordenador ou líder de um projeto no estilo bazar deve ter boa habilidade de comunicação e relacionamento.\nIsto deve parecer óbvio. Para construir uma comunidade de desenvolvimento, você precisa atrair pessoas, fazer com que se interessem no que você está fazendo, e mantê-las alegres sobre a quantidade de trabalho que estão fazendo. O entusiasmo técnico constitui uma boa parte para atingir isto, mas está longe de ser toda história. A personalidade que você projeta também importa.\nNão é uma coincidência que Linus é um rapaz gentil que faz com que as pessoas gostem dele e que o ajudem. Não é uma coincidência que eu seja um enérgico extrovertido que gosta de trabalhar com pessoas e tenha um pouco de porte e instinto de um cômico. Para fazer o modelo bazar funcionar, isto ajuda enormemente se você tem pelo menos um pouco de habilidade para encantar as pessoas.\n10. O contexto social do código aberto\nEstá escrito: os melhores programas começam como soluções pessoais para os problemas diários do autor, e se espalham porque o problema se torna típico para uma grande classe de usuários. Isto nos traz novamente para a regra 1, recolocada talvez de uma maneira mais útil: 18. Para resolver um problema interessante, comece achando um problema que é interessante para você.\nIsso foi o que aconteceu com Carl Harris e o ancestral popclient, e também comigo e o fetchmail. Mas isso foi entendido por um longo tempo. O ponto interessante, o ponto que as histórias do Linux e do fetchmail parecem demandar o nosso foco, é o próximo estágio – a evolução do software na presença de uma comunidade grande e ativa de co-desenvolvedores.\nEm “The Mythical Man-Month”, Fred Brooks observou que o tempo de um programador não é acumulativo; adicionar desenvolvedores em um projeto atrasado de software faz com que ele se torne mais atrasado. Ele expôs que a complexidade e custos de comunicação de um projeto crescem com o quadrado do número de desenvolvedores, enquanto o trabalho feito cresce somente linearmente. Esta afirmação é desde então conhecida como “A Lei de Brooks” e é largamente considerada como correta. Mas se a Lei de Brooks fosse tudo a ser levado em consideração, o Linux seria impossível.\nO clássico “The Psychology Of Computer Programming”, de Gerald Weinberg, sustentou o que, em retrospectiva, nós podemos ver como uma correção essencial ao Brooks. Em sua discussão sobre “programação sem ego”, Weinberg observou que nos lugares onde desenvolvedores não são territoriais sobre seu código, e encorajam outras pessoas a procurar por erros e melhorias potenciais nele, as melhorias acontecem dramaticamente mais rápidas que em qualquer outro lugar.\nA escolha da terminologia de Weinberg talvez tenha prevenido sua análise de ganhar a aceitação que merecia – é engraçado pensar em descrever os desenvolvedores da Internet como “sem ego”. Mas acho que seu argumento parece mais mais convincente hoje do que nunca.\nA história do Unix deveria ter sido preparada para nós do que nós estamos aprendendo com o Linux (e o que eu tenho verificado experimentalmente em uma menor escala por copiar deliberadamente os métodos do Linus). Isto é, embora codificar permaneça uma atividade essencialmente solitária, os hacks realmente bons advém de captar a atenção e poder de mente de comunidades inteiras. O desenvolvedor que utiliza apenas a capacidade cerebral dele mesmo em um projeto fechado irá ficar atrás de desenvolvedores que saibam como criar um contexto aberto e evolutivo no qual a visualização de erros e melhorias sejam feitas por centenas de pessoas.\nMas o mundo tradicional do Unix foi impedido de seguir completamente este método por vários fatores. Alguns deles foram os aspectos legais de várias licenças, segredos de comércio e interesses comerciais. Outro (tardio) foi que a Internet ainda não estava boa o suficiente.\nAntes de a Internet baratear, havia algumas comunidades geograficamente pequenas aonde a cultura motivava a programação “sem ego”??? de Weinberg, e aonde um desenvolvedor poderia facilmente atrair muitos co- desenvolvedores habilidosos. Bell Labs, o MIT AI Lab, UC Berkeley – estes se tornaram a origem de inovações que são lendárias e ainda fortes.\nLinux foi o primeiro projeto a fazer um esforço consciente e bem-sucedido a utilizar o mundo inteiro como sua reserva de talentos. Eu não acho que seja uma coincidência que o período de gestação do Linux tenha coincidido com o nascimento da World Wide Web, e que o Linux tenha deixado a sua infância durante o mesmo período em 1993-1994 que viu a expansão da indústria de ISP e a explosão do principal interesse da Internet. Linus foi a primeira pessoa que aprendeu como jogar com as novas regras que a onipresente Internet fez possível.\nEmbora uma Internet barata fosse uma condição necessária para que o modelo do Linux evoluísse, eu penso que não foi uma condição por si só suficiente. Outro fator vital foi o desenvolvimento de um estilo de liderança e conjunto de formalidades cooperativas que permitiria aos desenvolvedores atrair co- desenvolvedores e obter o máximo suporte do ambiente.\nMas o que é este estilo de liderança e estas formalidades? Eles não podem estar baseados em relações de poder – e mesmo que pudessem, a liderança por coerção não produziria os resultados que nós vemos. Weinberg cita a autobiografia do anarquista do século 19 chamado Pyotr Alexeyvich Kropotkin, “Memórias de um Revolucionista” para demonstrar o efeito neste assunto:\n“Tendo sido criado em uma família possuidora de vassalos, eu entrei a vida ativa, como todos os jovens homens da minha idade, com uma grande confidência na necessidade de comandar, ordenar, repreender, punir e etc. Mas quando cedo tive que conduzir empreendimentos sérios e lidar com homens [livres], e quando cada erro levaria de uma vez a sérias conseqüências, eu comecei a apreciar a diferença entre atuar segundo o princípio de comando e disciplina e atuar segundo o princípio da compreensão comum. O primeiro funciona de forma admirável em uma parada militar, mas de nada vale aonde a vida real é considerada, e o objetivo pode ser atingido somente pelo esforço severo de muitos propósitos convergentes.”\nO “esforço severo de muitos propósitos convergentes” é precisamente o que um projeto como o Linux requer – e o “princípio de comando” é efetivamente impossível de ser aplicado entre voluntários no paraíso anarquista que nós chamamos de Internet. Para operar e competir efetivamente, desenvolvedores que querem liderar projetos colaborativos têm que aprender como recrutar e energizar comunidades eficazes com interesse no modo vagamente sugerido pelo “princípio de compreensão” sugerido por Kropotkin. Eles precisam aprender a Lei de Linus.\nInicialmente eu me referi ao “Efeito Delphi” como uma possível explicação para a Lei de Linus. Porém analogias mais poderosas aos sistemas adaptativos em biologia e economia também se implicam fortemente. O mundo do Linux se comporta em vários aspectos como um mercado livre ou uma ecologia, uma coleção de agentes autônomos tentando maximizar um empreendimento que no processo produz uma ordem espontânea auto-evolutiva mais elaborada e eficiente que qualquer quantidade de planejamento central poderia ter alcançado. Aqui, então, é o lugar para procurar o “princípio da compreensão”.\nA “função empreendedora” que os desenvolvedores do Linux estão maximizando não é economia clássica, mas é a intangível satisfação do seu próprio ego e reputação entre outros desenvolvedores. (Alguém pode chamar a sua motivação de “altruísta”, mas isso ignora o fato que altruísmo é em si mesmo uma forma de satisfação do ego para um altruísta). Culturas voluntárias que trabalham desta maneira não são realmente incomuns; uma outra que eu tenho participado há tempos é a dos fãs de ficção científica, que ao contrário dos desenvolvedores, explicitamente reconhecem o “egoboo” (o aumento da reputação de alguém entre os outros fãs) como o guia básico por trás da atividade voluntária.\nLinus, por posicionar ele mesmo como o guia de um projeto em que o desenvolvimento é praticamente feito por outros, e por inspirar interesse no projeto até que ele se tornasse auto-sustentável, tem mostrado um intenso entendimento do “princípio da compreensão comum” de Kropotkin. Esta visão quase-econômica do mundo do Linux nos permite ver como esta compreensão é aplicada.\nNós podemos ver o método do Linus como uma maneira de criar um mercado eficiente no “egoboo” – para ligar a autonomia de desenvolvedores individuais tão firme quanto possível para dificultar fins que podem ser somente atingidos por uma cooperação sustentada. Com o projeto do fetchmail eu tenho mostrado (embora em uma menor escala) que seus métodos podem ser duplicados com bons resultados. Talvez eu tenha até mesmo feito de uma maneira um pouco mais consciente e sistemática do que ele.\nMuitas pessoas (especialmente aquelas que politicamente desacreditam os mercados livres) poderiam esperar de uma cultura de egoístas auto- direcionada ser fragmentada, territorial, desperdiçadora, reservada e hostil. Mas esta expectativa é claramente desfeita pela (para dar só um exemplo) imensa variedade, qualidade e profundidade da documentação do Linux. É notoriamente conhecido que os programadores detestam documentar; como, então, os desenvolvedores do Linux geram tanto disto? Evidentemente o mercado livre do Linux em egoboo trabalha melhor para produzir comportamentos virtuosos e direcionados a outros propósitos que os centros de documentação massivamente fundados de produtores de software comercial.\nTanto o projeto do fetchmail como o do kernel do Linux mostram que ao se recompensar propriamente o ego de muitos outros desenvolvedores, um desenvolvedor/coordenador forte pode usar a Internet para capturar os benefícios de se ter vários co-desenvolvedores sem fazer o projeto colapsar em uma confusão caótica. Então eu contra-proponho para a Lei de Brooks o seguinte:\n19. Contanto que o coordenador do desenvolvimento tenha uma mídia pelo menos tão boa quanto a Internet, e saiba como liderar sem coerção, muitas cabeças são inevitavelmente melhores que uma.\nEu acredito que o futuro do software de código aberto irá pertencer gradativamente a pessoas que saibam como jogar o jogo do Linus, pessoas que deixam para trás a catedral e abraçam o bazar. Isto não quer dizer que uma visão individual e brilhante não irá mais ter importância; ao contrário, eu acredito que o estado da arte do software de código aberto irá pertencer a pessoas que iniciem de uma visão individual e brilhante, então amplificando-a através da construção efetiva de uma comunidade voluntária de interesse.\nE talvez não somente o futuro do software de código aberto. Nenhum desenvolvedor de código fechado pode competir com o conjunto de talento que a comunidade do Linux pode dar para resolver um problema. Muito poucos podem até mesmo ser capazes de pagar as mais de duzentas pessoas que têm contribuído para o fetchmail!\nTalvez no final a cultura de código aberto irá triunfar não porque a cooperação é moralmente correta ou a “proteção” do software é moralmente errada (assumindo que você acredita na última, o que não faz tanto o Linus como eu), mas simplesmente porque o mundo do software de código fechado não pode vencer uma corrida evolucionária com as comunidades de código aberto que podem colocar mais tempo hábil ordens de magnitude acima em um problema.\nEste documento foi enriquecido através de conversas com um grande número de pessoas que ajudaram a depurá-lo. Agradecimentos particulares a Jeff Dutky dutky@wam.umd.edu , que sugeriu a formulação “depuração é paralelizável”, e ajudou a desenvolver a análise que se procedeu a isso. E também a Nancy Lebovitz nancyl@universe.digex.net pela sua sugestão que eu imitei Weinberg ao citar Kropotkin. Críticas incisivas também vieram de Joan Eslinger wombat@kilimanjaro.engr.sgi.com e Marty Franz marty@net-link.net da lista de Técnicas Gerais. Sou grato aos membros do PLUG, o Grupo de Usuários de Linux da Filadélfia, por permitir a primeira audiência de teste para a primeira versão pública deste documento. Finalmente, os comentários de Linus Torvalds foram importantes e seu apoio desde o início foi muito estimulante.\n12. Para leitura adicional\nEu citei várias frases do clássico The Mythical Man-Month de Frederick P. Brook porque, em muitos aspectos, suas considerações ainda precisam ser mais analisadas. Eu recomendo fortemente a 25a. edição de Aniversário de Addison-Wesley (ISBN 0-201-83595-9), que adiciona seu documento “No Silver Bullet” de 1986.\nA nova edição é envolvida por uma inestimável retrospectiva de 20 anos atrasada na qual Brooks admite francamente os poucos julgamentos no texto original que não resistiram ao teste do tempo. Achei que a retrospectiva deste documento estava substancialmente completa, e fiquei surpreso ao descobrir que Brooks atribui práticas como o estilo bazar à Microsoft! (De fato, entretanto, esta atribuição Halloween que a comunidade interna de desenvolvimento da Microsoft é estratificada, com o tipo comum de acesso ao código necessário para suportar o bazar muitas vezes nem mesmo possível.)\nThe Psychology Of Computer Programming, de Gerald M. Weinberg (New York, Van Nostrand Reinhold 1971) introduziu o conceito um tanto mal nomeado de “programação sem ego”. Embora ele não estivesse nem perto de ser a primeira pessoa a perceber a futilidade do “princípio do comando”, ele foi provavelmente o primeiro a reconhecer e argumentar o ponto particular de ligação com o desenvolvimento de software.\nRichard P. Gabriel, contemplando a cultura Unix da era pré-Linux, relutantemente argumentou a favor da superioridade do modelo primitivo do estilo bazar em seu documento Lisp: Good News, Bad News, and How To Win Big, de 1989. Embora obsoleto em alguns aspectos, este ensaio ainda é muito cotado entre os fãs do Lisp (incluindo eu). Um correspondente me lembrou que a seção entitulada “O Pior é o Melhor"parece-se mais como uma antecipação do Linux. O documento está disponível na World Wide Web em http://www.naggum.no/worse-is-better.html .\nFinalmente, eu devo admitir que eu quase chamei este documento de “A Catedral e a Ágora”, o último termo sendo o grego para um mercado aberto ou um lugar de encontro público. Os documentos “sistemas agóricos” de Mark Miller e Eric Drexler, descrevendo as propriedades emergentes de ecologias computacionais de mercado, me ajudaram a me preparar a pensar claramente sobre fenômenos análogos na cultura do código aberto quando o Linux esfregou o meu nariz neles cinco anos\nEstes documentos estão disponíveis na Web em http://www.agorics.com/agorpapers.html\n13. Epílogo: Netscape acata o Bazar!\nEric Hahn, Vice Presidente Executivo e Oficial Chefe de Tecnologia da Netscape, enviou uma mensagem para mim pouco tempo depois como se segue: “Em nome de todos da Netscape, eu quero agradecer a você por ter nos ajudado chegar a este ponto em primeiro lugar. Seus pensamentos e escritos foram inspirações fundamentais para nossa decisão.”\n14. Versão e Histórico de Mudanças\nEu liberei a versão 1.16 no Linux Kongress, em 21 de Maio de 1997. Eu adicionei a bibliografia em 7 de Julho de 1997 na versão 1.20. Eu adicionei a anedota da Perl Conference em 18 de Novembro de 1997 na versão 1.27. Eu mudei de software livre" para código aberto” em 9 de fevereiro de 1998 na versão 1.29. Eu adicionei ``Epílogo: Netscape Acata o Bazar!” em 10 de Fevereiro de 1998 na versão 1.31. Eu removi o gráfico de Paul Eggert sobre GPL vs. bazar em resposta aos argumentos coerentes de RMS em 28 de Julho de 1998. Eu adicionei uma correção de Brooks baseado nos Documentos Halloween em 20 de Novembro de 1998 na versão 1.40. Outros níveis de revisões incorporaram pequenas correções editoriais.


Casa máscara facial descartável costco de 3 camadas - 50 pack 0x cd de música r media fuso de 50 pack\nUFSC - Universidade Federal de Santa Catarina 28/03/2012 ...- máscara facial descartável costco de 3 camadas - 50 pack 0x cd de música r media fuso de 50 pack ,UFSC - Universidade Federal de Santa Catarina 28/03/2012Instituto Federal de Minas GeraisAlfinete de cabeça - Alfinete de cabeça, nº 24, niquelado, caixa com 50 g. Bota de PVC Par de bota em PVC injetado, na cor branca, tamanho 39, cano curto (altura 240 mm), com forro interno em poliéster e solado anti-derrapante. Corda para varal Corda para varal de roupas, material polietileno, pacote contendo 10 metros de comprimento. Outdoor\nTeclado abnt2 usb com teclas de atalho multimídia, em conformidade com as normas abnt2, com design ergonômico, pés de apoio emborrachado, botões de navegação, botões de controle multimídia, tecla media center, e-mail, home, volume + e -, mute, play/pause, teclas de atalho de internet/multimídia/sistema, teclas de membrana tátil de ...\nR$ 3.220,50 46 166.0 R$ 3.7,56 47 30.22.000189 PAPEL TOALHA BRANCO, folha simples em bobina com 20 x 200 m, picotado. Produzido com 100% de celulose virgem. Deverão ter boa propriedade de resistência ao estado úmido e não causar irritações dérmicas. Fardo com 06 bobinas de 200 metros cada, perfazendo um total de 1.200 metros por fardo.\npre：pa 3 camada máscara descartável revisão youtube completonext：máscara facial de algodão de camada tripla com arame para o nariz e bolsa de filtro


Projetos pessoais, 2017 e um Diário Sangrento - Layer Lemonade\nOld Staff - Layer Lemonade 28 de dezembro de 2016\nO ano está acabando e aquela sensação de recomeço, novas tentativas e novas conquistas bate no juízo e deixa todo mundo esperançoso. Para começar o ano com os dois pés na porta, nada como dar início a um novo projeto pessoal, né?! Que além de trabalhar aspectos como disciplina e organização, tem aquele potencial de se tornar algo maior e com ótimos resultados inesperados.\nEnquanto muitos estão preocupados com a escolha da roupa de ano novo, Min Liu está colhendo os frutos dos seus GIFs coloridos publicados no instagram durante 100 dias seguidos. Essa tática de produzir por uma determinada quantidade de tempo é uma ótima saída para quem não consegue administrar muito bem seu tempo a longo prazo.\nMin Liu estudou Belas Artes em Taipei e completou sua formação com estudos de animação 2D e motion graphics na Escola de Artes Visuais em Nova York, onde reside atualmente. Com o projeto finalizado, Wengu Hu foi convidado para produzir o sound design para o amontoado de GIFs e boom!, o projeto pessoal foi selecionado para a Annency 2016 e outras oito indicações em diversos festivais ao redor do mundo.\nMin Liu batizou seu projeto com o nome Bloody Diary, talvez por causa da presença constante de membros decepados que se movem independentemente de um corpo, ou talvez porque seja preciso se dedicar bastante para produzir uma animação dessas por dia. Sua meta era postar os GIFs até as 12h do dia, para então receber os feedbacks da internet.\nAs animações foram desenhadas à mão, o que significa que a artista anima seus GIFs frame by frame. Através do uso de uma paleta simples e de cores contrastantes, restrito ao uso do vermelho, preto e branco, e do uso abusivo da gestalt, Min Liu consegue focar nossa atenção sobre uma ação desejada, tornando a experiência visual muito louca – no bom sentido, claro.\nEm todas suas animações é possível encontrar aquela dose balanceada de humor, o que torna cada GIF ainda mais interessante. Apesar do projeto ter como protagonistas gatos e muitas mãos, Min Liu conta ter-se inspirado também em experiências, objetos e momentos vividos durante a realização do projeto.\nEntão é isso, vamos aproveitar essa sensação de recomeço causada pelo ano novo e meter a cara em um projeto pessoal. Não precisa focar suas forças em atenção, apenas produza algo com determinação e sabedoria, e use a internet ao seu favor. Sair da zona da Síndrome do Impostor requer empenho, organização e inspiração. O empenho e organização é por sua conta, a inspiração deixa que o limãozinho resolve!\nFonte: Domestika | Capa: Matt Popovich\n2017annecyBeethowen SouzaBloody DairyFull AnimationMin LiuProjeto pessoalWengu Hu\nOld Staff - Layer Lemonade 7 de junho de 2017


Como manter a low carb em tempos de coronavírus - Site RG – Moda, Estilo, Festa, Beleza e mais\nPOR: ligia kas 26.03.2020 Beleza\nO “problema” é que consequentemente baixa-se também a ingestão das frutas e legumes que contêm uma taxa alta de carboidratos/açúcares, o que é totalmente desaconselhável neste momento, em que precisamos estar com nosso sistema imunológico muito bem reforçado.\nSegundo a Dra. Bruna Marisa, médica endocrinologista, membro da Sbem (Sociedade Brasileira de Endocrinologia e Metabologia), pós graduada em medicina ortomolecular e especialista em emagrecimento e low carb, “Este momento não é o de perder peso, mas sim de pensar em melhorar a saúde, a qualidade de vida”.\n“Neste momento, vamos voltar com as frutas e legumes, que são as maiores fontes de nutrientes que temos. Vamos continuar com os ovos e as carnes e, aumentar um pouco mais a cota de carboidrato, que ao invés de 40 g a 80 g por dia, passará para 100 g a 200 g/dia para fortalecer o sistema imunológico como precisamos”, diz a médica.\n“Faça uso de própolis!”, afirma Bruna .\nO alho é rico em vitamina A, C e E, portanto um forte aliado contra a baixa imunidade, assim como a cebola que é anti-inflamatória, antiviral, antifúngica e antiparasitária e não podemos deixá-la de fora da dieta.\nOutra coisa importante é que o coronavírus vai afetar pessoas mais fracas, então, mantenha-se forte.\nPratique seus exercícios diariamente para fortalecer seu corpo.\nAinda que você não frequente academias nesta fase, experimente fazer seus treinos e exercícios ao ar livre ou mesmo em um cantinho confortável em sua casa. O importante é não parar, reforça a médica.\nConcluindo, agora não é a hora de perder peso, mas sim de cuidar da imunidade e manter seu corpo saudável e preparado para enfrentar estes tempos difíceis.\nLembrando que arroz, feijão, farinhas, macarrão, bolos, biscoitos etc. não possuem nutriente algum, portanto, continuam fora da dieta mesmo nesta fase, lembra Bruna.\nTags relacionadasatividade físicadietafrutaslegumeslow carbperda de pesosaúde


Análises sobre o AGW - Página 37\npágina 37 defende 42\npela avaliação » 04/11/16, 21:43\nJanic escreveu: A questão é: quais são os efeitos das não-submissões?\nBoa pergunta que permanecerá no estado em questão até que não seja vivida intimamente.\nA mente pode adivinhar à vontade.\nJanic escreveu: é uma ilusão da mente acreditar na liberdade de alguém (que, além disso), porque a toda causa está vinculado um efeito cujos meandros nos iludem sistematicamente.\nDe fato, não há liberdade possível por esse caminho sem fim.\nO caminho para a liberdade está precisamente na realização da ilusão do eu.\npela Terremoto » 17/11/16, 00:42\nDepois de páginas e páginas de trocas de argumentos climatocéticos e climatéricos convictos, aqui estamos nós em discussões espirituais sobre deus e livre arbítrio que deveriam ter sido "separados" deste tópico, porque não faltam interesse, mas 'tem apenas uma ligação distante com seu assunto.\nSe todos os palestrantes (ainda vivos) deste tópico concordarem agora com a validação de> 97% da comunidade de cientistas climatológicos para admitir a realidade do aquecimento global antropogênico, o econologie.com poderia fechá-lo ...\nHa ha, estou brincando, alguns certamente querem republicar pela enésima vez um argumento cético sobre o clima aparentemente imparável de 1995-2010, um vídeo já disputado de uma desova do tipo ou, no próximo ano, com base em números indiscutíveis mostrando um “arrefecimento” (números que se seguirão naturalmente ao fim do efeito El Nino 2015-2016), argumentos que “provarão” que caminhamos para uma nova era do gelo!\npela avaliação » 17/11/16, 10:16\nTerremoto escreveu: Depois de páginas e páginas de trocas de argumentos climatocéticos e climatéricos convictos, aqui estamos nós em discussões espirituais sobre deus e livre arbítrio que deveriam ter sido "separados" deste tópico, porque não faltam interesse, mas 'tem apenas uma ligação distante com seu assunto.\nEsse assunto é duplamente complexo: clima e seres humanos interagindo com o assunto climático.\nA mudança climática é objeto de consenso científico, é um fato.\nA ciência é definida por três componentes: observação, experimentação e leis.\nOs cientistas responsáveis pelo arquivo climático ainda não escreveram as leis que descrevem sem ambiguidade o clima da Terra.\nEste é um processo iterativo de construção de conhecimento, de propostas legislativas atuais diante de observações passadas e futuras do clima. Assim por diante\nMesmo que o consenso seja hoje de 97%, é muito presunçoso quem pode ter certeza absoluta quanto à evolução do clima futuro.\nComo o que não devemos separar os sujeitos, abordamos novamente a psique humana, que precisa de certezas para decidir sua ação.\nMelhor uma falsa certeza à qual todos aderem é mais tranquilizador do que viver com a imprecisão da incerteza.\nEnquanto se aguarda a promulgação de leis na ciência climática, repetidamente validada por observação e experimentação, os seres humanos sempre preferiram seguir o consenso geral em sua infância, porque o consideravam mais prudente e tranquilizador do que viver isolado com o incerteza, bastante provocadora de ansiedade.\nNo entanto, a única base intangível em que podemos confiar em qualquer pesquisa, científica ou espiritual, é: não sei.\nO resto é apenas um conjunto de cartas de conhecimento do dia, que vêm e vão com o progresso.\npela Terremoto » 19/11/16, 04:43\nAvaliação escreveu: A ciência é definida por três componentes: observação, experimentação e leis.\nAssim como a medicina ainda não escreveu as leis da saúde e da doença, é uma construção de tudo o que sabemos e não sabemos sobre doenças, saúde, biologia, microbiologia. , genética, fisiologia, cirurgia, neurologia, nutrição, psicologia, medicina alternativa, etc. Sem contar tudo o que se quer admitir ou negar, de acordo com todos os tipos de condicionamento.\na psique humana que precisa de certezas para decidir sua ação.\nEnquanto se aguarda a promulgação de leis na ciência climática, repetidamente validada por observação e experimentação, os seres humanos sempre preferiram seguir o consenso geral em sua infância, porque o consideravam mais prudente e tranquilizador do que viver isolado com o , bastante provocador de ansiedade\nNão entendo bem, se a psique humana precisa de certeza para decidir sua ação, mas se a certeza a que todos aderem é provocadora de ansiedade, seria melhor aderir à falsa certeza, à gagueira, para se tranquilizar. no borrão da incerteza?\nNão, no que diz respeito ao clima, muitas leis em cada disciplina já estão certificadas e suas conclusões concordam com o aquecimento global antropogênico, e nossos valentes cientistas estão apenas tentando reconciliá-los para validar modelos globais que permitam previsões para que O consumidor homo sapiens reconhece que poucos fatos perceptíveis em uma escala individual devem ser levados em consideração em decisões futuras (radiantes, mas não muito quentes nem irradiados). Ufa!\nEm qualquer pesquisa, talvez ... Para Deus, é indubitavelmente verdade ... mas com relação ao clima, passamos por esse estágio, fizemos descobertas e tentamos tirar dele conclusões ... Talvez saibamos o suficiente para fazer isso?\nLendo você, prefiro ter a impressão de que estamos nos retirando ...\nAh, uma última insolência ... para me citar (é inofensivo):\npela avaliação » 19/11/16, 10:02\nTerremoto escreveu: Não entendo bem, se a psique humana precisa de certeza para decidir sua ação, mas se a certeza a que todos aderem é provocadora de ansiedade, seria melhor aderir à falsa certeza, à gagueira, para se tranquilizar. no borrão da incerteza?\nO consenso é realmente provocador de ansiedade, uma vez que um futuro climático incerto é apresentado a nós, esse não era o ponto.\nO cérebro odeia a incerteza e prefere reunir-se a uma posição adotada maciçamente, que a tranquiliza, mesmo que essa posição seja descoberta mais tarde, em vez de viver no presente, sozinho e com dúvida, esse era o ponto. .\nSozinho e com dúvidas provocando mais ansiedade do que com o grupo aderindo a uma posição que provoca ansiedade.\n... mas no que diz respeito ao clima, passamos por essa etapa, fizemos descobertas e estamos tentando tirar conclusões ... Talvez saibamos o suficiente para fazer isso?\nÉ humano agir e pensar com o conhecimento do momento, portanto, se envolver com o conhecimento do momento.\nO futuro confirmará a pesquisa climática de hoje.\nNão sou climatologista para julgar a absoluta relevância da pesquisa climática.\nApesar de tudo, a climatologia continua sendo uma ciência jovem, diferentemente da mecânica newtoniana, que não é mais objeto de críticas até hoje.\nPrefiro manter uma pequena perspectiva do que não está dentro da minha competência e do que ainda não é objeto de um consenso de 100%.\nNo entanto, como humano, estou inclinado a seguir o consenso atual e a adotar as regras prudenciais resultantes.\nComo o assunto é complexo, não é apenas o clima em jogo.\nDo meu ponto de vista, é melhor manter uma certa perspectiva.\nÀs vezes, depois do fato, lamentamos a falta de previsão de seu compromisso.\nTodo mundo é diferente, todo mundo reage de maneira diferente à mesma situação.\npela Terremoto » 21/11/16, 23:26\nAvaliação escreveu: O cérebro odeia a incerteza e prefere reunir-se a uma posição adotada maciçamente, que a tranquiliza, mesmo que essa posição seja descoberta mais tarde, em vez de viver no presente, sozinho e com dúvida, esse era o ponto. .\nO cérebro (iluminado) detesta certezas infundadas e prefere se apoiar em argumentos bem fundamentados, mesmo que sejam perturbadores! O consenso atual é perturbador e ansioso, mas onde estaria a "vantagem" em negá-lo? Esquivar-se de nossas responsabilidades e não se preocupar com suas consequências?\nA dúvida é saudável e é parte integrante da atitude científica; poucos apoiadores atuais do consenso climato-antrópico (eles são cientistas) nunca tiveram dúvidas, mas quase todos reconheceram a contribuição antrópica para esse problema.\nEu me repito, mas a dúvida é saudável.\nNo entanto, deixe a mesma pessoa (Dupon-dt; Cambre, Duran) negar o consenso, invocando dúvidas e, em ordem e desordem, mas simultaneamente:\n- negação do atual aquecimento global do clima;\n- aceitação do mesmo aquecimento global do clima, mas negando suas causas antropogênicas;\n- curvas manipuladas (sem controle por pares, livres de conflitos de interesse) e, portanto, questionáveis;\n- aspectos de detalhes pouco compreendidos (a extensão do gelo antártico; argumentos meteorológicos locais com pouca conexão com argumentos climatológicos globais ...) que apóiam seu manuseio, mas que, após verificações posteriores, não questionam a tendência geral;\n- falta de probidade de 97% dos estudos que apóiam o consenso (ainda verificados por pares sem conflitos de interesse).\nEntão, pode-se perguntar quais são as motivações do Dupon-dt; Cambre, Duran e outros?\nComo é que seus insultos a toda a comunidade científica permanecem tanto tempo no topo do Google ou em outros resultados de pesquisa (custa dinheiro; não posso pagar)?\nPortanto, como o dinheiro importa tanto, de quem são seus esforços contra a maré financiada (assim como o destaque de seus delitos da mídia)?\nO consenso sobre o aquecimento global antropogênico é uma conspiração, adotada por 97% dos estudos (revisados por pares) de autores científicos com algo a dizer sobre o clima? Ou essa suposta trama é a posição dos céticos do clima (poucos dos quais têm alguma "carta" no campo do clima)?\nNo entanto, é improvável que a posição do consenso (majoritário, mas não unânime) promovido por 97% dos estudos seja obra de uma conspiração dos cientistas que estariam na origem dela, sabendo que as tramas são históricas e geralmente promovido por minorias que se opõem a este ou aquele consenso; conspiração: “narrativa teórica que afirma ser coerente e busca demonstrar a existência de uma conspiração entendida como o fato de que“ um pequeno grupo de poderosos está se coordenando em segredo para planejar e realizar uma ação ilegal e nefasta que afeta o curso de eventos "" https://fr.wikipedia.org/wiki/Th%C3%A9orie_du_complot.\nEm termos de consenso climático, estamos longe de ser um “pequeno grupo de pessoas poderosas”, capaz de se coordenar para traçar e divulgar informações falsas.\nPor outro lado, a atividade dos climatosceptics está muito mais próxima dessa definição ...\nÉ um pouco contraditório ... A medicina atual também é muito "jovem", você segue ou tem dúvidas legítimas? Você recusa as vacinas, os antibióticos? De que forma sua mente duvidosa espera pela prova, que seria o assunto de "100% de consenso"? Esse consenso de 100% existe em algum campo científico? Não. Então, de acordo com sua posição "humana", você não "acreditaria" em nada que seja apoiado pela ciência?\nSim, você seria um espécime sagrado da humanidade, observando o caminho para as piras que poderiam queimar você vivo!\nVolte à terra, a deriva continental (ou placas tectônicas), uma teoria proposta em 1912 por Alfred Wegener sozinho, esperou até a década de 1960 antes de ser admitida e obter um "consenso" científico, as teorias de Newton ou Einstein também esperou décadas antes de ser aceito pela maioria dos cientistas (não 100%). 100% de consenso simplesmente não existe e nunca existiu, em qualquer disciplina!\nVocê acha que será o mesmo para as teses climáticas, que foram prejudicadas por dados irrefutáveis (e não por teorias ou interpretações). Eles triunfarão nos próximos 50 anos? Suas teses serão validadas um dia ou outro? Isso é extremamente improvável, dado que são teses contra a maré dos dados, e não teorias apoiadas por fatos fisicamente mensuráveis (os dados).\nEntão você concorda com a ação contra o aquecimento antropogênico? Desculpe-me por fazer a pergunta novamente, mas sua posição me parece cheia de contradições ...\nO que mais? Crenças pessoais que não querem levar em consideração um consenso maciço? Filosofia?\nLá, finalmente concordamos absolutamente ...\npela Janic » 22/11/16, 08:39\nÉ um pouco contraditório ... A medicina atual também é muito "jovem", você segue ou tem dúvidas legítimas? Você recusa vacinas, antibióticos? De que forma sua mente duvidosa espera pela prova, que seria o assunto de "100% de consenso"? Esse consenso de 100% existe em algum campo científico? Não. Então, de acordo com sua posição "humana", você não "acreditaria" em nada que seja apoiado pela ciência?\nExcelente comparação! exceto que .... Pouquíssimas pessoas voltam à gênese de vacinas como antibióticos, e é exatamente nesse ponto que está o ponto importante. Esses dois meios mencionados são apenas respostas (cuja credibilidade pode ser questionada) ao medo, à ansiedade das populações diante de doenças, sofrimentos e, finalmente, morte.\nTambém é comparável à ecologia atual, que pode parecer ansiosa, além de enfatizar a responsabilidade de toda a sociedade abastada em relação aos seus comportamentos recentes (aos olhos da história), começando mais ou menos com o desenvolvimento industrial em total indiferença quanto às conseqüências inevitáveis em termos de poluição (por exemplo) ou resistência a antibióticos (os dois correspondentes em busca do milagre da "ciência" a serviço dos seres humanos). Exceto que, ao fazer isso, torna (e responsabilizou) todos os responsáveis por seu próprio comportamento: o medo de doenças e a vacina milagrosa "protegerão" os micro / vírus / bactérias ruins; o antibiótico (para quem pratica um pouco de anti-lingüística, anti-bio, vida e, portanto, contra a vida e não apenas contra vírus ruins e outros) sem precisar fazer a pergunta do porquê, que inclui sua resposta.\nDe fato, e de fato, a "ciência" é um instrumento a serviço de interesses poderosos (que financiam pesquisas direcionadas e obviamente orientadas) e não uma "ciência" neutra.\nReduzidos ao aquecimento global, estão em jogo os mesmos mecanismos, a saber, cenoura e pau, que serão e serão usados por sua vez.\npela Ahmed » 22/11/16, 09:38\nBasicamente, essas duas atitudes opostas, a maioria como a minoria cética do clima inconscientemente refletem (isso não é um enredo!). O desejo mortal que representa a dinâmica real de nossa sociedade, um desejo que está incorporado no fato de encontrar soluções tecnológicas para os problemas gerados pela tecnologia (deixo a você julgar a relevância da abordagem!) e que variam da engenharia climática à chamada transição de energia e juntos, para continuar usando combustíveis fósseis.\nNesse contexto, levar em consideração a natureza antrópica da RC deve ser entendido como uma oportunidade para a fabricação de novos equipamentos. adicional equipamentos convencionais e, assim, dissipam um pouco mais de energia, ou se preferir, conseguem aumentar os ganhos que tendem a estagnar estruturalmente. Psiquicamente, isso também percebe a possibilidade desse programa, tranquilizando aqueles e muitos há que observam o processo de destruição das condições de vida na Terra.\npela avaliação » 22/11/16, 11:54\nTerremoto escreveu: O cérebro (iluminado) detesta certezas infundadas e prefere se apoiar em argumentos bem fundamentados, mesmo que sejam perturbadores! O consenso atual é perturbador e ansioso, mas onde estaria a "vantagem" em negá-lo? Esquivar-se de nossas responsabilidades e não se preocupar com suas consequências?\nA acção individual em última análise, tem pouco peso, mesmo se o resultado da acção indivíduo não é zero.\nSó podemos permanecer humildes com nosso próprio poder para fazer as coisas acontecerem.\nE como os humanos fazem grande parte do mundo ao nosso redor, desconfio de muitos pontos, incluindo a saúde.\nIsso não me impede de me tratar quando necessário, mas permaneço crítico do que prescrito.\nDinheiro não é tudo no google, a popularidade também conta, é preciso acreditar que os céticos são populares.\nAs pessoas só querem outro sino para obter sua opinião, o que cria popularidade.\nPossível que lobbies e, portanto, dinheiro, estejam por trás de certos discursos, suponho que funcione para as duas correntes.\nNenhuma conspiração real é necessária, a natureza do ser humano é suficiente para explicar tudo.\nOs seres humanos são egocêntricos. Portanto, ele conspira contra todos os outros seres humanos egocêntricos e, finalmente, contra si mesmo, para perpetuar essa lógica interna de egocentrismo.\npela Terremoto » 22/11/16, 17:58


Vozes Encarnadas: Comentário que passa a post: Isenção do Benfica de 1,8 milhões a explicação\nComentário que passa a post: Isenção do Benfica de 1,8 milhões a explicação\nCaro Perfeito. Peço desculpa mas objectivamente e no contexto (ou descontexto) que lhe querem dar são exactamente a mesma coisa.\nPodemos ser criativos e pensar que não existem motivações outras por detrás desta decisão que não as que defendam o erário publico, mas não é por aí que se justifica ou contextualiza isto.\nO Benfica tinha direito a esta isenção? Tinha. E será muito fácil de o justificar quando comparamos o carácter social da Fundação Benfica com o carácter puramente propagandista que tem as Fundações de outros clubes.\nMas o facto é que se pretendem deslocalizar serviços de dentro do estádio da luz para um novo edifício que irá albergar em grande parte toda a estrutura administrativa e de gestão do grupo Benfica e sendo assim as motivações para uma isenção desta natureza também não são só as que emanam de uma mão cheia de ideias pérfidas que germinaram logo numa miríade de cabeças mal intencionadas.\nVoltamos à velha questão da mulher de César... O Benfica podia pedir esta isenção mesmo sabendo que o objecto da mesma poderia não ter na sua totalidade enquadramento legal para poder beneficiar dela. O próprio vereador ou responsável admite que o objecto da isenção não é na totalidade admissível, mas fez a proposta na mesma considerando as contrapartidas imediatas e futuras para a cidade e ela passou politicamente. Isto, convenhamos deixaria muita gente desconfortável ou receosa de tomar a decisão por ser fácil prever o impacto que teria na opinião pública. Especialmente agora nestes tempos que atravessamos.\nA decisão sendo política compromete o Benfica? Não. Muitos outros clubes já fizeram outros negócios com as câmaras municipais e obtiveram benesses muito maiores derivadas de isenções, benefícios fiscais, cedências de terrenos, permutas, etc etc etc... E sem se comprometerem a contrapartidas de maior.\nE neste aspecto o Benfica tem sido sempre muito claro e honesto nos negócios com as câmaras oferecendo contrapartidas a curto médio e longo prazo muito superiores às que acaba por receber.\nEm tempos de crise dizem alguns que não se deviam tomar decisões deste tipo... Pois eu digo exactamente o contrário. É nestas alturas que é necessário dinamizar, apoiar e até incentivar quem tem possibilidades de fazer investimento. Houvesse coragem dos nossos governantes em dar a mão às empresas que realmente geram valor (ou tem potencial para tal mediante a devida reestruturação) para o país e estaríamos concerteza sempre um passo à frente da crise...\nE já nem falo da construção e da criação de postos de trabalho que um edifício desta natureza poderá acarretar.\nAtenção que o Benfica pediu esta isenção mediante a apresentação de um projecto concreto de iniciativa própria. Ou seja, não esperou que fosse o estado ou o dinheiro público a projectar e construir para depois usufruir da natureza mecenática de alguns dos nossos dirigentes políticos para daí obter vantagens que lhe permitam alicercar sucessos em bases de concorrência desleal.\nPensem nisto antes de discordar...\nComentário do grande Benfiquista nunomaf do blog O Belo Voar da Águia\nPerfeito Correia 17 de fevereiro de 2015 às 01:31


Em Defesa da Escola Pública e da Dignidade da Docência: José Manuel Silva, ex- Director Regional de Educação do Centro acusa o governo de autismo...\nJosé Manuel Silva, ex- Director Regional de Educação do Centro acusa o governo de autismo...\nO ex-líder do PS de Leiria e ex-responsável pela Direcção Regional de Educação do Centro diz que “o Governo é autista e (oficialmente) o Partido Socialista está mudo e quedo”.\nEm dois “artigos” distintos no seu blog (http://www.campolavrado.blogspot.com/), José Manuel Silva coloca em causa as políticas do Governo liderado por José Sócrates e defende que “Manuel Alegre está a prestar um serviço ao partido e, sobretudo, ao país”.\nNuma alusão a uma reunião da distrital de Leiria do PS, o membro da Assembleia Municipal de Leiria revela que “os controleiros de serviço (…) tentam iluminar as almas e acalmar as hostes, chamando o rebanho à unidade e à acção quando, como é o caso, o barco começa a meter água”.\nCansado dos silêncios cúmplices, José Manuel Silva defende que é necessário que se reporte ao “líder do PS, por acaso o primeiro-ministro, o ambiente que se vive nas escolas, a desmotivação, o clima de medo, o desejo de fuga para outras profissões, enfim, a verdade que não pode ser escamoteada”. Conclui o socialista que “é por estas e por outras que a voz de Manuel Alegre se tornou tão importante”.\nTexto de João Carreira, in Região de Leiria, 15 de Fevereiro de 2008\nPublicada por Em defesa da Escola Publica à(s) 22:28\nEtiquetas: governo autista, José Manuel Silva\nA minh'alma está parva!!! Já conhecia o jogo de cintura deste senhor que, tendo começado no PCP e passado para o PS quando viu que no primeiro não ia a lado nenhum, nunca deixou de manifestar a sua consonância de opiniões com o então presidente da CML, Lemos Proença, eleito pelo PSD. Agora, vem mostrar a sua indignação pela política deste PS liderado por José Sócrates quando, ainda há relativamente pouco tempo, enquanto Director Regional de Educação do Centro, disse que o elevado número de alunos com NEE se devia a interesses corporativos (manter o número de lugares para professores de apoio), enxovalhando assim não só estes profissionais, mas também psicólogos e médicos que comprovam as NEEs, bem como os membros dos conselhos executivos que ratificam os PEIs desses mesmos alunos. Eu diria que este senhor foi brilhante no seu papel de acólito da sr.a Ministra da Educação, reproduzindo a ideia de 'incompetência' de todos quantos pululam nas escolas e agora, que perdeu o 'tacho', vem carpir as suas mágoas na praça pública. Será que não tem coluna vertebral???


Nunca Fomos tão Felizes: QUANDO NÃO SE TEM MAIS IDENTIDADE PRÓPRIA...\nBarack Obama ‘aceitou’ a indicação do Partido Democrata para disputar a reeleição. Grande novidade.Sabíamos que aceitaria.E seu discurso “mais do mesmo”...Bom, também tínhamos conhecimento prévio disso. Nada do que ele diria poderia fazer com que as massas pudessem ficar impressionadas.Talvez,os mais ingênuos,acostumados a citar o fato de que ele é ‘o primeiro presidente afro-americano” a chegar à Casa branca. Tirando isso, ele não se diferencia dos demais antecessores, em praticamente nada.\n"Eu concorri para a Presidência quando vi que essa essência estava\nacabando, quando em 2008 vimos que por quase uma década as famílias americanas lutavam contra o aumento do custo de vida, a hipoteca, o preço da gasolina, dos alimentos. Uma tragédia da qual ainda estamos lutando para se recuperar."\nClaramente criticando a administração de George W. Bush e com um tom quase messiânico,Obama insinua que ele poderia resolver as adversidades, e que estes problemas foram suas prioridades, durante o primeiro mandato. Conversa fiada. Primeiro, é evidente que pior do estava não poderia ficar. Segundo, que passado o primeiro semestre, sua gestão recrudesceu a tal ponto que já não era possível ver a diferença entre as duas presidências. Ele e Bush começaram a ter mais em comum do que gostaria seu eleitor mediano.\n"Cada vez mais, ouvimos de nossos adversários que mais cortes e menos regulamentação fiscal são a única solução. Que, já que o governo não pode fazer tudo, ele deve fazer quase nada.Mas sabe de uma coisa? Isso não é o que somos. Isso não é o nosso país”.\nEstranho Obama dizer isso. Ele seguiu passo a passo a cartilha conservadora dos republicanos.Talvez porque soubesse que esse era o caminho mais seguro para não desagradar seus novos amiguinhos de Wall Street.\n"Quando tudo estiver dito e feito --quando você pegar a cédula de voto-- você terá de enfrentar uma das escolhas mais importantes em uma geração. Ao longo dos próximos anos, grandes decisões serão tomadas em Washington sobre emprego, economia, impostos, deficits, energia, educação, guerra e paz --decisões que terão um enorme impacto em nossas vidas e nas vidas de nossos filhos."\nPerceba que o tema “guerra” já é recorrente na agenda democrata. Sempre o foi para o Partido Republicano. Mas desde Bill Clinton, que cometeu perjúrio negando que manteve relações sexuais com sua assistente Mônica Lewinski,e ao ver o cerco se fechando, ordenou um bombardeio pesado contra o Iraque (mais uma vez, Saddam pagou pelo o que não fez) pra desviar a atenção da mídia, o tema militar ganhou mais força do que de costume.\nTodos os tópicos que ele citou foram mal resolvidos por sua gestão equivocada. Suas promessas de campanha quase foram esquecidas por completo. Saúde e educação não obtiveram melhoras (afinal,lá como cá, não se educa melhor para não correr o risco de ver um povo mais consciente tirar políticos incompetentes do poder). E seu eleitorado base foi relegado a segundo plano.\n"Vai ser uma escolha entre dois caminhos diferentes para a América. A escolha entre duas visões fundamentalmente diferentes para o futuro."\nOutro erro crasso. Não da parte dele, é claro.Mas dos seus eleitores em potencial acreditarem que realmente há dois caminhos diferentes. Nunca a expressão “mais do mesmo” foi tão fácil de se identificar. Assim como no Brasil, o bipartidarismo americano tem se mostrado quase nulo. Poucas coisas diferem um candidato do outro;de um discurso do outro; de um partido para outro. Em mais de um momento Obama se esquivou de temas cruciais,e quando os abordou, foi superficial, como de costume. Ele se apoia no fato de ser carismático, diferentemente de seu opositor. Apoia-se, ainda, no fato dos afro americanos e os hispânicos se identificarem com ele(a questão racial ainda funciona para os mais incautos; quando se esquece sua cor, não há nada que o diferencie de Mitt Romney).\nMas quando o assunto é emprego (taxas altíssimas de desemprego pelo país), base de Guantánamo (sua promessa de campanha em 2008 foi a de fechar as instalações; até agora não saiu do papel),o conflito no Oriente Médio (prometeu lutar pelo reconhecimento do Estado Palestino, mas tem feito vista grossa, tanto ao endurecimento das ações por parte de Israel, quanto ao holocausto palestino), aquecimento da economia(se Clinton fosse seu adversário,diria a ele o que disse a George Bush pai, em 1992:”o problema é a economia, seu estúpido”. Isso lhe garantiu a devida atenção da mídia e fortaleceu seu discurso de campanha).\nTalvez por isso o mercado chinês passou a ser referência global, ante um cenário estagnado e prestes a declinar (a chamada curva descendente da economia) dos EUA.\nSem poder se auto proclamar “a melhor economia do mundo”, ou “a maior superpotência do planeta” (já que Rússia e a própria China tem mostrado suas garras, devido à fragilidade americana), cabe ao futuro presidente reverter esse quadro degradante; senão por seus concidadãos, ao menos por algo que lhes é tão especial : O EGO.\nTriste ver um país com tanto potencial se mostrar vazio em âmbito político, assim como as republiquetas latino-americanas. Sem perspectivas de melhora a médio prazo,sem opções , sem uma “Terceira Via”, sem um discurso (de qualquer um dos lados) consistente e arrojado. Somente o velho jogo de cena. As mesmas cartas marcadas eleitorais que vem movendo a política americana há décadas. Pra corroborar, é só ver que desta feita, Barack Obama conseguiu muito mais dinheiro para sua campanha (cifras extraoficiais chegam a bilhões), mostrando que ele finalmente se tornou um candidato palatável ao sistema. Bom,ele já era em 2008. Agora, apenas consolidou seu papel de “Ronald Macdonld’s” do Status Quo.\nMarcadores: campanha, crítica, eleições, EUA, internacional, Obama


“Leo pede para as pessoas mandarem as fotos e videos para vc e por favor publique esta situação e de utilidade publica foi uma verdadeira falta de respeito ao ser humano,talves através deste conceituado site chegue ao Ministério Publico.”\n23/02/2012 às 22:25\n“ESTA ATITUDE FOI ORRIVEL MAIS PRECISAMOS INVESTIGAR OS FATOS PARA DEPOIS DA UMA OPINIAO COERENTE E JUSTA PARA O ACONTECIDO”\n23/02/2012 às 23:49\n“Deivid estava em frente a casa dele, onde colocou um frezer para vender bebidas e um so que estava dentro da casa dele. Um grupo de amigos estava la, (inclusive eu) vendo os trios finalizando o desfile do bacalhau do beto. ”\n“E mandaram Junior que estava ajudando Deivid desligar o som, o mesmo colocou o dedo na cara dele e mandou desligar ja, Deivid foi explicar ao policial que era o dono, que Jr nao tinha nada haver, e o som estava dentro de casa. ”\n“O policial nem esperou Deivid falar, um deles tirou o cacetete e meteu na cabeça dele, apavorado Deivid quiz ir para cima deles, amigos nao deixaram, levando ele para ser socorrido. Quem estava proximo resolveu revoltado foram tomar satisfaçao.”\n“Para esses que tentaram tomar satisfaçao por tamanha violencia com Deivd, foram recpcionados com Spay de pimenta, mais de 10 pessoas foram atingidas.E eles sairam andando como nada tivesse acontecido.Eu fotografando, fui logo apontada por um, e me sai .”\n24/02/2012 às 00:02\n“E fui guardar a maquina na casa de mamae para eles nao tomarem. E la chegando tive uma queda de pressao, pois foi muito forte a cena que presenciei, e nao posso ver sangue. Hoje passei as fotos para Deivid.Espero que façam justiça. Bater no outro do nada!”\n“o problema dos policiais de Moreno é que são novos, inesperientes e querem aparecer para os amigos ou sei lá quem. mais sabemos que não é assim que a banda toca, isso é mais uma falha dos seus superiores...”\n24/02/2012 às 08:53\n“É uma vergonha para a classe da Policia,temos que fazer valer a pena nos direitos...vamos levar a impressa.”


Tag: Assim na terra como embaixo da terra | Blog da Editora Record\nAssuntoAssim na terra como embaixo da terra\nTrês livros da Record estão entre os finalistas do Prêmio São Paulo de Literatura\nTrês livros do Grupo Editorial Record estão entre os finalistas da edição 2018 do Prêmio São Paulo de Literatura. “Assim na terra como embaixo da terra”, de Ana Paula Maia, e “Nunca houve tanto fim como agora”, de Evandro Affonso Ferreira, concorrem na categoria Melhor livro do ano. Já “Última hora”, de José Almeida Júnior, integra a categoria Melhor livro de autor estreante com menos de 40 anos. Saiba mais sobre os livros a seguir.\nAutora de “Entre rinhas de cachorros e porcos abatidos”, “Carvão Animal” e “De gados e homens”, Ana Paula Maia lança em maio pela Record seu novo romance, que se passa numa colônia penal prestes a ser desativada. Leia entrevista a seguir, em que ela fala sobre sua obra.


Amadeu fica horrorizado ao descobrir o que Josiane fez e decide o que fazer com a filha\nRussel 31 de outubro de 2019, 08:32\nDepois que Josiane for presa, receberá a visita do pai e Amadeu dirá que é para ela contar toda verdade, do contrário não irá defendê-la e um advogado qualquer será indicado para o caso. Depois de dar uma bronca na filha e dizer que ela tem o sangue dos Ramirez e dos Matheus, o galã dirá que a compreende e assim a vilã ficará mais à vontade para contar tudo.\nJô começará seu relato chocante e dirá que quando se encontrou com Jardel e entregou o dinheiro a ele, o mordomo disse que continuaria com a chantagem, então viu o caminhão se aproximando e decidiu empurrá-lo, assim matou o sujeito.\nQuando ao garoto de programa, a megera dirá que ele recebeu de Jardel uma prova contra ela e o rapaz também começou a chantageá-la. Como ele também disse que continuaria pedindo mais dinheiro, acabou morrendo também.\nEm relação a Téo, Jô contou que o rapaz disse que não a denunciaria, mas como estava muito abalado e tinha uma prova contra ela em seu celular, decidiu matá-lo também, só que ele sobreviveu e contou tudo à polícia.\nChocado, Amadeu dirá que Téo amava a filha de verdade, que qualquer um poderia ver isto nos olhos do fotógrafo, mas ela retrucará: “Mas eu pensei: é uma prova. Tá no celular dele. Eu disse que era uma nova fase, fomos para o motel, eu tomei cuidado para não ser vista pelas câmeras“.\nAmadeu ficará horrorizado com a frieza da filha ao falar dos assassinatos sem demonstrar o menor arrependimento, mesmo assim decidirá defendê-la dizendo que apesar de sentir um ‘profundo horror’ a tudo que ela fez, é o pai dela e não irá abandoná-la neste momento.