Certificado Missão NASA em 2011 – Seu nome em um microchip !

O link para preenchimento é este:

http://mars9.jpl.nasa.gov/msl/participate/sendyourname/index.cfm

Você deve preencher com:
– Nome
– Sobrenome
– País
– CEP

Veja o meu certificado

http://mars9.jpl.nasa.gov/msl/participate/sendyourname/index.cfm?action=getcert&hashid=AFBF97E068D8ADB023499113AC947BEE

Fisl10 -Mais uma vez, não vai dar para eu ir…:(

Desenvolvedor pobre é um problema, mas um dia eu vou! (achei que nunca iria a Intel e me convidaram para ministrar palestra lá… Uia!)

http://fisl.softwarelivre.org/10/www/

Recomendo altamente para quem puder ir.

Microcrédito de softwares livres. (tomara que aconteça)

Post Interessante. Achei neste site:

http://www.tripsl.com.br/?page_id=17

“ARTIGO AINDA MUITO CRU. Modificações acontecerão diversas vezes por dia.

Microcrédito, ou microfinanciamento de software livre, é o crédito financeiro focado na pessoa, e não no negócio.

Percebe-se uma carência de pesquisa de novos softwares livres, ou adaptação de outros existentes, tradução, documentação e etc.

Avaliando o histórico do mundo do software livre, percebe-se que esta carência, deve-se ao fato dos desenvolvedores disponiveis, terem outras prioridades e dificuldades em captar receita.

Uma grande parte deles, poderia trabalhar mais ativamente no mundo do software livre, se obtivessem uma renda por este período trabalhado, suprindo a redução do período normal de trabalho dele.

“cada indivíduo na terra tem o potencial e o direito de viver uma vida decente. Através das culturas e das civilizações, Yunus e o Banco Grameen mostraram que mesmo o mais pobre dos pobres pode trabalhar e ser agente de seu próprio desenvolvimento” (Comitê do prêmio Nobel de economia)

Acredita-se que o microcrédito a pequenos desenvolvedores de software livre, podem trazer benefícios tanto para a comunidade quanto para a economia, gerando um novo ramo de atividade, baseado na renda obtida da melhoria de softwares já existentes, e criação de novos softwares, e consequentemente de novos slots comerciais. (http://www.cieep.org.br/index.php?page=artigossemana&codigo=604).

Para isto, é necessário não só microcrédito, mas uma completa estrutura de apoio, incluindo:

Servidores de desenvolvimento
Servidores de repositório
Servidores de deploy
Servidores de testes
Ações de marketing
Auxílio na análise do sistema
Auxílio nos testes
Local de trabalho, com estrutura completa e equipamentos a disposição, nos polos de apoio à iniciativa. (PSL)

A proposta, é criar todo o ambiente para o desenvolvedor, livrando ele desta carga desnecessária ao software dele, e também financiar o projeto dele, através de subvenções mensais.

O critério de avaliação é definido por um conselho formado pelo Mantenedor (TripSL), pelos subvencionadores (doadores de fundos), e por pessoas de renome na comunidade.

O desenvolvedor submete o projeto dele, considerando toda a parte técnica envolvida, e o foco ou publico alvo.

O conselho, avalia o projeto, e junto com o desenvolvedor, define as questões administrativas, financeiras, alocação de recursos humanos, e as etapas de desenvolvimento.

Se houver necessidade, o conselho determina um analista, para auxiliar o desenvolvedor a especificar o sistema dele em módulos, fases ou ações. Este analista poderá recompensado, nos mesmos moldes do desenvolvedor.

Após a conclusão do projeto, o mesmo vai para uma fila de avaliações, e será reavaliado pelo conselho, e se possível por empresários do ramo do projeto, para determinar a relevância dele para a comunidade de software livre, ou, no caso de idéia inovadora com foco comercial, a aceitação dele no mercado.

Este conselho determinará por quanto tempo o projeto receberá subvenções mensais, e qual a periodicidade de avaliação das metas atingidas. A cada período de avaliação, o conselho determinará se o projeto continua ou não a receber subvenções econômicas, ou se a subvenção será retida, para destinar o valor a outro projeto mais prioritário.

Como funciona o projeto fora do mundo virtual?

Empresas, ONGs e pessoas, fazem uma doação ao mantenedor do projeto.

O conselho determina quais projetos receberão subvenção, qual o valor mensal, e a partir de quando. Os valores variam de 250 a mil reais por mes no máximo. Projetos que dependam de mais crédito, terão as etapas reorganizadas para encaixarem neste limite.

O desenvolvimento é acompanhado pela equipe do mantenedor, e este acompanhamento estará livre para a comunidade também.

Diariamente o sistema avaliará os commits do desenvolvedor, as listas de discussão, os bug reports e os testes unitários…

Ao final da subvenção, com o beta do software pronto, a equipe do mantenedor irá iniciar as ações de marketing, fazendo com que a comunidade de software livre, passe a participar do projeto, ajudando no desenvolvimento e divulgação dele de forma viral.

Os softwares que podem funcionar como serviço, poderão ter algumas partes não GPL, para permitir o slot comercial e de marketing, e gerar renda. Mas deverão ter uma versão totalmente gratuita.

Os softwares categorizados como inovação de mercado, poderão receber outro modelo de subvenção ao final desta, baseado na parceria e divisão dos lucros de comercialização.

Como será feita a distribuição do código?

O mantenedor ficará responsável por manter pacotes debian atualizados dos softwares desenvolvidos, mas o desenvolvedor será responsável por criar os arquivos necessários para a compilação do pacote, scripts de instalação e configuração do mesmo.

Caso seja uma tradução, plugin ou adaptação, o mantenedor irá manter contato com os desenvolvedores originais, para incluir estas alterações nos pacotes oficiais.

Vídeo da Palestra Intel Moblin Day 2009 – HarvesterCORE1

Para quem não viu o Vídeo da Palestra Intel Moblin Day 2009 – HarvesterCORE1, qual foi removido do site da Intel, junto como outros de outros participantes.

HarvesterCORE1_Moblinday_480x280_16x9.flv.zip (75.5 Mb)

Links das noticias

http://www.vivaolinux.com.br/topico/Open-Source-News/Intel-Moblin-Day-12-de-fevereiro-de-2009-em-Sao-Paulo
http://www.intel.com/portugues/pressroom/releases/2009/0205.htm
http://www.nextgenerationcenter.com/v3/web/noticia.php?noticia_id=51
http://www.e-thesis.inf.br/index.php?option=com_content&task=view&id=4752&Itemid=59
http://moblin.ihvweb.com/index.php/entry/displayEntries/1660/portuguese/1/product_category
http://pt-br.wordpress.com/tag/intel-moblin-day-20009/
http://www.convergenciadigital.com.br/cgi/cgilua.exe/sys/start.htm?infoid=17699&sid=78
http://www.maxpressnet.com.br/noticia-boxsa.asp?TIPO=CE&SQINF=360343

Regras de Ética Computacional que sigo (tirado do meu antigo Blog)

 

1. ­ SER HONESTO E DIGNO DE CONFIANÇA

Um Desenvolvedor de Software tem o dever de ser honesto sobre suas limitações e competências, evitando conflito de interesses, colocando o bem-estar do grupo e a integridade das empresas sempre em primeiro plano, não fazendo declarações ou atos enganosas e/ou prejudiciais.

 

 

2. ­ RESPEITAR A PRIVACIDADE
Dado o escopo da pesquisa e desenvolvimento, é de responsabilidade dos integrantes manter a privacidade e integridade dos dados e informações, assegurando sua proteção contra acesso não autorizado ou revelações acidentais a indivíduos não autorizados. Nenhum desenvolvedor de software deve acessar ou usar o sistema, o software ou o arquivo de dados sem permissão apropriada. Os desenvolvedores de software não devem utilizar de sua autoridade ou conhecimento especial para acessar qualquer informação privilegiada, exceto quando necessário para o cumprimento de suas obrigações e responsabilidades. Mesmo assim, tal acesso deve ser o mínimo necessário para a realização da tarefa, e deve ser condizente com a regulamentação interna da organização. Independentemente da forma de obtenção, administradores de sistema devem manter a confidencialidade de informações sigilosas e reservadas.

 

 

3. ­ HONRAR A CONFIDENCIALIDADE
O respeito às obrigações de confidencialidade para com os dados das empresas/organizações é imprescindível, em todos os aspectos, sendo vetada a revelação de quaisquer informações internas para pessoas que não fazem parte do grupo de trabalho/desenvolvimento.

 

 

4. ADQUIRIR E MANTER A COMPETÊNCIA PROFISSIONAL
A educação contínua é um requisito básico, com a finalidade de atualização e extensão dos conhecimentos teóricos e técnicos, seja através de estudo, prática e compartilhamento de informações e experiências com os companheiros e profissionais da área, devendo esta troca ser recíproca e mútua.

5. ­ DEMONSTRAR PROFISSIONALISMO E COMPORTAMENTO EXEMPLAR NA REALIZAÇÃO DE SEUS DEVERES
O alto nível de qualidade no trabalho é essencial, e o esforço para mantê-lo deve ser constante, assim como o profissionalismo em seu desenvolvimento. O comportamento ético deve ser também estendido à vida pessoal do Cientista da Computação e em outras Áreas co-relatas, devendo este ser correto em qualquer atitude que tomar, em qualquer âmbito.

 

 

6. ­ COMUNICAR-SE SEMPRE COM OS COLEGAS
A comunicação entre Cientistas da Computação e outras áreas co-relatas, deve ser feita de forma regular e transparente, contendo todas as informações que possam, de alguma maneira, afetar o trabalho. Devem ser reveladas para a equipe informações tais como: compartilhamento de recursos comuns, manutenção de segurança, ocorrência de monitoramento de sistemas, situações de emergência e outros assuntos relevantes.

 

 

7. ­ TER RESPONSABILIDADE SOCIAL
É de suma importância aumentar o entendimento dos assuntos sociais e legais relativos aos ambientes computacionais, comunicando esta compreensão aos outros e encorajar a escrita e adoção de políticas e leis consistentes sobre sistemas de computação seguindo princípios éticos.

 

 

8. ­ IDENTIFICAR CLARAMENTE SUA PRÓPRIA OPINIÃO
Nenhum Cientista da computação e áreas co-relatas, possui autoridade para falar ou dar declarações em nome da empresa/organização, de forma pública ou com a mídia, sem que esta responsabilidade lhe seja delegada pelo coordenador/gerente de projetos. As opiniões dos Cientistas da Computação e áreas co-relatas devem representar suas opiniões pessoais, e não a opinião do grupo/trabalho/organização, a menos que esta responsabilidade tenha sido diretamente delegada. Cada cientista da computação deve, sempre que consultado, apresentar sua opinião de maneira imparcial, devidamente acompanhada de observações sobre preferências pessoais ou falta de maior conhecimento. Quaisquer conflitos de interesse devem ser expostos imediatamente. Os membros do grupo/trabalho/organização devem entender e deixar claros estes aspectos a respeito de suas declarações, sejam elas verbais ou escritas.

Mauro Risonho de Paula Assumpção
Desenvolvedor de Software / Analista de Segurança e Suporte

WebOS – Sistema Operacional Palm Open-Source (até quem fim…eu que diga…rss)

Eu me lembro, como hoje. Trabalhava em uma pequena empresa da cidade de Jaguariúna-SP, chamada JRS Computação, por sinal foi um dos lugares mais interessantes que já trabalhei, pois a política da empresa era reconhecer o esforço e trabalho de seus funcinário. É uma empresa, com “clima de amizade”, pessoal legal. Fiz bons contatos e boas amizades.

Nesta época, sai de outra empresa, um grande atacado em Campinas-SP, onde usam sistema da Microsiga, (na época Protheus 6.10) e coletores Symbol 1550 (lentos e com pouco tempo de bateria), que fica no centro da cidade, pois estava fazendo faculdade em Ciências da Computação na FAC3, para me mudar para Jaguariúna-SP e trabalhar com dispositivos móveis, no caso Palm.

Lembro-me que fui designado para desenvolver um software para fazer vistorias em Imóveis e que se conectava a um sistema de ERP, que a JRS Computação, havia desenvolvido iniciamente em Clipper a anos e que naquela época (2005), tinha portado para Delphi 7, creio eu uns 3 anos (não tenho certeza).

Bom. Eu tinha que programar isso em um “Quase-Pascal-Delphi”, chamado PocketStudio 2.0

Havia muitos problemas nesta linguagem, como por exemplo:

* Exibir um erro na depuração em uma linha em branco (onde não existia nenhum código – linha em branco mesmo e apontava que o erro estava ali.)
* Travamentos ao sincronizar.
* E outros que não me lembro agora.

Mas na verdade, eu também não dominava Delphi, mas deixei bem explícito isso na contratação e sim Clipper, na época, mas quem aprende uma linguagem e tem vontade e esforço, aprende qualquer uma (como agora com Cobol).

Foi bem recompensador, pois a maior parte do sistema consegui desenvolver.

Agora hoje tenho a notícia que a Palm, liberou o código-fonte do seu sistema operacional WebOS (acho um pouco tarde para Palm, pois perdeu um bom mercado, sendo que foi pioneira na área de mobiles), mas acho que muitas empresas possuem Palms antigos ou sem este SO, só dando vantagens a gerações futuras de Palms.

Mas, fico contente, pois quem sabe volto programar em Palms.

http://opensource.palm.com/packages.html

Vírus no Linux? Difícil…

Por que é que vírus de Linux não é mais do que um assunto para rodas de bate-papo?  Por que é que os vírus para Linux não nos afetam do jeito que os vírus para produtos Microsoft afetam, a usuários do Windows em particular, e aos cibernautas em geral?

Existem várias razões e “porquês” sobre o assunto vírus-de-Linux é abobrinha. Quase todas elas já familiares para quem usa o kernel, quase todas elas ainda desprezadas por quem gosta de ser enganado (tagarelando abobrinhas tipo “é menos atacado porque é menos usado”). Mas há uma razão, muito importante, que estudiosos da evolução biológica podem apreciar. Antes, porém, devemos saber porque o Linux não dá mole para vírus.

Para que um vírus infecte um programa executável num sistema com kernel Linux, numa distro GNU/Linux (Debian, Slackware, RedHat, Suse, Ubuntu, Kurumin, Mandriva, etc.) por exemplo, o executável precisa estar em arquivo com permissão de escrita para o usuário que esteja ativando o vírus. Tal situação é incomum. Numa instalação desktop, via de regra os arquivos executáveis têm como dono (owner) o administrador do sistema (root), e rodam em processo de usuário comum. Ou seja, a partir de uma conta não-privilegiada.

Além do que, quanto menos experiente for o usuário, menos provável que tenha ele mesmo feito a instalação do executável, e portanto, que seja o owner do arquivo correspondente. Assim, os usuários de Linux que menos entendem dos perigos de infecção viral são os que têm pastas pessoais (diretório home) menos férteis para isso.

Prosseguindo, ainda que um vírus consiga infectar um programa executável, sua missão de proliferar-se esbarra em dificuldades das quais os limites nas permissões do dono do arquivo infectado são apenas o começo (para neófitos, em sistemas com um só usuário (no caso, se fosse, um sistema Windows, o usuário instala seu sistema operacional, no seu computador com a conta Administor e a usa, como um único usuário comum, com todos os direitos ilimitados a conta, porque caso queira instalar qualquer programa, a qualquer momento, imagina não ter que digitar senha ou qualquer restrição a isso), esses limites podem desaparecer se a conta root for usada descuidadamente).  As dificuldades continuam nos programas para conectividade, por serem esses no Linux construídos conservadoramente, sem os recursos de macros em alto nível que têm permitido, por exemplo, a recentes vírus de Windows propagarem-se tão rapidamente.

Esse conservadorismo não é uma característica do Linux, mas reflete diretamente importantes diferenças na base de usuários de plataformas livres e proprietárias. Diferenças na forma como essas bases atuam no processo de desenvolvimento, e na forma como a robustez e a popularidade dos programas é afetada por essa atuação, através dos respectivos modelos de licença e de negócio. Na forma, por exemplo, em que vacinas atuam.  As lições aprendidas pela observação do que acontece no outro modelo servem, no modelo colaborativo, para vacinar não o software em si, mas o processo e a estratégia de desenvolvimento dos softwares livres, livres inclusive das estratégias de negócio de interessados que lhes sejam confiltantes.

Aplicativos e sistemas baseados em Linux são quase todos de código fonte aberto. Devido à quase totalidade desse mercado estar acostumado à disponibilidade do código-fonte, produtos distribuídos apenas em formato executável são ali raros, e encontram mais dificuldade para firmar presença. Isso tem dois efeitos no ecosistema viral, se considerarmos que a propagação ocorre em formato executável. Primeiro, programas com código fonte aberto são lugares difíceis para vírus se esconderem. Segundo, a (re)instalação por compilação do código-fonte corta completamente um dos principais vetores de propagação dos vírus.

Cada um desses obstáculos representa uma barreira significativa. Porém, é quando essas barreiras atuam em conjunto que a vida do vírus se complica. Um vírus de computador, da mesma forma que o biológico, precisa de uma taxa de reprodução maior do que a taxa de erradicação (morte), para se proliferar. Na plataforma Linux, cada um desses obstáculos reduz significativamente a taxa de reprodução. E se a taxa de reprodução cai abaixo do nível necessário para substituir a população erradicada, o vírus está condenado à extinção, nesse ambiente — mesmo antes das notícias alarmistas sobre o potencial de dano às vítimas.

A razão pela qual nunca vimos uma epidemia de verdade com vírus de Linux é simplesmente porque nenhum vírus conseguiu, até hoje, prosperar no ambiente que o Linux propicia. Os que já surgiram com esse alvo não são mais do que curiosidades técnicas (Staog foi o primeiro deles, e o único observado à solta, até 2005, foi o Bliss). A realidade é que não existe vírus viável para Linux.

Isso, é claro, não significa que nunca possa haver uma epidemia viral envolvendo o Linux. Por outro lado, isso significa que o vírus precisaria ser muito inovador e bem arquitetado para ter sucesso prosperando nesse ecosistema (do Linux), que é hostil para código furtivo. E também, que outros especialistas possam entender a questão de maneira diferente.

Convite para LPI 3 Security

Fui convidado para fazer a prova da 4linux, através de curriculum, mas estava sem condições para fazer, naquele momento:

http://www.lpibrasil.com.br/noticias/news161208.php

Nota da Palestra Intel Moblin

www.intel.com/portugues/pressroom/releases/2009/0205.htm

Removido o video sobre HarvesterCORE1, do Moblin Day

Fiquei triste com a organização do evento Moblin Day, devido a remoção (sem motivo aparente) do video sobre o projeto HarvesterCORE1.

Consegui anteriormente, obter o video, mas como são 77 megas, o upload está sendo realizado e será demorado