Meus artigos: O Software livre cria melhores profissionais

De Ramoni

Conteúdo 1 Introdução 1.1 A Internet 1.2 Constatação 2 Profissionais e serviços 2.1 De ambientes proprietários 2.2 De ambiente Open Source 2.3 Os serviços terceirizados 2.4 Necessidades específicas 3 Conclusão 3.1 Os profissionais 3.2 A Internet 3.3 O outro legume da faca 3.4 O loop resumido

Introdução

A Internet

O mundo de TI em geral está uma zona.

Tudo bem que não são mais as poucas máquinas da ARPANET, mas as pessoas que conectam seus sistemas à Internet precisam esculhambar as regras ??

• Administradores colocam seus sistemas disponíveis para o mundo sem configurá-los direito
• Usuários não possuem controle sobre seus sistemas operacionais
• Webmasters criam páginas que não funcionam em todos os navegadores
• Administradores de rede não sabem como suas estruturas funcionam, e não conseguem resolver seus problemas
• Administradores criam verdadeiros caminhos de rato no roteamento interno de suas redes, o que dificulta implementações de outras soluções
• Clientes corporativos pedem coisas que por conceito, são impossíveis
• Prestadores de serviços fazem o impossível, atravéz de "gambiarras"

Isso tudo gera em algumas instituições um ambiente complexo e difícil de manter, além do conhecimento que é perdido entre trocas de funcionários. Aliado à dificuldade de se achar um bom profissional no mercado, os ambientes tendem a se tornar cada vez mais complexo e fora de conformidade.

O que serve de consolo, é que obviamente os órgãos responsáveis pelas bases da Internet, fazem um ótimo trabalho de divulgação de guias de boas práticas de conduta, configuração, e documentos explicativos. O problema é muitas pessoas que colocam sistemas na Internet se quer conhece estes órgão e sabem como a Internet funciona. Muitos acham que ela "simplesmente funciona". Contratam um backbone, adquirem um range IP /30 e criam seus sites e emails. Os problemas mais comuns dizem respeito à:

• Open Proxies
• DNS com busca recursiva aberta
• Falta dos mecanismos de contato de um domínio. O contato do whois e os emails security@ e abuse@ muitas vezes não existem
• DNSs com TTL absurdos, e migrações que causam grandes indisponibilidades dos sistemas
• Emails em Open Relay, listados em DNSBLs e fora de conformidade com o SMTP
• Falta de configuração do DNS reverso (que em ranges menores que /24 deve ser solicitado ao provedor fazer a configuração)

Já ouvi Gerente de TI pedindo para liberar no firewall da empresa o acesso externo (vindo da Internet) a um servidor interno, e ao solicitar o IP origem ouvi: "192.168.1.1". Ou seja, a Internet é mágica.. cada um escolhe um IP para colocar na estação, usa este IP na Internet e nunca dá conflito porque estranhamente todas as pessoas escolhem IPs diferentes !

Conheço outro caso em que os servidores de email eram por padrão Open Relays, e eram montados e administrados por uma pessoa com pós em segurança.

Conheco programadores de sistemas que não conseguem criar um joguinho de forca.

Assim como um pessoa pode ser muito bem capacitada sem uma certificação ou curso na área, certificações e cursos não asseguram que o profissional não vá fazer besteira.

Constatação

O ponto que quero defender é o que eu tenho percebido em eventos, listas de discussão e de pessoas que eu conheço que trabalham com Open Source e softwares proprietários.

Tem gente que diz que o Open Source cria melhores profissionais, eu gostaria de corrigir a frase para o Open Source gera profissionais técnicos melhores.

Um ótimo técnico, pode não acrescentar muita coisa à empresa em termos comerciais, e o valor do seu trabalho pode não ser devidamente percebido. Um profissional não tão técnico, as vezes pode vir com idéias mirabolantes e quase impossíveis em termos técnicos, mas que acrescente valor comercial à empresa. E o pior, é que se a empresa gostar, não é ele que vai ter que fazer, e sim o bom técnico.

O que tenho constatado é que muitos profissionais que usam como base sistemas proprietários, são muito limitados em seu conhecimento. Tudo bem que para se trabalhar com uma coisa, não é necessário saber outras em volta, mas as pessoas acabam se acomodando e fazem questão de se limitar ao que ela acha que tem que fazer somente, não querendo se envolver com quaisquer coisas que envolvam outros sistemas. As vezes nem para ajudar na solução de um problema.

