|
pedro
rezende wrote:
> Caro Prof. Silvio Meira > > Agradeço por informar-me e autorizar o link (havia entrado na página no > caderno de informatica do jt sem encontrá-lo). Lamento ter eventualmente > interpretado erronamente suas intenções ao ler seu artigo... > pedro, nao se preocupe - -espero estar contribuindo para o debate sobre o tema. acho que vc entende que e impossivel discuti-lo em espacos tao pequenos como o que tenho. na maioria das vezes, nos so conseguimos, em colunas semanais, provocar uma discussao. o que, quando acontece, ja e um excelente resultado. uma coisa que eu acho fundamental, no caso do open/free software, e´ nos conseguirmos, com o tempo, tirar o caracter de birds of a feather da ecologia associada a isso, sem o que nunca sera realmente levado a serio pelo mainstream da economia. depois, e importante considerar que o free movement so consegue, na pratica, ser ativo quando ha monopolios reais ou virtuais no nicho de mercado, ou seja, quando ha um inimigo claro. por exemplo, do ponto de vista economico, eu duvido que haveria lugar pra open em op sys se o mercado de OS fosse dividido por 5 sistemas, o maior tendo 40%... a questao, no caso dos OS e que o duo unix/windos praticamente acabou com o desenvolvimento/pesquisa de sistemas operacionais, como se isso nao fosse mais preciso. linux and the like, pra mim, e uma reacao muito timida a isso, sem trazer o que BeOS traz, por exemplo, de novidades. ou sem avancar em outras areas, como epoch, o que e uma pena. eu acho que a briga do free esta em *things of the past*: e o que eu queria era ve-la em things of the furture, como mobile, hectocomputadores, etc... veja uma defesa do movimento em outro artigo meu... na ag
estado, falando
de algo do presente/futuro...
silvio meira |
|
Inicialmente peço desculpas
caso venha a incorrer em
algum erro por não conhecer bem o assunto. Como foi o senhor
mesmo quem pediu comentários, creio que posso
me dar esse luxo.
Antes de emitir opinião sobre o que o senhor mesmo escreveu, devo destacar que achei o texto do professor Meira um tanto quanto primário. Parece-me que o texto foi escrito às pressas, sem nenhuma pesquisa, pois não se fundamenta em nada. Para dizer a verdade, acho até que as perguntas finais, deixadas no ar, nem são tão interessantes diante do quadro que ele apresentou. Quanto ao tema
liberdade e direito autoral acho
louvável que ainda hoje existam pessoas que lutam para
que tenhamos direito de escolha sobre o que queremos
usar ou não, e sobre como queremos usá-lo, ou sobre
quanto queremos confiar naquilo que usamos. O que a maioria
prega é que existe um mundo
e que
nós temos que nos adaptar a ele, e usarmos os
Creio que modelos
de negócio alternativos
sejam
saudáveis para qualquer tipo de indústria que não
pretenda escravizar seu cliente, mas torná-lo
satisfeito, e lucrar com essa satisfação. Muitas
empresas ainda pensam na manutenção do cliente pela
dependência gerada e não pela qualidade dos
serviços.
Diante do sucesso de várias empresas virtuais, será
que não é visível o benefício de novos
modelos de
negócios? O temor dos que pregam a escravização
do
usuário é válido até o momento em que
pararem
de
pensar em como deter o movimento do software livre e
passarem a pensar em como atuarão dentro dele. Lança-se
então o discurso sobre a
segurança, ou a
falta dela. Tópico interessante diante do que foi
comentado a respeito de backdoors e troianos. Se não
podemos conhecer os programas que usamos, nunca saberemos que tipo de
"arma" está embutida ali, e que
será usada contra nós a qualquer momento. Mas será
possível um mundo onde não possamos confiar em nenhuma
empresa que nos atenda? Será que temos condições
de
ficar checando se nossos programas não fazem nada de
"errado"? Será que, de qualquer forma, não seriam
apenas alguns privilegiados que teriam a oportunidade
de se proteger, uma vez que têm acesso às
informações?
Por outro lado, talvez nem todos os usuários precisem
saber de todos os furos de um software, mas como
decidir quem precisa da informação e quem não
precisa? Sobra ainda a
discussão a respeito de patentes.
Mas antes de entrar nessa discussão quero destacar a
beleza do conceito do copyleft, que retrata a mais
pura filosofia do movimento do software livre (pelo
menos como eu consegui enxergá-lo até aqui!). A existência de empresas que só negociam patentes é suficiente para se questionar leis que fortalecem a visão de posse de uma idéia. Como garantir quem foi o primeiro a pensar em tal idéia? A
legalização de backdoors, e criminalização
da
divulgação de informações a respeito de
um software, é
a proibição da comunicação livre e aberta
entre
pessoas de uma mesma área, que têm os mesmos
interesses e que trocam experiências para melhorar seu
trabalho. Tem-se a impressão de que a indústria quer
impôr confiança ao invés de conquistá-la. A filosofia do cooperativismo vem obtendo sucesso em vários tipos de associações, que geram grandes empreendimentos, em vários setores. Porque não pensar que um modelo cooperativista poderia obter sucesso na indústria do software? Talvez seja o medo de um socialismo escondido nas sombras, ou algo parecido. Adriano Carmo. P.S.: Confesso que eu mesmo não entendia o que era o movimento pelo software livre, e passo a compreendê-lo um pouco melhor agora! |
|
Jeferson Fonseca De Mello Junior wrote: >
> Bons Dias... > > Bom, estive matutando e imagino que a maior ameaça mesmo para o código > aberto seria não os eventuais processos, afinal de contas se o autor do PGP > sobreviveu a um processo de crime federal, acho que o bom senso vencerá a > industria de processos no EUA. Porém a maior ameaça seja mesmo algo quem > inocentemente se estabeleceu seria a POO. Afinal de contas seriam poucos os > casos que a pessoa realmente desejaria saber o como está implementada uma > determinada finalidade e menor ainda vai se o desejo de acordo com a > filosofia da OO estiver estabelecida. > Pensando na opinião do Jefferson, vejo em seu raciocínio o reflexo da ingenuidade, decorrente da obsolescência do paradigma que abraça para entender o problema. Jefferson desperdiçou a oportunidade de testar a validade de seu raciocínio na aula passada -- da qual se ausentou -- onde a questão da intencionalidade dos programas foi novamente ventilada, desta vez sobre um caso específico (NSAKEY) apontado no artigo que comenta. Neste artigo quero dar a entender que o código aberto pode ser uma arma para quem queira se defenter de código embusteiro, principalmente no software de segurança. Nem Jefferson nem o prof. Silvio Meira entenderam minha ponderação, e acho que sei porque. Eles não percebem que o controle sobre a *intenção* do software é o que está em jogo na guerra ideológica que nos cerca, e que o teste de constitucionalidade de leis atualmente sendo promulgadas sob o regime de FUD (Fear, Uncertainty and Doubt) promovido por paradigmas obsoletos, pode levar mais de uma década para se esclarecer. E que enquanto a irracionalidade cumulativa de leis tais como o CDMA, o UCITA e a resolution 465 não vêm à tona, estão a concentrar exagerado poder em setores da indústria de alta tecnologia. Quando a poeira baixar, haverá decorrido tempo suficiente para que a indústria do sw proprietário haja esmagado o movimento do software livre, visto como empecilho a seu modelo de negócio. Para não falar dos direitos de privacidade e de escolha individuais. Jefferson não percebeu que os problemas de Zimmerman na decada de 80, anteriores à legislação draconiana com que estão se armando os grandes players, hoje parecem bricandeira de criança. (Zimmerman se safou negociando a licença de uso do RSA e exportando o fonte do PGP para uma empresa de software livre). Enquanto isto acontece, Jefferson, Silvio e outros seguem acreditando que a intencionalidade de qualquer sw está completamente descrita por sua especificação. Na aula de 27/03/00 voltei a sugerir que é muito fácil para um programador ocultar intencionalidade em código binario de rotinas criptográficas, como também voltei a lembrar que o processo da segurança se desdobra em safety (Murphey) e security (o diabo), sendo que a criptografia trata de security. Jefferson, Meira e outros continuam rezando o mantra "segurança = safety". A culpa não é da lingua portuguesa (que tem apenas uma palavra para security e safety) mas do paradigma computacional da década passada que abraçam, centrado na questão sobre como a eficácia pode ser confiável. Acontece que a questão central e urgente agora é outra; é sobre como a confiança pode ser. Quando estivermos falando sobre o SSL em aula, Jefferson terá a oportunidade de, caso delas não se ausente e não se disperse em conversas laterais, entender como certos detalhes de implementação na geração de chaves de sessão podem reduzir drasticamente a entropia da cifra implementada, neutralizando assim, para quem conheça tais detalhes, a eficácia da funcionalidade especificada para tal cifra. A filosofia POO é bela e pura, mas a intenção das pessoas que no mundo da vida distribuem codigo binário pode não ser, pricipalmente quando muito dinheiro está circulando por fios e fibras controlados por programas de computador. As falácias induzidas por paradigmas antigos no cenario atual de security gealmente nascem da confusão com um pequeno detalhe. Na engenharia de software, do paradigma antigo, o software deve fazer exatamente o que lhe for especificado. Na engenharia de segruança, o software deve fazer exatamente o que lhe for especificado E NADA ALËM. Esta pequena cláusula adicional na filosofia da coisa causa grandes dificuldades, não só para a especificação de segurança (security) mas também para a sua verificação. As especificações de interface na POO são úteis para muita coisa e por muitos motivos, mas certamente não são suficientes nem adequadas para a validação da eficácia de mecanismos de proteção que possam especificar. Há um ditado ingles que diz: "the devil is in the
details". Quando
se
pensa em seguraça, deve-se esquecer os dogmas da engenharia
de software
e se passar ao exercício da dúvida sistematica, a pensar
como Descartes. Mas deve-se exercer a dúvida não somente sobre o que diz o professor, mas também os vendedores de sw e as próprias crenças. E principalmente, saber diferenciar as formas de conhecimento. Sei porque me disseram, Sei porque fiz, sei porque fiz e testei, sei porque fiz e testei e usei por um bom tempo enquanto depurava, são saberes distintos. O diabo do security está exatamente nos detalhes, e quem quiser conhecer o assuto precisa abrir o capô e sujar as mãos com bits e bytes, às vezes até para agarrar gente inescrupulosa. Quando Jefferson diz: "Afinal de contas seriam poucos os casos que a pessoa realmente desejaria saber o como está implementada uma determinada finalidade e menor ainda vai se o desejo de acordo com a filosofia da OO estiver estabelecida" (sic.), espero que esteja, após descontado o uso do portugues, incluindo entre esses poucos curiosos do detalhe aqueles profissionais que se dedicam à segurança computacional com competência e os administradores de sistemas cautelosos. Pelo menos aqueles que tiverem obtido aprovação em minha disciplina. Caso contrário, terá dificuldades em convencer o professor de que tal disciplina lhe valeu para, ou vale, alguma coisa. A programação orientada a objetos já é realidade, tando no software livre como em código proprietario. Pode contribuir para melhorar o controle da complexidade do software quanto ao safety, mas sua relação com security é de forma adversa, pois o maior inimigo do security é justamente a complexidade, conforme discutimos na aula de 27/03/00. Aula que Jefferson perdeu. É claro que o curioso dos detalhes precisa saber filtrar o que lhe interessa em meio à complexidade, e para isso escolhe ou desenvolve e usa suas próprias ferramentas. Se os poucos a se interessarem por detalhes serão cada vez menos, parece que o futuro nos aguarda com software cada vez mais bem depurado, feito por gente cada vez mais bem intencionada, apresentando mensagens de erro honestas e esclarecedoras, onde cada vez se usará menos exploits, troianos e backdoors para invadir, vandalizar, sabotar, fraudar, roubar ou zoar. Ou seremos simplesmente cooptados a aceitar a proibição para abrir o capô e examinar o motor da maquina, resignando-nos com a nossa incompetencia e com a necessidade de usarmos software cada vez mais complexo e carregado de obscuros penduricalhos, pois é assim o fluxo de caixa dos donos do mundo se mantem. O futuro, conforme pintado por Jefferson e Silvio Meira, ou não me convence ou não me agrada. Nós é que fazemos o futuro, embora não possamos controlá-lo, etc, etc. Ou será que voces não acreditam nisso! >
> Quem sabe o codigo aberto abrira´ finalmente um segmento no campo > dos usuarios caseiros, alimentados por esforco conjunto de programadores de > todo o mundo e universidades, e um outro nas empresas... Provavelmente > havera´ mais mercado ainda com os PDAs... Jeferson Fonseca De Mello Junior
|