O Mozilla está em todo o lado...

O Konfabulator - recém-adquirido, e tornado gratuito, pela Yahoo! - usa o motor de JavaScript do Mozilla ("SpiderMonkey").

Curioso...
 

IE Sux!

A leitura do livro «Cascading Style Sheets: The Definitive Guide» está a deixar-me com a sensação de que o Internet Explorer ainda é pior do que eu pensava. A cada esquina o leitor é presenteado com mais uma chamada de atenção que toma quase sempre a seguinte forma...

"Internet Explorer for Windows through IE6, the most recent version as of this writing, does not support/permit/correctly recognize [something]."

O autor do livro mantém uma série de páginas que usam CSS para produzir alguns efeitos bastante interessantes. A mais curiosa chama-se «complexspiral distorted» e mostra-nos como se consegue produzir um efeito de transparência com efeitos, usando apenas CSS1.
Experimentem vê-la no Firefox, Opera ou Safari e depois no Internet Explorer. Apesar de usar apenas CSS1, não funciona no IE, pela simples razão de este interpretar o estilo background-attachment: fixed; como relativo ao próprio elemento, e não à janela do browser (ao contrário dos outros, que se esforçam por cumprir os standards).

No entanto, parece que a Microsoft não está minimamente interessada em corrigir estes problemas, já que - segundo se diz por aí - a beta do IE7 não traz grandes melhorias.

Já agora, a recomendação CSS1 já existe desde Dezembro de 1996 e a recomendação CSS2 desde Maio de 1998... É bom recordar à Microsoft que estamos em 2005.
 

Dive Into Python

Nestes dias tenho andado a ler dois livros em simultâneo: «Cascading Style Sheets: The Definitive Guide» e «Dive Into Python».

Até agora (vou na página 100, mais ou menos) o «Cascading Style Sheets: The Definitive Guide» está a revelar-se bastante interessante. Os temas vão sendo apresentados de forma lógica e a escrita é clara e de fácil leitura.
Como o próprio nome indica, é mais um guia do que uma referência, portanto dá um bom livro de cabeceira, para aprender alguma coisa mesmo sem aplicação imediata em algum projecto.

Já o «Dive Into Python» não me tem deixado uma impressão assim tão boa...


Começa por seguir uma lógica pouco ortodoxa: em vez de partir dos fundamentais para progressivamente entrar em temas mais complexos, entra logo nos temas mais complexos, para depois ir dando os fundamentais à medida que vão sendo necessários. Por exemplo, consegue a proeza de só mencionar o ciclo for no capítulo 6 - ao falar do acesso a ficheiros - já depois de falar de introspecção, ou meter list comprehensions logo no primeiro exemplo de código...
Esta progressão não-linear torna-se confusa para quem está a tentar ler o livro de uma ponta a outra, e torna difícil saltar capítulos. Se eu não quiser ler um capítulo sobre processamento de HTML, perco uma data de outros temas mais importantes...

E tem o truque and-or...

O truque and-or tenta simular o mesmo comportamento que em C se pode obter usando uma expressão "foo = a ? b : c;". Mas enquanto em C esta expressão é relativamente directa (a? então b, senão c), o truque and-or nem sempre funciona como esperado, obrigando a umas artimanhas para o tornar seguro. Se o objectivo é incentivar más práticas de programação, então começa bem...

É caso para recordar uma expressão de Dijkstra:

"The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague."

Para não dizer que os "truques criativos" tornam o código ilegível para outros programadores que venham a ter de o manter.
 

Why I Hate the Apache Web Server

(via Slashdot...)

Este é o título de uma das apresentações (PDF) na ApacheCon Europe 2005 que se debruça, com humor, sobre alguns aspectos particularmente irritantes do web server mais popular do mundo.

Eu achei particularmente piada à referência aos vhosts HTTPs. Realmente, ser obrigado a duplicar configurações só para ter acesso por HTTPs é um bocado estúpido...

Bom mesmo seria haver apresentações deste tipo em conferências como a GUADEC ou a KDE Developers and Users Conference, por exemplo. Mas aí teriam muito mais do que 19 slides...
 

