Tecnologia e Conhecimento

tecnologia, esporte, computação, livros, pensamentos, opiniões... 

Produtividade e Custo de TIC no Serviço Público

Tenho pensado a respeito dos modelos de operação das áreas ligadas à Tecnologia da Informação e Comunicações em organizações de governo. Trabalho na área de TIC há 17 anos, 4 dos quais no serviço público, entre as esferas federal e estadual. Também já fui terceirizado em órgãos estaduais e municipais. Assim, acho q posso juntar algum material das minhas memórias para tecer as críticas e sugestões que vou apresentar agora.

O que me tem feito pensar sobre esses modelos é a inevitável comparação entre o modelo de empresa pública prestadora de serviços, o modelo prata da casa, em que os servidores próprios do órgão operam a TI, e o modelo de terceirização com empresas privadas.

Obviamente, até pela minha condição de servidor público, não sou nem de longe a favor das políticas de estado mínimo que vivemos até cerca de oito anos atrás. Mas tenho percebido que o modelo de operação com servidores (não de hardware, mas de peopleware) próprios do órgão deve se manter apenas em nível gerencial para a área de TIC.

A terceirização com empresas privadas aparenta ser uma excelente opção, pois permite que o órgão mantenha seu foco no seu negócio. Apesar de parecer mais ágil, este modelo peca em muitos aspectos. Primeiro, a gestão de conhecimento é prejudicada, pois não há como controlar o turnover de funcionários. Contratos com prazo determinado prejudicam a continuidade dos serviços e levam a aditivos e maiores custos. Mudanças no poder influenciam em renovações contratuais. Vou me abster de falar sobre a questão da transparência nos processos licitatórios.

Quanto ao modelo onde servidores em cargos efetivos operam totalmente as áreas de TIC, este deveria ser o melhor modelo, pois a continuidade está garantida, o custo é mais previsível, a gestão de conhecimento é viável. Tudo graças ao grande horizonte de tempo de serviço que se espera de um concursado. Mas, é esse o grande problema. A estabilidade do cargo, adquirida após três anos de efetivo exercício, aliada à falta de instrumentos de coerção, leva a uma zona de conforto que prejudica muito a produtividade dos servidores. Como consequência, os projetos não andam, é difícil alocar pessoal, a burocracia aumenta pela falta de vontade. É daí que vem a péssima fama do funcionalismo. A renovação dos quadros promovida pela onda de novos concursos nos últimos anos levou para os órgãos muita gente jovem, de visão mais politizada e avessa ao desperdício do erário e à corrupção, mas infelizmente ainda não foi o suficiente para vencer a máquina do estado.

O modelo de relacionamento entre um órgão e uma empresa pública especializada se mostrou, na minha experiência, mais eficaz e mais eficiente. No começo eu achava esse modelo um absurdo. Não é preciso licitação para contratar serviços de empresa pública. Os preços são altíssimos se comparados com o mercado. Os empregados também são concursados. Onde está a vantagem em relação aos outros modelos? Aqui é possível reunir o melhor dos dois outros mundos. O órgão não tem que manter servidores de TI como área meio e não tem que criar expertise fora do seu negócio. Sem licitação o processo de contratação é mais rápido e mais flexível quanto ao objeto contratado. Empresas públicas estão sujeitas a diretrizes de governo, então é mais fácil padronizar os serviços em todo o poder público. Apesar dos empregados serem concursados, o regime de contratação não é estatutário, logo não existe a estabilidade que leva à zona de conforto, a hierarquia organizacional se faz valer.

Alguém pode pensar: o que você está propondo vai fazer com que a iniciativa privada nunca mais forneça serviços para o governo! Mas não é bem assim. Empresas públicas também podem, até devem contratar serviços mais especializados da iniciativa privada. Só que a centralização da contratação e a gestão do serviço prestado feita por quem tem mais competência no assunto garantem o melhor aproveitamento e controle.

