Tudo Sobre Nada

Scanner em Rede usando SANE

Existem algumas coisas interessantes que apenas se conseguem fazer em Linux/Unix. Uma dessas coisas é colocar um simples scanner em rede.

Há umas semanas andei a configurar uma coisa deste género na sala de Linux existente no Departamento de Química da FCT. Uma das máquinas tem um scanner ligado e, através do sane, permite que todas as outras máquinas da sala digitalizem a partir dele.

Hoje andei a configurar um setup semelhante em casa, ligando um scanner USB ao meu servidor doméstico[1]:

O Servidor

A configuração deste serviço é relativamente simples. Depois de confirmar que o scanner é correctamente reconhecido no servidor, correndo "scanimage -L" numa shell, é necessário acrescentar o serviço sane ao ficheiro "/etc/services", adicionando a linha:
sane     6566/tcp     saned     # SANE network scanner daemon

A seguir configura-se o daemon xinetd para escutar a porta do serviço sane e arrancar o saned quando receber um pedido de algum cliente, criando na directoria "/etc/xinetd.d" um ficheiro "sane" com o conteúdo:
service sane

{
disable = no
socket_type = stream
server = /usr/sbin/saned
protocol = tcp
user = root
group = root
wait = no
bind = 192.168.0.1
}

A linha "bind = 192.168.0.1" significa que este serviço só estará disponível na interface com este endereço, que no meu caso é a que está ligada à rede interna. Apesar de ter uma firewall configurada, convém limitar as interfaces onde os serviços escutam sempre que possível.

O último passo é adicionar ao "/etc/sane.d/saned.conf" os endereços das máquinas autorizadas a usar o scanner. Eu autorizo qualquer máquina na minha rede interna:
192.168.0.0/24

Agora só falta fazer "/etc/init.d/xinetd restart" para reiniciar o xinetd.

Os Clientes

Nos clientes Linux só é necessário adicionar o endereço (ou nome) do servidor ao ficheiro "/etc/sane.d/net.conf". A partir daqui todas as ferramentas de digitalização[2] vão ver o scanner remoto.

O problema em Windows é que parece que todo o software existente, ou está abandonado ou não vê alterações há bastante tempo. O que estou a usar é o SaneTwain que já não é actualizado desde 2002, mas parece ter toda a funcionalidade necessária, e o protocolo do sane não mudou desde essa altura. Talvez seja essa a razão do "congelamento". Seja como for, mandei um email ao autor para confirmar.

Mas voltando ao que interessa, para instalar o SaneTwain é necessário fazer o download do programa, e copiar o ficheiro "SaneTwain.ds" para dentro da directoria "twain_32" existente na directoria de sistema do Windows[3]. Se não existir nenhuma directoria "twain_32", é porque o TWAIN não está instalado, e é necessário fazê-lo[4].

Depois digitaliza-se como se faria com um scanner local (por exemplo, no Photoshop far-se-ia "File -> Import -> SaneTwain").

Actualização: O autor do SaneTwain já me respondeu, afirmando que o projecto se encontra activo, estando até uma nova versão na calha.

[1] Um modesto Pentium a 133MHz com 96Mb de RAM, que consegue desempenhar esta tarefa lindamente.
[2] Xsane, Kooka, etc.
[3] Por exemplo, "C:\Windows\twain_32".

[3] Se algum scanner já foi configurado na máquina, o TWAIN já vai estar instalado. Senão, copiam-se os ficheiros contidos neste zip para a directoria de sistema do Windows e cria-se lá uma directoria chamada "twain_32".

Ahhh...

Não sei se é por estar a usar ALSA, mas sei que hoje fiquei agradavelmente surpreendido ao reparar que a definição "Surround 5.1" no xine agora realmente funciona. Menos mal, já não é necessário ir ao Windows para ver DVDs com som de qualidade.

Firewalls com o FireHOL

O FireHOL é um interpretador de regras para firewall (stateful), em Linux. Lê um ficheiro de script e gera as regras iptables adequadas.

Em casa uso-o como forma de gerar as regras para a minha gateway/servidor. Em parte porque ainda não me dei ao trabalho de aprender a usar o comando iptables, e também porque aquilo consegue gerar de uma forma simples uma série de regras que me dariam um trabalhão para gerar manualmente como, por exemplo, bloquear conexões de endereços IP unroutable[1] vindos da Internet.
version 5


interface eth0 lan
policy drop
server ssh accept
server cups accept src myworkstation
client all accept

Este pequeno script fecha todas as portas da máquina (a directiva "policy drop", que até não era necessária pois está activa por omissão) e abre apenas o ssh e a impressão remota usando CUPS/IPP. Este último serviço fica apenas acessível à máquina myworkstation. Por fim, a directiva "client all accept" indica que todas as ligações que partem desta máquina são permitidas.

