Re: fiquei sem a??o

Matias Schweizer <matias-7pUm/SSSJFa7hsvYdc9FTl/I71DsQ//[email protected]>
Newsgroups gmane.org.user-groups.linux.parana
Message-ID <[email protected]>
At 17:10 19/8/2005, you wrote:
>recebi um e-mail de um cliente, e não sei exatamente como responder a 
>ele, segue a parte que mais me intrigou.

Olá Diogo:

Eu acho que não é tão complicado argumentar. Primeiramente, achei o texto
um pouco confuso. As frases estão estruturadas de maneira: Se isso, afinal aquilo, então aquilo outro. Do jeito que está, o leitor tira o
foco da argumentação, cai na explicação e concorda com a conclusão.

>"Pelo Windows se tratar de um sistema operacional fechado a dificuldade 
>na descoberta de vulnerabilidades e subseqüente exploração das mesmas é 
>muito maior. O que é algo bom.

Esse é o tradicional argumento contra o software aberto, dizendo que todos têm acesso aos fontes, várias pessoas procurando vulnerabilidades, etc. Um ponto importante a comentar é que o software aberto tem, não só
sua distribuição aberta, mas também o desenvolvimento. Existem várias
equipes trabalhando no código-fonte e as descobertas de falhas durante
esse desenvolvimento pode ser identificada antes do mesmo estar disponivel.

Aqui um ponto pessoal: Mesmo com o argumento acima, o que se tem visto
é que as vulnerabilidades descobertas é muito maior. Um colega meu, do
NIC.br, uma vez me passou um site que tinha uma listagem de vulnerabilidades encontradas/ano/sistema. Lembro que o linux estava
abaixo dos windows e acima do BSD. O com menor vulnerabilidades era
um Mac X, mas acho que não vale a comparação.


>Um administrador de SO geralmente não é um programador ou pouco entende 
>do assunto. Ou seja, dificilmente modificará o código fonte do SO ou 
>mesmo buscará por vulnerabilidades no mesmo o que torna o SO de código 
>aberto igual ao de código fechado, para este profissional.

Para o administrador não é importante, nem interessante, mexer nesses códigos-fonte. O importante é ter quem ache os problemas e forneça soluções para a correção. No caso de softwares fechados, ele precisará
contar com a garantia da empresa de que dado patch funciona. Além disso,
quem garantirá que esse patch não tem efeitos colaterais ou que não
abre outras vulnerabilidades?


>Quanto à divulgação das mesmas, por se tratar de um SO amplamente 
>difundido é maior, mais abrangente (pois além de ser fechado o suporte é 
>centralizado), e mais rápido. Além do que existem incontáveis empresas e 
>indivíduos, não relacionados diretamente à Microsoft, especializados 
>apenas nas descobertas e divulgação de vulnerabilidades para os SO’s MS."

O problema é que os incontáveis individuos são "subordinados à empresa".
Imagine a seguinte situação:

Alguem dessa consultoria descobre um problema grave, que pode destruir todo o sistema e pode ser usado por qualquer um. Imagine ainda se a 
solução para isso levasse um tempo para sair e/ou precisasse de uma
nova versão do SO em questão. 

Será que essa consultoria iria divulgar a vulnerabilidade? E se vazar,
como é que fica? Um consultoria desse tipo parece, ao meu ver, aqueles
casos onde o advogado, juri e juiz são a mesma pessoa. Eles estão
defendendo a parte deles e não podemos contar com a isenção desse
grupo.

Além disso, existem as mesmas e incontáveis empresas e indivíduos que
procuram vulnerabilidades no software aberto. A diferença é que não
precisam estar necessariamente ligados à empresa que os criou. Pesquisando nos newsgroup, para resolver problemas simples, pode-se
ver a diferença entre resolver um problema em software aberto e fechado.

[]'s





>-- 
>Diogo Henrique Padovani
>Técnico em Informática
>Sociedade Educacional Fleming
>Campinas - SP
>
>
>
> 
>Links do Yahoo! Grupos
>
>
>
>
> 


Matias Schweizer
matias-7pUm/SSSJFa7hsvYdc9FTl/I71DsQ//[email protected]
SCHNAUZER Plastimodelismo
http://www.spmodelismo.com.br/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.