• Webmasters que não sabem usar FTP para transferir o site (ok, pode não ser a função do webmaster, mas então, quando a página tem um link errado, porque que o administrador do servidor é capaz de modificar a página e resolver ?)
• DBAs Oracle que não sabem instalar Oracle.
• Administradores de controladores de domínio Windows que não entendem de LDAP
• Administradores de outras plataformas que não conseguem fazer troubleshooting de um problema de rede porque desconhecem roteamento, TCP/IP, sniffers, e nem conseguem formular um teste a ser feito para descobrir onde um problema pode estar.

E muitos mais...

E, no que isso está ligado ao Open Source gerar profissionais mais técnicos ?

Simples. Grande parte destes problemas das outras áreas são resolvidos por estes profissionais.

Não é o foco deste artigo discutir custos, segurança ou outras coisas relacionadas às plataformas envolvidas.

Profissionais e serviços

De ambientes proprietários

Os ambientes em cima de plataformas proprietárias tendem a ser mais organizados, pois normalmente são sistemas menos flexíveis. Quando a diretoria ouve um "Não consigo resolver isso" do DBA ou do administrador Windows, ela entende que a coisa não é possível de ser feita. As vezes isso é pela falta de flexibilidade do sistema as vezes pelo desconhecimento do profissional. O que quero dizer é que normalmente a empresa não contesta a resposta.

Em alguns casos, quem torna as soluções possíveis são os administradores dos sistemas mais flexíveis que estão por baixo, os sistemas Open Source.

Exemplo de um caso típico seria algo não ser possível em um banco de dados que precisa consultar outro servidor interno. Digamos que o servidor de banco de dados aponte para o outro via o hostname que resolve em um IP público, e que esta conexão não é permitida no firewall público. A solução poderia ser fazer com que o banco aponte para o IP interno do outro já que estão na mesma rede, mas o DBA diz que isso quebraria outras referências em outros lugares, não sendo possível fazer aquilo. Lá vai o "cara de Linux" criar um NAT no firewall interno para redirecionar a conexão....

Por exemplo, é possível um administrador de um controlador de domínio Windows, não saber nada de LDAP. Embora a solução seja baseada em LDAP, a coisa funciona "out of the box", e funciona bem. Logo, dificilmente este administrador precisará conhecer LDAP para resolver um problema. Aí lá vem o administrador do proxy Linux, querendo integrar a autenticação no controlador de domínio. Ao pedir as informações de como ele deve acessar o controlador via LDAP, o administrador fala "LDAP ? Que LDAP ?". Lá vai o "cara de Linux" estudar LDAP e se virar para achar o caminho para a autenticação e acesso aos grupos...

Existem administradores Oracle que usam exclusivamente ferramentas gráficas para a administração total do banco, criação de bases, tabelas, backups etc. Quando a ferramenta não funciona e ele precisa conectar ao banco via SQL, tem dificuldades até de formular um select. Aí vem o administrador Linux, que já possui uma certa experiência em SQL devido ao servidor de emails com contas no MySQL e o ajuda a formular o select.

Outro caso são as VPNs IPSEC. O cara do cisco da outra ponta configura a VPN, e o cara de Linux se vira para configurar o IPSEC. IPSEC por si só já não é muito simples, e a configuração possui muitas opções. Normalmente as dificuldades encontradas pelo cara no Linux são os parâmetros de configuração que ele deve utilizar para falar com o Cisco, que nem o cara do Cisco sabe responder se usa DES ou 3DES por exemplo. Lá vai ele na Internet procurar qual o default que o Cisco usa para poder configurar.

Por seguir definições claras, os serviços prestados em plataformas proprietárias tendem a ser executados com maior padrão.

Para uma empresa, acho que seria mais fácil substituir o administrador de um IIS ou Exchange do que um de Apache ou Postfix. Não conheço o IIS nem Exchange, mas devem existir menos formas de se configurar uma mesma coisa, ficando mais clara a compreensão. Um apache, dependendo de quem configurá-lo, pode tornar complexo uma outra pessoa que configuraria de forma diferente entender a configuração atual. Um Postfix, ou sendmail as vezes, pode ser configurado de 200 formas diferentes ainda mais quando usado um anti-spam como amavis ou mailscanner, e fica difícil para um segundo administrador resolver problemas se a configuração não está do jeito que ele está acostumado. Ou seja, a falta de flexibilidade, junto das definições claras de funcionalidades e das interfaces de administração, tendem a tornar uma mudança de profissional mais suave.