A linguagem é bastante directa e permite fazer scripts de fácil compreensão, mas é também poderosa e extensível. O FireHOL é um script bash e permite incluir no script de configuração estruturas de controlo da shell, como if ou for. Também permite criar regras mais complexas do que simples accepts/drops/rejects, como NAT, redirecções de portas e também permite criar proxies transparentes.

O curioso é que suporta serviços, como o NFS, que não são deterministas na porta em que ficam à escuta. O FireHOL resolve isto recorrendo ao comando "rpcinfo -p", durante a inicialização, para descobrir quais as portas que deve abrir. Isto funciona quer a firewall esteja na mesma máquina que o servidor NFS, quer esteja numa máquina remota.

Esta semana queria colocar o FireHOL num servidor e descobri que não suportava NIS nem o servidor de quotas remotas NFS. Fiz um Request For Enhancement e afinal a versão que está no CVS já suporta o rquotad, mas não NIS. Como bom membro da comunidade que sou, acabei por fazê-lo eu mesmo, basicamente pegando nas regras do NFS.

Penso que virá incluído na próxima versão, vamos ver.

O que é pena foi não ter conseguido criar um suporte a 100% para NIS, pois é impossível conciliar uma firewall e a replicação master/slave quando esta existe, pois é lançado um novo daemon (yppush) a cada evento de replicação e é impossível determinar as portas onde vai escutar a tempo de inicialização. Não se pode meter uma firewall entre dois servidores, apenas entre estes e os clientes.

Actualização: todas as modificações que fiz ao FireHOL estão presentes na versão lançada recentemente. :)

[1] Endereços reservados para uso em redes internas. Podem indicar intenções suspeitas se aparecerem vindos da Internet.

Demasiado Tempo Livre

Definitivamente há por aí gente com tempo livre a mais, e com alguns parafusos a menos.

Um australiano fanático por Macs "vintage" decidiu tentar correr a última versão do MacOS X (Panther) num Centris 650, com um processador a 25MHz e 68Mb de RAM.
O problema é que o MacOS X só corre em PowerPC, sendo necessária uma camada de emulação fornecida, neste caso, pelo PearPC, um emulador de PPC que corre em Windows e Linux. Ora o MacOS 8 não está nesta diminuta lista, sendo assim, também foi necessário instalar lá Linux.

Resultado, aquilo vai levar apenas 1 semana para fazer boot...

Burocracia

Estive há pouco na loja do cidadão a tratar de uns assuntos e, apesar de já saber como estas coisas funcionam, a burocracia dos serviços públicos nunca deixa de me espantar. Gostava que alguém me explicasse porque é que para pedir seja o que for à Segurança Social se tem de preencher sempre uns impressos onde se escreve o nome, morada - com distrito, concelho, ... - e telefone pela n-ésima vez... Será que por lá ainda ninguém descobriu que o número de identificação já tem essa informação associada? É enervante... Se não se tivesse de perder tempo a preencher tralha desnecessária, se calhar não se tinha de esperar horas para se ser atendido!1

1 Por acaso hoje esperei pouco mais de uma hora. Foi bom, porque da última vez só tive de esperar umas três...

Nham, Nham...

O Linux parece não ser a única plataforma a entrar em força na área da produção cinematográfica. Mas enquanto que o Linux está a expandir-se vindo das render farms e clusters em geral para o desktop dos artistas, a Apple parece estar a seguir em sentido contrário.

Saíu recentemente em DVD a trilogia Star Wars (episódios IV, V e VI) e todo o trabalho de recuperação foi feito recorrendo a uns belos 600 dual-G5 a 2GHz, juntos com um total de 400 terabytes de storage.

Tudo isto para processar 180.000 frames, cada uma com 70Mb.



A Dura Verdade

Este artigo baseia-se em algo muito simples, vale a pena trocar uma funcionalidade por um bug?

Bem sei que já aqui falei, mais ou menos, disto, mas é algo que me incomoda profundamente. Porque é que a reconhecida robustez e qualidade do software opensource de nível técnico ou servidor é contrastada com a imperfeição e rudez da maioria dos programas gráficos?

Não digo que na maior parte dos casos não façam bem o trabalho a que se destinam, mas nota-se quase sempre uma falta de polimento que não é decorrente de nenhuma falha do modelo de desenvolvimento, mas sim uma espécie de tendência irritante para deitar os problemas para debaixo do tapete.

Falo de coisas simples, como um Firefox que pega erradamente nas cores do menu definidas pelo tema do GNOME, fazendo com que usar o tema Simple signifique ter os itens realçados nos menus com texto branco sobre fundo branco, invisíveis; Ou um Thunderbird que, com certos temas, desenha erradamente toda e qualquer progress bar, fazendo com que o rectângulo que "cresce" comece e acabe fora da sua moldura, ou teima em pendurar durante alguns segundos (poucos, mas o suficiente para que o GNOME pense que bloqueou e lance a janela de "not responding") sempre que se fecha e se têm contas IMAP1. Os exemplos podiam continuar.

