1. Problemas no Mariner (1962)

Custo: 18,5 milhões dólares

Desastre: Mariner, um foguete com uma sonda espacial para Vênus, foi desviado de seu percurso de voo logo após o lançamento. O controle da missão destruiu o foguete 293 segundos após a decolagem.

Causa: Um programador, ao passar para o computador uma fórmula que haviam lhe entregado escrita manualmente, se esqueceu de uma barra. Sem ela, o software tratava variações normais de velocidade como se fossem sérios problemas, causando falhas por tentativas de correções que acabaram por enviar o foguete fora do curso.

2. Hartford Coliseu Desmorona (1978)

Custo: 70 milhões de dólares, além de outros danos de 20 milhões para a economia local

Desastre: Poucas horas depois de milhares de fãs deixarem o Coliseu Hartford, o teto de treliça de aço desabou sob o peso da neve molhada.

Causa: O programador do software CAD, utilizado para projetar o coliseu, incorretamente assumiu que o suporte do telhado de aço enfrentaria apenas compressão natural. Mas quando um dos suportes inesperadamente recebeu um bloco de neve, este desencadeou uma reação em cadeia que derrubou o telhado de outras seções como dominós.

3.  CIA distribue gás aos soviéticos (1982)

Custo: Milhões de dólares e danos significativos a economia soviética

Desastre: O software de controle se descontrolou e produziu uma intensa pressão no gasoduto Trans-Siberian, resultando na maior explosão não-nuclear da história.

Causa: CIA operatives allegedly planted a bug in a Canadian computer system purchased by the Soviets to control their gas pipelines.  The purchase was part of a strategic Soviet plan to steal or covertly obtain sensitive U.S. technology.  When the CIA discovered the purchase, they sabotaged the software so that it would pass Soviet inspection but fail in operation.

4.  3ª Guerra Mundial (Quase!) (1983)

Custo: Quase toda a humanidade

Desastre: O sistema de alerta precoce soviético falsamente indicou que os Estados Unidos tinham lançado cinco mísseis balísticos. Felizmente, o oficial de serviço soviético tinha uma “sensação esquisita no estômago” e fundamentalmente, se os EUA estavam realmente atacando, eles lançariam mais de cinco mísseis, por isso ele relatou o aparente ataque como um alarme falso.

Causa: Um bug no software soviético falhou ao detectar reflexos solares como falsos mísseis.

5.  Máquina medicinal mata (1985)

Custo: Três mortos e três seriamente feridos

Desastre: A máquina de radiação canadense Therac-25 irradiou doses letais em pacientes.

Causa: Por causa de um bug sutil chamado de “condição de corrida“, um técnico acidentalmente configurou o  Therac-25 de modo que o feixe de elétrons seria como um fogo de alta potência.

6.  Crash na Wall Street (1987)

Custo: $500 bilhões em um dia

Desastre: Em 19 de outubro de 1987, o índice Dow Jones  caiu 508 pontos, perdendo 22,6% de seu valor total.  Esta foi a maior perda que Wall Street já sofreu em um único dia.

Causa: Um mercado em grande alta foi interrompido por uma série de investigações conduzidas pela SEC  e por outras forças do mercado. Como os investidores fugiram de ações investigadas, um número muito grande de ordens de venda foram gerados pelos computadores, quebrando sistemas e deixando os investidores efetivamente cegos.

7.  Linhas da AT&T  “morrem” (1990)

Custo: 75 milhões de ligações perdidas e 200 reservas aéreas perdidas

Desatre: Um switch dos 114 centros de swiches da AT&T sofreu um problema mecanico que fez com que todo o seu centro fosse desligado. Quando o seu centro voltou a ativa, enviou uma mensagem aos outros, o que causou o desligamento dos outros centros e deixou a empresa parada por 9 horas.

Causa: Uma única linha de código em uma atualização de software implementada para acelerar chamadas causou um efeito cascata que desligou a rede.

8.  Patriot Acaba com Soldados (1991)

Custo: 28 soldados mortos e 100 feridos.

Desastre: Durante a primeira Guerra do Golfo, um sistema (Patriot) americano de mísseis na Arábia Saudita falhou ao interceptar um míssel vindo do Iraque. O míssel destruiu acampamentos americanos.

Causa: Um erro de arredondamento no software calculou incorretamente o tempo, fazendo com que o sistema Patriot ignorasse os mísseis Scud de entrada.

9.  Pentium Falha em uma Divisão Longa (1993)

Custo: $475 milhões e a credibilidade de uma empresa

