Diego Pereira escreveu: > Só meus 2c (meio offtopic). > > Eu não sou usuário habitual do OO, mas precisei usar ele este semestre pra > fazer umas apresentações rapidamente, nada muito complexo, mas incluindo > alguns gráficos, gerados por ele mesmo. O meu problema não foi na > apresentação, foi quando da geração dos slides mesmo, deu pra perceber um > comportamento muito instável. Pra fazer uma apresentação com uns 15 slides > ele "morreu" umas 3 vezes, sendo que numa delas levou parte do meu trabalho > junto e tive que refazer. Repito: o vexame do OO nesse caso foi que os arquivos que ele gerou foram lidos de forma incorreta pelo Power Point. O OO em si não falhou porque na faculdade não o usam. Quanto ao problema com slides, parece-me claro que o OpenOffice não consegue transformar as instruções XLM que criam os gráficos em algo que o PowerPoint entenda (e pelo que sei o power point não cria gráficos a partir de séries de dados). > Eu nunca cheguei a olhar o código do OO, mas já > ouvi comentários de que não é lá essas coisas. Desde quando ele era StarOffice isso já e famoso, algumas pérolas:
* Os comentários do código, na época em que o código foi aberto, eram em alemão. Por isso muito do código teve de ser reescrito, sempre que os programadores não sabiam alemão e não entendiam o que o código fazia. * O código do OO não era (não sei se já) indentado. * O código do OO não tinha linhas em branco. * Os nomes de funções eram em ALL_CAPS * Boa parte do código não pode ser aberto porque continha linhas licenciadas de empresas terceiras (Lernout & Hauspie, entre outras) e por isso essas funcionalidades tiveram que ser recriadas. * Por alguma razão a Sun se recusou a portar a interface para QT, embora isso fosse uma sugestão popular entre os desenvolvedores. Alguns argumentam que eles simplesmente resolveram não tomar partido na rivalidade Gnome/KDE ao desagradar a ambos. * A compilação do OpenOffice depende de uma série de programas pouco usados no mundo linux. A shell tem que ser zsh por causa dos scripts usados durante a compilação. O programa make tem que ser o cmake (cujo único uso importante hoje é compilar o OO). As build-deps do OO incluem pelo menos vinte bibliotecas que ninguém mais usa. > A mesma coisa vale pro > firefox e seus memory leaks. > Por isso me alterno entre o Seamonkey, o Galeon e o Opera. > Enquanto que software livre tende a ter uma boa qualidade, isso de forma > alguma é uma regra, e esses programas demonstram isso. Minha impressão é um pouco diferente: Software livre popular tende a ser de boa qualidade. Programas menos conhecidos tendem a ser instáveis, cheios de erros de design ou dotados de poucas funcionalidades. > Em relação ao OO, > depois do comportamento que eu percebi minha confiança nele caiu muito. > O problema é que o desenvolvimento do OO é imensamente mais complexo do que o da maioria dos projetos OpenSource. Eu digo isso de cadeira porque estou acostumado a compilar tudo quanto é programa. Eu já baixei o código fonte do KOffice 1.3, fiz adaptações e o compilei com dependências compartilhadas para que rodasse ultra-rápido em meu PC. Deu certo. Eu sempre compilei o Abiword quando usava o Conectiva porque aquela distribuição tinha uma birra com esse programa e sempre estava duas ou tres versões atrás da versão recente. E ainda compilo o LyX, tendo sido uma das poucas pessoas a compilar e usar sua linda interface GTK (agora abandonada, snif!). Mas o OO é, ao lado do Mozilla, do KDE, do Gnome e do Kernel, o único software livre que tentei compilar e não consegui. No caso do KDE e do Gnome eu desisti porque percebi que quaisquer ganhos de performance que tivesse não justificavam perder as vantagens do empacotamento. No caso do Mozilla e do OO a coisa é diferente. O código fonte do OO tem quase 300 MB e fica com mais de 1.5GB depois de descompactado. Para poder compilar você tem que instalar mais de 100 MB de build-deps (isso da última vez que eu tentei, no tempo do Fedora 3). Só a configuração, se você conseguir uma combinação de opções que não sejam contraditórias, levou quase quarenta minutos! A compilação era estimada em 16 horas para um processador AMD k-6II em 2005. Acredito que hoje, com meu processador, ela ainda duraria pelo menos umas oito horas! Como compilar o OO é uma tarefa indimidante, que está acima da capacidade -- e da pachorra -- da maioria dos usuários, o OO acaba tendo muito menos contribuição que outros projetos e o seu desenvolvimento fica dependendo do antigo time da StarDiv (Alemanha) e dos times da Sun (EUA) e da Red Flag (China). Não sei de nenhuma outra comuhidade forte de desenvolvedores além destas -- e tenho sérias dúvidas se a RedFlag não é só propaganda. Eu já postei uma vez na web que seria prestado um grande serviço ao Mundo Livre se uma equipe de desenvolvedores criasse, a partir do zero, uma suíte de escritório leve baseada nos formatos ODF (eu sugeriria o kit FLTK para ficar leve até para processadores antigos) que substituísse o OO na maioria dos usoa. De certo modo, o Koffice, se for bem cuidado, tem o potencial para fazer isso (e se tornar mais um dos 12 motivos para se usar KDe em vez de Gnome). > Eu teria muito mais confiança em recomendar o uso de SL baseado em qualidade > e robustez no passado, de um tempo pra cá, em muitos projetos nota-se uma > deterioração. Isso tudo, claro, é só a *minha* percepção, talvez eu tenha só > tido um pouco mais de azar que a média, vai saber. > Sua percepção é muito rigorosa, mas eu acho também que certos projetos, Mozilla e OO principalmente, estão ficando complexos demais. Daqui a pouco o Mozilla já vai ter seu próprio kernel e sua própria planilha. Dentro de alguns anos o OO vai navegar na internet, administrar email e rodar um mini-kernel... etc.... ;-) -- José Geraldo Gouvea www.mundosefundos.co.nr -- Interessado em aprender mais sobre o Ubuntu em português? http://wiki.ubuntu-br.org/ComeceAqui - ubuntu-br mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-br