São estas pequenas imperfeições, que apesar de parecerem triviais e irrelevantes deixam ficar um travo amadoresco e pouco profissional. O pior é que estes pequenos problemas são conhecidos e resistem ao lançamento de versão após versão.

Daqui vem a minha frase inicial. Eu prefiro sempre não ter uma funcionalidade, se isso significar que as que existem funcionam convenientemente. Prefiro dizer que o programa não faz x do que ter de reconhecer que é uma porcaria porque faz x de uma forma incorrecta.
Uma forma de tornar este meu princípio abstracto em algo concreto é dizer que prefiro algo do tipo Fluxbox, estável e consistente, do que um KDE com uma série de pequenos glitches (normalmente uso GNOME, que está no meio) ou que prefiro gravar ISOs para CD usando o cdrecord directamente na linha de comando do que ter de aturar uma interface mal conseguida de algum frontend.

É preciso alguém enfiar nas cabeças dessa gente que um programa gráfico tem de ser tão robusto quanto um SGBD e ao mesmo tempo elegante e bem desenhado. E entulho gráfico, preferências a granel e instabilidade2 não são sinónimo de nenhuma destas características.

Para isso é preciso que comecem a ser picuínhas, ou a dar ouvidos a quem o é, não minimizando a importância dos botões estarem espaçados 3 pixels em vez de 2, por exemplo. Porque é este nível de exigência (gráfica) que ocorre numa Microsoft ou numa Apple. E para sermos melhores que eles não basta que o nosso código invisível seja mais capaz, aquilo que os utilizadores vêem também tem de o ser. A elegância gráfica é tão ilustrativa do profissionalismo e qualidades do programador (que neste caso também é o designer de interfaces) como a qualidade do código que produz.

Ainda não estou a ponto de concordar com os que dizem que o Linux (ou o Unix em geral) é só para servidores e não tem lugar no desktop, mas admito que o panorama actual não aponta para outra coisa...

1 Tem piada que nenhum destes problemas aparece nas versões para Windows, o que é bem exemplificativo do que falo quando digo que o problema não está no modelo de desenvolvimento. Além disso também serve para ilustrar a percepção de polimento. Tanto o Firefox como o Thunderbird em Windows me parecem aplicações perfeitamente capazes de tomar o seu lugar no desktop de qualquer pessoa, enquanto as mesmas versões em Linux me parecem ainda imaturas.

2 Reconheço que aqui já não estamos muito mal, mas ainda não estamos lá.

Workshops

Estive hoje na FIL a pretexto do workshop Internacionalização de Software Livre.

Basicamente foram duas apresentações, uma do projecto gnuLinEx, a distribuição de Linux da Junta da Extremadura de Espanha, e outra da Caixa Mágica. Foram ambas interessantes, apesar de já ter visto o Paulo Trezentos fazer mais ou menos aquela mesma apresentação, da Caixa Mágica, na FCT, por ocasião do 5º Encontro de ASPI.

No mínimo deu para ficar com a sensação que em Portugal somos muito bons a produzir legislação para promover o software livre no sector público e a criar comissões para analisar a sua viabilidade, enquanto os nossos vizinhos espanhóis são pessoas de acção. Duvido muito que um projecto com a dimensão e momento do gnuLinEx pudesse ocorrer em Portugal, com toda a falta de iniciativa (em geral), desconfiança e dependência dos fornecedores de software proprietário que por cá existe. Mesmo com o empenho e a boa vontade do pessoal da Caixa Mágica.

Pecou pela falta de assistência, eramos muito poucos, mesmo muito poucos. Penso que em futuros eventos deste tipo deve evitar-se um horário como o de hoje (17h a um dia de semana é lixado, um sábado de manhã ou início da tarde seria preferível) e tentar investir mais na promoção (não é preciso muito, propor um artigo no Gildot teria sido suficiente).

Santa Ignorância

O artigo «30th Anniversary of Pascal» (do UCSD Pascal, não da linguagem em si), no Slashdot, fez-me recordar os tempos em que programava em Pascal.

Já lá vão alguns anos, uns 8, desde que fiz o meu primeiro programa. Era em Turbo Pascal e o seu propósito era gerar aleatoriamente 10 chaves para o Totoloto. Começou por ser muito simples, como é óbvio, mas depois comecei a usá-lo como forma de aprender mais qualquer coisa. A primeira fase foi tentar fazer uma interface pseudo-gráfica, em modo texto, com um menu onde se podia escolher quantas chaves se queria gerar, guardar as chaves geradas num ficheiro ou sair do programa.