Desastre: O altamente promovido Pentium, da Intel, ocasionalmente cometeu erros ao dividir números de ponto flutuante em um intervalo específico. Por exemplo, dividindo 4195835.0/3145727.0 obteve 1,33374 ao invés de 1,33382, um erro de 0,006%. Embora o bug afetasse apenas alguns usuários, se tornou um pesadelo nas relações públicas. Com uma estimativa de 5 milhões de chips defeituosos em circulação, a Intel se ofereceu para substituir os chips Pentium apenas para os consumidores que poderiam provar que eles precisavam de alta precisão. Contudo a Intel acabou substituindo os chips de qualquer um que reclamou.

Causa: O divisor na unidade de ponto flutuante do Pentium tinha uma tabela de divisão falha, faltando cerca de cinco mil entradas, resultando nestes erros de arredondamento.

10.  Ariane Rocket Goes Boom (1996)

Custo: $500 milhões

Desastre: Ariane 5, o mais novo foguete da Europa não-tripulado, foi intencionalmente destruído segundos após seu lançamento em seu vôo inaugural. Também f0ram destruídos  quatro satélites científicos para estudar como o campo magnético da Terra interage com os ventos solares.

Causa: O desligamento ocorreu quando o computador de orientação tentou converter a velocidade do foguete de 64-bits para um formato de 16 bits. O número era muito grande, o que resultou em erro de estouro. Quando o sistema de orientação desligou, o controle passou para uma unidade idêntica redundante, que também falhou porque nele estava correndo o mesmo algoritmo.

11.  Skynet Traz o Dia do Juízo Final (1997)

Custo: 6 bilhões de mortos e quase a destruição de toda a civilização humana e ecossistemas terrestres (ficção).

Desatre: Alguns operadores, na tentativa de desligar a Skynet (rede mundial de computadores), acabam fazendo a empresa responder disparando mísseis nucleares dos EUA à Rússia, iniciando uma guerra nuclear global a qual o que ficou conhecida como Dia do Juízo Final (29 de agosto de 1997).

Cause: Cyberdyne, o principal fabricante de armas, instalou a tecnologia Skynet em todos os equipamentos militares, incluindo bombardeiros e sistemas de defesa antimísseis. A tecnologia Skynet formava uma rede contínua e efetivamente removia recursos humanos de defesa estratégica. Eventualmente o Skynet se tornou consciente, foi ameaçado quando o homem tentou colocá-lo offline, procurou sobreviver, e revidou com uma guerra nuclear.

12.  Estudo Desastroso (1999)

Custo: Credibilidade da ciência

Desastre: Neste caso, o software utilizado para analisar os desastres tinha um desastre próprio. O jornal The New England Journal of Medicine relatou aumento das taxas de suicídio depois de graves desastres naturais. Infelizmente, estes resultados mostraram-se incorretos.

Causa:  Um erro no programa mostrava a taxa de suicídios por ano como o dobro do seu valor real, o que foi suficiente para inutilizar toda a pesquisa.

13.  Passaportes britânicos para lugar nenhum (1999)

Custo: £12.6 millões

Desastre: A agência de passaportes do Reino Unido implementou um sistema da Siemens que falhou ao emitir documentos para meio milhão de cidadãos britânicos. A agência teve que pagar milhões ao governo para compensar a raiva da população.

Causa: A Agência lançou seu novo sistema sem testá-lo de forma adequada ou treinar seus funcionários. Ao mesmo tempo, uma mudança na lei exigia que todos os menores de 16 anos viajando ao exterior deveriam obter um passaporte, resultando em um aumento enorme na procura de passaportes, o que sobrecarregou o sistema .

14.  Bug do Milênio (1999)

Custo: $500 bilhões

Desastre: O desastre de um homem é a fortuna de outro, como demonstra o Bug do Milênio. Empresas gastaram bilhões com programadores para corrigir uma falha no software legado. Embora nenhum falha significativa ocorreu, a preparação para o Bug do Milênio teve um custo significativo e impacto no tempo em todas as indústrias que usam a tecnologia computacional.

Causa: Para economizar espaço de armazenamento de computador, softwares legados muitas vezes armazenavam anos para datas com números de dois dígitos, como 99 para 1999. Esses softwares também interpretavam 00 para significar 1900, em vez de 2000, por isso, quando o ano de 2000 veio, bugs apareceriam.

15.  Tratamento de Cancêr Mortal (2000)

Custo: 8 pessoas mortas e 20 seriamente feridas

Desastre: O software de radiação da empresa Multidate calculou mal a dosagem de radiação que deveria ser enviada, expondo pacientes a níveis fatais de radiação. Os físicos que foram indicados para checar as máquinas foram condenados a morte.

Causa: O software calculava a dosagem de radiação baseando-se na ordem de entrada dos dados, e algumas vezes enviava o dobro da dose do que deveria.