A parte boa, é que como não é necessário um profundo conhecimento da parte de rede, estes administradores podem estudar outras soluções e projetos que seriam interessantes para o futuro.

De ambiente Open Source

O que um profissional que trabalha com plataformas Open Source tem a ver com isso ?

Em pequenas e médias empresa, e até em provedores, grande parte dos sistemas de infra-estrutura são os sistemas Open Source. A vantagem de um profissional desses é que na maioria dos casos, independe se o servidor web apache está em cima de um OpenBSD ou de um Linux, a administração será muito parecida.

Os sistemas Open Source em geral são como "patos". Um pato anda, nada, corre, voa.. mas não faz nada disso direito. Os sistemas Open Source em geral são mais flexíveis, e permitem atender às loucuras que são pedidas pela diretoria (quanto à não fazer nada direito, é porque depende do administrador, que em muitos casos, é um pato).

Um firewall Linux ou OpenBSD por exemplo, consegue fazer NATs que um CheckPoint não faz... NATs muito específicos feitos para alguma outra coisa que está errada funcionar.

A flexibilidade é o motivo pelo qual a maior parte dos servidores em software livre estão lá.

Um profissional de Linux (vou exemplificar como Linux, pois é o mais fácil dos sistemas Open Source) normalmente já começa no seu primeiro emprego a gerenciar servidores Web, DNS, FTP, e Email. Alguns também precisam gerenciar serviços como Radius, NTP, BGP, Firewalls, IDSs, Backups além de fazer verdadeiras acrobacias com roteamentos e NATs.

Muitas vezes, a visão da própria empresa colabora para isso, porque para tudo que roda em Linux, ela contrata um "cara de Linux". E este cara vai ter que resolver todos os problemas das VPNs IPSEC dos roteadores, dos Oracle (já que rodam em cima do Linux) etc.

Os sistemas Open Source costumam ter melhores ferramentas de troubleshooting também. Um administrador de um firewall Linux por exemplo, quando precisa resolver um problema, ele normalmente não pensa em que ferramentas ele tem para usar. Normalmente ele pensa o que ele poderia fazer pra testar, e haverá uma ferramente disponível. Ele pensa "Será que é problema de MTU ? Se eu testar o envio de pacotes de tamanhos diferentes eu vou descobrir" e vai lá e usa o ping; "As rotas parecem certas.., mas não há resposta. Um host à frente consegue conectar, mas eu não. Se eu mascarar o meu IP para chegar lá com o IP do servidor que conecta, eu vou descobrir que há um problema de rota." e vai lá e usa o iptables ou o pf para fazer este teste rápido. Ou seja, normalmente, por terem um conhecimento maior dos protocolos básicos de redes, têm mais imaginação para formular testes de troubleshooting e todas as ferramentas necessárias para isso.

Um exemplo simples: você precisa testar uma regra de firewall que pode estar causando problemas na resolução de nomes do servidor windows. Peça ao administrador do windows gerar um pacote UDP de tamanho X para a porta 53 e tendo como origem a porta 53... , mesmo para um bom administrador Windows isto pode ser difícil. Já para o de Linux, prontamente vem em sua cabeça o comando para gerar o payload necessário que junto ao cabeçalho UDP gerarão os X bytes, e depois basta usar o comando para abrir a conexão e injetar esse payload.

Quando uma integração entre sistemas livres e proprietários precisa ocorrer, normalmente quem quebra a cabeça é o responsável pelo sistema livre. Em alguns casos existem até os diálogos famosos: "Mas o seu servidor não está respondendo como deveria ! Ele devia estar se comportando conforme a RFC xxxx, e por isso eu não entendo sua resposta e não funciona !" - "Mas eu não mechi em nada. Esse aí é o padrão do meu servidor. Se vira aí".

Os serviços terceirizados

Outro fator importante, é que os serviços são tratados de formas diferentes. Em uma solução proprietária você normalmente tem o suporte dela, pois você comprou a solução.