Claro que podia ter usado a biblioteca Turbo Vision, incluída no Turbo Pascal, para fazer a interface, mas a orientação por objectos era coisa que me transcendia completamente na altura e eu não fazia a mínima ideia de como lhe pegar. Acabei por reinventar a roda. E todos nós sabemos onde isso vai dar... No final tinha uma bela interface com relógio e tudo, mas mesmo lenta (no meu Pentium 100 não se notava nada, mas no 286 que um primo meu tinha... via-se claramente o programa a desenhar o ecrã).

Depois tentei fazer aquilo imprimir, com partes do texto a negrito e outras em itálico. Peguei nuns manuais de uma HP Deskjet 550C, e de uma Epson qualquer, e passadas algumas horas estava feito.

Resultado final: mais de 1.000 linhas de código(!) para uma coisa tão simples.

Depois quando entrei para a faculdade foi como se tivesse começado do zero1. Na altura, na cadeira de Programação I dava-se Pascal ISO usando o GPC (GNU Pascal Compiler), sem floreados, apenas boas regras de programação.

Hoje, quando olho para o código desse meu primeiro programa, até tenho suores frios. É incrível o grau de mau daquilo... "if/else" ad nauseum, atingido profundidades medonhas. Montes de linhas de código repetido que podiam facilmente ser substituidas por meia dúzia de linhas num ciclo "for", etc. Mas é um bom exercício, vejo que evoluí bastante desde essa altura e, ao mesmo tempo, relembro-me do que se sente ao ver código tão mau, e ainda por cima escrito por mim.

1 E de certa forma até comecei, eu nunca tinha tido aulas de programação até então. O mais próximo tinham sido as aulas de "Introdução às Tecnologias da Informação" no 10º ano, mas nem tivemos tempo de chegar ao QBASIC sequer...

Aplicações Web com o OpenLaszlo

Depois de recentemente ter escrito aqui acerca do XUL e do XAML, como forma de criar web applications, descobri outra forma de fazer mais ou menos o mesmo, usando o OpenLaszlo.

Se no caso do XUL, as aplicações são interpretadas pelo browser (Mozilla ou Firefox) de uma forma on-demand a partir de um servidor web, podendo assemelhar-se a uma aplicação nativa, já neste caso acontece algo mais parecido com as tradicionais applets Java. Existe um motor que corre num servidor web, sob a forma de uma servlet Java, que compila as aplicações do código XML/JavaScript em que são escritas - à semelhança do próprio XUL - para um ficheiro Flash, que depois é enviado para o browser do utilizador. O motor também é responsável por fazer caching dos ficheiros compilados (para evitar andar sempre a compilar a mesma coisa) e mediar as comunicações entre as aplicações a correr nos clientes e os serviços a que elas acedem no servidor.

A utilização de Flash como ambiente de execução no cliente, permite que as aplicações possam ser utilizadas numa grande variedade de browsers e plataformas, desde que tenham o plug-in Flash (versão 5 ou superior) instalado.
Do lado do servidor também há uma grande flexibilidade, já que o motor pode ser usado em qualquer plataforma onde exista um servidor de aplicações J2EE ou apenas um ambiente de execução de servlets Java, como o Tomcat.

Como é óbvio, a aplicação tem de ser completamente descarregada para a máquina local antes de ser executada, o que, mesmo numa ligação rápida, pode implicar alguns tempos de espera. O XUL, por exemplo, não sofre desse problema porque as diferentes partes da aplicação vão sendo descarregadas do servidor à medida que vão sendo necessárias, da mesma forma que as páginas de um site à medida que o utilizador navega. No fundo o tempo de espera total pode acabar por ser o mesmo, mas no caso do XUL está disperso em tempos de espera diminutos em vez de obrigar a um tempo de espera inicial grande.

Alguns exemplos, com código, da plataforma Laszlo podem ser vistos na secção de demonstrações do site do OpenLaszlo.

Como se vê, existem algumas alternativas poderosas, abertas e multiplataforma para desenvolver aplicações web ricas, sem recorrer a soluções que só correm em Windows e Internet Explorer, como o futuro instrumento de lock-in da Microsoft, o XAML.

3D e Open-Source

Talvez por influência dos efeitos especiais dos filmes de Hollywood, as ferramentas usadas para gerar cenas 3D fotorealistas sempre me fascinaram. E dada a minha preferência pelo software opensource, as ferramentas que obedecem a este princípio exercem um fascínio particular.

Ocasionalmente tenho dispendido algum tempo de volta do POV-Ray, um dos mais antigos e potentes raytracers disponíveis. Já em 1995, ainda o POV-Ray estava na versão 1.0, e já se conseguiam produzir algumas imagens bastante interessantes com poucas linhas de código.
Apesar das minhas capacidades artísticas não serem nada de especial, há quem consiga fazer com ele imagens verdadeiramente impressionantes, algumas sem sequer recorrer a modeladores 3D.

