Comentários do Blog

  1. Avatar de edcomrocha
    Opa então ja são 3 interessados, manda ver, gosto de astronomia tambem

    Abraços
  2. Avatar de code
    Que bom! Já temos dois (possíveis) interessados no curso. Quem mais tiver interesse, deixe seu recado nos comentários. Sugestões também são bem vindas. Lembrem-se que vou começar este curso sobre o Stellarium, do zero, em todos os sentidos, seja desde a instalação do software, até um básico de astronomia para que todos possam acompanhar o curso sem probemas.
  3. Avatar de tuxdahora
    Eu também tenho muito interesse por Astronomia, e gostaria de conhecer mais sobre o Stellarium. Se você puder criar uma série de posts que compreendam um curso de instalação e uso deste software (principalmente associado a parte prática da observação dos céus com lunetas e telescópios), será muito bem vindo.
  4. Avatar de nickmarinho
    Eu gosto de observar as estrelas e pretendo comprar uma luneta pelo menos.
    Mas por enquanto ainda não estou dispondo de recurso para tal.

    Eu quero receber conteúdo sobre o assunto.
    O que puder me enviar eu agradeceria.

    Abraços
  5. Avatar de code
    Citação Postado originalmente por pssousa
    Sábias palavras, code!

    O grande problema (o que certamente não acontece aqui) é que quando muda a cor do mouse o usuário final (os 90% que usam sistema operacional fechado) só encontra o teclado, entende?

    Muitas da vezes tentei convencer meus clientes que o Foxit é infinitas vezes mais rápido e com o mesmo propósito quando comparado ao Adobe Reader, mas, infelizmente, essa é uma luta perdida...

    Enquanto ele não vê o ícone vermelho do Adobe 9 no seu desktop não se contenta. Mesmo que o programa que abre e gerencia deus Portable Data Files seja o Foxit. Santa paciência...:damnmate:
    Entendo perfeitamente seu problema. Eu tenho sofrido com isso a mais de 10 anos. Trabalho com Linux (e tenho utilizado desde então exclusivamente o Linux) desde 1998. E desde essa data, também tenho incentivado migrações com pessoas físicas e jurídicas, para que elas larguem o Windows e venham para o Linux. E um dos problemas que nunca muda é esse: se o usuário não encontra o botão do jeito que ele conhece, da cor que ele conhece, no lugar de sempre, ele nem vai tentar procurar onde aquela funcionalidade se encontra, e vai alardear aos quatro ventos que o "programa não presta"! Mesmo que o programa em código aberto sugerido seja muito melhor que sua versão proprietária em uso.

    RESUMINDO: Só porque ele não encontrou a funcionalidade (i. é: porque nem a procurou), vai dizer que o programa não presta. É fato!

    Mas eu continuo insistindo, em paralelo ao meu trabalho, em auxiliar migrações bem sucedidas de Windows para Linux e, nesses mais de 10 anos, tenho aperfeiçoado as "técnicas de migração", principalmente para lidar o melhor possível com esse tipo de usuário: o que "não quer pensar", e parece querer ficar preso aos ciclos viciosos de problemas dos softwares proprietários. Isso sem contar que um dos maiores incentivadores desses usuários a continuarem com o software proprietário é a PIRATARIA, ao qual sou terminantemente CONTRA (mas isso fica para um próximo post ;-).

    No caso de leitores de PDF, como eu só trabalho com Linux, sempre aconselho as pessoas a migrarem seus computadores para esse sistema operacional. E lá, pronto! Tudo está instalado e configurado por padrão. E se não estiver o que você procura, é só ir nos repositórios e selecionar para instalação. É tudo "automágico" :-D

    Eu também prefiro incentivar programas para Linux (apenas) que sejam de código aberto (exclusivamente). Então eu faço minhas, as palavras do tuxdahora, quando ele sugere os leitores PDF das versões correntes do KDE.
    Atualizado 27-12-2009 em 21:43 por code (Correção gramatical.)
  6. Avatar de tuxdahora
    Minha sugestão vai para os leitores PDF já embarcados em qualquer distribuição Linux baseada no KDE, ou que possua os mesmos repositórios em seus servidores. Lá, procure por KPDF (KDE 3.5.x), ou o Okular, que vem para substituir o KPDF nas versões do KDE 4.x. O mais interessante do Okular é que ele, além de PDF, pode ler arquivos no formato CBR (que nada mais é que um formato de compactação do tipo RAR, e muito utilizado para armazenar sequências de imagens digitais como revistas e quadrinhos).
  7. Avatar de fbugnon
    Eu recomendo o Sumatra: sumatrapdf - Project Hosting on Google Code
    Já inteiramente traduzido para o português.
    Para a imensa maioria dos usuários é o quanto basta.

    Infinitamente mais leve e rápido que o Adobe Reader ou mesmo o Foxit.

    E além disso, tem a grande vantagem de ser software livre e não apenas grauito como o Foxit...
  8. Avatar de pssousa
    Citação Postado originalmente por code
    Estive pensando aqui com os meus botões: o código do Adobe Reader é tão ganbiarra assim, a ponto de, caso se corrija uma falha crítica antes do "suposto prazo" de correção de bugs deles, o resto dos bugs que forem encontrados não poderão ser corrigidos por um bom tempo? Será que uma correção antecipada consegue bagunçar mais ainda um código a ponto de inviabilizar as correções de outras falhas?

    E onde está a suposta programação estruturada e modular, que um software deste calibre deveria ser/ter? O Adobe Reader não passa de uma "enorme macarronada mal-servida", a ponto do código do programa ser uma "enorme emaranhado de código"? E pra corrigir um problema em "uma sopa de letrinhas dessa", você precisa Fazer novas e novas gambiarras, a todo momento, sendo que qualquer gambiarra adicionada, forçosamente atrapalha ainda mais a correção de novas falhas que apareçam no futuro? Que raios de projeto é esse? Só podia ser um projeto de código fechado! Se ninguém vê o código, ninguém pode reclamar... até o momento que acontece situações como essa...

    Esse é o caminho mais curto até a entropia máxima (também conhecido como Caos). Ainda bem que existem muitos outros leitores de arquivos no formato PDF que são livres (e, sendo redundante, possuem o código fonte aberto, e são projetos geridos pela comunidade, além de muitos serem para Linux). Esses mesmos projetos também são muito mais leves, e possuem um código bem mais estruturado. Verdade! Isso você só encontra em projetos de SL/CA (Softwatre Livre e de Código Aberto).

    Quando o projeto é livre, dificilmente teremos (muita) gambiarra no código. Quando o código é público, não dá pra ser ruim de se trabalhar nele, pois se o mesmo fosse algo horrível de se manter, os interessados em participar do projeto nunca conseguiriam sequer mexer um bit no código, e o "produto final" nunca conseguiria ser lançado. E quando um projeto fechado tem seu código aberto a comunidade, é bastante comum vermos "re-engenharias" sendo aplicadas nele. Por que será (modo irônico ativado)? Acredito que, se as ganbiarras fossem tão monstruosas em um projeto de software livre, o mesmo não teria futuro.
    Sábias palavras, code!

    O grande problema (o que certamente não acontece aqui) é que quando muda a cor do mouse o usuário final (os 90% que usam sistema operacional fechado) só encontra o teclado, entende?

    Muitas da vezes tentei convencer meus clientes que o Foxit é infinitas vezes mais rápido e com o mesmo propósito quando comparado ao Adobe Reader, mas, infelizmente, essa é uma luta perdida...

    Enquanto ele não vê o ícone vermelho do Adobe 9 no seu desktop não se contenta. Mesmo que o programa que abre e gerencia deus Portable Data Files seja o Foxit. Santa paciência...
  9. Avatar de code
    Estive pensando aqui com os meus botões: o código do Adobe Reader é tão ganbiarra assim, a ponto de, caso se corrija uma falha crítica antes do "suposto prazo" de correção de bugs deles, o resto dos bugs que forem encontrados não poderão ser corrigidos por um bom tempo? Será que uma correção antecipada consegue bagunçar mais ainda um código a ponto de inviabilizar as correções de outras falhas?

    E onde está a suposta programação estruturada e modular, que um software deste calibre deveria ser/ter? O Adobe Reader não passa de uma "enorme macarronada mal-servida", a ponto do código do programa ser uma "enorme emaranhado de código"? E pra corrigir um problema em "uma sopa de letrinhas dessa", você precisa Fazer novas e novas gambiarras, a todo momento, sendo que qualquer gambiarra adicionada, forçosamente atrapalha ainda mais a correção de novas falhas que apareçam no futuro? Que raios de projeto é esse? Só podia ser um projeto de código fechado! Se ninguém vê o código, ninguém pode reclamar... até o momento que acontece situações como essa...

    Esse é o caminho mais curto até a entropia máxima (também conhecido como Caos). Ainda bem que existem muitos outros leitores de arquivos no formato PDF que são livres (e, sendo redundante, possuem o código fonte aberto, e são projetos geridos pela comunidade, além de muitos serem para Linux). Esses mesmos projetos também são muito mais leves, e possuem um código bem mais estruturado. Verdade! Isso você só encontra em projetos de SL/CA (Softwatre Livre e de Código Aberto).

    Quando o projeto é livre, dificilmente teremos (muita) gambiarra no código. Quando o código é público, não dá pra ser ruim de se trabalhar nele, pois se o mesmo fosse algo horrível de se manter, os interessados em participar do projeto nunca conseguiriam sequer mexer um bit no código, e o "produto final" nunca conseguiria ser lançado. E quando um projeto fechado tem seu código aberto a comunidade, é bastante comum vermos "re-engenharias" sendo aplicadas nele. Por que será (modo irônico ativado)? Acredito que, se as ganbiarras fossem tão monstruosas em um projeto de software livre, o mesmo não teria futuro.
  10. Avatar de felipemhz
    Por isso que eu uso faz tempo o FoxIt Reader.
    Tem as mesmas funcionalidades do Adobe Reader e é 10X mais leve.