Há, porém, que se garantir que a empresa pública que vá se tornar a prestadora de serviços oficial seja bem administrada. Uma premissa importante: a empresa deve necessariamente ter objetivo de lucro. Nada de fazer parte do orçamento. Tendo o lucro como meta, a empresa pública vai lutar por custos menores e ser competitiva, afinal, o governo pode contratá-la sem licitação mas não é obrigado a fazer isso. Sempre se pode recorrer à iniciativa privada. O uso de cargos em comissão deve ser balanceado com a designação de empregados do quadro nas posições estratégicas.

Enfim, há muitas vantagens, mas a implementação desse modelo não é trivial. Esse assunto é extenso, há muito sobre o que se discutir. Qual sua opinião? Tem algo a acrescentar? Discorda? Comente e vamos continuar a conversa! Abraços.

Loading mentions Retweet
Filed under  //   governo   opinião   pensamentos   produtividade   tecnologia  

Comments [5]

Copa do Mundo, Enchentes, Solidariedade e Ações de Governo

 

Vou fazer aqui uma reflexão, talvez mais um questionamento, sobre o que motiva a população e o governo a fazerem de modo extraordinário o que deveriam fazer constantemente: ajudar uns aos outros e executar obras que beneficiem a sociedade.

Passamos recentemente (espero que tenha acabado) por um período de fortes chuvas e inundações no nordeste brasileiro. Vimos cidades grandes, como Salvador, Recife e Fortaleza, e cidades pequenas, no interior, sofrerem com o aumento do índice pluviométrico. Destruição de casas, ruas e empresas, morte, fome, desabrigados.

Mais ou menos no mesmo período, vivemos a expectativa da escolha das cidades que seriam as subsedes para a Copa do Mundo de Futebol no ano de 2014. Muita euforia no dia do anúncio oficial, muita festa, gente comemorando.

Em ambos os casos tem havido uma mobilização muito contundente. De um lado a população mais abastada e menos afetada pela tragédia das enchentes mostra força e organiza campanhas de doação de alimentos, roupas e remédios. Desde indivíduos isolados até empresas que dispendem esforços logísticos no intuito de ajudar a distribuir o que vem sendo arrecadado. Minha esposa e eu também organizamos uma campanha de doação no edifício em que residimos e obtivemos uma resposta satisfatória da vizinhança. Do outro lado, governos municipais se esmeram em apresentar projetos ambiciosos de modernização e ampliação não só dos estádios, mas da rede hoteleira, sistemas viários e de saúde, investimentos em educação e capacitação de pessoas, enfim, medidas que trarão incontáveis benefícios para as cidades envolvidas.

Observem que não há ironia nas minhas palavras quando me refiro aos projetos ligados à Copa. Eu realmente acho importantes esses projetos, os benefícios são tangíveis.

Mas o pensamento que me levou a escrever esse post foi o de que eu mesmo preciso ajudar mais as pessoas, não só quando há enchentes. Ora, tem gente sem casa e sem comida aos montes nas ruas! E não são desabrigados só por causa da chuva, os fatores que os levaram a essa condição são muitos. Sempre existiu gente pobre, tanto nas ruas das grandes cidades quanto nos sertões castigados pela seca, gente sem terra para produzir, sem acesso a luz elétrica, ensino fundamental, saneamento básico. Todos os dias vemos gente pedindo comida nos semáforos e esquinas. Precisamos ajudar mais, doar mais e constantemente. Essa mesma bondade súbita pós-enchente deve permear nossos dias, fazendo com que nos lembremos sempre que enquanto estamos aqui na frente do computador, no ar condicionado, tem alguém segurando no colo o filho que chora de fome.