Se na área dos raytracers já existem soluções opensource maduras há muitos anos, no que se refere aos modeladores 3D isso não acontece. Ainda só se passaram dois anos desde que o Blender foi tornado opensource, após a Blender Foundation o ter adquirido por 100.000€, angariados numa campanha que durou apenas 7 semanas (o que demonstra a sua popularidade).

E o que é o Blender? O Blender é uma aplicação de modelação 3D, inicialmente desenvolvida in-house pelo estúdio de produção holandês NeoGeo e que posteriormente teve o seu desenvolvimento a cargo da empresa NaN, antes desta ter fechado as portas.
É um software bastante potente, mas com uma interface de utilização algo austera, muito ao estilo do software proprietário usado pelos profissionais nas workstations SGI, com IRIX, desde há muitos anos. Felizmente esta tem sido uma área onde os developers têm investido bastante, podendo dizer-se que actualmente a interface é bastante mais amigável, sem perder o seu poder.



Tem bastante funcionalidade e surpreendentemente o download varia apenas entre os 3.5 e 5.5Mb, dependendo da plataforma. Pode dizer-se que, neste caso, o software não se mede aos palmos (ou aos megabytes).

O Blender conta com um renderer embutido, mas começa a ser cada vez mais popular combiná-lo com o YafRay, um raytracer também opensource e desenvolvido na vizinha Espanha.

Se ainda não estão convencidos que com algo tão pequeno se consegue produzir trabalho de qualidade, eu aconselho olharem com atenção para a galeria do Blender ou, se tiverem tráfego para gastar, para o vídeo promocional que apresentaram na Siggraph 2004.
Também pode ser interessante saber que o Blender teve o seu lugar na produção do filme Spider Man 2.




PS: tomem atenção ao menu no topo da página do Blender, a prova de que é possível fazer um menu com bom aspecto e a funcionar em todos os browsers, sem recorrer ao uso de Flash.

Sun vs. Red Hat

A Sun foi, no seu auge, um dos mais proeminentes fornecedores de soluções proprietárias hardware/software, com as suas máquinas SPARC a correr Solaris, mas o mundo mudou e a Sun entrou em declínio.
É claro que isto também afectou a IBM, por exemplo, mas esta soube dar a volta por cima, centrando-se nos serviços e levando a sério soluções de Linux em x86.
Não quero com isto dizer que o Linux em x86 é a razão do sucesso da IBM, até porque eles continuam a promover o seu AIX junto de clientes de maior porte, mas faz parte da sua gama de ofertas.
Ora, o Linux tem vindo a ser uma grande fonte de erosão para os Unixes proprietários e isso significa que a IBM decidiu passar parcialmente para o outro lado da barricada.

Mas a Sun não o fez, e não foi por falta de oportunidades. Dentro da Sun parece haver um grande movimento conservador que não admite mudanças estratégicas. Se é verdade que a Sun fornece máquinas x86 com Linux, também é verdade que se sentem parcialmente envergonhados por isso, continuando a ver o Solaris como um campeão que vai derrotar o Linux. Não me parece que isso vá acontecer, apesar de achar que o Solaris tem o seu potencial, como já havia falado há umas semanas.

Daí decidem tomar como rumo os ataques constantes à Red Hat, o maior e mais reconhecido distribuidor de Linux.
O «rationale» parece-me simples, a Red Hat é bastante criticada dentro da própria comunidade opensource por receio de que o seu sucesso a transforme numa espécie de Microsoft do Linux. Juntando-se às críticas, e atirando-lhes com a banana do Solaris opensource, a Sun espera poder colocar esses opositores do seu lado. Senão vejamos:

«Red Hat has pretty much forked the distribution. This has given Red Hat tremendous gains for now, but ultimately it's an impediment in the growth of Linux.» [fonte: eWeek]

Esta frase já foi atirada para o ar por muita gente, muito antes do Jonathan Schwartz ter chegado a presidente da Sun. E não deixa de ser uma falácia por isso, tal como diz o próprio Linus Torvalds:

«Sure, RH definitely has their own vendor kernel, but it's not proprietary, and a number of the top Linux kernel contributors are Red Hat employees.»

Para além de todas as distribuições aplicarem os mais diversos patches externos ao kernel do Linus, tal como a Red Hat o faz. Move along, nothing to see here...

Mas isto já foi há algum tempo. Agora na ordem do dia está o preço das soluções da Red Hat (vá lá, uma argumentação com pés e cabeça). A Sun alega que os preços praticados pela Red Hat são excessivamente altos, o que pelo menos parece ser o caso, a $2.500 por máquina/ano no nível de suporte mais elevado (RHEL Advanced Server), bastante mais do que os preços da SuSE, que rondam os $800 (o mesmo que a Red Hat pede pelo suporte do RHEL Enterprise Server). No entanto, o esquema de preços da SuSE é menos claro e fico sem saber realmente se os níveis de suporte de ambas as empresas são proporcionais ao preço (sendo que a SuSE, através da Novell fornece esquemas de suporte personalizados que podem ser mais caros).