I'm not RMS! - Take 2

Quando se fala de modelos de negócio baseados em serviços, como forma de poder gerar lucro a partir de software open-source disponível livremente, a maioria das pessoas torce o nariz. Não acreditam que tal seja viável.

Hoje estive a pensar neste assunto, e realmente eu também não acreditaria se me expusessem a questão nestes moldes...

O problema está na direcção do raciocínio: primeiro pensa-se no software, e depois tenta-se arranjar um modelo de serviços para o sustentar.
Este tipo de raciocínio pode fazer perfeito sentido para aqueles que partilham da ideologia do Richard Stallman. Todo o software tem de ser livre, portanto é obrigatório arranjar um modelo de serviços se queremos sobreviver à sua custa.

Na verdade, se queremos fazer negócio à custa de uma peça de software por nós desenvolvida, e se é preciso esforço para encontrar um modelo de serviços natural, talvez seja um claro indício de que a via proprietária é a melhor opção.

Mas se invertermos a questão, e pensarmos primeiro nos serviços e só depois no software, talvez possamos compreender porque o modelo open-source tem ganho popularidade, e porque não parece estar a ser trucidado pelas "forças do capitalismo"...

A chave está na irrelevância do software perante os serviços. Se eu quero montar um negócio baseado no fornecimento de serviços, será que eu não posso desenvolver ferramentas open-source, deixando aberta a possibilidade de receber contribuições externas? Será que eu não posso simplesmente participar no desenvolvimento de ferramentas open-source já existentes e usá-las no meu trabalho?

É certo que outras empresas no mesmo ramo poderão fazer uso das mesmas ferramentas para competir comigo mas, se a licença usada obrigar à devolução das alterações à comunidade (p. ex. GPL), não compensará o risco? Empresas como a IBM já deverão ter considerado estas questões, e aparentemente concluíram pela positiva.

Mas por serviços não se pode entender o simples suporte pós-venda, porque não é necessário na maior parte dos casos. O suporte pós-venda só é realmente viável quando é parte da venda de soluções e não de produtos, o que nos coloca na situação de estar a pensar no software antes de pensar nos serviços.

O caso mais paradigmático do modelo de negócio baseado na venda de suporte é a Red Hat. No entanto, eu digo que esta é a excepção e não a regra. IMHO, o suporte vendido pela Red Hat é apenas uma fachada. Ninguém quer saber do suporte, e poucos realmente usufruem dele. Na verdade, o que interessa é garantir que não se perde o suporte (esse sim, valorizado) fornecido pela Oracle, e isso obriga a comprar um RHEL, que - por acaso - traz suporte incluído.
É claro que nem toda a gente está nesta situação. Julgo que a Red Hat também monta soluções por contrato (pelo menos foi esta ideia com que fiquei depois de ler uns documentos sobre o GFS), o que dá mais sentido à necessidade de suporte por parte da própria Red Hat. E depois, sempre há a Red Hat Network, que apenas está disponível para clientes que comprem pacotes RHEL.

Agora, criar uma empresa para dar suporte genérico ao PostgreSQL, e ficar à espera de pedidos de ajuda, é meio caminho para morrer de fome...

O modelo open-source não tem aplicação universal. Porque, se uma empresa que monta servidores nas empresas da vizinhança, ou uma empresa de web design (que distribuí publicamente o seu toolkit na esperança de que outros contribuam para o melhorar) podem ter sucesso nestes moldes, uma empresa que venda software especializado dificilmente o conseguirá.

Se adicionarmos a isto a questão da "propriedade intelectual", e interpretarmos a expressão livremente, podemos dizer que no modelo open-source a "propriedade intelectual" é o processo (o acto de montar servidores ou desenvolver sites) e no modelo proprietário a propriedade intelectual é o produto (o software em si).

Para arrematar esta questão, resta referir o modelo de dual-licensing. Quando o importante é o software em si, este modelo pode ser uma alternativa à via proprietária. Cobrar por licenças comerciais, mas potenciar a colaboração externa permitindo o uso sob uma licença open-source em situações não-comerciais, pode fazer sentido.
No entanto, eu tenho dúvidas acerca da sua utilidade. O único software que me ocorre nesta situação - e que não está associado a um modelo de serviços - é o MySQL, o que pode significar que é apenas uma excepção e não a regra.
 