16.  EDS Drops Child Support (2004)

Custo: £539 milhões (e a conta ainda cresce!)

Desastre: A grande empresa de serviços EDA desenvolveu um sistema para o Centro de Suporte à Crianças do Reino Unido (CSA) que acidentalmente pagou a mais 1.9 milhões de pessoas, recebeu em menos de 700.000 casos, registrando uma lista incansável de erros.

Causa:A EDS apresentou um sistema de TI complexo e grande demais para o CSA, ao mesmo tempo em que tentava reestruturar a agência.

17. Desatre no FBI (2005)

Custo: $105 milhões jogados fora!

Desastre: O FBI desistiu da revisão de um sistema após quatro anos de esforço. O projeto Arquivo Virtual foi um maciço sistema de software integrado para agentes compartilharem arquivos de casos e outras informações.

Causa: Má gestão e uma tentativa de construir um projeto de longo prazo sobre tecnologia ultrapassada, resultou em um sistema complexo e inutilizável.

Traduzido e adaptado de DevTopics.

Utilizado pela primeira vez em 1987, o TCO  foi criado pelo Gartner Group, como medida e aproximação para gerenciamento e redução de custos, envolvendo pessoas, processos e tecnologia. Neste cenário, precisamos estar cientes que os custos relacionados a sistemas, não estão restritos apenas aos custos de aquisição ou desenvolvimento dos mesmos.

Na verdade, o ciclo de vida de um sistema incorpora o ciclo de desenvolvimento do mesmo além do custo operacional que considera os envolvidos em manutenções, tanto corretivas quanto evolutivas.

Neste contexto, a ISO/IEC 12207 considera o desenvolvimento e manutenção do software como processos que compõem o ciclo de vida de software, desde sua criação até a descontinuação do mesmo, compondo o TCO relacionado ao produto de software.

Deste modo, o custo de manutenção torna-se um ponto de grande importância para as empresas. No dia a dia percebe-se que muitas pessoas não possuem um sentimento claro, do quanto pode custar a manter um sistema de baixa qualidade em operação após sua implantação.

Já presenciei empresas com legado composto por diversos sistemas sem documentação, baixa qualidade e que, frequentemente, apresentam problemas de funcionamento. Além das paradas no negócio da empresa, estes sistemas geram perdas imensuráveis, relacionadas à sua imagem perante o mercado e clientes. Isto quando os usuários previstos para o sistema acabam nunca utilizando o mesmo, devido a ele cair em descrédito. Neste caso, todo o investimento é perdido por desinteresse em sua utilização.

Você continuaria utilizando uma operadora de telefonia celular que vivesse fora do ar? Para quantas pessoas você falaria mal desta empresa e qual seria o impacto no negócio da mesma? Qual o prejuízo gerado para ela?

O que já vi algumas vezes e que infelizmente acabarei vendo novamente, são pessoas acreditando que desenvolver software utilizando processos e o paradigma Orientado a Objetos, não são necessários e até mesmo, bobagem. Simplesmente acham que não vale a pena gastar e esperar mais, para ter seus sistemas desenvolvidos utilizando as melhores práticas de Engenharia de Software de mercado.

A verdade é que tudo que deixa de se gastar desenvolvendo software AD HOC, se gasta muitas vezes mais nos processos de manutenção dos sistemas, além de eventuais impactos imensuráveis de imagem junto ao usuário e/ou cliente.

Mas pense bem, se fosse realmente bobagem utilizar metodologias e orientação a objetos, por exemplo, por que grandes empresas como a Sun Microsystems, atualmente adquirida pela Oracle, teria gasto tanto esforço de excelentes profissionais nesta área?

Estudos mostram que cerca de 50% do tempo gasto em manutenções é gasto no processo de entendimento do código a ser manutenido (Fjeldstad & Hamlen, 1983; Standish, 1984). Isto evidencia a importância de um código bem implementado e documentado.

Redução de custos, o que todos desejam

Com o propósito de reduzir custos, podemos mesclar uma série de opções, tais como, renegociar com fornecedores, trocar fornecedores, ajustar Acordos de Nível de Serviço, realizar (re)engenharia de processos de negócios, rastrear gastos, considerar alternativas de Outsourcing, trocar recursos para localização de custos mais baixos substituir tecnologias/sistemas ultrapassados, gerenciar portfólio TI e minimizar custos operacionais com TI.

Dos pontos apresentados acima, percebemos que substituir tecnologias/sistemas ultrapassados, através de outras mais alinhadas ao negócio da empresa e minimizar custos operacionais com TI, através da utilização de sistemas com custos de manutenção menor e maior qualidade, estão alinhados aos objetivos da Engenharia de Software.

