Adalto, também peço desculpas a você e aos demais da lista pelo tom da minha resposta. Não sei quanto aos outros , mas achei seu primeiro quote em meu e-mail e logo depois no do Renato, bem arrogantes.
Mas nada justifica minha atitude. Novamente, desculpas a você e todos os outros membros. No nosso caso que usamos hardware Cisco, já tem uns 3 anos que não temos nenhum downtime por conta de falha de hardware ou IOS nos routers. Quando precisamos foi menos de 5 minutos entre a abertura do chamado e a solução do problema, com o router 100% funcional. Trabalho com Free e UNIX há alguns anos e sei que pra certos problemas mais cabeludos, por mais que se tenha experiência com o sistema, com a ferramenta, com o hardware e tudo o mais, estes problemas demandam tempo para serem resolvidos: procura nos logs, debuga o processo, testa configuração A, testa configuração B, olha mensagens de erro no console, procura no google, pergunta em ML... e por aí vai. Você melhor que ninguém sabe que um cliente que acordou um contrato pedindo X% de disponibilidade, não vai dar a mínima para o motivo do problema, qualquer que seja ele. Ele quer a rede dele funcionando e pronto. É pra isso que ele está pagando. Como disse antes, existem casos e casos. Acredito que para quem tem uma estrutura mais compacta e quer oferecer a melhor relação custo/benefício ao cliente, a abordagem adotada por vc, pra citar um exemplo, talvez seja a ideal. No meu caso e de outros tantos, essa solução é inviável. Imagina eu trocar todos os meus CEs por PCs, botando um ou dois spares pra cada. Imagina uma atualização de segurança pro OS ultra-mega-super urgente que envolva uma nova compilação de kernel ou talvez, um downgrade na versão do OS. Imagina uma queda de energia que danifique o sistema de arquivos inviabilizando o boot na máquina. Imagina que tem que se trocar uma placa, mas a placa que vc comprou não funciona pq ninguem fez um driver pra ela ainda e pra lascar tudo, a placa antiga não é mais fabricada... enfim, são muitas variáveis a se considerar quando se adota i386 numa rede desse porte. Acredito ser pouco provável, mas se um dia a Cisco ou Juniper vierem a ser seriamente ameçadas por i386, haverá um barateamento no preço de routers como nunca houve na história, sendo a principal fonte de lucro destas empresas, o suporte (que hoje já não nada é barato). Aí então o principal motivo para a adoção de i386 como dispositivos de roteamento vai cair por terra. Isso é uma opinião minha. No fim das contas o que os tomadores de decisão querem, é uma garantia que caso alguma cagada aconteça, ela seja sanada o mais rapidamente possível e que de preferência, ofereça muitas e muitas facilidades. Eles não ligam se isso vai ser em Free, em Open, em Linux, em Cisco ou Juniper. Eventualmente o fator preço pode ou não determinar a vitória da solução X sobre a solução Y. Quanto a questão de aprender a mexer com a nova ferramenta (i386+OS+Software que faz o roteamento) não acho seja um ponto tão dificultador, pois como já diz o ditado, " a necessidade faz o homem". Se fossem usuários comuns, até seria um fator de peso, mas estamos falando de técnicos. Basicamente a mensagem é: ou aprende ou tá demitido. Finalizando, peço desculpas novamente pelo meu e-mail. []'s -- http://www.webcrunchers.com/crunch/ http://www.myspace.com/whippersnappermusic http://www.purevolume.com/whippersnapper ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