I'm not RMS!

Parece que não posso defender este ou aquele aspecto onde considero que o modelo open-source marca pontos, sem que acabem por me colocar na posição de "representante oficial" do open-source, responsável por demonstrar que é a melhor coisa desde o pão fatiado...

Lamento ser desmancha-prazeres, mas eu não sou o Richard Stallman... Eu não considero o modelo open-source adequado a todos os casos.

É certo que, para o utilizador, ter acesso ilimitado ao código fonte é sempre uma vantagem. Mesmo que nunca faça uso de tal possibilidade, ela está lá. Mas as coisas não começam nem acabam no utilizador, não adianta ter um modelo que garanta n liberdades ao utilizador se depois não for sustentável. E nem sempre o é.

Daí eu defender o modelo open-source no geral, mas reconhecer que a sua aplicabilidade só pode ser avaliada caso a caso.

Superficialmente podemos considerar que, se o valor está nos serviços, o modelo open-source pode fazer sentido, mas se o valor está no próprio software, então o modelo proprietário pode ser incontornável.
É claro que em ambos os casos o modelo open-source é perfeitamente aplicável se o software for desenvolvido como hobby e não como negócio.

» Open-source, apenas para infraestrutura?
 

Microsoft Brainwash 2005 - Government Edition

Depois de grande esforço por parte do nosso governo, a Microsoft escolheu Portugal para a realização de um evento que se destina a... fazer lavagem cerebral a membros do governo!

Claramente no nosso caso não vai ser difícil, estamos quase lá...
 

J. Random Newbie

Um dos capítulos do The Art of Unix Programming (Eric S. Raymond), conta-nos a história do J. Random Newbie...

«Newbie has to code increasingly elaborate workarounds for component problems, to the point where the net gain from using the libraries starts to look marginal. The workarounds make his code progressively grubbier. He probably hits a few places where a library simply cannot be made to do something crucially important that is theoretically within its specifications. Sometimes he is sure there is some way to actually make the black box perform, but he can't figure out what it is.»

É uma leitura bastante, errr... "motivante" para quem quer seguir uma carreira de programador...
 

Picotux

O picotux é provavelmente o mais pequeno computador a correr Linux (uClinux 2.4.27), com uma dimensão de apenas 35mm×19mm×19mm.

Apesar do tamanho diminuto, não deixa de ter umas especificações interessantes, com conectividade via porta série ou ethernet 10/100, e ainda uns "pinos" para uso geral, 2Mb de memória flash e 8Mb de RAM, tudo alimentado por um processador ARM de 32bit a 55MHz.

Uma coisa destas tem milhares de aplicações interessantes, ao poder adicionar conectividade ethernet a uma infinidade de dispositivos, para controlo ou monitorização.


Por exemplo, teria piada se os fabricantes de automóveis juntassem uma coisa destas ao computador que hoje em dia existe em tudo quanto é carro, para se poder ligar lá um portátil e obter os mais variados dados, desde os consumos ao estado do motor... O valor geek de uma coisa destas seria incalculável.

PS: Eu sei que a maioria dos carros já permitem ligar lá um portátil, mas usam uns conectores e protocolos proprietários, juntamente com software proprietário, o que é propositado, para não se poder fazer exactamente aquilo que eu gostaria de fazer... :)

Actualização: esta pequena máquina - baseada em PowerPC - também tem bastante piada:

Batman Begins

Apesar de já estar nos cinemas há algum tempo, só hoje fui ver o Batman Begins, e devo dizer... finalmente um filme de super-heróis realmente decente...

Já não acreditava que tal fosse possível, normalmente são demasiado pipoqueiros e com uma história fraquinha, fraquinha...

Este Batman Begins consegue ser um filme sério, com algum humor aqui e ali - mas sem estragar o ambiente - e esforçando-se por evitar que os efeitos e os gadgets se tornem dominantes sobre a história.

Não é uma obra prima, mas é bastante bom.
 

PuTTY