A grosso modo, todas as empresas querem e precisam gastar o mínimo possível na aquisição e manutenção de sistemas.

Também as empresas que desenvolvem software querem produzi-los no menor custo e prazo.

Novamente, a Engenharia de Software pode ajudar muito para se atingir estas metas.

Mas como aumentar a qualidade do software?

Podemos citar algumas sugestões, tais como, utilização de uma Metodologia de Desenvolvimento de Sistemas faseada, que possua processo formal de testes/qualidade e documentação, esta para agilizar eventuais manutenções evolutivas e correção de bugs. Primordialmente devemos ter um eficaz levantamento e gerenciamento de requisitos, utilizar equipes de desenvolvimento e testes com pelo menos um profissional sênior, utilizar as melhores práticas de mercado, utilizar design patterns que são soluções de mercado testadas e utilizadas por centenas de profissionais e empresas há muito tempo.

Para saber mais, leia o livro Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1

Quem trabalha com projeto de software com certeza já se deparou com alguma das situações acima.

Ao contrário de outras áreas, como construção civil, indústria e serviços de telemarketing, nós não estamos conseguindo medir o tempo que levamos para executar determinada tarefa.

Muitos problemas podem ser resolvidos criando uma base histórica de desenvolvimento ou de analise de projeto, mas o problema está ao abrir o código. Você encontra um carretel de linha todo embaraçado.

Ao contrário de outras áreas, onde é possível de se enxergar a evolução de um projeto, exemplo construção civil – onde é possível verificar o tamanho e a velocidade que uma parede é construída – na nossa área não somos capazes de mostrar tal evolução, pois pode ser que apenas ao final da codificação percebe-se que não era para ser desenvolvido da forma que está, devido à falta de documentação ou da necessidade de se fazer as pressas. Por este motivo, faz-se necessária a criação de um padrão de desenvolvimento de software de uma forma clara e objetiva, além de uma boa analise do sistema.

Os sistemas legados são os grandes problemas das principais corporações, pois são sistemas remendados e que muitos desenvolvedores colocaram a mão, e como a visão da empresa está focada nas entregas, nem sempre é possível desenvolver um trabalho com qualidade, acarretando assim, muito retrabalho.

As empresas cada vez mais buscam prazos mais curtos, mas estão esquecendo-se de manter seu quadro de funcionários e valorizar os profissionais mais antigos. Novos funcionários levam até 6 meses para entrar no mesmo ritmo dos demais desenvolvedores. Quando o assunto é sistema legado, este prazo pode aumentar para até 1 ano!

Os sistemas legados não têm documentação física, ou seja, a documentação está na cabeça dos desenvolvedores mais experientes e estes por sua vez, devido aos prazos curtos, não se lembram de todas as regras do sistema e das “gambiarras” que tiveram que fazer durante o ciclo de vida do projeto. Por este motivo, todo sistema ao completar 5 anos deve ser repensado, pois sua arquitetura, provavelmente, estará obsoleta, o que pode trazer sérios impactos nos prazos de desenvolvimento e na inserção de novos desenvolvedores.

Como as aplicações estão cada vez mais integradas e em sistemas legados esta integração é cada vez mais prejudicial, pois como o sistema não tem documentação, qualquer alteração pode prejudicar toda a estrutura do software, além do fato de muitos desenvolvedores terem inseridos verdadeiros enigmas nos códigos.

O prazo, em sistema legado, é e continuará sendo um grande problema. As empresas devem encarar a realidade de reescrever suas aplicações e trazerem para uma realidade mais próxima do cenário atual. Assim, a equipe de projeto fará parte desta nova escrita e o conhecimento que antes era de alguns passará a ser de conhecimento de todos os envolvidos. Além da possibilidade de equilibrar o conhecimento da equipe é uma excelente possibilidade de documentar o sistema para futuros membros e aproximar-se das demais áreas da empresa para estudar as funcionalidades que estavam em utilização e as que caíram em desuso.

Ricardo Agostinho – @ric_agostinho

O que é Iteração:
É essencial a comunicação com o cliente, saber o que o cliente quer demonstrar em cada etapa do desenvolvimento do sistema e verificar se haverá a necessidade de alguma modificação.

Algumas dicas para uso da iteração.

- Dividir para conquistar:
Divida seu projeto em mini-projetos em vez de fazer uma iteração para todo o projeto, transforme ele em pequenos ciclos, em que você sempre fará uma iteração a cada ciclo.

- Aperfeiçoe seu tempo:
Crie um plano de iteração para cada ciclo, e determine a prioridade e o tempo de execução para cada requisito obtido durante a iteração juntamente com a sua equipe.