Os serviços em software livre normalmente são feitos por free-lancers ou por pessoal interno do início ao fim. Não tendo contrato de suporte, apenas o funcionário que montou.

Acontece que estas situações são possíveis nos dois mundos, mas as opções só são vistas no mundo proprietário. Existe a escolha em abos.

Uma empresa que precisa de um software, pode comprar de uma fabricante de software e ter o suporte, ou então ter uma equipe interna de programadores para fazê-lo e se beneficiar do controle e da possibilidade de maior customização do software.

Da mesma forma, uma empresa que precisa de um servidor de emails pode contratar uma empresa que o faça, ou então ter uma equipe interna de administradores e se beneficiar pelo maior controle e customização.

Ou seja, não estou falando se a plataforma é livre ou não, isto, é outra decisão. Para todas as necessidades a empresa tem sempre a opção de ter o desenvolvimento in-house ou terceirizado. A decisão depende de vários fatores, como foco do negócio da empresa, custos e outras coisas.

Quando a empresa decide por não ter uma equipe própria para o desenvolvimento ou administração de um serviço, ela terceiriza e aí tanto faz se o serviço prestado será em cima de software livre ou não.

Conheco MUITAS soluções fechadas em que seus fabricantes optaram por usar plataformas Livres, como o Ironport (FreeBSD), Intrushield da McAfee (Linux.. você vê as ethN subindo na inicialização), CheckPoint (O Secure Platform é Linux), os MacOS Servers (A Apple faz questão de divulgar ná página que usa postfix+clamav+spamassassin etc) e outros. Não há problema algum nisso, os fabricantes escolhem as melhores plataformas para utilizarem em seus produtos e normalmente não escondem que há um sistema livre embaixo. Alguns até divulgam que usam uma plataforma livre e que se baseiam nos softwares que são usados largamente. Alguns até contribuem as mudanças de volta para o upstream. Software livre está presente em roteadores, access points, aparelhos de DVD, media centers etc.

Necessidades específicas

Quando uma empresa opta por um software proprietário, ela está obrigatoriamente terceirizando o controle do software. Uma empresa pode ter uma equipe interna de ótimos desenvolvedores, mas não poderá customizar o software para adicionar uma funcionalidade.

Além de depender da fabricante do software implementar o que você quer na nova versão do programa, esta modificação estará disponível para todos os compradores daquele software, incluindo a empresa concorrente.

Se você usa um software livre, e precisa que ele tenha uma funcionalidade a mais, sua equipe de desenvolvedores PODE implementar isso para você. Dependendo da licensa do software, você pode ou não redistribuir suas mudanças. O importante, é que você PODE implementar aquela função que irá fazer seu negócio ter um diferencial.

Esta não a realidade da maioria das empresas claro, mas o fato é que no software proprietário perde-se a possibilidade de customizar o software mesmo que você tenha uma equipe capaz.

Este tópico aliás, nem está no escopo deste artigo.

Conclusão

Os profissionais

Os sistemas proprietários em geral, possuem melhores ferramentas de administração e se integram entre si sem grandes problemas.

Essas ferramentas e facilidades acabam fazendo que o administrador não tenha que entender do protocolo ou linguagem que está por baixo, o que acabará dificultando um troubleshooting quando for necessário. Normalmente quando se tem um problema neste ambiente, aciona-se o suporte do produto.

As funções dos profissionais de plataformas proprietárias também costumam ser mais separadas. Normalmente as funções diferentes são feitas por pessoas diferentes. O cara que programa o sistema não é o mesmo do DBA que administra o banco que não é o mesmo que administra o servidor Windows que o sistema roda.

Já uma situação típica no Open Source, é o administrador de Linux ser o responsável por tudo que envolve Linux. Também ter que programar em PHP para mudar a cara do Webmail e fazer scripts perl para as rotinas de administração do banco de dados MySQL. Responsável até por coisas que não rodam em Linux, basta passar por um firewall Linux.

O profissional da plataforma open-source normalmente é responsável por mais sistemas diferentes, e normalmente precisa saber mais sobre redes.

As empresas pequenas e médias não percebem que também são funções diferentes, e não entendem como o administrador do Firewall não conseguiria alterar as funcionalidades do WebMail em PHP e do banco em MySQL. Para estas empresas, se roda em Linux, um cara de Linux tem que resolver, e pior, as vezes é só UM.