Desenvolvendo mais esse raciocínio, percebo que os problemas que devem ser solucionados para que uma Copa do Mundo seja realizada no Brasil também estão presentes há muito tempo. As ruas que são estreitas e esburacadas estão assim há muito tempo. A "desculpa" para se gastar tanto em tão pouco tempo é a de que os efeitos benéficos se farão sentir depois da Copa, quando a população desfrutará dos aprimoramentos realizados. Mas se há como arranjar 50 bilhões de reais e fazer tudo ficar pronto em menos de três anos, por que não fazer isso simplesmente porque é preciso? É preciso melhorar o trânsito nas cidades grandes, é preciso espalhar postos de saúde, é preciso capacitar pessoas para o mercado de trabalho, investir em turismo, em ciência. Não necessário que uma Copa do Mundo aconteça pra que essas necessidades surjam "do nada".

Acredito que as enchentes catastróficas não possam ser evitadas, mas os "pequenos" efeitos como ruas alagadas, desabamento de encostas, etc poderiam ser evitados com investimento em moradia, esgotamento sanitário, limpeza urbana. Se esses investimentos fossem feitos sempre com o mesmo empenho e seriedade com que estão sendo tratados agora, essas obras anunciadas não precisariam ser feitas a toque de caixa, a escolha do Brasil como sede teria sido mais tranquila, enfim, já estaríamos com meio caminho andado.

Vi também que esse fenômeno de motivação da sociedade e do governo parece ser um padrão, já que não é a primeira vez que acontece. Basta lembrar do Pan do Rio e das enchentes (coincidência?) em Santa Catarina. Fica a sugestão de reflexão e o convite para os comentários. Abraços.

 

Loading mentions Retweet
Filed under  //   governo   pensamentos  

Comments [1]

Menos é Mais - Engenharia de Software

Voltando à série de posts Menos é Mais, este é um texto mais longo, pois trata de um assunto de abordagem mais complexa que os anteriores.

Posts anteriores:

Um dos grandes problemas com as técnicas de levantamento de requisitos convencionais é que se dá ao cliente a liberdade total para inventar características "essenciais" ao projeto.

Premissas das Análises Estruturada e Essencial como "recursos infinitos", "prazo infinito" e técnicas de entrevista como brainstorm deixaram um legado de mal costume e não cabem mais nos tempos de hoje, quando a competição é extremamente acirrada e quem chega primeiro leva uma fatia considerável do mercado. Quando o levantamento de funcionalidades é feito dando-se liberdade total ao cliente, cria-se o compromisso de construir um projeto muito maior do que a necessidade real e imediata, gerando uma expectativa com chance quase total de frustração.

Além desse inchaço de requisitos, a fase de análise dessa grande quantidade de requisitos causa uma fase muito longa de criação de diagramas, modelos abstratos e redação de textos, de onde devem partir as reuniões de validação de entendimento que geram mais confusão.

Nos processos convencionais, inicia-se então uma fase de projeto, em níivel mais baixo, que afasta o cliente da solução que ele espera, pois começam a surgir os detalhes mais técnicos. A partir daí, vem a implementação de todo o conjunto de funcionalidades levantadas na primeira fase. Mesmo que seja escolhido um modelo híbrido interativo + cascata, até que o cliente possa ver o mínimo que seja do projeto pronto, vai se passar um período considerável. E muito provavelmente o cliente chegará à conclusão de que a implementação não corresponde ao que ele imaginava para o software.

A solução? Menos! Menos tudo! Menos reuniões, menos requisitos, menos análise, menos modelos e diagramas. Definindo um pequeno conjunto de características que abordem o núcleo do problema a ser solucionado, é possível trabalhar num processo iterativo curto, de trabalho conjunto do desenvolvedor com o cliente, que terá contato com algo concreto, como o funcionamento das telas da aplicação. Dessa maneira, será possível avaliar o mais cedo possível se o entendimento está correto para ambos, desenvolvedor e cliente. Com o escopo reduzido, eventuais correções podem ser feitas até mesmo durante a apresentação, e como as iterações são curtas e frequentes, rapidamente o cliente terá um produto que funciona nas mãos.

Saímos de um cenário que entregava uma solução da qual o cliente não participou, conceitualmente errada, com funcionalidades não essenciais e depois de um longo prazo para um cenário novo que entrega em curto intervalo de tempo um produto que resolve o problema primário do cliente, com sua direta participação. Isso garante menor custo e maior satisfação. É isso o que se chama de "release early, release often". Entregue cedo, entregue frequentemente.