- O tempo é essencial:
Não deixe seu projeto por um longo tempo sem uma iteração, pois através dela o seu cliente ficará por dentro do andamento do projeto e isso poderá ajudar você a ajustar o projeto ao que realmente o seu cliente quer. Um bom período entre as iterações seria de 20 dias dependendo do período total de duração do projeto.

- Prepare-se para mudança:
Só reforçando o que foi dito, a iteração vai lhe ajudar nas mudanças que o seu cliente possa achar necessário no decorrer do projeto, por isso, sua iteração não pode ter um intervalo muito longo. Imagine chegar ao final do projeto e seu cliente descobrir que o projeto não foi feito como ele imaginava.

A iteração é uma técnica essencial para o desenvolvimento de um software de qualidade que respeita a opinião do seu cliente e sua vontade, seu orçamento e seu tempo de execução.

REFERÊNCIA:
Use a Cabeça Desenvolvimento de Software
Autor(es): Dan Pilone e Russ Miles

O CAIS gostaria de informar que o Horário de Verão 2009/2010 terá início à zero hora (00:00) de 18 de Outubro de 2009 e término à zero hora (00:00) de 21 de Fevereiro de 2010.

O decreto no. 6.558 de 8 de setembro de 2008 determinou datas fixas de início e encerramento do período de Horário de Verão. O início sempre será à zero hora do terceiro domingo de Outubro e o encerramento sempre à zero hora do terceiro domingo de Fereveiro do ano seguinte. Se o terceiro domingo de Fevereiro for um domingo de Carnaval então o encerramento é automaticamente transferido para zero hora do domingo seguinte.

No próximo domingo, 18 de Outubro, ser&acoacute; preciso adiantar os relógios em 1 hora nos estados da região Sul, Sudeste e Centro-Oeste que participam do Horário de Verão.

• Rio Grande do Sul
• Santa Catarina
• Paraná
• São Paulo
• Rio de Janeiro
• Espírito Santo
• Minas Gerais
• Goiás
• Mato Grosso
• Mato Grosso do Sul
• Distrito Federal

Lembramos a todos que, tratando-se de incidentes de segurança, a precisão dos relógios dos sistemas é fundamental para manter a consistência dos logs, além de ser imprescindível nas investigações e identificação de responsáveis. Lembramos ainda que os logs reportados durante a vigência do Horário de Verão estarão no timezone UTC-0200 (GMT-2).

Mais informações:

• Decreto no. 6.558 de 8 de setembro de 2008 – Institui a hora de verão em parte do território nacional
• Observatório Nacional – Hora Legal Brasileira

Alterações de Configuração Necessárias para o Horário de Verão 2009/2010

O horário de verão tem relação com o timezone (fuso horário) configurado no sistema. Ao alterar o timezone altera-se o parâmetro do sistema que determina a diferença em horas entre o horário absoluto (UTC / GMT 0) e o horário local.

Se o relógio do sistema (horário absoluto) marca 16:00:00 UTC, ajustado por NTP, temos:

• Para o timezone do Brasilia (UTC-3), o horário mostrado ao usuário será 13:00h ou UTC-3 (hora local)
• Para o timezone de Paris (França – UTC+1) o horário mostrado ao usuário será 17:00h ou UTC+1 (hora local)

Nenhuma modificação na configuração do serviço de NTP é necessária. Entretanto, deve-se tomar um cuidado especial com os servidores NTP (Stratum 1, Stratum 2 e outros) quando ocorrerem modificações de configuração para o horário de verão. Caso o servidor NTP detecte uma diferença maior do que 20 minutos entre o horário do sistema (horário absoluto) e o horário registrado pelo servidor NTP (ntpd, OpenNTPD), o serviço NTPD poderá parar. Assim, deve-se redobrar a atenção durante o processo de configuração do horário de verão em hosts que provêem este serviço.

Lembramos também que, para algumas versões de Linux/Unix, poderá ser necessário reiniciar o daemon “cron” após o início do horário de verão, de forma que as tarefas agendadas através do Cron possam continuar a ser executadas no horário correto. Para mais informações, verifique o manual do “cron” e “crontab” do seu sistema.

A seguir são descritos os procedimentos de atualização do localtime em sistemas FreeBSD, GNU/Linux, Solaris, AIX e Windows, bem como em alguns equipamentos Cisco que usam IOS. Antes de prosseguir com estes procedimentos é preciso que se saiba de antemão o timezone da sua região.

1. Cisco IOS
2. GNU/Linux
3. FreeBSD
4. OpenBSD
5. Solaris
6. AIX
7. MS Windows

