| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Em relação ao ultimo paragrafo do post só tenho um comentário: Bullshit!!!
"Big brother is watching you, and little brother is too. When big brother goes to sleep, little brother goes through his stuff." |
| | | LOL (Pontos:3, Interessante) |
| | Sim, boa perspectiva..
Enquanto que no softare livre, inerentemente código aberto, eu posso ver o que lá está e certificar-me que não é malicioso, no software proprietário tenho de me sujeitar ao livre arbítrio de quem faz as aplicações. Até pode estar lá as instruções para detonarem uma central nuclear no Mississipi, mas isso eu nunca saberei..
Eu não concordo com nada escrito e muito menos com o último parágrafo. Eu posso modificar o kernel do linux para o tornar um vírus.. mas quem disse que alguém o vai adoptar para utilizar numa distribuição? Ou sequer, se alguém vai utilizar?
Quanto ao caso da SCO, dada a natureza do código aberto, eles têm acesso a todas as instruções. Eles que digam exactamente onde está a cópia escandalosa ao UNIX.. pena que ainda não o tenham feito..
Dominus vobiscum |
| | | | | | Enquanto que no softare livre, inerentemente código aberto, eu posso ver o que lá está e certificar-me que não é malicioso, no software proprietário tenho de me sujeitar ao livre arbítrio de quem faz as aplicações. Até pode estar lá as instruções para detonarem uma central nuclear no Mississipi, mas isso eu nunca saberei..
Concordo inteiramente contigo e convém salientar que eu no meu comentário disse que poderia ver-se de outra prespectiva e não era propriamente uma afirmação de uma opinião formal, mas sim de uma possibilidade que se deve sempre considerar.
|
| | | | | O software é americano. Ele existe para promover a nossa produtividade. A caro que alguns alegam que de certeza fazem com que os deputados portugueses estejam sujeitos a uma miríade de mensagens subliminares. É que não conseguem acreditar que os nossos deputados sejam corruptos nem de tal forma ignorantes. A culpa, alegam, tem de ser do software. Mas este é excelente e farto de funções que nos ajudam a socializar. Ora bem, imaginem que eu tenho uma mensagem para enviar dizendo «devemos considerar as vantagens do linux». A nova tecnologia FSKC (Full synthatical key corrector) do novo Outlook irá corrigir-me a frase para: «devemos nós ainda assim considerar as alegadas vantagens do Linux?!». A tecnologia WOSIWIMYM (What others see is what I mean you mean) irá ajudar os leitores do Gildot a expressarem-se correctamente. Por exemplo a frase que apareceu no email de um tal Capitão foi: «o software livre vai despromover o emprego nacional.» Originalmente era: «o software livre vai despromover o meu emprego, e eu sou seu constituinte e cidadão nacional.» Foi aqui a que função de auto-resumo sintático (ARSE) foi activada. O que seríamos nós sem estas preciosas ajudas? Sinceramente o que consegui fazer até agora foi o GAL (Get a life) e que consiste no acto voluntário de desligar o computador e ir ler um livro ou brincar com os putos.) Eu sei, estou envergonhado. Francisco Colaço
|
| | | | Como te compreendo...
Dominus vobiscum |
| | | | | ^magico^ escreve "Neste artigo é referida que houve uma tentativa de introduzir um Back-Door no código do Linux Kernel, tentando modificar directamente o código na CVS tree. Se por um lado é possivel detectar possiveis tentativas, ou até mesmo manter um nivel alto de segurança no código que é introduzido no kernel, por outro fica uma possivel abertura a falhas na revisão do código que é introduzido no software. Convém estar atento a estas possíveis "falhas", se bem que este poderá ser um ponto que empresas com software proprietário e fechado poderão referir como "veêm o código está aberto, qualquer um o pode alterar e escrever instruções maliciosas". «É nesta perspectiva que a SCO é capaz de ter alguma razão quando se preocupa com possível código licenciado no Linux. Não estou a colocar em causa se o código é da SCO ou não, mas de acordo com este artigo onde Jesús Vega acusa o mundo open-source pela "ausência de métodos de controlo que impeçam a inclusão de código não autorizado no desenvolvimento de software livre". "»
TRETAS!!
Isso é tão valido para o Software Livre como para o proprietário, sendo que é mais grave no proprietário porque não se pode consultar o codigo para provar.
|
| | | | | | Isso é tão valido para o Software Livre como para o proprietário, sendo que é mais grave no proprietário porque não se pode consultar o codigo para provar.
Não disse o contrário, e concordo contigo. O problema é que o software proprietário já existe no mercado à vários anos e a única forma de o opensource se afirmar é não ter nenhuma margem de falha tanto no seu método de desenvolvimento bem como possuir caracteristicas que sejam superiores à do software proprietário.
|
| | | | alguém da SCO abriu a boca. Sentiu-se o vento. Assume-se que ele disse alguma coisa. Mas não houve conteudo.
|
| | | | | | | Veio um fedor, que soprava dos lados de Redmond... Francisco Colaço
|
| | | | focar-me no parágrafo relativo à SCO, dois comentários:
1) segundo um comentário no slashdot, aparentemente o Interbase da Borland sofreu de um gravíssimo problema de segurança, a introdução do backdoor data de 94, até à altura em que passou a ser opensource (actualmente o fork chama-se Firebird), foi descoberto e, julgo eu, removido. Isto comprova a veracidade que não há controlo sobre o código fechado, coisa que devia haver NMO;
2) nos projectos open-source, talvez devesse haver um responsável por verificar se o código não infringe uma licença proprietária, mas vejo dois "senãos": 1 - é impossível verificar se o código veio de uma aplicação fechada, porque não existe o acesso ao código dessa aplicação, 2 - isto é giro enquanto o projecto não tem dimensões consideráveis. Não vejo como rever linha a linha código de aplicações complexas com o kernel, Mozilla, OpenOffice, etc.
A opção mais viável é esperar que alguém se queixe e depois remover o código que é propriedade de terceiros.
----------
-1: Redundante! |
| | | | "Se por um lado é possivel detectar possiveis tentativas, ou até mesmo manter um nivel alto de segurança no código que é introduzido no kernel, por outro fica uma possivel abertura a falhas na revisão do código que é introduzido no software."
Mostra que não leste a informação relevante e especialmente os comentários na KML. Lê e depois vais perceber porque é que o BitKeeper, por muito que critiquem ser closed source, impede que código "extra" não entra (hint: o gajo que pôs o código na CVStree não contava com os mecanismos de verificação do BK e este ao sincronizar o código recebe um patch inesperado e dá um aviso)."Convém estar atento a estas possíveis "falhas", se bem que este poderá ser um ponto que empresas com software proprietário e fechado poderão referir como "veêm o código está aberto, qualquer um o pode alterar e escrever instruções maliciosas"."
Pode até ter sido uma das teorias de conspiração mais fantasiosas, mas quem não se lembra do NSA code no windows...? "É nesta perspectiva que a SCO é capaz de ter alguma razão quando se preocupa com possível código licenciado no Linux. Não estou a colocar em causa se o código é da SCO ou não, mas de acordo com este artigo onde Jesús Vega acusa o mundo open-source pela "ausência de métodos de controlo que impeçam a inclusão de código não autorizado no desenvolvimento de software livre". "
Ai, ai, mas que raio tem a SCO a ver? Ao Vega repito +- os comentários do Linus, patentes e afins são coisas para os advogados, o resto é que interessa aos programadores.
"No comments"
|
| | | | | | Mostra que não leste a informação relevante e especialmente os comentários na KML. Lê e depois vais perceber porque é que o BitKeeper, por muito que critiquem ser closed source, impede que código "extra" não entra (hint: o gajo que pôs o código na CVStree não contava com os mecanismos de verificação do BK e este ao sincronizar o código recebe um patch inesperado e dá um aviso).
Sim li (se não tivesse lido não tinha publicado aqui o artigo). A questão não é o uso no BK que garante a segurança do código lá guardado. A questão é que nem toda a gente usa BK, e convém relembrar o que aconteceu com algum código que estava num servidor da FSF (julgo eu) aqui há uns meses atrás. Se o BK é bom, óptimo, mas existem bastantes aplicações opensource e muitas delas com relevância que não usam o BK.
Pode até ter sido uma das teorias de conspiração mais fantasiosas, mas quem não se lembra do NSA code no windows...?
A única forma de um produto inspirar confiança é manter o seu padrão, e quando algo de mau acontece não dizer "ahh mas aquele produto tb tem problemas". O Windows gerou desconfiança e os utilizadores optam por mudar para outro sistema. Se esse outro sistema tb pode ter o mesmo género de problemas de que serve a mudança?!
Não é solução desculpar as nossas dificuldades ou problemas rebaixando os outros, mas sim evidenciando as nossas qualidades!
Ai, ai, mas que raio tem a SCO a ver? Ao Vega repito +- os comentários do Linus, patentes e afins são coisas para os advogados, o resto é que interessa aos programadores.
Supoe um programador que trabalhe numa empresa, também faz parte de uma equipa que programa algum projecto opensource relevante. Esse programador usou código que fez para empresa, no projecto opensource e não existe nenhum controlo sobre isso. É óbvio que mais tarde ou mais cedo a empresa pode vir reclamar o uso de código interno e este pode ser retirado do projecto, mas mais uma vez pode dar asas a mais uma situação semelhante à da SCO não interessando muito se ou com razão; o que interessa aqui é o ambiente que se gera à volta da situação.
Saliento mais uma vez, que estas são "sugestões" que podem levantar discussão e eventualmente surgir alguma coisa para melhorar os métodos de trabalho, não sendo nenhum ataque aos métodos actuais que da minha parte têm bastante valor.
|
| | | | | "Sim li (se não tivesse lido não tinha publicado aqui o artigo). A questão não é o uso no BK que garante a segurança do código lá guardado. A questão é que nem toda a gente usa BK, e convém relembrar o que aconteceu com algum código que estava num servidor da FSF (julgo eu) aqui há uns meses atrás. Se o BK é bom, óptimo, mas existem bastantes aplicações opensource e muitas delas com relevância que não usam o BK. " Lê por favor o que foi discutido no KML. Se leres atentamente, verificas que "alguém introduziu um 'extra' directamente no CVSTree e sem r-e-v-i-s-ã-o, e ao sincronizarem com o BK este alertou para uma alteração não prevista"! O que quer dizer que, o CVSTree não funciona bem, as alternativas capazes ao BK não existem (ainda), os mecanismos de controlo do BK funcionam e o facto de alguns dos mantainers o usarem deu um garante de segurança, e os mecanismos que possibilitam esta, vão ser ainda mais reforçados. Consulta o link que dei e lê os comentários do McVoy(?). Quanto ao que aconteceu na FSF ou possa acontecer noutros sítios, cada um sabe de si, e se não tratam da segurança convenientemente... "Supoe um programador que trabalhe numa empresa, também faz parte de uma equipa que programa algum projecto opensource relevante. Esse programador usou código que fez para empresa, no projecto opensource e não existe nenhum controlo sobre isso." Um caso para os advogads. O programador tem que ser penalizado mas o mesmo não pode ser feito com o projecto. Este simplesmente tem que remover o offending code. A SCO não diz qual o código, então este fica lá. Mas eu DÚVIDO que a SCO tenha alguma coisa para reclamar...
"No comments"
|
| | | | Fico pensando se a SCO não colocou de propósito código do Unixware no linux para depois entrar com a ação contra a IBM... Seria um bom meio de ganhar um dinheiro fácil e sair do atoleiro ou como chantagem para forçar a sua compra...
|
| |
|