Já há muito tempo que um pequeno problema com o PuTTY me andava a chatear... As teclas "Home" e "End" não funcionavam ao ligar-me a máquinas SUSE e Debian (mas não Red Hat/Fedora).

Hoje descobri finalmente, algures numa mailing-list do Debian, como se dá a volta a isto... Em Connection -> Data -> Terminal-type string, altera-se "xterm" para "linux", e voilá!
 

VMware

Segundo acabei de ler no KernelTrap, o valor HZ do Linux vai mudar de 1000 para 250.

Na prática, este valor indica o número de ticks (por segundo) do sistema, o que influencia directamente coisas como a frequência com que o scheduler acorda para dar tempo de CPU a um novo processo, entre outras tarefas regulares como a actualização do relógio do sistema (o Linux não usa o relógio da máquina, porque este não tem precisão suficiente em muitos casos).

Isto quer dizer que um valor mais elevado beneficia processos interactivos (que correm mais frequentemente, e respondem mais rapidamente), mas também introduz mais overhead, que penaliza processos que preferem ter mais tempo útil de processamento do que serem eleitos mais frequentemente para execução (todos os daemons, praticamente).

O que é que isto interessa? Perguntam vocês...

A mim interessa-me bastante, tal como interessa a todos os que querem correr o kernel 2.6 em cima do VMware.

Acontece que quanto maior forem "os hertz", mais trabalho o VMware tem a interceptar e gerar interrupts para a máquina virtual. Como esta não é a sua única tarefa, os interrupts perdem-se cada vez mais, quanto maior for o valor HZ. Ora, cada interrupt perdido é uma actualização do relógio que não é feita, o que faz com que este se atrase.

Numa máquina física, também se perdem interrupts (algumas operações de I/O obrigam a desligar os interrupts temporariamente), mas o kernel tem várias formas de o compensar (por exemplo, analisando o registo TSC - Time Stamp Counter - presente em todos os CPUs modernos para ver quantos ciclos realmente se passaram deste o último tick). Formas que o VMware não suporta, ou suporta mal e porcamente (na verdade, a culpa é mesmo do VMware, e não do Linux).

Em guests Windows este problema não ocorre, provavelmente porque o Windows usa outro método para manter o relógio, ou o VMware tem suporte especial...

Sem nenhuma intervenção manual, o relógio de uma instalação de Linux baseada no kernel 2.6 chega a perder 30 minutos por hora(!).

Passando ao kernel os parâmetros "noapic nolapic nosmp clock=pit", o problema reduz-se, mas acontecem coisas bizarras como o "/proc/cpuinfo" dizer que o CPU corre a 0.000 MHz... Passar "clock=pmtmr" é o meio termo.

Mas... mesmo isto não é suficiente. Com um pouco de carga, o relógio começa a atrasar-se até ao ponto em que o NTP (ou as VMware Tools) já não conseguem acompanhar...

A única solução é recompilar o kernel, alterando o valor de HZ para 100 (o valor que tinha no kernel 2.4).

Isto resulta perfeitamente no VMware Workstation 5.0 em Windows, mas não num VMware GSX Server em Linux...

Neste momento estou encalhado... Ando há semanas a tentar dar a volta a isto, para tentar meter uma máquina virtual Debian em produção num dual-Opteron a correr uma versão de 64bits do SuSE 9.2.

Provavelmente algum factor nesta configuração faz com que nenhuma solução resulte... Talvez alguma coisa no Debian, ou no SuSE 9.2, ou por ser x86-64...

O que era bom era ter este valor alterável em run-time, para evitar ter de andar a recompilar o kernel e a fazer n experiências sem sucesso...

Portanto estou ansioso que apareçam as tecnologias de apoio à virtualização da Intel (Vanderpool) e da AMD (Pacifica), para finalmente o VMware (e o Xen) poderem mostrar aos guests uma máquina realmente 100% fiel à máquina física.
 

Generic Keyboard

Da Rússia vem este teclado bastante interessante. As teclas não têm símbolos fixos, mas sim um pequeno display OLED que mostra a sua função actual.