Outro aspecto é que o uso de plataformas proprietárias chama a aquisição e uso de outras soluções proprietárias, como soluções corporativas de anti-vírus, programas caríssimos de backup, soluções de segurança voltadas especificamente àquela plataforma...

Em servidores Linux, algumas destas soluções nem são necessárias, e outras o administrador é que tem que se virar. Fantásticas rotinas de backup, automatizações etc.

Não vou discutir um script de backup contra uma solução proprietária de backup, o fato é que para os servidores em Linux as empresas colocam a responsabilidade em cima do administrador Linux, e para o ambiente proprietário aceitam usar soluções proprietárias.

E Sim ! Existem soluções proprietárias de backup, servidores e etc, mas por algum motivo, as empresas acham que o responsável pelo Linux tem que fornecer estas soluções todas.

É exatamente este cenário que, na minha opinião, acaba exigindo um aprendizado muito maior do profissional de Linux. Isso, aliado à falta de interfaces de administração, pouca ajuda nas integrações com outras plataformas e melhores ferramentas de troubleshooting, gera uma necessidade cada vez maior de estudo.

As empresas confiam nos sistemas Open Source para as funções de infra-estrutura. O problema é que elas tendem a achar que é simples gerenciar todos esses serviços, e normalmente não investem tanto nestes profissionais, equipamentos e soluções.

As empresas exigem mais dos profissionais Linux, e esperam que os sistemas Linux façam sempre mais com custo sempre baixo. E já que o custo do sistema é baixo, o custo com o profissional e o hardware também deve ser.

Eu acho que deveria ser o contrário. Um profissional que vive te aconomizando custos, como uma compra de um Cisco de U$10.000 e faz o firewall/nat/router/proxy/vpn/qos/bgp (em alguns casos até mais) em Linux, deveria ter seu mérito reconhecido. Tá ok, Cisco é Cisco. Mas a empresa foi que optou por não comprar a solução por causa do custo.

Em plataformas proprietárias, por exemplo quando uma empresa compra um Windows Server e um servidor Exchange, já que investe na plataforma, também investe no proffisional que vai administrá-lo. E normalmente este profissional, ficará restrito à administração dos Exchanges e dos servidores Microsoft.. as vezes um anti-vírus e/ou um IIS. O que importa, é que normalmente o profissional contratado para isso dedica-se ao estudo destas poucas soluções, e ele não será colocado para administrar o Oracle, que provavelmente terá outro profissional qualificado como DBA. Diferente do que acontece com o profissional Linux.

Os sistemas proprietários em geral, como são menos flexíveis, as vezes impedem que o administrador faça algo errado.

A Internet

Os profissionais de Linux então estão ali resolvendo os problemas das redes internas e os problemas vindos da Internet (problemas de DNS, Email, Web etc). Os sistemas que administram são normalmente os que estão "de cara para a Internet", e a Internet é um caos.

Isso exige que seu conhecimento seja cada vez maior, que entenda cada vez mais dos protocolos TCP/IP para implementar defesas e boas configurações para resolver os problemas da Internet.

A saturação das funções de um profissional de Linux acaba exigindo que ele se torne especialista em todos os tipos de servidores que rodam em cima de Linux. Como isso é muito difícil, e envolve soluções muito diferentes, são criados administradores que sabem bem configurar um firewall mas não entendem nada de DNS e SMTP. Ou administradores peritos em Apache que criam sistemas de intranet em PHP e mysql, mas não entendem nada de firewall. Piores, são os que entendem um pouquinho só de tudo. Mesmo assim, eles ficam sendo responsáveis por tudo, incluindo a parte que eles não dominam.

O outro legume da faca

A acessibilidade ao Open Source acaba sendo uma faca de dois "legumes".

Exemplificando um caso extremo, um carinha qualquer baixa um Linux fácil de instalar, voltado para desktop, instala em uma máquina, usa uma interface limitada para configurar o sistema e sobe nele todos os tipos de serviços, como o servidor de email, web, dns, mysql, firewall, vpn etc. Está tudo ali no Linux que ele instalou. Logo depois disso, lendo alguns how-tos na Internet (existem muitos how-tos do tipo: "crie o servidor de email e anti-spam em 3 horas") ele já se acha capaz de trabalhar com isso. Arruma um emprego, e vai ser o administrador da rede da empresa. Pronto, tá lá o pateta.

