Isaque Alves

Quase inimaginável, mas a microsoft conseguiu mais uma vez chamar atenção da comunidade de usuários de software livre. Dessa vez, claro, algo sem o menor nexo.  Mas todo o crédito da façanha deveria ir para os agentes do USPTO (United States Patent and Trademark Office)…

O USPTO deu direitos a exploração de patente sobre algo denominado pela MS de “Rights Elevator”, em tradução livre:

Systems and/or methods are described that enable a user to elevate his or her rights. In one embodiment, these systems and/or methods present a user interface identifying an account having a right to permit a task in response to the task being prohibited based on a user’s current account not having that right.

Sistemas e/ou métodos[...] que habilitem ao usuário elevar seus direitos. Esses sistemas e/ou métodos oferecem uma interface de usuario identificando uma conta como portadora de um direito de executar uma tarefa normalmente proibida com base em um tipo de  conta de usuario que não possuiria normalmente aquele direito.

O mais impressionante é que esse tipo de ’sistema ou método’ vem sendo usado desde a invenção de sistemas computacionais multiusuário. Gnu/Linux, Apple Mac OS X, BSD, quer dizer, muitos ambientes operacionais usam o sudo para promover elevação de direitos de usuarios comuns para realizar tarefas administrativas .Uma simples visualização da página de resumo histórico do sudo < http://www.sudo.ws/sudo/history.html > já deveria descaracterizar tal ‘invenção’ ou ao menos situá-la como ‘invencionice’…

Conceder essa patente à microsoft é como reconhecer propriedade intelectual sobre a roda para qualquer indústria de automóveis, sob alegação de que ninguém patenteou antes porque não sabia explicar para que serviria a roda ou como ela funcionava e deveria ser construída.

É certo que a Microsoft não está nem um pouco preocupada com isso, porém se ainda existem coisas como ‘direito adquirido’ ninguém poderá acusar a comunidade de violar uma patente absolutamente inconsistente e ilegítima (a data de postulação do direito é 22 de abril de 2005). Isso também só torna mais perceptível a inépcia do USPTO frente aos direitos do comum.

Para observar algo que poderia ser encarado como displicência do USPTO, entre as referências consultadas há páginas de manual do linux, starter guides da red hat, etc. Quer dizer: havia e há motivos mais que suficientes para se recusar tal pedido.

Agora é esperar para ver as alegações ou justificativas dessa aberração jurídica.

Quase posso imaginar como seria ter que usar uma interface gráfica do tipo ‘next > next > fail’ para ‘instalar’ o ‘microsoft sudo’ nos meus Ubuntu, Fedora e Gentoo… e ao final, conseguir uma dialog box do tipo: “Microsoft sudo executou uma operação ilegal e será fechado.”

Microsoft Stinks, USPTO Sucks…

Semana passada, após uma série de problemas indesejados com hardware de produção, decidi que iria mesmo utilizar um dos sistemas disponíveis para controle de versão. Inicialmente cogitei utilizar o SVN, que já conheço e utilizo, embora sem tanta frequência. Após uma boa pesquisa, e notando que o NetBeans (meu IDE favorito do momento) possuia suporte ao Mercurial, decidi experimentá-lo.
Sim. Decidi, mas não sem antes procurar entender os recursos que ele me ofereceria.

Por que o Mercurial?

Bem, também pensei isso:

- “Ora, por que arriscar com um sistema que ainda terei que aprender a usar?”

A resposta foi simples: Pela facilidade e reduzida quantidade de recursos a serem utilizados.

O Mercurial, ao contrário do Subversion (SVN) e do Concurrent Version System (CVS) não precisa de um processo servidor em execução para realizar efetivamente o controle de versão.

Por que então, não usar o GIT, famoso por ter sido escrito por Linus Torvalds?

Novamente o quesito simplicidade. O GIT é realmente muito bom, mas no momento, eu precisava de algo simples. então, o Mercurial foi a opção.

Não pretendo descrever os recursos do Mercurial nem traçar um paralelo em relação a outros CVS, apenas quero relatar a minha experiência.

Meu primeiro ‘repositório’

Vamos direto ao assunto.

Trabalho com desenvolvimento para web, e particularmente uso PHP para construir a parte lógica dos sistemas, preciso constantemente revisar algumas partes de código (acho que todo programador faz isso, ou não?). Tô enrolando de novo, não é? Foi mal…

Pois bem. Criei uma aplicação de teste para fazer esse primeiro repositório. (Lembrando que eu uso GNU/Linux, então “Terminal”,”emulador de terminal”, “linha de comandos”,”mkdir”, “touch”, “mkdirhier”, serão termos constantes aqui…).

Como vocês podem notar, é uma aplicação simples. Apenas esbocei uma possível estrtura, não usável talvez na ‘vida real’…
Observem o uso particular do comando mkdirhier:

isaquealves@localhost$mkdirhier application/{view/{css,html},libs/{js,php},doc/{html,css}}

Ele cria toda a estrutura de diretórios necessária para o inicio do trabalho.
Eu poderia ter usado mkdir -p, mas… Keep It Simple, Stupid…

Partindo do princípio de que eu tenho o mercurial instalados…
Agora estarei mostrando como criar o repositório. Por etapas, vou mostrar o conteudo de todos os diretorios, depois, criar um arquivo index.html em application/docs/html com o conteudo “Aqui ficará o conteudo da Documentação”, um arquivo index.php em application sem conteudo, um arquivo css e um html em application/view/css e application/view/html e inicializar o repositorio. Depois de inicializado vou confirmar a adição de todos os arquivos ao repositorio.

Até aqui, o único comando novo que apareceu foi o hg init. Esse comando inicia o repositório.
Os próximos passos serão clonar o repositório, adicionar os arquivos ao clone, o que eu demonstrarei numa próxima postagem. Por enquanto, fiquem com isso…