Mas aposto que custa uma fortuna... Além de provavelmente não funcionar sem o apoio de drivers especializados, o que coloca algumas questões quanto ao seu funcionamento em sistemas que não o Windows ou MacOS X, ou mesmo durante o boot ("Press DEL to enter BIOS Setup", mas onde está o DEL...?).
 

Acho que devíamos dar um tempo...

Comecei a usar Linux em meados de Dezembro de 97 (Red Hat 5.0), no tempo em que os homens eram homens, e tudo se fazia com ficheiros de texto. Com o seu geek appeal, rapidamente se tornou no meu desktop primário, usado 85-90% do tempo.

Ter começado a utilizar Linux nessa altura foi um pontapé de saída para aprender muito do que sei hoje (ou, pelo menos, as coisas que não têm nada a ver com o currículo da faculdade), mas tanto se aprende que ao fim de algum tempo os desafios se começam a tornar aborrecimentos. E estamos em 2005, ano em que as lutas do dia-a-dia com o desktop Linux têm vindo progressivamente a irritar-me mais e mais.

Ter de fazer wrapper scripts para permitir executar o Firefox ou o Thunderbird mais do que uma vez sem fazer aparecer o Profile Manager[1], ter de andar à porrada com o Xine ou o MPlayer para os convencer a tocar este ou aquele vídeo, são coisas que já foram uma forma de aprendizagem mas que hoje são apenas perda de tempo.

De repente a lentidão peculiar do Firefox em Linux, os bloqueios permanentes do Thunderbird ao fechar, o Gaim[2], etc., começaram a irritar-me profundamente.

E depois há o reinstalar a cada 6 meses, que não é opcional. Ou se instalam novas versões ou se sente na pele a verdadeira definição de obsoleto, além de que é a única forma de deixar para trás um monte de bugs irritantes (ou descobrir que ninguém lhes ligou pevide).

Este é o verdadeiro estado do Linux no desktop. E eu estou farto.

O Linux é excelente no servidor (convém separar bem as águas), e a minha experiência diária ainda não me mostrou nada que me fizesse duvidar disto (apesar de ter uma série de gripes em relação ao SuSE, mas fica para outro dia...), porque não consegue evoluir no desktop? Será que é pedir muito?

Manter servidores (Windows e Linux) e acudir aos problemas dos utilizadores é parte integrante do meu trabalho e, a bem da manutenção da minha sanidade, não quero chegar a casa e ir fazer mais do mesmo... É preciso evitar cair num estado de burn-out, em que todo o software é uma merda, e onde começo a pensar seriamente se não seria melhor dedicar-me à pesca.
No trabalho ainda estou muito longe disto (é claro que há sempre aqueles dias...), mas em casa já estava a começar a notar os primeiros sintomas, o que é natural... é suposto os hobbies serem agradáveis, e não provocarem aneurismas...

Assim, e para evitar que este estado de "pavio curto" acabasse por afectar (injustamente) a minha percepção do Linux em geral, a minha utilização do Windows em casa subiu vertiginosamente.

Mas não se preocupem, não é agora que vou começar a usar o Internet Explorer, ou o Outlook, ou o MSN Messenger... É mais uma continuação do Firefox e do Thunderbird, Trillian em vez do Gaim, por estes dias também jEdit e ActivePython e ainda várias janelas do PuTTY ligadas ao servidor de testes Linux, onde a verdadeira acção acontece (ler o mail e navegar na web não é acção).

Além do mais, isto já se estava mesmo a ver com todo o deita-abaixo do desktop Linux que tenho feito ultimamente... Ou, se calhar, estou apenas a passar por uma fase de comodismo...

[1] Imaginem que têm o Thunderbird aberto e clicam num link "mailto:" no Firefox, ou que têm o Firefox aberto e clicam num link no Thunderbird...
[2] Aquilo é mau... mesmo mau! E é o melhor cliente de IM para Linux...
 

Depois de 30 anos é que se lembram disto...

Parece que a Microsoft, na sua infinita sabedoria (ou arrogância), decidiu tornar obsoletas umas quantas funções da biblioteca standard do C (via Pedro Santos). Funções como "sprintf", "strcpy", "memcpy", ou mesmo "printf" e "fopen", passam a estar deprecated na implementação da MS. Tudo em nome da segurança.