Obviamente, o produto não precisa estar 100% acabado, com as maquiagens visuais de interface e artimanhas para produtividade de operação, mas o já estará operacional, guardando dados e gerando informação. Claro que esta foi apenas uma visão rápida, superficial, para caber num blog post. Façam seus comentários e poderemos discutir as idéias apresentadas. Até a próxima.

Loading mentions Retweet
Filed under  //   conhecimento   pensamentos   tecnologia  

Comments [1]

O (Comovente) Guia de Ruby do Why

No início deste mês de abril, o Carlos Brando anunciou em seu blog a tradução para Português do livro Why's (Poignant) Guide to Ruby. A equipe de tradução realizou um grande trabalho, como pode ser visto no site do livro traduzido.

Logo depois do anúncio, surgiu uma demanda da comunidade por uma versão do livro traduzido em formato PDF, como pode ser visto nos comentários postados pelos leitores na página do anúncio. O Carlos Brando concordou com a demanda, mas levantou a premissa de que o PDF devia ser feito com qualidade.

Bem, resolvi encarar a empreitada e parti para o trabalho. Depois de experimentar várias alternativas para a geração do PDF, acabei partindo para a força bruta. Copiar página por página da web para um arquivo do BrOffice 3.0 e exportar para PDF. Mas por que isso? Com o BrOffice eu consigo, além de numeração de páginas no rodapé e um cabeçalho, gerar as barras laterais com texto adicional que permeiam todos os capítulos do livro e, principalmente, manter um índice automático que depois é exportado para o PDF como uma lista de bookmarks que facilitam a navegação e localização dentro do texto.

Admito que essa não é a melhor maneira de se gerar o PDF enquanto processo, pois as atualizações e correções não podem ser incorporadas automaticamente. Do jeito que está, nós teremos que acompanhar as atualizações no repositório do "código fonte" do livro no GitHub e, então, manualmente alterar o arquivo ODF (.odt, do Writer), que é o "código fonte" do PDF gerado. Ainda precisaremos estudar uma solução pra isso, vou conversar com o Brando e a equipe que mantém o trabalho original de tradução para encontrarmos juntos uma maneira melhor. Se você tiver uma sugestão de como melhorar esse trabalho, fique à vontade para enviar seus comentários.

Quanto ao conteúdo, está idêntico ao que foi publicado pelo Brando, inclusive com os erros apontados pelos leitores do blog Nome do Jogo no post de anúncio da tradução. Preferi não interferir ainda no trabalho realizado pela equipe, já que minha contribuição está focada na disponibilização do arquivo PDF. Obviamente, pretendo contribuir com revisões também.

Há também algumas oportunidades de melhoria no PDF gerado, como melhorar a fonte e o espaçamento entre linhas dos trechos de código, aprimorar o grafismo, talvez com umas cores de fundo para destacar os sidebars do restante do texto, fazer o cabeçalho igual ao original, etc.

Este trabalho, assim como o original  em Inglês e sua tradução para o Português, é distribuído sob licença Creative-Commons Atribuição-Compartilhamento.

Ah, sim, claro! Os arquivos! Aqui estão. Bom proveito.

O (Comovente) Guia de Ruby do Why - PDF

O (Comovente) Guia de Ruby do Why - ODT (BrOffice 3.0 - Writer)

Loading mentions Retweet
Filed under  //   conhecimento   livros   programação   projetos   ruby   software livre   tecnologia  

Comments [6]

Oracle comprou a Sun - E o Software Livre com isso?

É oficial: a Oracle comprou a Sun numa transação em que o valor de cada ação foi negociada US$ 9,50 em cash, segundo a Sun.


Claro que para o mercado como um todo essas movimentações são uma sensação, as bolsas ficam eufóricas (ou não :-) ), mas será que para a comunidade de software livre, com o perdão do trocadilho, isso foi um bom negócio?

