|
Office 2003 chega e derruba
Windows 98/Me
Com a tradicional campanha milionária, pacote apresenta poucas novidades e só
funciona em versões mais recentes do Windows. Principais mudanças são no
Outlook e Frontpage. Confira a análise.
Paulo Rebêlo
Chegou às prateleiras a versão 2003 do Office, rebatizado com o nome de
Microsoft Office System. Tivemos acesso à versão final do produto, em inglês,
e apresentamos aqui as novidades do pacotão de programas.
A versão testada foi a Professional, com 5 CDs. O primeiro CD traz o Word,
Excel, Powerpoint, Access, Outlook e Publisher. O segundo vem com o Frontpage; o
terceiro CD inclui o Visio 2003 Pro; o quarto tem o Project 2003 Pro e,
finalmente, o quinto é o OneNote.
O nome Office System define bem a “nova” proposta para o pacote: um conjunto
de produtos, servidores e serviços; e não apenas a velha ladainha de programas
para escritório. A Microsoft empreendeu uma verdadeira odisséia no
desenvolvimento do pacote e, claro, na divulgação.
Antes de a versão final chegar aos fabricantes e à imprensa, mais de 600 mil
cópias de edições beta (para testes) foram distribuídas. De acordo com a
Microsoft, é quase o triplo de participantes de testes do que qualquer outro
produto.
Como nem tudo são flores, certas mudanças no Office podem prejudicar uma
significativa parcela de usuários e empresas. O lançamento marca de vez o
fim da plataforma Win9x: o Office System só funciona em Windows
2000, Windows XP e Windows Server 2003. Deixa para trás milhões de usuários
dos Windows 98, Millennium e NT.
O argumento da Microsoft é a garantia de apresentar um produto mais estável e
mais rápido justamente por ser otimizado às tecnologias embutidas no Win2000/XP.
Não é a primeira vez que isso acontece. A suíte Office XP, por exemplo, não
funciona no Windows 95.
Como sempre, as maiores diferenças são internas, invisíveis ao usuário
comum; por outro lado, o Office System chega com programas antes desconhecidos
dos usuários, como é o caso do OneNote e do InfoPath – este disponível
apenas nas versões “Enterprise” do Office.
A principal mudança significativa, que teve início de forma tímida no Office
XP, é a adoção do XML (eXtensible Markup Language) como linguagem
nativa.
Antes de sair correndo às lojas, vale a pena analisar a viabilidade (ou a
necessidade) de instalar o Office 2003. Um dos fatores de risco são os
requisitos de sistema. É preciso um mínimo de 128 Mb de RAM para rodar o
pacote, mas é claro que não se consegue boa performance com o mínimo. É bom
ter, pelo menos, 256 Mb de RAM e bons 600 Mb de espaço em disco.
Outlook –
Com o sucesso conquistado pelo Outlook, a nova versão deste gerenciador de
contatos e emails é, sem dúvida, o grande trunfo do Office 2003.
De todos os programas, foi o que mais ganhou alterações. Melhorou
visual, usabilidade, tecnologia, privacidade e segurança.
Muito mais integrado aos outros programas do Office, o novo Outlook pode
trabalhar com uma nova interface de três painéis – pode até parecer
complicada no início, mas aos poucos se torna uma mão na roda para quem lida
com muitas mensagens por dia e várias pastas. De acordo com a Microsoft, a
interface com três painéis implica um melhor aproveitamento de tela em até
40%.
Mordendo a própria língua, a Microsoft deixou a configuração padrão do
Outlook de forma a não permitir a visualização de emails em HTML –
aquelas mensagens que parecem websites e que podem trazer vírus e códigos
maliciosos.
A grande polêmica da história é que foi a própria Microsoft, a partir do
Outlook Express 4.0, que ajudou a disseminar emails em HTML no lugar de
mensagens em texto puro. A iniciativa de agora, em recusar emails HTML por
padrão, é uma questão de segurança contra vírus e, sobretudo, spam.
Claro que, se o usuário quiser, ele pode clicar em um botão dentro da mensagem
para ver o conteúdo.
Por falar em spam, ponto positivo para o sistema de controle de spam do Outlook,
bastante melhorado. E para quem gosta de manter sempre tudo bem organizado, o
Outlook pode combinar várias mensagens em um único segmento de data – ex.:
por dia, por semana, por mês... – facilitando o acompanhamento de emails.
Muita gente escreve software livre das 9 às 6. Alguns, inclusive, usam
gravata.Mas que coisa feia... Essas pessoas, sendo pagas por seus empregadores,
ficam brincando de fazer software que depois vão dar pros outros?
Não é bem isso. Para responder esta pergunta, eu vou citar alguns exemplos.
O produto que quase servia. Algum tempo atrás, trabalhando na empresa de
um amigo, havia um cliente que tinha a necessidade de autenticar os usuários da
sua intranet contra um domínio em um servidor Windows NT. É uma necessidade
comum.
O cliente, um banco internacional, tinha optado por construir sua intranet com
um servidor de aplicações chamado Zope (do qual eu gosto bastante, como
evidencia o "powered by" que permeia meu site). Localizamos um
componente para o Zope que permitiria fazer exatamente isto (e mais um monte de
outros truques que não vêm ao caso agora). Mas havia um problema.
No primeiro teste na rede do banco, o componente não funcionou. Examinando o
código-fonte dele, descobrimos que ele não funcionaria por motivos
relacionados à arquitetura da própria rede do banco (e que não seria, de
forma alguma, modificada). Conversamos e decidimos que o caminho mais fácil
seria arrumá-lo. Algumas horas depois, conversando com o "dono" do
projeto via IRC (ele vive na Austrália), dois de nós se tornaram colaboradores
"oficiais" (nossos nomes estão na página
do produto).
Poucos dias depois, não só o problema da autenticação estava resolvido, como
o produto tinha tido melhoras muito expressivas em seu desempenho com a
implementação de várias otimizações. E nós nem mesmo precisamos desvendar
os becos escuros do Windows por onde é feita a autenticação.
Resumindo: Melhorar um produto de terceiros tornou possível entregar,
rapidamente, uma solução que atendia as necessidades do cliente. Como um
efeito colateral, outras empresas que criam soluções baseadas em Zope têm uma
opção melhor para integrar suas aplicações às redes Windows dos seus
clientes. Se ninguém tivesse precisado da funcionalidade, ela não teria sido
implementada ou permaneceria minimamente funcional, exatamente como a
encontramos. A necessidade, e não as forças do mercado, guiam a evolução do
software livre.
Os outros exemplos não são em primeira mão, mas ilustram outras formas de se
usar software livre.
Tenho caixas para vender. Lá por 2000, a IBM tomou conhecimento de três
coisas. Primeiro: ela não tinha uma solução Unix muito boa em termos de
preço/performance. Isso estava fazendo com que concorrentes, entre eles a Sun,
levassem clientes embora.
Segundo: eles tinham servidores baratos, poderosos, baseados em hardware Intel,
que poderiam reverter isso, se, ao menos, a IBM tivesse um sistema operacional
Unix-like para colocar neles.
Terceiro: eles dependiam da Microsoft para fornecer o único sistema operacional
disponível para toda a linha de servidores Intel. Isto é, eles dependiam da
mesma empresa que era parceira no desenvolvimento do OS/2 e que lançou um
produto, o Windows 3, para concorrer justamente com o OS/2. Que Deus o tenha.
Nas palavras da IBM (eu uma vez conversei com um VIP responsável pelos
esforços de Linux da IBM - ainda estou procurando o cartão dele), em 2000, o
Linux não estava bom o bastante para aplicações críticas. Foi quando eles
decidiram que, em vez de portar novamente o AIX para Intel (existiu uma versão
dele que rodava nos PS/2 mais parrudos), eles investiriam recursos para tornar o
Linux "enterprise-ready".
Trocando em miúdos, a IBM achou que o mercado de sistemas operacionais
proprietários para PCs estava morto (a Microsoft consome todos os recursos
desse "ecossistema") e que não valeria a pena investir num AIX/x86
quando, por menos dinheiro, eles poderiam ajudar a deixar o Linux capaz de
atender às demandas dos clientes.
Brigas judiciais à parte (a SCO, ex-Caldera, acha que a IBM roubou código e
usou "métodos proprietários" dela para colocar no Linux), a IBM fez
várias contribuições de código para o kernel e drivers do Linux em áreas
importantes como escrita em discos e suporte a multi-processamento com acesso
não-uniforme à memória (que tinha sido desenvolvido por uma empresa que a IBM
comprou, a Sequent, especializada em computadores com dúzias de processadores).
A IBM também fez e bancou vários estudos sobre como o uso de servidores Intel
rodando Linux é economicamente vantajoso em relação ao emprego de máquinas
RISC rodando versões proprietárias de Unix (inclusive os pSeries da própria
IBM). Debaixo da mesma bandeira, favoreceu o desenvolvimento de versões do
Linux para seus mainframes.
Resumindo: ao investir (junto com outras empresas) no desenvolvimento do Linux,
a IBM conseguiu várias vitórias importantes. Ela agora tem uma linha de
servidores Linux de baixo custo competindo com enormes vantagens com soluções
RISC dos seus concorrentes e mesmo com servidores baseados em Windows.
A IBM é o único produtor de mainframes reportando crescimento das vendas no
segmento, com empresas consolidando dezenas de servidores menores em um único
equipamento. Como um efeito colateral disso, o kernel do Linux deu um salto
impressionante de qualidade.
Onde, anos atrás, eu teria que instalar um Windows, eu hoje posso usar um
sistema operacional moderno e modular, que usa um kernel firme como uma rocha
(minha máquina de desenvolvimento detém o meu recorde doméstico de 61 dias
sem um boot - quebrado não por um crash, mas por uma falta de energia), com
discos que não perdem dados quando a energia falha (graças ao journal), com
excelente suporte a máquinas com mais de um processador (que, infelizmente,
não é meu caso) e que não serve como meio de cultura para pragas digitais
como o Blaster ou Slammer. E ela ainda encontra tempo para registrar pelo menos
umas 30 tentativas de contágio por worms a cada dia.
Uma caixa nova. Na mesma linha de raciocínio, Intel e HP perceberam que
lançar o processador Itanium no mercado sem um suporte expressivo de software
aplicativo seria suicídio. Em vez de pedir gentilmente à Microsoft (na
verdade, eles gastaram bastante dinheiro mandando programadores deles para
ficarem dentro da Microsoft ajudando no trabalho) que portasse o Windows para o
Itanium (lição de história: a falta de aplicativos e de suporte do Windows
foi o último prego no caixão dos processadores MIPS, PowerPC - em PC-likes- e
Alpha) e rezar para que ele estivesse pronto ao mesmo tempo em que o processador
fosse lançado, a HP decidiu apostar em mais dois cavalos extras.
Um deles, o port do HP/UX (o Unix proprietário da HP) para o Itanium e, em
outra, no port do Linux para o processador. Com um processador de 64 bits no
mercado há algum tempo, a HP hoje pode vender suas soluções com uma escolha
maior de sistemas operacionais em vários mercados que não estariam acessíveis
não fosse essa decisão.
Hoje a HP vende os equipamentos HP/UX sobre Itanium aos seus clientes HP/UX
tradicionais, vende máquinas Itanium rodando Windows para seus clientes Windows
e vende máquinas Itanium rodando Linux para os clientes que preferem Linux. E,
claro, vendem máquinas Intel também.
Debaixo do chão. Outro caso bem interessante é o do Metrô de São
Paulo. O Metrô já tinha trocado um sistema de e-mail corporativo baseado em
mainframe por um construído com software livre quando decidiu economizar
dinheiro usando StarOffice (naquela época a Sun não cobrava por ele) em vez do
Microsoft Office.
Eles tinham dois problemas: O primeiro deles era que não existia
documentação, material didático ou tutoriais em português para o produto.
Para resolver isto, o Metrô contratou uma empresa para ajudar na preparação
da documentação e dos treinamentos.
O segundo problema era o do idioma: Existia uma versão do StarOffice/OpenOffice
em português, mas era o português de Portugal.
A solução, no entanto, não veio do Metrô. Um engenheiro químico de
Rondonópolis, Cláudio Ferreira Filho, decidiu coordenar a tradução do
OpenOffice, que acabou, inclusive, sendo concluída antes que a Sun conseguisse
lançar o StarOffice 6 em português.
No final das contas, mesmo investindo dinheiro para modificar e complementar uma
oferta existente, a economia feita em licenças não compradas de Microsoft
Office mais do que cobriu os investimentos no produto livre. Pode não ser muito
vantajoso se você tem um escritório com cinco pessoas, mas para eles, com mais
de 1000 desktops por toda a companhia, a decisão foi acertadíssima.
E o resto, de onde vem tudo isso?. Você pode imaginar que, sem uma
estrutura de investimentos pesada, nenhum produto de software tem condições de
se desenvolver. Todos os exemplos que eu citei envolvem empresas enormes.
Nós vimos o passo de lesma com que o software tem evoluído nos últimos 30
anos. Janelas, mouse, display bit-mapped e letras pretas em fundo branco foram
transformados na GUI moderna que ainda nos serve, no centro de pesquisas de Palo
Alto, da Xerox, no meio da década de 70. Hoje eu tenho mais cores e mais
botões no mouse. E não muito mais do que isso.
Meu micro desktop continua travando de vez em quando. Em semanas eu devo
reformatar a máquina e deixá-la limpa outra vez - com seis meses na minha
mão, qualquer Windows precisa ser reinstalado do zero.
O que o software livre tem que o software proprietário não tem e que pode
resolver isso? Na verdade é o contrário. O software livre não tem uma coisa.
Duplicação de esforço. Quando uma empresa de software proprietário
desenvolve, digamos, um editor de textos, ela guarda segredo sobre tudo o que
descobriu no processo. Seja um algoritmo novo, seja uma forma de otimizar
código, seja uma modificação feita no sistema operacional para que o programa
se inicie mais rápido, ou uma que faça seus concorrentes rodarem mais devagar.
Essas coisas são as jóias da coroa de uma empresa de software tradicional.
São guardadas a sete chaves.
Quando uma segunda empresa quiser escrever, digamos, um editor de textos, vai
ter que redescobrir algoritmos de hifenação, formatação, projetar estruturas
de dados que comportem as informações necessárias e vai, com toda
possibilidade, repetir vários erros pelos quais a primeira empresa já passou.
Eventualmente chegará em uma forma totalmente diferente e secreta de armazenar
os textos no disco. E talvez tenha que inventar um jeito de ler os textos que o
primeiro programa salvou. Terão que investir tempo em conviver com o inimigo.
O mesmo para a terceira, a quarta e todas as outras. Nenhuma avisará as que a
seguem de onde estão os buracos. Algumas nem sairão deles.
O desenvolvimento de software livre é eficiente exatamente por isso. Ele não
precisa ser mais eficiente do que os processos internos das empresas de software
proprietário, porque o mercado que elas geram, como um todo, é grotescamente
ineficiente, um festival de rodas re-inventadas. Eu não repito seus erros. Os
outros não precisam repetir os meus. Eu não preciso reinventar a roda - posso
escolher uma de várias. Posso precisar pegar essa roda e acrescentar algo a
ela. E todos nós teremos um novo tipo de roda. Se eu faço algo estúpido,
você vem e me corrige. Eu aprendo. E depois posso ensinar alguém. Todos
ganhamos.
Software livre é imune a outros vícios também.
Não há pressão por datas: eu não preciso liberar uma versão do meu
capturador de tiras do Dilbert todo ano. A versão atual tem um ano desde sua
última modificação e ainda funciona perfeitamente. Enquanto eu não precisar
que ela faça nada de diferente, ela fica como está. Não vamos desperdiçar
recursos com isso.
Há uma enorme pressão para se fazer as coisas direito: Como todo o código é
aberto, se você escrever código porco, alguém vai chamá-lo de porco. Em
público. Decisões estruturais costumam ser debatidas e validadas pela
comunidade de desenvolvedores e usuários. Em último caso, se alguém acreditar
mesmo que aquele não é o caminho certo, pode "fazer um fork", isto
é, pegar o código e tudo o que foi desenvolvido até aquele ponto e começar
um novo projeto que seguirá, a partir dali, caminhos independentes do primeiro.
Não há a pressão por recursos desnecessários: Todos os sinos e apitos estão
lá porque alguém precisava deles (ou, no mínimo, queria muito e conseguiu
convencer bastante gente). Não porque alguém achava que eles iriam ajudar a
vender este produto ou, muito pior, fazer com que você precisasse de outro
produto.
Mas afinal quem paga?. A resposta é simples e, para muitos, chocante:
Software livre não é de graça.
Vou repetir: Software livre não é de graça.
Eu pago (em meu tempo, quando faço eu mesmo, em dinheiro, quando alguém faz
por mim), quando corrijo um erro na documentação, quando extendo alguma
funcionalidade ou quando porto alguma coisa para uma plataforma nova.
Pago em divulgação, quando peço para um aluno usar o Eclipse em vez do
Borland J-Builder que ele comprou no camelô da porta da faculdade, ou ainda
quando escrevo este artigo. Você paga do mesmo jeito. Ou paga escrevendo um
manual, ou preenchendo um bug-report, ou arrumando uma página para que
usuários do Konqueror ou Mozilla consigam vê-la. Montes de graduandos de
Ciência da Computação pagam, expandindo e criando software livre.
Meus clientes pagam quando me contratam para construir alguma coisa usando
software livre. No final das contas, continuamos pagando pelo software.
Isso é importante: Quando você paga, você paga pelo software. Você vira dono
dele. Em vez de pagar caro (ou não) apenas pelo direito de usar uma cópia de
uma coisa que continua pertencendo a outra pessoa. E ai de você se esquecer que
aquilo nunca foi seu. Pela primeira vez na história, o software é seu, de
verdade. Você pode levar pra casa tudo, mas tudo mesmo, o que comprou. [Webinsider]
|
|