Quer estejamos a falar de código crítico (em termos de eficiência) dentro de um sistema operativo, ou software de controlo para sistemas embebidos, é a flexibilidade do C que o torna a linguagem ideal. O C é, por definição, um assembly de alto nível, a linguagem com a qual é possível espremer toda a performance de uma máquina, criar software com baixos requisitos de memória e armazenamento.

Mas toda a flexibilidade do C tem um preço. O eficiente desempenho da sua função implica riscos, e esses riscos não podem ser eliminados sem comprometer o eficiente desempenho da sua função. O C é uma serra eléctrica, é eficaz porque não tem protecção. Está nas mãos do programador evitar ficar sem dedos. E estou convencido que a grande maioria dos programadores de C estão vários níveis acima dos code punchers vulgares, e sabem bem com o que estão a lidar.

Qualquer programador de C deve saber pesar os prós e os contras do uso de funções perigosas como o "strcpy". Se não souber, bem, as falhas provocadas por estas trivialidades vão ser as mais simples de corrigir...

Como se pode constatar pelas falhas encontradas no software para Linux (na sua maioria desenvolvido em C), os buracos estão quase sempre no domínio do problema, e não são acidentes ingénuos com as funções disponibilizadas pela biblioteca standard. São problemas semânticos e não sintácticos. Problemas destes ocorrem com qualquer linguagem, mesmo as consideradas mais seguras.

Isto só vai servir para criar confusão num standard que já tem décadas, e adicionar overhead, sem quaisquer vantagens práticas. Ao tentar tornar o C mais seguro, vão limitar o seu interesse nas áreas para as quais é apontado, e não vão ganhar nada noutras áreas, onde outras linguagens são preferíveis.

O C é perigoso, e se o risco não compensa, escolhe-se outra linguagem. O que não falta são linguagens por aí...

Uma alternativa seria manter a mesma API, fazendo as alterações (possíveis) ao nível interno, deixando ao programador a escolha de as activar, ou não.

Mas como sempre, a Microsoft faz as coisas à sua maneira, atropelando standards sem dar cavaco a ninguém. E neste caso, sem qualquer efeito prático (esperem e verão)... Não admira que todo o suposto empenho ao nível da segurança não esteja a dar muitos frutos...
 

Morte por esmagamento!

Segundo se pode ler no 24 Horas da tecnologia, a proposta que abria as portas às patentes de software na UE foi esmagada no parlamento europeu. 648 votos contra, num total de 670, é uma votação muito expressiva.

O lobbying contra as patentes de software conseguiu então alcançar a vitória, apesar de eu achar que o golpe fatal foi dado pela própria comissão, ao desprezar as opiniões e sugestões do parlamento.
 

Not again...

Sempre que se discutem os benefícios do software open-source e os malefícios das soluções proprietárias, alguém intervém com o já clássico «Quem quer usar Linux usa Linux, e quem quer usar Windows usa Windows», tentando dar a prova máxima de uma neutralidade e de um pragmatismo acima destas discussões mundanas e inconsequentes...

Em tese, eu concordo com esta afirmação, cada um é livre de usar o que quer, mas será que "livre" é o termo adequado? Não. Ignorar estas discussões é, na realidade, por em causa essa mesma liberdade.

Antes de continuar com isto, é importante deixar bem claro que não estou aqui a falar de retórica stallmanista, onde "o código quer ser livre", ou "todo o software deve obedecer às quatro liberdades".

Para se ser livre para escolher entre uma solução proprietária e uma solução open-source, é necessário que não estejamos já condicionados à partida, obrigados a optar por um dos lados por quaisquer outras razões que não as estritamente relacionadas com os objectivos que queremos atingir.

É aqui entram os standards abertos e a interoperabilidade.

Talvez o efeito mais importante do movimento open-source seja tornar evidente a importância destes dois factores que, durante bastante tempo, foram sendo vistos como irrelevantes, sacrificáveis em troca de uma suposta "superior integração" que não era mais do que uma camisa de forças, limitando as escolhas futuras e efectivamente criando aquilo que vulgarmente se chama "vendor lock-in".