Mas... nada obriga a comprar suporte para todas as máquinas, como até os críticos admitem. Na maior parte dos casos, em que se têm várias máquinas com configurações semelhantes, faz apenas sentido comprar suporte para uma e depois aplicar as respostas nas outras. Fazer isso com Solaris não me parece que seja fácil, porque parte do custo de suporte do S.O. está disfarçado no preço das máquinas, e duvido que a Sun dê suporte a Solaris fora do seu hardware (onde as combinações são infinitas e tudo pode acontecer).

O que é certo é que, apesar do seu sucesso, tudo a que a Red Hat deita a mão é tornado opensource, o que invalida a Teoria da Próxima Microsoft. E em alguns casos esta abertura até é vantajosa mesmo considerando os preços praticados no RHEL como demasiado elevados.

Um bom exemplo é o GFS, que a Red Hat tornou opensource após comprar a Sistina. Hoje é possível usá-lo de borla, através das versões não suportadas do RHEL distribuidas por terceiros (White Box Enterprise Linux, por exemplo), ou pagando suporte à Red Hat. Seja como for, os valores são hoje bastante mais baixos do que os $10.000 por máquina que a Sistina cobrava (apenas pelo GFS, entenda-se). Estivemos a considerar o GFS para uso no DQ e mesmo os $5.000 das licenças académicas eram um bocado puxados...

A moral da história é a do costume, a Sun precisa definir bem o caminho que quer seguir, e pensar duas vezes antes de apostar as fichas todas numa guerra Solaris/Linux, que se arriscam seriamente a perder. É que a Red Hat pode cobrar caro, e os seus clientes podem fugir, por exemplo, para a SuSE. Mas a questão é que podem, enquanto que no Solaris fogem para onde?

Nostalgia

Bons velhos tempos em que não existia a febre do 3D que existe agora. Quem se recorda desses tempos, decerto se lembra dos grandes clássicos da LucasArts, a série Monkey Island (I, II ou o mais recente III), The Dig, Sam & Max, etc.

Horas e horas passadas em frente do computador a resolver os puzzles (muitas vezes com a ajuda das soluções) e a seguir a história. Porque sim, nessa altura os jogos tinham história e os personagens tinham vida, como as personagens de um livro, não eram simplesmente umas marionetas que controlávamos para aqui e para ali.

Depois veio a mania de que tudo tinha de ser 3D, e até conseguiram criar um título interessante, o Grim Fandango, mas ficou por aí. O quarto título da série Monkey Island já não era a mesma coisa (para além dos bonecos parecerem uns palitos).

Mas ainda existe muita gente que não quer deixar morrer estes clássicos, como é o caso do pessoal que desenvolve o ScummVM, uma máquina virtual para correr estas aventuras gráficas antigas, que já tive a oportunidade de experimentar, tanto com o Beneath a Steel Sky como com o The Dig, que joguei de uma ponta a outra sem problemas.

Curiosamente, a produtora original do Beneath a Steel Sky ofereceu o código necessário para correr o jogo ao ScummVM, e também o próprio jogo, que está disponível para download.

Por isso, quem se sentir nostálgico pode assim recordar estas velhas glórias, seja qual for a sua plataforma de eleição, Windows, Linux, MacOS X, ou mesmo PalmOS ou PocketPC.

Patentes de Software III - Kodak vs. Java, O Resultado

Afinal não foi por 1.000 milhões de dólares, foi por bastante menos, 92 milhões, mas a Sun chegou a acordo com a Kodak na disputa em que esta alegava que a Sun havia infringido algumas das suas patentes no Java. Isto é grave, o inverno nuclear das patentes de software aproxima-se cada vez mais.

O Poder de um Monopólio

Java vs. .NET

O Java já cá anda há alguns anos, com muita gente a torcer o nariz à sua adopção em maior escala, mas basta a Microsoft acenar com o .NET, que logo manadas de empresas e developers se juntam à nova tecnologia de Redmond, mesmo que ainda imatura por comparação. E é também incrível como a Microsoft pode incompatibilizar o VB.NET com o Visual Basic 6, talvez a plataforma de RAD mais popular do mundo (infelizmente), e safar-se, sem que hajam motins, saques e pilhagens, e derramamento de sangue pelas ruas. Não, as pessoas migram todas alegremente...

XUL vs. XAML

Apesar do XUL já cá andar há tantos anos quanto o Mozilla, desde que a Microsoft anunciou o XAML, como parte do Longhorn, que não se fala de outra coisa. Aliás, como o Longhorn não sairá antes de 2006, existem até já empresas que se dedicam a produzir implementações de XAML que, nada surpreendentemente, só funcionam em Windows e Internet Explorer. Ora, não seria preferível usar a proposta mais madura, multiplataforma, opensource e que já deu provas(*) de funcionar?