A Sun vinha numa crescente em relação à aproximação com a comunidade, desde o advento do NetBeans, Glassfish e, por último, o OpenJDK (Java sob licença livre). Depois teve a aquisição da MySQL, que, embora não tão puramente software livre, tinha um certo reconhecimento e uma comunidade forte.

A Oracle andou ciscando na comunidade também, com a cessão do código do ADF Faces para o pessoal do MyFaces. Inegavelmente, a Oracle sempre apoiou o Linux de diversas formas, mas nada que chegasse a ser comparável à contribuição maciça de código ou liberação de algum de seus produtos sob alguma licença livre. O apoio era muito mais baseado no interesse de que seus clientes do banco Oracle utilizassem Linux em seus servidores, plataforma em que a Oracle sempre alardeou ter 20% de ganho de desempenho em relação à versão para o sistema das janelas.

Será que para a comunidade não teria sido melhor se a IBM tivesse realizado a compra, como disseram os boatos? A IBM tem uma história muito mais sólida em relação ao software livre, com o Eclipse, suporte a Linux na plataforma S/390, campanhas e programas de desenvolvimento em plataforma livre, Linux para os processadores Cell (Playstation 3 e servidores), etc.

Há uma possibilidade de que o pessoal que fazia a Sun - Simmon Phipps, o executivo chefe do open source na Sun, mais especificamente falando - ainda terá voz depois dessa aquisição? Quais serão os planos da Oracle para o Glassfish? E o Java em si? Será que o entusiasmo com o  OpenJDK vai se manter?

Lá vamos nós, como sempre, esperar para ver...

Loading mentions Retweet
Filed under  //   java   mercado   software livre   tecnologia  

Comments [0]

Menos é Mais - Apresentações

Meu amigo Serge Rehem postou no Twitter um link para uns slides sobre uma técnica visual de se construir apresentações. O autor chama essa apresentação de A Era da Apresentação Visual

Obviamente, os slides são compostos de excelentes imagens coletadas do Flickr e do Stock Exchange. Mas uma coisa me chamou a atenção na apresentação especialmente: o grande barato da técnica é a simplicidade, ou seja, menos texto, menos slides, menos informação inútil.

Um dos slides atribui a seguinte frase a Leonardo da Vinci: "Simplicity is the ultimate sophistication" ou "Simplicidade é a sofisticação definitiva". Ainda que não tenha sido o Leonardo mesmo quem disse isso, é essa a idéia que venho tentando passar nessa série de posts. Faça menos e consiga mais. O que é mais simples é mais fácil de ser compreendido, aceito, vendido, comprado!

Texto é difícil de ler, uma imagem vale por mil palavras! Não escreva, mostre! Posts pequenos são mais fáceis de ler também :-) Até a próxima!

Loading mentions Retweet
Filed under  //   dicas   pensamentos  

Comments [0]

Menos é Mais - Java no APP Engine

Complementando e atualizando o post anterior, agora o Google App Engine está dando suporte a Java!

Além disso, está rolando uma promoção de acesso para os primeiros 10 mil a assinarem o serviço.

O serviço suporta Java 6 e, para quem por qualquer motivo ainda não podem contar com essa versão, como os usuários de Mac OS X, há também o suporte a Java 5. A persistência é feita através de JDO acessando o Google DataStore.

Há também um plugin para o Eclipse que facilita o desenvolvimento das aplicações com o SDK do AppEngine.


Loading mentions Retweet
Filed under  //   programação   software   tecnologia  

Comments [0]

Menos é Mais - Hospedagem de Aplicações

Dando continuidade ao post anterior, vou falar um pouco sobre escalabilidade de aplicações, cloud computing, Rails, SaaS e a tendência minimalista dos novos tempos.

Até dois anos atrás ninguém discordaria de que um projeto de software que tivesse a expectativa de um alto volume de acessos ao mês (e aí estou me referindo aos milhões) deveria ser construído numa arquitetura de software robusta, distribuída, obedecendo a padrões bem estabelecidos. Na verdade, acho que hoje ainda todos concordam com isso. Mas uma coisa parece estar mudando fundamentalmente. 

