O OpenOffice.org deveria ser uma suíte light?
Enviado por Ednei Pacheco (ednei·pachecoΘgmail·com):
““Não é que esteja reclamando do desempenho e consumo energético das versões atuais do OpenOffice.org, muito pelo contrário: ele vem rodando redondinho em meu netbook, que é uma máquina com capacidade de processamento limitada. No entanto, ao olhar para o poderoso e consagrado Microsoft Office, me parece que ter um perfil de uma suíte Office leve, rápida e de fácil manutenção, pode ser uma ideia interessante para o futuro da suíte. Então, que vantagens teríamos se as futuras versões do OpenOffice.org fossem concebidas para serem lights? Por Ednei Pacheco” Veja em: http://www.guiadohardware.net/artigos/openoffice-light/” [referência: guiadohardware.net]
• Publicado por Augusto Campos em
2010-09-03
@brlinuxblog
Feed RSS
Acho que, pelo menos se tratando de ambiente Linux/BSD, já temos alternativas de suítes mais leves como o KOffice, Gnumeric e outros.. logo, isso não me preocupa..
Temos que levar em conta que, depois do Firefox, o Openoffice é um dos aplicativos livres mais famosos, e roda justamente no Windows.
O KOffice não roda sem o KDE (estou sendo simplista aqui), e o GNumeric, bem, ele é uma planilha separada. Posso estar falando besteira, mas um usuario comum se sentiria um pouco incomodado em baixar o Abiword e o GNumeric, quando ele pode ter de uma vez só uma suite de aplicativos com as duas coisas (e mais um monte de penduricalhos).
Mas, na real: quem ainda se preocupa tanto assim com programas leves? Eu queria ter um benchmark para comparar o MSOffice com o Openoffice (mesmo sabendo que o MS ganha por causa do Java), mas isso realmente importa? O proprio autor do artigo diz que o Openoffice roda bem em seu netbook…
Joséks, o Java não é obrigatório no OO. E fazem só uns 10 anos que ele não é mais pesado.
@Paul
Desculpe o off, mas Java não é pesado? Faz um teste ai usando um software que utiliza Java, tanto em Linux como no Windows que tu vai ter a resposta.
Continua pesado como sempre, mas como o desempenho e a disponibilidade de memória dos PCs aumentaram muito, parece que ele ficou mais leve.
No meu computador de testes, um AMD Atlhon64 3500+ de 2,2GHz com dual boot Ubuntu/Windows XP, o Java roda incrivelmente mais lento no Windows. Pior ainda se a janela for minimizada.
Já no Ubuntu, as aplicações parecem até GTK+ nativo (em relação à velocidade). O OpenOffice.org tem uma queda no desempenho quando o Java é habilitado nele, mas nada que reduza a minha produtividade.
Acho a ideia de se criar uma suíte light boa e muito válida. Eu não entendo essas pessoas que só olham pro próprio umbigo, com discursos do tipo: “ah eu tenho memória suficiente…” E quem não tem? E salas de inclusão que usam computadores mais modestos? Devem ficar privados de usar o OpenOffice?
Se há como fazer, até uma versão light do OpenOffice, por que não fazer?
Isso não tem sentido, o próprio autor diz que ele roda bem num netbook… E esse negócio de “software light” não é adequado para uma suíte de aplicativos de automação de escritórios, que TEM que ter muito recurso mesmo.
Vale lembrar que atualmente já existe uma série de suítes leves disponíveis “na nuvem”, que permitem preparar textos, apresentações e planilhas mais simples de forma bem razoável. Creio que um OpenOffice mais leve seria um tanto redundante neste cenário. É claro que qualquer ganho de performance que possa ser obtido através de uma melhor programação é sempre bem vindo, mas acho que abrir mão de recursos em prol deste ganho pode não ser o melhor caminho para a suíte. Até porque usuários que precisam de recursos mais avançados ficariam um tanto órfãos.
Eu melhoria essa frase e diria que, pelo menos hoje em dia, o KOffice não roda nem no KDE.
Tenho tentando usar o KOffice desde as primeiras versões 2.*, e ainda está muito difícil.
Abs!
O Koffice ainda precisa andar muito para ser uma verdadeira opção viável para substituir o OOo.
Até se a Oracle ficar de bobeira com o OOo como fez com o OpenSolaris, pode ser uma boa para atrair mais ajuda.
No dia(se esse dia chegar) que o Koffice for uma opção viável, certamente vão criar um instalador para Windows do tipo NNF sem traumas.
Existe instalador do KDE para windows que vai baixando dependências, mas por enquanto é só para experiências.
Acho que o que poderia ter é o seguinte:
Poder baixar em partes o pacote, pois a maioria das pessoas não usa nada além do Writer, Calc e Impress.
Além disso o Impress que muitos usam pra ver anexo de e-mail, a maioria usa apenas pra visualizar, poderia então abrir num modo Visualizador, pra carregar mais rápido e se quiser poderia abrir o modo edição como opcional. Agora a opção de tirar recursos eu não concordo.
Talvez, quem sabe (posso ta falando bobeira) mas se o openoffice utilizasse QT4 ou GTK não seria mais rápido em vez de usar uma API própria.
Sim, o (BR)openoffice é pesado, mas se comparar-mos com o que é exigido pelo sistema operacional da MS hoje, será que realmente é tão pesado? Muitas funções do MSoffice rodam em backend com o próprio sistema operacional causando a ilusão de que é leve, o que não o deixa de ser. Um comparativo justo seria fora do ambiente windows, para que tivéssemos uma idéia real, não tenho um mac, mas que o tem podem opinar melhor sobre o desempenho das suites.
Pessoalmente falando, mesmo o (BR)openoffice, gastando mais memória, mas dentro de um ambiente mais lite, se compensa a perda de desempenho gerando uma melhor relação custo/benefício. Acredito que uma forma modular da suite seria mais interessante, visto os usuários que precisassem de mais recursos fossem implementando, tais recursos, com extensões.
Entendo que o OO fica tão poderoso quanto o MS Office devido aos seus recursos implementados, mas que por outro lado incha.
Um idéia (o inferno está cheio) seria implementar o básico como indicado no texto e essas características serem plugins ou desativar para ficar mais rápido o seu objetivo. Imagino que isso faria o OO muito mais rápido, muito menor (em instalação) e muito menos uso de recursos que o MS Office.
Esses “plugins” ou Add-ons poderiam vir em pacotes separados (em grupos para não criar 500 pacotes) mas sim uns 10 a 20, é uma ideia.
Att.
O java não é pesado mesmo, quando comparado com liguagens compiladas nativamente e bibliotecas nativas, pode até ser, mas de um aspecto geral até que ele não é pesado. A suíte light do OO poderia ser muito útil e interessante, mas não é primordial ou necessária. Há alternativas.
Concordo com a parte do texto: quantos aqui realmente usam Base, Draw e Math? Porque não mante-los em separado, seja 2 pacotes (1 completo e outro só com o fundamental Writer, Calc e Impress), ou mesmo disponibilizando a instalação das d+ opções posterior as padrões q todos usam? Vários offices on-line ou o Symphony disponibilizam apenas o q é realmente usado: Texto, Planilha, Apresentação. E mesmo esse trio deveria conter por padrão apenas o que é necessário, oferecendo a instalação posterior d diversos opcionais.
Também acho que o trio Writer, Calc e Impress sejam o suficiente para uma boa parcela dos usuários. Se a oferta de uma pacote apenas com os três puder melhorar a performance do OOffice seria uma boa opção. Só tenho minhas dúvidas se a oferta de mais ou menos opções dentro do pacote teria esse efeito benéfico na performance da suíte.
Me corrijam se eu estiver errado: o KOffice e o MSOffice são leves devido à maior integração com o sistema, fazendo uso de bibliotecas existentes (e previamente carregadas) no KDE e Windows, respectivamente. Já o OpenOffice tem que carregar várias bibliotecas próprias (mais pesadas que as dos outros programas) para que seja executado. Então, acho que limitar os recursos do OpenOffice não vai resolver o problema de forma definitiva. Aliás, se não estou enganado, no Windows e em algumas distribuições Linux é possível instalar apenas alguns componentes do OpenOffice. Só não sei se isto tem o mesmo efeito de uma redução de recursos e nem se resulta em melhora da performance.
@psicoppardo.
Eu tenho um Mac. O OOo é leve! E graças a um grupo que reimplementou o OpenOffice nativo como o NeoOffice, o OO ficou utilizável no Mac. Os desenvolvedores do OOo aproveitaram de uma facilidade do Mac de rodar nativamente o X11 (a partir do Leopard) e fizeram a m*rda de colocar o OOo nesse ambiente emulado.
Com o Gimp é a mesma coisa, não existe versão nativa para Mac, então roda uma do linux modificada para Mac no servidor X11! O Gimp já não é lá essas coisas, e ainda quer competir, no Mac (!!!), dessa forma com o Photoshop!? Piada, né! É o que eu sempre digo: se for para fazer mal feito, não faça.
Mas o Office é leve no Mac! O NeoOffice também é. Aliás é super leve, a galera do NeoOffice fez um excelentíssio trabalho. Mas no Mac é difícil de comparar porque o hardware é muito bem feito e o software, além de bem feito é otimizado para o hardware. O meu primeiro MacBook de mais de 2 anos de vida tem um chip 2.4G C2D com 4G de RAM com placamãe projetada pela Apple rodando Mac OS 10.6. É covardia. O meu MacBook mais novo tem chip 2.53G C2D, mas com projeto da placamãe bem mais novo. É mais covardia ainda.
O que eu acho é o seguinte: o openOffice tem que largar mão de usar Java e ser implementado inteiramente em C/C++. É por isso que o MSOffice é mais leve.
No Mac eu não vejo diferença não. Mas no windows. Hehehehe, no windows é gritante. E as ferramentas da Microsoft são incrivelmente leves. Mesmo com um linux, o OOo possui desempenho beeeem pior que o MSOffice.
E como eu disse, no Mac não tem diferença nenhuma. Aláis, a impressão que passa é que no Mac o NeoOffice é muito mais leve que o OOo do linux e do windows. Talvez (chutômetro), o pessoal do NeoOffice tenha convertido a parte java para Objective-C. Ai, hehehe, a coisa muda muito de figura.
Eu acredito que a matriz do problema do OpenOffice é a sua origem: o StarOffice. Esse sim era uma grande m*rda!
Em relação ao texto do Guia do Hardware, eu discordo totalmente. Escreve um OOo do zero! Já tem a espertise. Muitos software foram feitos assim. Inclusive o Kernel do linux!
@Tiago, acontece que o openoffice não é implementado em java. Ele é C++. O java no OO serve para coisas muito específicas, como filtros de importação e exportação.
E, neste caso em específico, a linguagem não interfere muito. O problema do OO é que ele parece ter sido feito “nas coxas”. Há dez anos o seu modelo de desenvolvimento até que funciona bem, mas hoje não funciona mais.
Na minha opinião o openoffice deveria sair um pouco da cena de atualizações e passar um tempo sendo reescrito. Se a Oracle ou a Novell se dispusessem a desenvolver um novo OO em paralelo, utlizando tecnologias atuais (como C++/Qt ou mesmo C#/Mono) e cobrasse para isso, garantindo que teria um produto semi-pronto em, quem sabe, um ano, eu pagaria uma mensalidade sem problemas.
Mas acontece que o Office 2007 é uma super suíte, cheia de recursos e tudo mais, e ainda o Office 2010, que está pra sair, vem ainda com mais recursos, tendo ainda um desempenho bem melhor que o OpenOffice.
Não ligo tanto que o OpenOffice demore para iniciar (este tempo diminui bastante se vc desabilita o java, mas não fica tão “instantâneo” quanto o MS Office), seu desempenho ainda é ruim, principalmente se vc manipula muitos objetos no Impress, por exemplo. Além disso no Linux o OpenOffice é feio pra caramba. Não há “capa” em Gtk ou Qt que consiga esconder sua feira.
Por isso lá vai a minha dica pra Oracle ou para a Novell: peguem uns 5 ou 10 dos principais desenvolvedores do OpenOffice e o coloquem para trabalhar exclusivamente com a reescrita e redesign do software. O resto da equipe deixe fazendo manutenções na versão atual.
Abra o desenvolvimento da nova versão para a comunidade contribuir (colocando o código no github, por exemplo), e cobrem uma espécie de mensalidade dos interessados em ter um software funcionam dentro de um período de, sei lá, um ano. Creio que muitas vezes demolir o prédio e construir de novo é melhor que ficar tentando esconder rachaduras na estrutura (eita frase clichê!).
O Openoffice atingiu a marca de 400 milhões de downloads estes dias. Acho ser improvável que a menos uma parte destes milhões de usuários não se disponha a pagar para ter um software decente. Eu pagaria, desde que pudesse ser um valor “voluntário”.
Ah sim, o Koffice 2.x ainda não está muito leve não. Tem bem menos funcionalidades que o OpenOffice e mesmo a versão 1.x do Koffice. Mas está com um visual e funcionalidades bacanas.
Se eu disser para você que eu uma vez usei o ms-word no laptop do meu colega no linux via wine e achei ele mais rápido que o openoffice, você acredita?
Não fiz nenhum teste sério, apenas percepção natural, mas me pareceu claro que o msoffice é mais rápido mesmo nessas condições.
Bem é verdade que o openoffice tem melhorado muito a questão da velocidade a cada versão. Que continuem assim então.
Abs!
No meu Phenom II X4 945 + 4gb memória DDR3 + ATI HD 4000 é um piscar de olho para iniciar o Desktop do Ubuntu Lucid e outro piscar de olho para abrir o Writer. Então se melhorar estraga…
@Curioso, se vc acha que foi apenas o hardware que evoluiu, sorry, mas você não manja bosta nenhuma de Java.
Não estou dizendo que é peso-pena. Mas há anos são feitas otimizações a cada release.
@Paul
Nem se estressa com esse pessoal que ainda tem na cabeça que Java é uma carroça.
Eles acham que o simples fato de um programa ser escrito em Assembly faz dele o programa mais rápido do mundo…
OpenOffice Light se chama Google Docs.
@Limão, a implementação do java da Sun realmente tem uma ótima performance, mas programas em Java pra desktop ainda são bastante penosos para iniciar. Dizer que não é fechar os olhos para a realidade (ao menos para a minha! hauah). E não é culpa de rodar em cima de uma vm não, já que programas em mono rodam bastante rápido no Linux. Talvez o problema esteja na toolkit gráfica usada pelos programas para desktop, o tal do swing. Alguém aí já programou para desktop usando java+qtjambi para ver se existe muita diferença de desempenho?
O OO tem a opção de instalar somente o editor de textos e planilha, mas mesmo assim é pesado.
Segundo os desenvolvedores, o @Fellype está certo, tem muita coisa que ele implementa sozinho sendo que já existe no Sistema Operacional, um dos motivos dele ser lento. Outra é que o código dele é assumidamente bagunçado, cheio de gambiarras e com muitas apis antigas que não exploram os recursos que existem hoje nos SOs modernos.
Os desenvolvedores se defendem dizendo que a equipe deles é muito pequena, a Sun praticamente cedia as máquinas mas entrava com poucos desenvolvedores e quase nenhum dinheiro. Até 3 anos atrás, existiam apenas 2 (DOIS) desenvolvedores voluntários pra versão do Mac OS X, só então a Sun emprestou mais gente.
Sobre o peso, pras máquinas atuais não incomoda tanto, mas é fato que ele é mais pesado que o MS Office, mesmo tendo menos recursos. E mesmo no Mac OS X, nos testes que fiz, ainda é mais pesado.
Não sei se uma versão light ajudaria, já que versões light de suítes de escritório existem aos montes, o que falta é justamente o propósito do OO: uma suíte comparável ao MS Office. Mas ele precisa de investimentos.
O Larry Ellison é adversário ferrenho da MS, sempre foi. Se ele vislumbrar a suíte gratuita como uma forma de enfraquecer o concorrente, talvez invista pesado nele. Se ele preferir deixar a versão corrente como está e direcionar o StarOffice (versão comercial do OO) para o mercado corporativo, daí não ajuda nem prejudica.
Marcos Alexandre (usuário não registrado) em 3/09/2010 às 5:31 pm
“Segundo os desenvolvedores, o @Fellype está certo, tem muita coisa que ele implementa sozinho sendo que já existe no Sistema Operacional, um dos motivos dele ser lento.”
faz parte da tradicional cultura java de redundância e desperdício para vender hardware Sun mais potente… bem, Sun não existe mais, poderiam parar com isso. Mas já é tarde na maioria dos adestrados nessa cultura…
Agora que consegui pegar o jeito +/- no Base vão querer de inventar em cancelá-lo? Ai ai ai!!!
Desativando o Java o Base não funciona. Acho que as macros do Calc idem. Agora, mesmo desativando o Java, o OpenOffice continua um peso. Agora concordo que podia ser viável baixar os principais pacotes (Writer, Calc e Impress) em separado, deixando o Draw, Formula e Base como opcionais. Mas isso é possível fazer no Linux. No Windows tem que baixar o pacote inteiro, mesmo se for só para usar o Writer.
De boa, eu queria que a Novell assumisse o OpenOffice e o VirtualBox (ainda que este último tenha melhorado quando a Oracle assumiu). O OpenSUSE está um primor. A Novell faria maravilhas no OO e no VBox.
Já vi que comentaram, então deixo a minha opinião de que deveria haver um programa visualizador ou mesnos para o Impress.
Vivo recebendo (e quem não vive?!) e-mails com apresentações anexas. Eu e 99,9% só vão querer ver a apresentação, na verdade eu acho um saco receber tantas e a maioria eu não quero ver mesmo, mas acredito que deixo de ver algumas apenas pq é um saco esperar o Impress carregar no meu netbook.
Eu não consigo colocar o BrOffice.org Impress para rodar a apresentação 100% tela cheia, sempre ficam umas bordas. Notei isso nas versões mais atuais, pois antes não acontecia isso.
Concordo com a opinião do Valerio Dias para que a Novell assumisse o OO.
A versão da Novell (http://www.go-oo.org/) está bem a frente dos demais, tanto em desempenho como em aparência e em funcionalidades. Pelo que sei só ele tem um tema que “reveste” ele do belo KDE 4, inclusive usando as caixas de dialogos do mesmo. ;)
Mas mesmo assim existe uma enorme lentidão na hora de manipular a suite, principalmente se for salvar um documento com muitas imagens ou com varias paginas.
Façamos um paralelo entre o OpenOffice e os ambientes gráficos (KDE, GNOME etc etc).
Os recursos de hardware (cpu, memória e etc) que os ambientes gráficos requerem, além da complexidade dos programas, são infinitamente maiores que o OpenOffice. No entanto, o OpenOffice parece gastar muito mais recursos.
Apenas para relembrar, o StarOffice queria ser um ambiente gráfico, com um desktop, menu com os programas instalados e por ai vai. Aquilo era um peso enorme.
Como o código do starOffice foi base, isso me leva a crer, que a forma com que foi escrito o OpenOffice, não estou falando da linguagem, faz com que fique pesadão, já que ele independe do ambiente gráfico. Em outras palavras, tudo que ele necessita, praticamente está dentro dele mesmo!
Acredito que a melhor forma de programação, seria alocar, embutir parte das suas ‘engines’ dentro dos ambientes gráficos. Dessa forma, o OO ficaria mais leve ao ser carregado e as engines seriam ligadas apenas após a chamada da principal.
Isso poderia engordar um pouco o motor base desses ambientes na memória, mas como seriam executados apenas quando chamados, não traria danos a performance desses ambiente. Talvez no carregamento inicial.
Contudo, esta integração das equipes de desenvolvimento / mantenedores para viabilizar esse projeto, teria um custo: uma ferida no ego!!! Alguém teria de ceder.
Rapaz, para mim o texto nao faz o minimo sentido, nao sei se o autor sabe da existencia das instalacoes personalizadas onde ele pode escolher os componentes que serao ou nao instalados. Eu uso debian GNU/Linux e posso escolher pacote a pacote componentes e extensoes que farao ou nao parte do meu OO.o instalado, podendo facilmente incluir ou retirar aplicativo ou extensao, com bem quiser.
Outra coisa importante, acredito que o autor nao se deu o trabalho de verificar os argumentos da MS na disputa, sempre relatando os itens a mais que o time da ‘janela’ tem que o da sabichona (Oracle) vermelha nao tem em seu pacote de produtividade.
Devemos ajudar a aumentar o numero de funcionalidades e manter o OO.o modular.
O autor nao conhece obiviamente a regra dos 80 – 20, isso deve ser levado em consideracao quando estivermos falando da mais importante suite de produtividade do mundo FOSS. Se tirarmos uma funcao que 20% usa, vamos ter um abandoo de 20% dos usuario, que nao serao mais atendidos plenamente e os que sobrarem vao constituir uma nova formatacao 80 – 20, ai vamos tirar a funcionalidade que somente esses novos 20% usam, e tchau para eles junto com as funcionalidades. Enquanto isso no mundo Closed Source, mais e mais funcionalidaes sao adicionadas, expandidas e devidamente exploradas.
Devemos nos perguntar o porque de uma funcao esta sendo parcamente usada e nao exclui-la, permitir que nao seja instalada tudo bem, mas o que realmente precisamos eh de livros, cursos, video aulas, materias em revistas de grande influencia, zines com mais que textos dizendo, para que serve tal aplicativo ou botao de aplicativo, mas com exemplos de casos de usos didaticos. Por exemplo funcoes e formulas nao eh coisa de cientista da Matematica ou Fisica so nao, Engenharias, Geologia, humanas como Economia e Contabilidade, saude como Farmacia, Biologia e Medicina (alguem ai sabe como sao desenvolvidos os remedios hoje em dia?!?!?!). Hoje em dia quem nao usa formulas eh porque nao sabe usar (ou a formula ou o programa para escrever) e nao porque nao necessita, entao devemos nos concentrar em tornar acessivel esse conhecimento. Ateh o pessoal de Computacao usa (ou deveria), seguranca, redes, hardware, complexidade de algorithms, problemas de optmizacao (vixi a lista nunca acaba, dah para colocar o simbolo de infito aqui? ;-p ).
Sera que alguem acredita que a MS esta pensando em descontinuar o MS Access (tah loco?!?!?), MS Project, Visio, Publisher, InfoPath (e vc que exluir o formula ?!?!?). Defendo ampliar o OO.o com um aplicativo so para competir com o MS Visio, deixando o OO.oDraw mais focado e design publisher para fazerfrente ao MS Publisher, bem como melhorar extensoes como a publicacao para web sites e wikis, a programacao linear e nao linear dentro do OO.oCalc e o mais importante, um concorrente ao treinamento da MS que pode ser instalado com texto videos e animacoes mostrando como usar cada coisa do MS Office EM EXEMPLOS praticos (desculpe a caixa alta, eh so para enfatizar) e nao, botao > funcao. Vah perguntar a equipe do KOffice (cada vez melhor!! alegria de ver o trabalho dsses caras e mocas) se eles querem ser um basicao sem opcionais de fabrica?
O GNOME Office desandou um pouco quando nao conseguiu implementar o Agnubis, para apresentacoes, mas tem um formato competitivo (precisar criar um nucleo mais proprio, minha opniao) com texto, planilha, e-mail, financas, diagramas e base de dados, o resto eh buraco tapado com outros projetos e totalmente nao-integrados.
Para mim o negocio eh muuuuito mais, nao menos. Menos deve ser escolha sua de nao instalar e nao a falta de opcao de acabar se bandiando para o lado MS da forca, ops, das suites de produtividade.
Acredito que produtos compactos como 4kids, ou para tables, smartphones e netbooks devam ser criados, mas meramente como subconjuntos devidamente selecionados e adaptados para cada caso e realidade.