Acho que a Mozilla Foundation precisa apostar seriamente na promoção do XUL, tanto dando ênfase ao facto de que uma instalação do Firefox é uma instalação que pode correr aplicações XUL, como esforçando-se por criar um pequeno pacote run-time que poderia chamar-se qualquer coisa como «Mozilla Run-Time Environment». Aliás, algo deste género até já se encontra em curso.

Já agora, para quem se quer saber rapidamente para que servem estas tecnologias, imaginem uma aplicação cuja interface gráfica é muito fácil de desenhar - através de uma linguagem baseada em XML - e que pode, não só correr directamente no computador, mas também a partir da rede, on-demand, como se se tratassem de páginas web - ao contrário de, por exemplo, uma applet Java que tem de ser completamente carregada para ser executada.

Um bom exemplo disto é o Mozilla Amazon Browser, uma aplicação de pesquisa na base de dados da Amazon.
Para a experimentar basta ir a esta página, usando o Mozilla ou Firefox (em qualquer das plataformas para as quais existem) e clicar no link apropriado.

(*) O Mozilla é, ele próprio, desenvolvido em XUL, tal como o Firefox, o Thunderbird e mesmo aplicações de terceiros como o IDE Komodo.

Em Casa de Ferreiro...

A Internet só existe como a conhecemos hoje porque é baseada em protocolos que são standards abertos, disponíveis em praticamente todas as plataformas. O TCP/IP, SMTP, HTTP, DNS, IMAP ou o POP3 são apenas exemplos de protocolos indispensáveis que nunca teriam ganho a dimensão que têm hoje caso fossem proprietários.

Pois bem, vamos então ao sumo deste artigo.

Vai decorrer nos próximos dias 7 e 8 de Outubro a CRC 2004, a 7ª Conferência sobre Redes de Computadores, um evento que irá ser transmitido pela FCCN através da Internet. Ora, sendo uma conferência sobre redes de computadores, organizada pela entidade responsável pela gestão da rede académica nacional e do domínio ".pt" - que agora até alberga uma réplica de um dos servidores DNS de topo - e que junta algumas das maiores figuras nacionais da área, esperar-se ia que escolhessem algo melhor do que Windows Media. Eu já nem digo para usarem algum codec de streaming opensource, mas pelo menos usavam alguma coisa que não estivesse limitada a uma única plataforma, e logo do monopólio de serviço. Podiam usar, por exemplo, Real Video, que pelo menos existe para uma série de plataformas, desde o Windows ao IRIX, passando pelo Linux.

É Portugal...

Actualização: Bem, afinal o streaming nem sequer funciona noutro browser que não o Internet Explorer... e nem sequer é mais que o simples plugin do Windows Media Player, que vergonha!

Patentes de Software II - Kodak vs. Java

Segundo este artigo, a Kodak acabou de ganhar um processo contra a Sun, em que alegava que esta havia violado algumas das suas patentes no desenvolvimento do Java. As patentes em causa referem-se a tecnologia adquirida pela Kodak em 1997 quando compraram a Wang Laboratories Inc.

Não sei detalhes sobre a que se referem exactamente as patentes, mas o artigo diz:

«The patents describe a method by which a program can "ask for help" from another application to carry out certain computer-oriented functions. That's generally similar to the way Java operates, according to Kodak and other experts.»

São estes casos que demonstram o perigo das patentes de software. Mesmo perante aqueles que consideram que os casos da Amazon.com (que patenteou o one-click-shopping) ou da British Telecom (que tentou patentear o hyperlink) não são suficientes.

A Sun, após ter investido anos de trabalho e milhares de milhões de dólares(*) no desenvolvimento do Java, vê-se agora na mão de uma empresa que nada investiu por causa de patentes demasiado generalistas. O engraçado nesta questão é que, ao que se sabe, estas patentes poderão ser usadas contra qualquer outra tecnologia baseada na interpretação de bytecodes, como ou .NET, o Python ou o PHP. Mesmo que estas implementações sejam completamente distintas umas das outras e nenhum dos intervenientes possa ser acusado de ter roubado o outro. É como se a JVC (com o VHS) e a Sony (com o BetaMax) nunca tivessem podido competir por alguma delas deter uma patente sobre "Gravação de um Sinal Analógico sobre uma Fita Magnetizável", teria sido terrível não? Pois bem, as patentes de software podem ser ainda mais generalistas e, por isso mesmo, ter efeitos mais nefastos, como eu já falei noutra entrada deste blog.

