Re: [Cliente remoto Microsiga AP7] Falha de segmentação
On 5/22/07, Paulo de Souza Lima <paulocwb2003@yahoo.com.br> wrote:
Maxwilliam,
>> Dizer que o Linux não é homologado por não ter ninguém para culpar em
>> caso de problemas é puro FUD.
Que seja, mas a visão das empresas de software é assim. Mais por proteção
jurídica do que
por motivos técnicos.
Cara eu já trabalhei em empresas pequenas, médias e hoje estou numa
software house multinacional. Nunca ouvi tal exigência por proteção
jurídica.
E pra te falar a verdade, duvido muito que ele funcione no Red Hat e não
funcione no
Debian. A gente só tem de encontrar a maneira.
Há questões que impedem isso, questões técnicas como constado
anteriormente: incompatibilidade de bibliotecas. Há solução sim, mas
muito trabalhosa.
>Quando tu instala uma distribuição tu instala o software "como é",
>contratos como o da SuSE/Novell, RedHat e outras inclui isto logo no
>começo. Ao usar o software tu aceita os termos e, portanto, não pode
>responsabilizá-los por eventuais falhas.
Sim. O software sim. Mais um motivo pra ter desconfianças quanto ao S.L.
É por isso que apareceram as distribuições como Red Hat, Suse, Ubuntu e
outras:
para dar a credibilidade de uma entidade que se responsabiliza pelo
software.
Parece brincadeira, mas é isso mesmo.
Na verdade a SuSE sempre teve um foco empresarial e a RedHat assumiu
esta postura pela popularidade. Ubuntu é o fruto de um entusiasta
milionário disposto a gastar com isso.
Se tu tiver um RedHat AS 5.0 e perder os dados de todo o teu ERP por
um bug no kernel, não vai poder fazer nada contra a RedHat, tu leu e
concordou com isto, citado no contrato. Neste caso, o que adianta ter
a empresa para responsabilizar juridicamente? O mesmo vale para tantas
outras como Microsoft, Sun e etc. Eles fornecem um sistema operacional
e em alguns casos suporte, nada mais.
>Em relação à segurança, ou melhor, relação a QA, o Debian é de longe a
>distribuição mais avançada com um ciclo de desenvolvimento
>excepcional, não sendo, à toa, a segunda distribuição mais velha ainda
>em atividade e base de tantas outras. (A saber, a mais antiga em
>atividade é o Slackware, que saiu um ano antes do Debian)
Eu concordo, mas isso não é suficiente pra sensibilizar o CEO e o CIO de uma
empresa, na hora de decidir por um S.O. de um servidor. A palavra chave
nesse
momento é "risco". O cara pode pensar: "Estarei eu disposto a colocar o meu
na
reta e escolher o Debian, a melhor distribuição do mundo, mas que não tem
suporte nem uma figura jurídica, ou o Red Hat, uma distribuição meia -boca,
mas que me garante que eu posso jogar a culpa se alguma coisa der errado?
Estarei eu disposto a ficar com a bomba na mão, mesmo que ela esteja
desarmada?"
Te garanto que muitas dessas decisões passam por gente competente e
que tem conhecimentos técnicos antes de chegar num CIO e/ou CEO. Meio
sem fundamento este argumento de "deixar na reta", ele fica "na reta"
de todas as formas mais por uma questão de equipe incopetente que por
problemas com a empresa/fundação que provê o sistema operacional.
>Para fins de informação, a Marinha dos EUA, Exército Brasileiro,
>ANVISA, e mais todo o pessoal deste link[1] usam.
>
>Resumindo, falta informação, vontade e capacidade para que empresas
>tomem atitudes como esta.
>
>1 - http://www.debian.org/users/
É verdade. Falta vontade e falta coragem. Mais porque elas não estão
dispostas a
correr riscos desnecessários, menos ainda aqueles que não têm a ver com o
seu
negócio, mas que podem causar grandes estragos.
Um caso que gosto muito de citar (e que não está na lista) é o da Celepar, a
companhia de processamento de dados do Paraná. Tudo (ou quase tudo) o que
eles desenvolvem hoje é S.L. E eles usam Debian a rodo lá.
Não é risco desnecessário, é falta de conhecimento técnico mesmo. Como
disse, poderia muito bem homologar com determinadas versões de
bibliotecas e se fosse o caso compilar todos os binarios
estaticamente. Assim o requisito seria "compatibilidade com binários
ELF" e no máximo uma versão da LIBC e não uma distro. ;)
Reply to: