sexta-feira, 12 de abril de 2013

O FLISOL - Festival Latino­americano de Instalação de Software Livre


Festival Latino­americano de Instalação de Software Livre é um evento que acontece desde 2005, cujo propósito é promover o uso de software livre e a integração de comunidades de usuários de software livre em todos os países da América Latina.
Para executá­-lo, serão realizados, simultaneamente, eventos em cidades diferentes onde especialistas irão instalar,de maneira gratuita e totalmente legal, software livre nos computadores das pessoas interessadas, que comparecerem aos locais confirmados.
O evento, também conhecido como “Install Fest”, consiste em um grande encontro de pessoas com conhecimento em software livre e outras que querem conhecer mais sobre o assunto. Os visitantes deverão levar seus computadores para que voluntários ajudem a instalar o sistema operacional. Durante o período das instalações, são promovidas palestras de introdução(algumas filosóficas, outras técnicas), sobre softwares específicos, de grupos de usuários existentes, etc.
Dentre os softwares que serão instalados, estão distribuições de GNU/Linux e BSD, assim como programas livres para outras plataformas, como Microsoft Windows e MacOS.
O FLISOL tradicionalmente acontece no quarto sábado de abril, e em 2013 será no dia 27 de abril.

O site oficial do evento é: www.flisol.info 

Nesta 9a. edição do FLISOL está confirmada a participação de 20 países, e no Brasil até o momento são mais de 50 cidades de todas as regiões organizando os eventos paralelos. Veja quais cidades brasileiras estão inscritas:

Amparo; Anápolis; Aracaju; Araguatins; Assis; Belém; Brasília; Campina Grande; Campinas;Campo Grande; Campo Mourão; Capanema; Chapecó; Concórdia; Curitiba; Florianópolis; Fortaleza; Francisco; Beltrão; Goiânia; Indaiatuba; Itajubá; Itapipoca; Itapuranga; Jaguaruana; Joinville; Juazeiro do Norte; Luziânia; Marília; Maringá; Mossoró; Natal; Novo Hamburgo; Palmas; Ponta Grossa; Porto Alegre; Pouso Alegre; Quixadá; Redenção; Rio de Janeiro; Russas; Salto; Salvador; Santos; São Carlos; São Gonçalo; São João Batista; São Luís; São Paulo; Senhor do Bonfim; Serra Talhada; Sinop; Sobral; Sorocaba; Tabuleiro do Norte; Uruaçu; Valença; Viamão; Vitória.

Se você deseja organizar o FLISOL em sua cidade, acesse o site do evento e obtenha todas as informações necessárias: www.flisol.info/Brasil/ComoInscreverSuaCidade

Obtenha maiores informações sobre cada uma das sedes do FLISOL no Brasil aqui: 


Além do “Install Fest”, várias cidades também promovem palestras, oficinas, mini­cursos, e espaços abertos para discussões informais. É importante ressaltar que uma das regras para organizar o FLISOL é que o evento deve ser totalmente gratuito. Não pode haver qualquer tipo de cobrança de inscrição, pois o evento é aberto a toda a comunidade. Também só deve existir um local para o FLISOL por cidade.

quarta-feira, 27 de fevereiro de 2013

Inventando Chromebook


Enquanto trabalhava para o Google em 2006, eu tive a sorte de trabalhar um novo sistema operacional. Confesso que não foi criado a partir do zero. Foi uma baseado em uma distribuição Linux - como tantas  ja existentes  nos dias de hoje. Este novo sistema operacional foi originalmente chamada de "Google OS" e  em 2009 foi lançado para o público sob os nomes Google Chrome OS, Chromebook, e Chromebox. Eu escrevi uma patente para ele, # 8239662, intitulado"Sistema operacional baseado em rede Across Devices" que finalmente foi concedida em 07 de agosto de 2012.
Algum tempo depois eu deixei o Google, Eis algumas novidades interessantes sobre a invenção do Chromebook, O Chromebook foi inicialmente rejeitado pela administração do Google. Eu escrevi a primeira versão em Julho de 2006 e o mesmo foi mostrado a diretoria que em vez de lançar o projeto, me deu
apenas uma resposta morna. Meu chefe reclamou, "Você não pode usá-lo em um avião." - Na verdade, como você poderia, sob as cobertas, ele ainda era um esqueleto de distribuição Linux e pode executar qualquer programa Linux instalado.Segundo, o Google OS não foi originalmente escrita para o Chrome ou chamado "Chrome OS". As primeiras versões foram todos baseados no Firefox. Quando escrevi a primeira versão em 2006, o Google ainda não tinha iniciado o desenvolvimento de um navegador próprio, nem tinha o nome de "Chrome" existe como um produto do Google.Versões do Chrome, seguido, em 2007, depois de versões beta de testes internos do Chrome passou a ser passado ao redor dentro do Google. Terceiro, Chromebook definitivamente não era a intenção de ser "outro dispositivo" para navegar na web - como revisores de muitos produtos têm caracterizado os modelos Samsung Chromebook. As primeiras versões eram distribuições Linux nu-ossos, mas totalmente funcional para muitas tarefas, incluindo o desenvolvimento de código para um engenheiro do Google.Eu mesmo utilizado versões do Chromebook, exclusivamente, todos os dias, por mais de um ano como minha caixa de desenvolvimento primário, fazendo-o em muitas viagens de negócios, e até mesmo alguns aviões. Quarto, a principal prioridade do Chromebook - inicialmente - não era escrever um webapp somente sistema operativo.Na verdade, a principal prioridade quando eu comecei a construir o sistema operacional foi a necessidade de velocidade -. Criar um sistema operacional super-rápido Por que se preocupar para escrever um sistema operacional super-rápido? Eu estava frustrado com Windows e Linux, o que eu percebi foram desnecessariamente lento. Por exemplo, na época a minha profissão estava escrevendo webapps para o Google, então eu estava reiniciar o meu navegador com freqüência, às vezes centenas de vezes por dia, para limpar o cache do navegador e os cookies como parte do processo de desenvolvimento de código. Reiniciar o navegador era uma operação particularmente lenta, muitas vezes levando 30-45 segundos, se o IE ou o Firefox, Linux ou Windows. (Chrome não estar disponível em 2006.) No entanto, mesmo tarefas simples, como a exibição de um diretório em um explorador de arquivos foram operações excessivamente lentas, exigindo vários segundos para uma tarefa que deve ser quase instantânea. Alguns segundos aqui, 45 segundos lá, pode não soar como muito de um atraso, mas quando esses atrasos ocorrem centenas de vezes por dia, acrescenta-se a uma quantidade de tempo caro. Qual a solução? Mova todo o sistema operacional desktop em RAM. Ao mover todo o sistema operacional na memória RAM, que imediatamente tirou a mesa dos maiores gargalos de desempenho no sistema operacional: File I / O. Muito poucas tarefas que um sistema operacional executar são intensivo da CPU ou causar outros grandes atrasos que não podem ser atribuída a File I / O. Ao executar o sistema operacional inteiramente na memória RAM, a maioria das tarefas, tornou-se quase instantânea, sem a necessidade de reescrever ou fazer qualquer otimização de desempenho em todos os milhares de aplicativos que compõem o sistema operacional.Por exemplo, o Firefox reiniciar passou de  45 segundos para 1 segundo. Navegando um diretório no arquivo explorador passou de 8 segundos para 0.01 segundos.Mesmo compilar código tornou-se 60% ​​mais rápido, e eu poderia correr não indexadas, greps recursivas de todo o sistema de arquivos RAM residente em menos de 15 segundos. Tente fazer isso com um disco rígido. Ao discutir a arquitetura residente RAM das versões originais do Chromebook, quase todos expressa preocupações sobre a perda de dados. De facto, a perda de dados não foi um problema, por diversas razões.Em primeiro lugar, muitas tarefas foram realizadas como webapps, por isso, enquanto os webapps foram bem escrita, não havia qualquer possibilidade de perda de dados, não há. Segundo, eu tinha configurado meu IDE para auto-save backups para uma unidade de rede, por isso mesmo, no caso de uma falha no sistema apenas alguns segundos de trabalho podem ser perdidos. Em terceiro lugar, alguma versão ocasionalmente sincronizado backups para uma mídia de armazenamento local. Além de que a inicialização e, nunca o sistema operacional acessa qualquer mídia de armazenamento local além de RAM dinâmica. Nunca. Executando um sistema operacional residente RAM Posar outros desafios. Em primeiro lugar, evitar a instalação de todas as aplicações inchados. Uma aplicação inchado monopolizando alguns gigabytes de espaço em disco rígido pode não ser doloroso, mas monopolizando alguns gigabytes de memória RAM é.Bloat tal, devia ser evitado, substituindo a funcionalidade com webapps. Segundo, muitos fornecedores de software não suportam Linux em tudo. Essa funcionalidade também foi substituído por webapps. Assim, rastreando webapps para substituir toda e qualquer funcionalidade normalmente encontrados em uma área de trabalho, tornou-se uma prioridade. É assim que as sementes das webapps no desktop Cromo, embora originalmente escritas em HTML e em execução no Firefox, foram plantadas. Ao executar o sistema operacional de front-end inteiramente na memória RAM é uma mudança fundamental para o status quo de arquiteturas de sistema operacional moderno, Estou convencido de que os benefícios superam os custos. Como vivemos nossas vidas, recursos conectados e online, poucos ou nenhum precisam ser armazenados no mesmo computador como o teclado conectado, e aqueles que são armazenados não precisa ser acessado por girar um prato magnético. 

Texto originalmente excrito por Jeff Nelson em seu Blog