Agora a questão vai passsar para o nível monetário, onde a Kodak exige um pouco mais de mil milhões de dólares de indeminização. Se isto não é parasitismo, o que é? Têm a certeza de que é isto que nós queremos na Europa?

Se quiserem saber mais, o Groklaw tem um artigo mais extenso sobre este processo.

Actualização: Para quem quiser ficar ainda mais informado, aqui está um texto bastante completo: Software Patents: An Industry at Risk.

(*)Na terminologia anglo-saxónica, um bilião de dólares é na realidade um milhar de milhões, por oposição à definição normal de um milhão de milhões.

A Web Portuguesa

Eu sou um utilizador quase exclusivo do Firefox. De vez em quando uso o Mozilla e, menos frequentemente, o Opera. Mas só uso o Internet Explorer para fazer os updates do Windows. Mesmo assim nunca tenho problemas, nem nunca me vejo obrigado a recorrer ao IE para utilizar algum site. Não que todos funcionem impecavelmente, antes fosse, mas ainda não encontrei nada a que não pudesse dar a volta ou, normalmente, simplesmente desistir e seguir para outra.

Pode ter a ver com o meu padrão de utilização da web, visito maioritariamente sites técnicos, mas também visito sites de entretenimento, como os sites de filmes, portais tipo Sapo e também uso ocasionalmente a banca online. Dito isto, acho que o número de sites que apenas funcionam no IE, ou que apenas nele aparecem com uma formatação correcta, já não é tão grande quanto costumava ser, mas não é tão pequeno quanto devia.
O caso é completamente diferente se considerarmos apenas os sites portugueses. Aí, seguramente 90% deles têm problemas. Aliás, posso dizer com segurança que, dos sites que visito e dão problemas no Firefox, pelo menos 90% deles são portugueses, o que é uma percentagem assustadora.

Não sei se o problema se deve ao já mítico espírito de manada dos portugueses, que os impede de ver que existe vida para além da Microsoft e dos seus produtos de qualidade duvidosa, ou à ignorância e esmagadora falta de profissionalismo de quem concebe sites em Portugal.

A desculpa é sempre a mesma "90% dos nossos visitantes usam IE", e não fica menos estúpida de cada vez que a leio. Será que esta gente deita fora 10% da audiência assim tão facilmente? Sera que é assim tão complicado fazer um site mantendo um mínimo de compatibilidade com outros browsers para além do IE? Se lá fora o fazem, porque é que os nossos «génios» da web não o fazem também?

É simples, não têm competência para mais. Se tivessem não faziam parvoíces como colocar tags img com "\" nos paths para as imagens (como acontece em algumas secções do site da EDP, coisa que até prometeram resolver... já lá vai mais de um ano!).

Mas é mesmo assim, temos os programadores web que merecemos. Num país de pseudo-iluminados e seguidores da manada não podiamos esperar melhor.

Já agora, se sabem de um site que só funciona bem no IE e os responsáveis são umas mulas e recusam-se a corrigir o problema, deixem a vossa marca no fórum do Mozilla PT.

PS: sabem que até a Microsoft se disponibiliza a corrigir problemas de visualização do seu site em browsers não IE? Se não sabiam ficam a saber.

Oops, Trigger Happy

Bem, acho que dei com o problema do X.org (mais ou menos). Voltei à versão anterior e o problema manteve-se, reinstalei os drivers da nVIDIA e o problema desapareceu. Voltei a fazer um "yum update" e o problema voltou. O "nvidia-installer --sanity" queixava-se de que a libGL.so estava a apontar para lado nenhum e, de facto, o update tinha dado cabo dela. Consertei a symlink à mão e ficou tudo na mesma, mas depois de reinstalar os drivers está tudo bem de novo.

Resultado, o X.org escavacar a symlink é um bug (o suporte OpenGL default do X.org é fornecido pelo sub-pacote Mesa que nem sequer está instalado) mas parece que não é a única coisa que rebenta no driver da nVIDIA, e como este é proprietário não consigo obter mais informação.

Raios Partam Estes Gajos!

O Linux no desktop é uma espécie de cenoura à frente de um burro, está sempre meio metro à frente mas nunca a vai alcançar. Hoje esta minha convicção foi reforçada. Os tipos do Fedora lançaram um update para o X.org que simplesmente criou o caos. Agora, quando o xscreensaver arranca, o X morre e sou presenteado com o ecrã de login do GDM, e quando tento correr alguma coisa OpenGL o X morre e leva com ele tudo o resto. Já estou mesmo a ver, se isto só acontece com os drivers da nVIDIA (ou mais ninguém se acusa) os tipos vão mandar-me passear e dizer que não têm nada a ver com isso. Estou a começar a ficar farto!

A propósito, quando é que a nVIDIA se decide a deixar de compilar os drivers contra um X jurássico?! Quando o XFree86 4.0.2 era moderno, a nVIDIA ainda produzia GPUs a vapor!