segunda-feira, 22 de junho de 2009

Dica de programa: DHelp

Essa dica vai muito bem para os desenvolvedores. No meu caso, como uso o Octave, é sempre bom ter o manual em mãos.

Para aqueles que querem manter os seus documentos de ajuda em HTML bem organizados, faz o seguinte: instala o dhelp.

O dhelp (ou melhor Debian Help) é um programinha muito simples mas muito poderoso, ele faz uma varredura em todo HTML do seu disco e tenta organizá-lo em grupos, normalmente pelas pastas onde os arquivos se encontram.

Cara fica uma beleza a organização.

Só mais uma coisa: se você tem um servidor Web (e.g. Apache - httpd) você deve apontar o navegador para http://localhost/doc/HTML/index.html ou se não, você deve acessar o índice gerado através de: file:///usr/share/doc/HTML/index.html.

Se você esquecer disso, basta digitar dhelp num terminal, que ele vai abrir a página index ou então dhelp para acessar uma busca por documentação específica, como por exemplo: dhelp gnu octave

domingo, 21 de junho de 2009

Configurando o StarDict

Bem, de fato o stardict está se tornando o padrão em programa de tradução para o mundo open source e para Linux em particular.

No Ubuntu, por exemplo, uma das primeiras coisas que faço é instalá-lo. O programa de dicionário padrão do sistema é simplesmente muito ruim para se usar. Nunca consegui usá-lo adequadamente.

Mas o problema com o stardict é que ele não tem lá muitos dicionários e os que existem, pelo menos para português não são lá muito bons. Mas os dicionários do Babylon são excelentes. Então que tal usar os dicionários do Babylon no stardict?

Para isso, baixe os dicionários do Babylon e os converta para o formato do stardict. Use as dicas contidas aqui: http://ubuntuforums.org/showthread.php?t=1044452.

Mas se você nao quiser se encher muito, segue uma dica que funcionou para mim tranquilamente.
  1. Pegue os dicionários que deseja em: http://reciteword.sourceforge.net/stardict/babylon.php, como por exemplo o stardict-babylon-Babylon_English_Portuguese-2.4.2.tar.bz2
  2. Dê dois cliques no arquivo stardict-babylon-Babylon_English_Portuguese-2.4.2.tar.bz2, vai abrir o Archive Manager.
  3. Extraia todos os arquivos para a pasta ~/.stardict/dic. Se esta pasta não existir, pode criar. (o ~ é a sua pasta pessoal, ou melhor a sua pasta HOME).
  4. Reinicie o stardict
  5. Vá em Manage dictionaries (o segundo ícone da esquerda para a direita em baixo) e veja que os dicionários estão ativos. Desative os dicionários padrão, que só servem para pegar um monte de coisas meio inúteis da Web.
Agora seja mais um usuário feliz com um dicionário Inglês-Português de mais de 114 mil palavras.

Só atenção a uma coisa: eu uso a interface do Ubuntu 9.04 em inglês, talvez você tenha que adaptar algo para a sua interface.

É isso.

sexta-feira, 19 de junho de 2009

Saiu a versão 3.9.6 do HPLIP: Fazendo HP LaserJet 1000 funcionar no Ubuntu 9.04

Saiu a versão 3.9.6 do HPLIP.

Dessa forma, a impressora HP LaserJet 1000 e praticamente todas as impressoras da família passam a ter suporte.