1. Cisco IOS

Será preciso incluir (ou atualizar) as seguintes linhas nos arquivos de
configuração dos roteadores Cisco:

clock timezone GMT-3 -3
clock summer-time GMT-2 date Oct 18 2009 0:00 Feb 21 2010 0:00

Os logs gerados pelo Cisco passarão a informar a hora como GMT-2, que é a
nova configuração do timezone.

2. GNU/Linux

Usuários de sistemas baseados em GNU/Linux devem seguir o procedimento
abaixo:

1. Verificar a existência do arquivo ‘/etc/localtime’. Se este arquivo existir verifique se ele é um link simbólico. Uma das formas de fazer esta verificação é executar o seguinte comando:$ file /etc/localtime
   localtime: timezone dataA saída acima indica que se trata do próprio arquivo com dados de timezone. A saída abaixo indica um link para o arquivo.$ file /etc/localtime
   localtime: symbolic link to `/etc/localtime’
   
   Não é recomendado possuir o arquivo /etc/localtime como link simbólico. Sistemas cujo diretório /usr é acessivel (não tiver sido montado, por exemplo) no momento de inicialização da máquina, os dados do arquivo localtime não serão lidos.
2. Verificar se existe algum arquivo no diretório /usr/share/zoneinfo/Brazil que contenha informações relativas a outros anos. Normalmente este arquivo tem extensão ZIC (.zic).
   1. Se não existir um arquivo com tais dados então crie um novo (verao.2009.zic por exemplo) no diretório /usr/share/zoneinfo/Brazil/. Este arquivo deverá conter as seguintes linhas:Rule Brazil  2009    only     -       Oct    18   00:00   1       S
      Rule Brazil  2010    only     -       Feb    21   00:00   0       -
      
      Zone    Brazil/East             -3:00   Brazil          BR%sT
      
   2. Se existir um arquivo com dados de outros anos basta inserir as linhas acima ao final do arquivo existente.As duas primeiras linhas de configuração acima informam quando se inicia o horário de verão, quando termina e qual é a ação tomada. Lembre-se de que no início do horário de verão a hora local é acrescida em uma (1) hora.A última linha informa qual arquivo será modificado pelo comando ‘zic’. No exemplo acima será o arquivo ‘East’ (dentro do diretório Brazil). Esta linha também informa qual o timezone original da região – no caso de São Paulo (East) temos UTC-3. Caso você esteja utilizando um timezone diferente do adotado em São Paulo (East) modifique estes parâmetros para o timezone de sua região:#Fuso horario do Arquipelago de Fernando de Noronha:
      Zone    Brazil/DeNoronha     -2:00   Brazil          FN%sT
      
      #Fuso horario dos estados a Leste
      Zone    Brazil/East          -3:00   Brazil          BR%sT
      
      #Fuso horario dos estados a Oeste (AC, AM, RO, RR, MS, MT)
      Zone    Brazil/West          -4:00   Brazil          AM%sT

      * Parâmetros definidos pela glibc presente em sistemas Linux, disponível para download em http://www.gnu.org/ .

3. Uma vez feitos os devidos ajustes no arquivo ‘verao.2009.zic’ execute o comando ‘zic’:# zic verao.2009.zicNeste caso em particular o comando atualizará o arquivo East.
4. Para verificar se as configurações corretas foram feitas execute o comando ‘zdump’, conforme as orientações abaixo (troque East pelo timezone de sua região):# zdump -v Brazil/EastVocê deverá obter uma saída como esta:Brazil/East  Sun Oct 18 02:59:59 2009 UTC = Sat Oct 17 23:59:59 2009 BRT isdst=0 gmtoff=-10800
   Brazil/East  Sun Oct 18 03:00:00 2009 UTC = Sun Oct 18 01:00:00 2009 BRST isdst=1gmtoff=-7200
   Brazil/East  Sun Feb 21 01:59:59 2010 UTC = Sat Feb 20 23:59:59 2010 BRST isdst=1gmtoff=-7200
   Brazil/East  Sun Feb 21 02:00:00 2010 UTC = Sat Feb 20 23:00:00 2010 BRT isdst=0 gmtoff=-10800

   Note que em “Sat Oct 17 23:59:59 2009 BRT” o sistema ainda não está no horário de verão (indicacao ‘BRT’). No segundo seguinte as modificações do horário de verão entram em vigor, adiantando o localtime em uma hora: “Sun Oct 18 01:00:00 2009 BRST” (O horário mostrado ao usuário passará para 1 da manhã e não para meia-noite, mostrando o adiantamento do horário).

   Em “Sat Feb 20 23:59:59 2010 BRST”, o horário de verão terminará no segundo seguinte, com o localtime sendo então atrasado em 1 hora: “Sat Feb 20 23:00:00 2010 BRT” (o horário mostrado ao usuário voltará para 23:00).

5. Por último, se o arquivo /etc/localtime não for um link para o arquivo /usr/share/zoneinfo/Brazil/East, deve-se copiar o arquivo East para /etc/localtime$ cp East /etc/localtime

3. FreeBSD

Usuários do sistema FreeBSD devem proceder da mesma forma que usuários GNU/Linux. A única diferença está no diretório onde deverá ser criado o arquivo ‘verao.2009.zic’ – /usr/share/zoneinfo. As linhas a serem incluídas neste arquivo, assim como em sistemas GNU/Linux, são:

Rule Brazil  2009    only     -       Oct     18   00:00   1       S
Rule Brazil  2010    only     -       Feb     21   00:00   0       -

Zone    hv2009             -3:00   Brazil          BR%sT

No exemplo acima, o nome ‘hv2009′ representa o arquivo que será criado ao executar o comando:

# zic verao.2009.zic

O arquivo conterá as informações do horário de verão e deverá ser copiado sobre /etc/localtime, lembrando que será preciso fazer uma cópia de segurança do arquivo /etc/localtime antes de sobrescrevê-lo.

4. OpenBSD

Usuários do sistema OpenBSD devem proceder da mesma forma que usuários GNU/Linux.

5. Solaris

Usuários de Solaris devem seguir o procedimento abaixo:

1. Verificar o zoneinfo respectivo. O arquivo /etc/TIMEZONE contém as informações relativas a qual arquivo será consultado para verificar o zoneinfo.# more /etc/TIMEZONE
   TZ=Brazil/EastNo exemplo acima o arquivo a ser consultado é East, no diretório Brazil. Por padrão este diretório deve estar em /usr/share/lib/zoneinfo.
2. Verificar se existe no diretório /usr/share/lib/zoneinfo algum arquivo em formato texto que contenha informações relativas a outros anos (geralmente um arquivo com extensao .zic).
   1. Se não existir um arquivo com tais informações crie um novo arquivo (brazil.zic por exemplo) e insira as seguintes linhas.Rule Brazil  2009    only     -       Oct     18   00:00   1       S
      Rule Brazil  2010    only     -       Feb     21   00:00   0       -
      
      Zone    Brazil/East             -3:00   Brazil          BR%sT
   2. Se existir um arquivo com informações de horário de verão de outros anos basta inserir as linhas acima.As duas primeiras linhas informam quando inicia o horário de verão, quando termina e qual a acão a ser tomada. Lembre-se de que no início do horário de verão deve ser adicionada uma hora.A última linha informa qual arquivo será gerado pelo comando ‘zic’ – no exemplo será o arquivo ‘East’ (dentro do diretório Brazil). Esta linha também informa o timezone da região, no caso o de São Paulo, UTC-3.No exemplo que se segue existe um diretório ‘Brazil’ dentro de /usr/share/lib/zoneinfo que contém um arquivo brazil.zic, que deve ser atualizado com as linhas mencionadas acima.
3. Deve-se então gerar o novo arquivo (em formato binário) como segue:# zic brazil.zic
4. Para verificar se as configurações foram feitas corretamente execute o comando ‘zdump’ conforme as orientações abaixo (troque East pelo timezone de sua região):# zdump -v Brazil/EastVocê deverá obter uma saída como esta:Brazil/East  Sun Oct 18 02:59:59 2009 UTC = Sat Oct 17 23:59:59 2009 BRT isdst=0 gmtoff=-10800
   Brazil/East  Sun Oct 18 03:00:00 2009 UTC = Sun Oct 18 01:00:00 2009 BRST isdst=1gmtoff=-7200
   Brazil/East  Sun Feb 21 01:59:59 2010 UTC = Sat Feb 20 23:59:59 2010 BRST isdst=1gmtoff=-7200
   Brazil/East  Sun Feb 21 02:00:00 2010 UTC = Sat Feb 20 23:00:00 2010 BRT isdst=0 gmtoff=-10800

6. AIX

Usuários de AIX devem alterar o arquivo /etc/environment incluindo a diretiva:

2009: TZ=GRNLNDST3GRNLNDDT,M10.3.0/00:00:00,M2.3.0/00:00:00

A saída acima indica que o horário de verão se inicia às 00:00 do terceiro domingo do mês 10 (18 de outubro) e finaliza às 00:00 do terceiro domingo do mes 2 (21 de fevereiro), seguindo a seguinte sintaxe:

2009: TZ=GRNLNDST3GRNLNDDT,Mm.w.wd/00:00:00,Mm.w.wd/00:00:00

• m: mês ( 1 < m < 12 )
• w: ocorrência do dia da semana no mês contados a partir do dia 1o. (1 < d < 5)
• wd: dia da semana ( 0 < n < 5 : Domingo corresponde a 0)
• hh:mm: horário

7. MS Windows

Em Abril de 2008 foi sancionada a lei no. 11.662/08, que reduziu o número de fusos horários brasileiros para três. Os fusos horários dos estados do Acre, Pará e Amazonas foram afetados. Em Agosto a Microsoft disponibilizou uma atualização cumulativa que trata desta mudança.

• August 2008 cumulative time zone update for Microsoft Windows operating systems

Para sistemas Windows 9*/NT/2000/XP recomenda-se o uso do utilitário TZEDIT (tzedit.exe), incluido no CD do Resource Kit que acompanha a distribuição do sistema. Não existe URL oficial para download deste programa no site da Microsoft, mas ele pode ser facilmente encontrado na Internet, lembrando que neste último caso não se garante a integridade do programa.

Uma segunda opção para modificação do timezone em Windows XP é a utilizacao do utilitário ‘timezone.exe’, disponível para download em:

• Microsoft Download Center – Windows XP Service Pack 2 Support Tools

O download é precedido de um processo de validação, que verifica se sua instalação de Microsoft Windows é genuína.

Administradores de sistemas Windows que queiram automatizar a atualização do horário de verão podem encontrar mais informações em:

• How to configure daylight saving time dates for Brazil

Para a configuração de timezone do seu sistema utilizando o comando ‘timezone.exe’ siga os seguintes passos:

1. Faca o download do “Windows XP Service Pack 2 Support Tools” e instale-o no seu sistema, caso você não possua o utilitário ‘timezone.exe’.
2. Em um prompt de comando (cmd.exe) execute, a partir do diretório “Program FilesSupport Tools” (se foi utilizada a instalação padrão), o seguinte comando:C:Program FilesSupport Tools>timezone.exe /s 00:0:3:10  00:0:3:02As configurações acima seguem o formato:Hora:DiaDaSemana:Dia:Mes    Hora:DiaDaSemana:Dia:Mes
   (Início horário de verão)   (Fim horário de verão)
   • Hora: Hora (00 ate 23)
   • DiaDaSemana: Dia da semana (0 – 6 : 0 = Domingo, 1 = Segunda, etc)
   • Dia: Ocorrência do dia da semana no mês (1 – 5: Exemplo -> no caso do dia da semana ser Terça-Feira:  1 – primeira terça do mês, 2 – segunda terça do mês, etc)
   • Mes: Mês do ano (01 – 12)
3. Execute o seguinte comando para verificar se as modificações ocorreram com sucesso:C:Program FilesSupport Tools>timezone.exe /g
   
   Current Timezone is :
   
   Daylight Saving Time begins at 00:0:3:10
   Daylight Saving Time ends at 00:0:3:02
4. Configure o sistema para utilizar automaticamente as configurações do horário de verão:
   • Start -> Settings -> Control Panel -> Date and Time -> Timezone;
   • Certifique-se que você esteja utilizando o timezone de Brasília (UTC-0300);
   • Certifique-se que a caixa “Automaticamente ajuste o relógio para o horário de verão” esteja marcada.

Para configuração de Horário de Verão em sistemas Microsoft Windows Vista por favor consulte a seguinte página da Microsoft:

• Microsoft – Windows – Ajuste o horário de verão do seu Windows

O CAIS recomenda que os administradores mantenham seus sistemas e aplicativos sempre atualizados, de acordo com as últimas versões e correções oferecidas pelos fabricantes.

O Linux é o terceiro sistema operacional mais utilizado no mundo, entre plataformas móveis (celulares e videogames) e computadores (desktop, notebooks, netbooks).

A chegada até o 1′% envolveu um bom crescimento nos últimos anos. Oscilando entre 0,2% e 0,4% de janeiro de 2004 a julho de 2006, o Linux atingiu mais que o dobro de janeiro de 2007 a julho de 2008, com índices entre 0,4% e 0,8%, sem cair desde então.

Em dois anos, o crescimento é de 150%.

Ainda no topo da pesquisa segue o Windows com 87,9%, e na segunda posição vem o Mac, com 9,73%. O quarto sistema operacional mais usado, logo atrás do Linux, é o iPhone, com 0,55%.

Entre os smartphones, após o iPhone vêm Android (0,07%), Symbian (0,06%), Windows Mobile (0,05%), BlackBerry (0,03%) e Palm (0,02%).

Fonte: ClicRBS Tecnologia