Felizmente isto começa gradualmente a mudar, com muita gente a abrir os olhos a tempo, e outros a descobrirem que se enfiaram num buraco de onde vai ser difícil sair...

Eu não recrimino ninguém por usar este ou aquele produto, nem recrimino os Joe Users por não reconhecerem a importância da interoperabilidade, mas recrimino aqueles que deveriam saber que a liberdade de escolher, sem condicionamento, the best tool for the job está sob constante ameaça, e não fazer nada para a defender é condená-la à aniquilação.

Por exemplo, a Microsoft não tem vindo a melhorar a interoperabilidade - ainda manifestamente insuficiente - dos seus produtos, com soluções de terceiros, apenas porque acha que isso é bom para as pessoas, mas porque a indústria assim a obriga. E a "indústria" somos todos nós.

Um tipo pode usar apenas Windows no seu desktop, e manter uma maioria de servidores Windows, mas se em algum caso a melhor escolha for uma máquina Linux, tem de trabalhar para poder fazer essa escolha. E isso significa mostrar que reconhece a importância da interoperabilidade e penalizar (sempre que razoável) quem a tenta limitar.

Ignorar a questão, e deixar as coisas simplesmente num «Quem quer usar Linux usa Linux, e quem quer usar Windows usa Windows», é demonstrar cegueira e conformismo, que só reconhecerão quando for tarde demais...

Artigos relacionados: 

• Porquê formatos livres?

Esquisito

Estou há uma data de tempo a tentar descobrir porque razão os browsers ignoram o...

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

...que tenho definido nesta página.

Por alguma razão, quando o ficheiro é aberto a partir do disco local a codificação escolhida pelo browser é "UTF-8", mas quando aberto a partir de um servidor web, é escolhida a codificação "iso8859-1", completamente à revelia da meta-tag.

E isto não é exclusivo de apenas um browser, acontece - pelo menos - com o Firefox e o Internet Explorer.
 

Mimas

Now, witness the power of this fully operational battle station...
 

Ferramentas deliciosas

Desde ontem descobri algumas ferramentas interessantes para lidar com as bookmarks guardadas no del.icio.us.

A primeira foi-me sugerida num dos comentários ao artigo anterior, o del.icio.us direc.tor, que permite uma navegação bastante eficiente através das tags. Mas tem um inconveniente, só se consegue chegar lá clicando numa bookmarklet quando se tem uma qualquer página do del.icio.us aberta, devido a restrições do browser.

Também encontrei um search plugin para o Firefox e uma applet Java que mostra um grafo das tags, por onde se pode navegar.

No entanto, ainda não encontrei algo que me daria bastante jeito: uma forma de colocar todas as bookmarks na sidebar do Firefox, com um campo de pesquisa associado.
 

Delicioso

Manter bookmarks é uma chatice, e as minhas estão mais do que fragmentadas... espalhadas pelo Firefox em Windows e em Linux, tanto em casa como no trabalho.

Portanto, depois do blogging e do "flickrering", aderi a mais uma moda, o del.icio.us. Assim as minhas bookmarks estão em todo o lado.

Só gostava que aquilo tivesse uma interface um bocadinho melhor, talvez com uma hierarquia em árvore ou qualquer coisa assim...
 

Morte por velhice

Ao longo do tempo, o meu site pessoal tem vindo a ficar desactualizado, por falta de tempo para dar uma volta naquilo e também alguma falta de ideias sobre o que realmente fazer...

Algumas das secções foram feitas no tempo da outra senhora, e já cheiravam a mofo, enquanto outras pecavam por falta de conteúdos. E o código... o código daquilo era de meter os cabelos em pé, completamente impossível de manter sem perder a sanidade.

Além do mais, este blog é a minha página pessoal de facto...

Esta semana fartei-me... o site passou à reforma. Deixei lá apenas a página referente ao driver powermust (que sempre foi uma coisa separada) e ainda o Windows Cloning HOWTO (que já está a pedir uma actualização há bastante tempo) e a página com os links para documentação (que ainda tem utilidade).