Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
|
|
| | Estranho.. ainda à pouco palmilhei a lista de aprovações e não vi lá esse artigo ou proposta de debate ... Ando a ver, certamente.
vd |
| |
| | Os editores são críticados por (passo a citar) "shameless self-promotion" e outros predicados que tornariam este post aborrecedor. Está aqui uma boa oportunidade de um deles escrever um artigo acerca do assunto, aprová-lo e mostrar que o que se diz nem sempre é verdade. |
| |
| | Passo a citar "mais importante que isso parecem-me as notícias sobre a SCOsource.... e ainda não vi aqui debate nenhum..." (Quantic-Oscilation) "Está aqui uma boa oportunidade de um deles [editores] escrever um artigo acerca do assunto, aprová-lo e mostrar que o que se diz nem sempre é verdade." (Dizes tu) Todos os utilizadores do gildot podem propor um artigo e por isso o aquele comentário a querer diminuir a importância da thread em questão por um outro assunto não faz sentido. O gildot é um fórum cujos artigos são propostos tanto por utilizadores normais como por editores. Por isso os editores não são os responsáveis por uma dada notícia não ter aparecido. Existe muita gente para além deles que a poderia ter submetido e não o fez. E se alguém se queixa de uma notícia não ser importante e de haver algo bem mais importante que ainda não foi publicado, "e já conheço isso há duas semanas" dizem por vezes, deviam era ter-se lembrado de propor artigos. O gildot só cresce e só se mantém com a ajuda de todos nós. |
| |
| | Eu não li nenhum comentário em que se responsabilizava os editores pelo facto de o artigo não ter sido escrito e se interpretaram o que eu escrevi dessa maneira, lamento. Não percebi muito bem o que é que quiseste dizer com o teu comentário mas escrever artigos dá trabalho (experimenta escrever um) e o que muitas vezes já aqui foi discutido e que está implícito no primeiro post e depois no meu comentário tem a ver com os critérios de aprovação usados pelos editores.Nada mais. Todos gostamos do gildot caso contrário nem sequer estaríamos aqui a ler esta notícia/comentário mas o ditado "não há bem que sempre dure nem mal que nunca acabe" dá que pensar... |
| |
| | escrever artigos dá trabalho (experimenta escrever um) Já escrevi... PS -1:Redundante |
| |
| | ... com tanta sistema novo nao ira AUMENTAR ao "dll hell" ? |
| |
|
| | Pessoalmente, considero este editorial da AAXNET.COM (Automation Access - Uma empresa da Califórnia) muito mais importante.
Este documento sim, este vem colocar os pontos nos ís sobre o que precisamos de saber acerca da pouca-vergonha que a Microsoft quer fazer em relação ao rumo dos seus negócios para o ano 2003 e depois...
Depois de lerem este editorial por completo (ok, é um pouco extenso, mas compensa a leitura!) poderão ficar talvez um pouco mais convencidos de que relamente NÃO COMPENSA APOIAR A MICROSOFT!!!
URL do editorial:
--- tyFUZZ |
| |
| | Ok. Então programas que instalarem novas versões de DLL não deverão sobrescrever versões anteriores (para não querar software pre-existente). Fantástico... Isto, por um acaso, não significa perpetuar falhas de segurança? Afinal, se DLLs antigas (potencialmente faltosas) serão preservadas, seus bugs também o serão! Não seria tão mais simples simplesmente evitar que os aplicativos pudessem instalar DLLs de uso "público"? Eu considero, simplesmente, temerário saber que qualquer aplicativozinho possa substituir as DLLs de SSH!!
[]s, Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| |
| | :)
No woman ever falls in love with a man unless she has a better opinion of him than he deserves. |
| |
| | AHAHHAAHHAHAAHAHHAAHHAAHAHHAHAHAHA Conta outra vai... Agora a sério.. os problemas das DLL's no Linux são realmente aborrecedoras. True, True.
vd |
| |
| | Problemas de dll em Linux? Espantoso!
--- Omnia aliena sunt: tempus tantum nostrum est. (Séneca) "Tudo nos é alheio: apenas o Tempo é nosso." |
| |
| | "Ora instalo carradas de software diferente, formato o desktop de 2 em 2 anos e nao vejo onde esta tal problema ?" enough said... |
| |
| | partindo do principio que o ac nao e' um troll, calculo que esteja a falar do problema das libs (em windows e em linux). afinal e' isso q sao as dlls certo? ou nunca vos aconteceu o #rpm -Uvh xptolib-x.x.2.rpm error: failed dependencies: libfoo.so.0 is needed by bar-devel-x.x.x-1 [...] e depois - como ate' e' uma coisa sem importancia que se lixe se nao funcionar depois desinstala-se - espeta-se-lhe com um --force com nitidos maus resultados? ou o ./configure && make && make install lembrar-se de sobrepor libs? já sei que me vão dizer que ha muitas maneiras de ultrapassar isso, eu tambem sei algumas. mas para windows tambem: ja tive de o fazer e nao e' assim tao complicado ( basta retirar o dll do [winnt|system|system32] e coloca-lo na dir do programa para alguns, ou entao um batchzinho para alterar o PATH para incluir a dir com a dll da versao que se quer ), e diga-se de passagem, ate' e' bastante menos frequente... Não acho que o comentario merecesse que lhe caisse tudo em cima. Cumps, floWS |
| |
|
| | O problema é que as DLLs de windows têm o mesmo nome para versões diferentes. Em unix ocupam nomes diferentes ao nivel do filesystem (ou seja, nomes de ficheiros realmente diferentes) e tb ao nivel de shared-name (i.e. ao nivel da ligacao que aparece referenciada num executavel). Normalmente isto significa a seguinte distribuicao de "dll"s: libfoo.so.0.37 libfoo.so.0.38 libfoo.so.0 -> libfoo.so.0.38 libfoo.so.1.1 libfoo.so.1 -> libfoo.so.1.1 As .so.0 são compativeis entre si, tal como as .so.1 entre si. Cada minor (.37 , .38 ) representam bugfixes, performance enhancements, etc... De uma major para minor pode haver alteracao de APIs , perca de compatibilidades, etc... Mas o prog que foi compilado e ligado à .so.0 vai continuar a funcionar. Ambas as versoes podem ser mantidas no sistema. Por isso é que em unix não existe dll hell. Existe DLL chatice, mas isso há-de haver sempre, que resulta do facto de existirem dependencias. Se um programa depende da existencia das versões .so.(+1) das que existem no sistema, essas vao ter que ser instaladas ou o programa nao funciona. Tuff luck, mas nao há volta a dar-lhe. -- carlos |
| |
| | #rpm -Uvh xptolib-x.x.2.rpm error: failed dependencies: libfoo.so.0 is needed by bar-devel-x.x.x-1 [...] Acabas de apontar um problema do RPM, e nao do sistema de shared libraries.
|
| |