Onde antes havia uma grande preocupação com a plataforma de desenvolvimento, framework de persistência, inversão de controle, distribuição de transações e dados, especificações de arquitetura, serviços e infinitos padrões de projetoagora vemos investimentos para garantir disponibilidade e tempo de resposta direcionados para o software básico, ou seja, sistemas operacionais, bancos de dados, balanceamento de carga, virtualização. As aplicações começam a ser desenvolvidas com foco apenas na aplicação em si (uau!), com o mínimo de camadas, o mínimo de código ortogonal.

O mesmo acontece no mundo do Ruby. O Rails, o framework MVC mais conhecido na plataforma Ruby, não tem NADA que faça alusão a distribuição de objetos da aplicação, padrões de projeto complexos, especificações rígidas. Ao contrário, é tudo muito simples, minimalista, baseado em convenções. Construa sua aplicação como se fosse executá-la apenas para você. Depois, se precisar escalar, basta fazer o deploy num ambiente com estrutura mais robusta em termos de hardware ou cluster e até mesmo nuvem. Há uma série de 13 screencasts produzida pela New Relic tratando somente sobre escalabilidade de aplicações em Rails. Veja por si só o que estou dizendo.

O Google App Engine é o ambiente de computação em nuvem do Google, lançado para concorrer com o Amazon Web Services. O App Engine tem um SDK (Software Development Kit) baseado em Python com o qual se pode desenvolver as aplicações e hospedá-las na infra-estrutura oferecida pelo serviço. O SDK fornece algumas classes básicas para persistência com tratamento de transações. A persistência é feita num datastore do próprio Google. O importante é que quem desenvolve a aplicação não precisa se preocupar com interfaces remotas, filtros, múltiplas camadas de negócio, etc. Apenas codifique sua aplicação como se fosse standalone. Quando fizer o deploy, poderá escalar conforme a necessidade, sem precisar mexer na aplicação.

Parece que o ciclo de gato e rato da corrida entre software e hardware está na fase do hardware na frente, onde o agrupamento de processadores está dando o tom da música do processamento corporativo de alto desempenho. Obviamente, hardware sem software é apenas silício e cobre, então o suporte a vitualização e clustering em sistemas operacionais e servidores de aplicação, além da combinação de estratégias de cache e balanceamento de carga, tem tornado possível o acesso de pequenas empresas a uma estrutura robusta e barata sem a necessidade de grandes conhecimentos técnicos por parte da equipe de desenvolvimento. Menos custo, menos tempo, menos código, menos treinamento, menos manutenção...

Loading mentions Retweet
Filed under  //   programação   software   tecnologia  

Comments [1]

Menos é Mais - Introdução

Apesar do nome e do assunto de que trata, este post provavelmente vai se tornar uma série. Por incrível que pareça, tenho juntado muita coisa pra falar a respeito e vários aspectos onde se aplica a idéia que eu estou começando a chamar de Menos é Mais.


Tenho observado um movimento em direção a um mundo minimalista. Antes o interessante era ter um portal abarrotado de informações na capa, muito texto, muita propaganda. Softwares de sucesso eram softwares muito completos, com infinitas funcionalidades. Casas boas tinham que ter muitos cômodos.

Hoje, vemos por aí studios ou lofts fazendo sucesso como empreendimentos imobiliários - menos paredes -, páginas web enxutas, sem muitas cores, fontes grandes, poucos menus e pouco texto, algo bem direto - menos informação à vista -, microblogs com seus posts bem pequenos - menos texto -, programas de TV com cenários mais limpos, mais discretos - menos poluição visual.

Agora mesmo estava lendo um blog que dá dicas de como produzir e manter um blog de forma eficiente. O título do post mais recente: "Problemas para escrever? Pense pequeno!". Se vc tiver menos coisas a dizer, será mais eficaz, será mais fácil começar a escrever. Seguindo um dos conselhos desse tal blog, resolvi quebrar esse assunto em partes. Assim, nos próximos posts vou falar sobre computação em nuvem, web 2.0, desenvolvimento ágil, gerenciamento de projetos e acho que até música!!!