Os problemas mais comuns causados por administradores assim são:

• O sistema de email fora de conformidade, porque o muleque não entende nada de SMTP e não sabe o que precisa nem como configurar o servidor DNS direito, e logo não conseguirá enviar emails para provedores sérios que exigem conformidade.
• Não sabe como "fechar o relay" e seu sistema será usado por spammers consumindo banda, load e será listado em DNSBLs,
• O IP de saída da rede interna também irá entrar em DNSBLs, pois a rede interna será infectada por vários vírus que utilizarão as máquinas para enviarem spams, e o firewall está aberto.
• O proxy interno será acessível via Internet e será usado como open proxy consumindo banda do link porque ele não sabe configurar direito, não atentou para o detalhe e/ou não sabe fechar isto no firewall
• O DNS aceitará busca recursiva e outros problemas bem comuns
• O FTP para acesso ao servidor web com acesso anônimo liberado e com permissão de escrita

À medida que os sistemas livres vão ficando mais acessíveis e mais fáceis, mais administradores (bons e ruins) serão criados, e mais caos na Internet teremos.

Já vi acontecer por várias vezes, de um cara comecar a usar Linux, achar que sabe tudo e já partir pra um emprego montando servidores de email, firewalls.. e depois postar em listas de discussão "Como eu fecho o relay ??".

Solução ?? Que todos estudassem os protocolos relacionados aos servidores que administram ??

Na verdade, este caminho que exemplifiquei é o caminho correto (até a parte de iniciar o aprendizado). E muitos bons administradores começaram assim.

Esta facilidade gera em muitos, uma noção de que é simples e fácil administrar servidores. O que é fácil, é "colocar para funcionar". Configurar e administrar corretamente, exige que se pesquise muito sobre os protocolos envolvidos, e muita gente não se dá este trabalho.

O problema está em se achar capaz de ser responsável por estes serviços. Ninguém deveria aceitar um trabalho para ser responsável por coisas que ainda não domina.

Na minha percepção, a maior parte dos problemas na Internet (principalmente os de email) são gerados por esta situação. O administrador ruim. É mais fácil você criar um administrador ruim no mundo Open Source do que no proprietário, devido à literalmente qualquer um ter a possibilidade de baixar e instalar os servidores.

Para as empresas, é extremamente difícil medir o conhecimento do profissional. Ainda mais que em alguns casos a empresa tem uma equipe pequena ou somente uma pessoa e está contratando um cara de Linux porque o anterior saiu. As empresas não conseguem saber se o trabalho do funcionário, ou de um freelancer, está sendo bem prestado. A empresa apenas vê se a coisa funciona ou não... se funciona como deveria, não sabe. Desta forma fica difícil para a empresa perceber se o psofissional precisa de cursos de aprimoramento, e o ambiente acaba se mantendo inadequado.

Tem muita gente que trabalha com software livre que não sabe da onde isso veio, porque aquilo está ali, porque que o Apache é o servidor web mais utilizado na Internet (e na minha opinião, estes administradores ruins contribuem para que algumas empresas tenham problemas com o Apache e mudem para IIS. Na verdade o problema não foi com o Apache, foi com o administrador. Trocar os dois, as vezes acaba resolvendo).

O loop resumido

Minha conclusão é essa:

• Os sistemas proprietários em geral, por serem menos flexíveis, as vezes impedem que o administrador faça algo errado
• Os sistemas proprietários em geral tendem, por receberem mais investimentos, a serem configurados normalmente por pessoas com maior conhecimento (as vezes não o ideal, mas maior que o pateta que de graça acha que aprendeu a configurar um servidor em cima de Linux)
• Devido à flexibilidade, trabalhar com software livre exige que você administre vários tipos de servidores
• O caos da Internet exige que o profissional aprenda cada vez mais sobre protocolos e como resolver problemas
• O baixo custo e acessibilidade do Open Source, cria os administradores patos e os bons
• As empresas contratam administradores patos e bons
• Os administradores patos colocam sistemas mal configurados na Internet
• Os sistemas mal configurados geram problemas na Internet
• Os problemas na Internet fazem os administradores sérios trabalharem mais

E por aí vai, como um traceroute em loop....

Existem maus profissionais em todas as áreas. Como o software livre cria mais oportunidades, cria mais administradores bons e ruins.