[Ubuntu-BR] Vexame do OO

[José Geraldo Gouvea]

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