Veja a continuação desta série!

Loading mentions Retweet
Filed under  //   pensamentos   tecnologia  

Comments [0]

Por que eu uso Linux?

À parte questões legais como licenças de software e pirataria ou a paixão incondicional que profissionais de informática tendem a desenvolver por uma ou outra plataforma, na maioria da vezes a questão do uso do software livre versus proprietário tem um viés econômico. Geralmente é difícil explicar ou argumentar por meio desse viés, mas quando olhamos os fatos em escala muito pequena, fica fácil.

No final da semana passada eu resolvi trocar minha conexão de internet. Antes eu tinha Net, agora estou com uma conexão 3G da Claro. O motivo da troca foi apenas contenção de despesas mesmo.

Em casa temos dois notebooks, o de Isabela, minha esposa, rodando Vista Starter, e o meu, rodando Ubuntu Linux. Alguém pensaria: "Hum, deve ter dado um trabalhão intalar o modem 3G no Linux. No Vista deve ter sido só espetar." Bem, não foi isso o que aconteceu. No Linux deu mesmo um certo trabalho. Mas no Vista também não foi natural, espetar e usar...

Eu uso uma versão "antiga" do Ubuntu, a 7.10 (ou seja, a versão de outubro de 2007). Por que as aspas em "antiga"? Porque já existem duas versões mais novas e a terceira está saindo agora em abril. Já o Vista foi lançado um tempinho antes. Assim, há de se entender o fato de nenhum deles trazer suporte embutido ao modem que eu uso, o MD300 da Sony Ericsson.

Aí já se mostra a primeira vantagem do Linux, ou do software livre de modo geral. As versões mais novas do Ubuntu já possuem suporte nativo para esse modem. Já o Vista (e os outros Windows e outros sistemas fechados, como MacOS) continuam dependendo do apoio do fabricante para ter o suporte, o que implica acordos comerciais, dinheiro alto e interesses pra lá e pra cá.

Mas o que mais me chamou a atenção foi o fato de que o software da Sony Ericsson para gerenciar o modem ocupa mais de 100 (cem!!!) megabytes no disco rígido!!! Se por um motivo qualquer, digamos para uma conexão corporativa, eu tivesse q usar mais de um modem, de marcas diferentes, já seriam mais de 200MB indo embora à toa!!! E eu não quero nem olhar o consumo de memória desse "programinha".

No Ubuntu eu estou usando o KPPP, que é um software gerenciador de conexões discadas, independente do modem. Ele ocupa menos de 4 (sim, menos de quatro) megabytes e gerencia quantos modems eu tiver, quantas contas eu tiver, me dá gráfico de utilização da largura de banda, e mais outros detalhes técnicos que não cabem aqui.

Tá, mas e daí? Espaço em disco é barato, por que essa choradeira toda? Simplesmente porque eu gosto do meu dinheiro. Eu gasto menos disco e menos memória para me conectar à Internet do que quem usa Windows. Meu disco rígido vai demorar bem mais para ficar lotado, o que significa que minha máquina vai me atender por mais tempo. Logo logo ela estará precisando de mais espaço, só por causa desses abusos e teremos que comprar outro computador ou um HD externo. Já eu terei um retorno muito maior pelo investimento no meu notebook com Linux, pois a quantidade de espaço que o software da Sony Ericsson ocupa no Windows eu uso para guardar umas 150 fotos da minha filha ou uns 40 MP3 das minhas bandas preferidas.

Agora pensem nos mais diversos tipos de software que usamos diariamente. Eu dei apenas um pequeno exemplo. É uma questão de senso prático e valorização de detalhes que agregam valor ao investimento.

Loading mentions Retweet
Filed under  //   opinião   pensamentos   software livre   tecnologia  

Comments [1]