Basta ir ao site do projeto HPLIP (http://hplipopensource.com/hplip-web/index.html), baixar a nova versão e executar via terminal. Para executar, como se trata de um script, você deve ativar a permissão de execução do arquivo manualmente. Isso porque o Linux é um sistema mais seguro, não permitindo que qualquer script seja executado, apenas aqueles que você tem certeza que são seguros, como este.

É só seguir as instruções (o script está em inglês). Ele irá fazer uma série de verificações e instalará todo o software necessário (os pré-requisitos) e irá compilar os módulos que fazem o HPLIP. Depois ele irá executar uma rotina de instalação e então você pluga a impressora, confirma para o programa baixar o plug-in do servidor principal. Ao final a impressora deverá fazer aquele barulho de inicialização característico. Já estará funcionando!

Só um comentário: bom que a HP agora esteja se importanto um pouco com o mundo Linux e fazendo suas impressoras funcionarem também neste nosso sistema. O projeto (opensource) agora está no sourceforge.net e, como é compilado na máquina, o que você baixa é o código fonte.

É isso.

segunda-feira, 25 de maio de 2009

Mantendo parágrafos juntos no Latex

Essa dica veio da lista Tex-BR. Beleza. Coloco aqui para não esquecer:

Para se manter dois parágrafos juntos, isto é, para manter dois parágrafos na mesma página, sem uma quebra de página entre eles, você pode forçar uma quebra manual antes do parágrafo que você quer manter com o próximo. O problema é que se, de repende, você mexe no texto, acaba tendo uma página em branco, por uma quebra automática seguidade de uma quebra manual.

A forma menos traumática, segundo o Ivan Ramos (da Lista Tex-BR) é dar uma dica ao Latex. Essa dica é dada como comando \penalty

O \penalty funciona da seguinte forma: você coloca um número positivo entre 1000 e 10000 para dar uma penalidade ao Latex caso ele quebre a página ali. Você também pode colocar um número negativo entre -1000 e -10000 para dar um incentivo se ele quebrar a página naquela posição. Quanto maior o incentivo ou a penalidade maior é a tendência de ele não quebrar a página ou quebrar a página na posição que você indicou.

Assim:


Parágrafo 1: blablabla

\penalty 1000

Parágrafo 2: blebleble


ou


\penalty -1000

Parágrafo 1: blablabla

Parágrafo 2: blebleble


Testei com parágrafos subssequentes dentro de um ambiente itemize (que teoricamente já deveria manter parágrafos juntos), e funcionou legal. Mas tenha em mente que o Latex vai ter que realinhar as distâncias dos parágrafos que ficaram na página, de forma que, dependendo se você colocou uma penalidade muito alta faltando ainda um bom espaço para terminar a página, o leiaute final pode ficar bastante desagradável.

É isso!

domingo, 17 de maio de 2009

O que falta para o Ubuntu deslanchar?

Bem, para muitos essa questão tá errada, pois, para eles, o Ubuntu já deslanchou. Do ponto de vista do Pinguim com certeza, mas do ponto de vista de mercado, ainda há muito o que fazer. Abaixo segue uma lista de coisas que, acredito, devam melhorar no mundo Linux, em particular no Ubuntu, para que ele deslanche de uma vez.
  1. Propaganda mais agressiva: nesta semana, a Veja está com uma matéria de capa falando sobre os hábitos (infelizes) dos brasileiros na Internet, bem como de sua base instalada de programas e, com eles, um bocado de roubadores de senha, vírus e companhia. Como sabemos, o Linux é bem menos vulnerável a essas práticas e, como o usuário do Linux acaba tendo que aprender um pouco mais que o zero costumeiro dos usuários do Windows, segue-se que o conjunto usuário + sistema é excelente em temos de segurança. A comunidade Linux deveria ser mais incisiva quanto a isso e a propaganda deveria ser mais agressiva quanto a vulnerabilidade do outro sistema. E sem essa que o Linux não tem essas pragas por causa de sua baixa popularidade. É claro que aumentaria o número de casos, mas em termos percentuais, continuaria como está hoje, talvez com um leve aumento e não mais que isso, bem diferente do Windows que, sabe-se é 100% vulnerável desde a sua instalação e o usuário deve correr à frente dos invasores para colocar um mínimo de segurança em seu PC, se não acaba ficando atrás e, literalmente, refém deles.

  2. Um DVD descente: o que quero dizer com isso? Que o Ubuntu deve deixar de lado essa de colocar um sistema inteiro em apenas um CD e o seu DVD ser um mero ajuntamento das diversas versões (dos diversos CDs existentes) em uma única mídia com um pouco mais de pacotes de idiomas (tradução e regionalização). Devemos ter um DVD que deixe o sistema pronto mesmo: com os pacotes multimídia lá, java, flash etc. e, também igualmente importante, os arquivos de documentação. Não tem jeito, o mundo ainda não é open source e, por isso, esses formatos proprietários ainda são necessários. Num mundo em que os pen drives estão na casa dos GiB e praticamente todos os computadores atuais saem de fábrica com um leitor de DVD, está meio sem sentido essa política. Mas tem o pessoal da África, podem argumentar alguns, mas até eles acabam usando o Ubuntu em DVD mesmo, porque tem que fazer a instalação do pacote de idioma e, como a gente sabe, a maioria lá não tem acesso a Internet. Realidade igual no Brasil que, apesar de ter um bom percentual de pessoas com acesso a Internet, sabe-se que boa parte desse acesso é no ambiente de trabalho, em cafés ou pontos públicos, ou via internet discada: simplesmente não dá para baixar 700MiB de pacotes novos via internet discada! A propósito, no Brasil é possível você distribuir tudo (até mesmo o w32codecs) sem problemas legais.

  3. Comunidade preparada para receber 1, 2, 5, 10 milhões de usuários: a verdade é essa, não temos uma comunidade preparada para receber um número tão grande de usuários. Se todos os usuários atuais do Ubuntu fizessem parte da lista de discussão "oficial", já não faríamos outra coisa no dia que não apagar (nem mesmo ler) mensagens de e-mail dessa lista. Hoje a lista tá um volume e tanto e só temos cadastrados uma parte pequena dos usuários do sistema. Ou seja, necessitamos nos organizar, empresas devem nascer para dar suporte, escolas devem começar a usar e ensinar os alunos etc. Sem esse suporte na esquina, fica difícil: a maioria dos usuários Windows o são simplesmente porque é fácil e barato encontrar "alguém" que por uns trocados (quando não faz de graça mesmo, pela amizade) instala o sistema em qualquer PC. Tudo bem se é pirata, esse detalhe aqui no Brasil é quase irrelevante.

  4. Venda casada de computadores: talvez seja a prática mais comum no mundo da informática, talvez tão comum que as pessoas nem se tocam que se trata de venda casada, o que é proibido pelo código de defesa do consumidor mas que, por hora, até mesmo o Ministério Público faz ouvidos de mercador e nem liga. Já cheguei a mandar e-mails para eles denunciando um site que estava vendendo PC com Linux e, juntamente, vinha uma cópia de "testes" do Microsoft Office. Isso mesmo, caro leitor, vinha o MsO junto com o PC novo, cujo SO era Linux. Bem, não deram nem resposta. Pois bem, para o Ubuntu deslanchar mesmo, não tem que ficar mendigando que 0,1% de computadores da Dell saiam com o sistema. No Brasil tem alcançar mesmo é o número dos milhares de "montadores" pequenos e médios que estão fazendo a farra com uma quantidade absurda de distribuições Linux que nem ao menos funcionam direito (às vezes nem entra o X) no computador. O Ubuntu se fazendo presente nestas empresas e com o sistema rodando bonito haverá menos rejeição do usuário final e, principalmente, não teria motivos muito plausíveis para mudar de SO. Sabemos que o Ubuntu consegue um percentual enorme de compatibilidade com os hardwares mais comuns no Brasil, mesmo considerando os Winmodens e as Wincams espealhados por aí. Então a Canonical deveria sim fazer essa venda casada: nada de instalação, sistema seguro, sistema rodando com tudo que o usuário tá precisando, compatibilidade com os formatos de arquivos mais comuns, java rodando, flash embutido no navegador ok e boa compatibilidade com o hadware. Aí é só correr pro abraço.

  5. Uma documentação descente: apesar dos esforços da comunidade, ainda é precária a documentação do sistema. Não é que falte, mas ela está dispersa. Sem a agregação certa fica difícil fazer as coisas. Por exemplo: a ajuda do OpenOffice.org até que é boa, mas basicamente ensina teclas de atalho, o significado de um ou outro termo numa caixa de diálogo, quais as opções mais relevantes de um combo-box etc. Mas o principal para eles que é como usar o conjunto dos aplicativos para fazer as coisas da maneira certa, isso não tá lá. Tudo bem, pode-se comprar livros sobre o OpenOffice que ajudam, mas nem todos podem comprar e/ou nem todos tem o tempo necessário para ler e aprender com os livros. Lembro-me que a primeira versão do Word para Windows, o Word 2.0, vinha com um sistema de ajuda simples (sem as firulas que eles tem hoje), mas recheado de dicas para se ganhar produtividade com o Word. Ensinava desde o conceito de um parágrafo e caractere para o sistema e daí os motivos de se ter formatações tanto para parágrafos quanto para caracteres. Falta isso para o mundo open source em geral e para o Ubuntu em particular. Alguns podem se lembrar dos How-Tos por aí, mas uma vez mais, assume-se que a pessoa tenha acesso a Internet e que tenha tempo de procurar por um monte de lugares diferentes a resposta que está querendo (falta agregação). Aquela de se ter a primeira página do FF em português é 10, mas os links levam para o sítio da comunidade em inglês, isso é zero. Outra coisa é você abrir o Gimp, por exemplo mas poderia ser qualquer aplicativo, teclar F1 e aparecer uma mensagem dizendo que esta característica não está instalada no sistema. É dose. Porque raios os pacotes de documentação não vem junto com os programas? Ahhh, mas tudo tem que caber em um CD somente, aí não dá para colocar os programas e mais a documentação. Então partamos para um DVD, ora pois (vide a discussão acima).

  6. Brigar pela diminuição da pirataria: essa sim é uma briga boa. Se todas as pessoas que usam computador ao menos soubessem que estão cometendo um crime quando instalam um programa sem a devida nota fiscal ou, o que é pior, recbem um computador com diversos programas já instalados sem o devido "agreement" (o contrato de licença do software) então já teríamos um meio caminho andado para a proliferação do software livre, isso porque, o que as pessoas inicialmente vão olhar, não tenham dúvidas, é o tamanho da conta. No Brasil a pirataria corre solta simplesmente porque não temos dinheiro sobrando para comprar o software. Neste caso, o software livre acaba ajudando, porque boa parte dele é igualmente grátis.

  7. Vamos aproveitar que estamos no Brasil e podemos fazer isso: essa talvez seja a melhor das coisas que poderia acontecer com o Ubuntu. Se o Brasil, emergente que cresce internacionalmente, passasse a ser o carro-chefe, os outros países da África e Ásia acabariam por utilizar o sistema. Digo que devemos aproveitar que estamos no Brasil porque aqui software não tem patente, e sim, direito autoral. Ora, se o w32codecs e libdvdcss2 (talvez os pacotes mais problemáticos em termos de patentes nos EUA), foram todos escritos a partir do zero pela comunidade e tem uma licença GPL, então no Brasil podem ser distribuídos livremente, respeitando o direito autoral (no caso a comunidade GNU) dentro do DVD do Ubuntu.

segunda-feira, 11 de maio de 2009

Compilando o RTAI no Ubuntu

Para os meus colegas que já estavam cobrando a um tempo, aqui vai o resumo dos procedimentos de compilação do RTAI no Ubuntu. Basicamente são os mesmos passos que o Debian. Lembrar que a compilação do RTAI NÃO funciona no gcc 4.3, então você DEVE usar a versão 3.4.

Aqui descreve-se os procedimentos básicos para a compilação de um kernel vanilla no ambiente Ubuntu. A versão utilizada no Ubuntu é a versão 7.10. Povavelmente o procedimento funcione com outras versões do Ubuntu, bem como outras distribuições baseadas no Debian. Utilizou-se o jeito Debian de se compilar e instalar o kernel do Linux.

Procedimento de Compilação do Kernel de Tempo Real

Os procedimentos a seguir devem ser realizados como superusuário (root), inclusive os testes no RTAI.

Preparativos
  1. Criar diretorio dos fontes:

    $ mkdir /usr /usr/src

  2. Ir para o diretorio de fontes:

    $ cd /usr/src

  3. Baixar o linux e o rtai:

    $ wget www.rtai.org/RTAI/rtai-3.6.bz2
    $ ftp ftp.kernel.org
    login> anonymous
    pass>
    ftp> pass
    ftp> bin
    ftp> cd /pub/linux/kernel/v2.6/
    ftp> get linux-2.6.23


  4. Descompactar os fontes:

    $ tar xjf rtai-3.6.tar.bz2
    $ tar xjf linux-2.6.23.tar.bz2


  5. Criar os links simbólicos:

    $ ln -s linux-2.6.23/ linux
    $ ln -s rtai-3.6/ rtai


Provavelmente o leitor que replicar estes procedimentos o fará somente uma vez enquanto que os demais procedimentos serão executados inúmeras vezes.
Compilando o Kernel
  • Linux mais recente suportado: linux-2.6.23
  • Rtai mais recente: rtai-3.6
  1. Ir ao diretorio do linux:

    $ cd linux

  2. Aplicar o patch do RTAI no Linux:

    $ patch -p1 < ../rtai/base/arch/i386/patches/hal-linux-2.6.23-i386-1.12-00.patch

  3. Copiar a configuração atual:

    $ cp /boot/config-`uname -r` .config

  4. Editar a configuração:

    $ make menuconfig

  5. Opções a serem editadas:
    1. General Setup
      1. Prompt for development and/or incomplete code/drivers: Y
      2. Local version - append to kernel release: -rtai

    2. Enable loadable module support: Y
      1. Module versioning support: N

    3. Processor Type and Features
      1. Interrupt Pipeline: Y
      2. Timer frequence: 1000 Hz
      3. Preemption model: Low Latency Desktop

    4. Kernel hacking
      1. Compile the kernel with debug info: N
      2. Compile kernel with frame poiters: N

    5. Obs.: Pode ser necessário e é extremamente recomendável, segundo o manual do RTAI, desabilitar as opções relacionadas ao Gerenciamento de Energia: ACPI, APM e Graduação da Freqüência da CPU.

  6. Opções a serem editadas para o meu caso:
    1. Processor Type and Features
      --> Processor Family: Core 2/newer Xeon
      --> Hyperthreading: N

    2. Device Drivers -> Sound -> Advanced Linux Sound Architecture -> PCI Devices
      --> Intel HD Audio: N

    3. Obs. 1: Desabilitar todas as opções que não são relativas ao hardware diminui o tempo de compilação

    4. Obs. 2: Necessitei deixar as opções de Gerenciamento de Energia habilitada para a compilação, mas no boot do kernel utilizo as opções noacpi e noapm

  7. Compilando:

    $ make-kpkg --initrd kernel_image kernel_headers

  8. Aguardar o término da compilação. Pode levar horas.

  9. Ir para a pasta src:

    $ cd ..

  10. Criar a pasta de firmware para esta instalação [Um bug no pacote criado gera uma mensagem de erro durante a posterior instalação do pacote, por isso a necessidade deste passo]:

    mkdir /lib/firmware/2.6.23-rtai

  11. Instalar os pacotes Debian criados:

    $ sudo dpkg -i *.deb

  12. Reiniciar com o kernel novo.

Compilando o RTAI
  1. Apagar qualquer versão anterior

    $ rm -rf /usr/realtime

  2. Ir ao diretorio do RTAI:

    $ cd /usr/src/rtai

  3. Configurar RTAI

    $ make menuconfig

  4. Compilar RTAI

    $ make
    $ make installs

  5. Reboot

    $ reboot

  6. Ir ao diretorio do testsuit:

    $ cd /usr/realtime/testsuit/user

  7. Testar a instalação

    $ cd latency
    $ ./run
    $ cd ../preempt
    $ ./run
    $ cd ../switch
    $ ./run
Testando o RTAI

Para se saber se o sistema está aceitável ou não, a implementação do RTAI contém um conjunto de programas de teste e calibração: o testsuit para os testes. O objetivo é que a latência seja baixa, sem overruns e valores de tempo de troca de contexto o menor e menos variante possível.

O resultado dos testes realizados em minha máquina após todo o procedimento de instalação está mostrado abaixo, as quais mostram respectivamente o resultado do teste de latência, preempção e troca. Note que o número de overruns é zero. Os testes foram executados com carga, isto é, no momento do teste, a interface gráfica estava ativa e rodando várias aplicações de usuário, em especial, em um terminal estava sendo rodado o programa flops.