Em Fri, May 24, 2002 at 01:39:35PM -0300, Syndson Silva escreveu: > Vamos aos coment�rios. Ah, sim! Acabei juntando tudo de todo mundo de > uma vez s�! Espero que n�o crie muita confus�o. :-)
nah, n�o cria confus�o, afinal voc� s� enviou para mim! ;) OK, estou respondendo e colocando a lista de volta no circuito :-) > > O erro j� come�a ao comparar Windows 9x/3x com Linux. Os dois n�o t�m > > nada a ver um com o outro no que tange a integridade do sistema. > > ----------------- (CORTA!!!) --------------------- > >Assim, um programa feito para Windows 3.1 funciona em Windows mais > >novos porque instala suas pr�prias bibliotecas, muitas vezes > >em cima das bibliotecas do pr�prio Windows. > Isso � verdade somente para o Windows, j� que ele tem mania de > zonear o Windows\System, mesmo quando voc� n�o quer que ele fa�a isso! No > DOS, e at� em alguns (raros) aplicativos Win 3.11, cada aplica��o tinha suas > pr�prias bibliotecas, portanto voc� conseguia separar numa boa. Ainda bem > que no Linux voc� tem controle! Ele avisa que vai fazer kaaquinha, mas por > SUA conta e risco. Como root no Linux voc� tem toda a corda do mundo para deixar o sistema inst�vel, � s� usar pacotes compilados a partir de fontes, o que torna o gerenciamento via ferramentas como apt ou rpm invi�vel ou muito dificultado, usar --force com o rpm, etc. > > Em outras palavras, se um programa A foi projetado para rodar no ambiente > B, > > n�o tente rod�-lo no ambiente diferente de B, a n�o ser que analise o > > �... isso d� � pano pra manga... mas juro que n�o concordo muito com > esse "Jeito Windows de ser" dentro do Linux. Se por um lado eu acho o ?!? > m�ximo o fato que ele controla as bibliotecas de modo que n�o � poss�vel > ferrar sem querer a m�quina jogando uma por cima da outra, tamb�m � verdade > que se voc� tem um programa WXW que depende da AcmeLib-1.0, por exemplo e > voc� tem instalada a AcmeLib-1.1, nada garante que que a vers�o atual > mantenha a retro-compatibilidade, e a� a instala��o do WXW pode simplesmente > n�o ocorrer, ou mesmo rodar e travar. Para isto existe o soname (Shared Object Name, IIRC) que permite que v�rias vers�es da mesma biblioteca estejam instaladas ao mesmo tempo, cada uma sendo usada pelos programas que precisem delas. O problema � que para gerenciar isto com apt + rpm n�s precisamos colocar o soname (grosseiramente: a vers�o da lib) no nome do pacote, assim quando a vers�o AcmeLib-1.1 na verdade seria AcmeLib1.1-1.1, assumindo que neste caso soname e vers�o sejam a mesma coisa (1.1), entao estariam instalados tanto AcmeLib1.1-1.1 quanto AcmeLib1.0-1.0. Isto � o que � feito no Conectiva Linux j� h� algum tempo, veja isto: [acme@einstein RPMS]$ l libpng-1.0.11-3cl.i386.rpm -r--r--r-- 1 root root 62051 Mar 23 23:37 libpng-1.0.11-3cl.i386.rpm [acme@einstein RPMS]$ l libpng3-1.2.1-1cl.i386.rpm -rw-r--r-- 1 614 614 101530 Abr 18 08:56 libpng3-1.2.1-1cl.i386.rpm Temos tanto a vers�o com soname 2 (libpng-1.0.11-3cl) quanto a com soname 3 (libpng3-1.2.1-1cl), assim programas mais antigos que ainda estejam compilados ou usem a ABI da libpng2 podem continuar sendo usados com seguran�a, pois est�o usando a vers�o da libpng que foram projetados/testados. Ah, mas porque a libpng com soname 2 n�o est� como libpng2-1.0.11-3cl? Retrocompatibilidade, se mud�ssemos o apt se perderia, pois n�o perceberia que o pacote com nome libpng2 deve atualiar o pacote libpng, mesmo com todos n�s sabendo que � o mesmo pacote, s� renomeado e em uma release diferente... Verifiquem a lista de pacotes do Conectiva Linux 8 e ver�o que isto est� sendo usado para um n�mero grande de bibliotecas e � a pol�tica do Conectiva Linux. Para ver o soname: [root@brinquedo /root]# objdump -p /usr/lib/libpng.so.2 | grep SONAME SONAME libpng.so.2 [root@brinquedo /root]# rpm -qf /usr/lib/libpng.so.2 libpng-1.0.11-3cl [root@brinquedo /root]# objdump -p /usr/lib/libpng.so.3 | grep SONAME SONAME libpng.so.3 [root@brinquedo /root]# rpm -qf /usr/lib/libpng.so.3 libpng3-1.2.1-1cl Outro exemplo: [root@brinquedo /root]# rpm -qf /usr/lib/libtiff.so.3 libtiff3-3.5.7-1cl [root@brinquedo /root]# objdump -p /usr/lib/libtiff.so.3 | grep SONAME SONAME libtiff.so.3 > Como falei, esse caso ocorreu comigo ao instalar o licq 1.1, que exigia > a openssl 0.9.6b e eu tinha a openssl 0.9.6 . Se eu instalava a mais > moderna (via upgrade), nada mais funcionava na minha m�quina. A solu��o > foi dar um jeito de instalar as duas junto. E olha que esse foi um caso > simples. E com um programa com muitas depend�ncias? Como fica? Usa o que voc� descreveu, e que � a pol�tica do Conectiva Linux 8) instala as duas, de forma automatizada e simplificada :) > >Esta regra n�o funciona nem nos mais conhecidos, como � o caso do Word e > >do Excel. Trabalhos mais elabporados feitos no antigo servi�o eram > >comprometidos. > Ah, sim! Estava falando de compatibilidade de programas, e n�o de > documentos. Quanto a isso, a Microsoft � mestra em fazer obsolesc�ncia > programada. Quantos n�o tiveram de jogar seu Word 6.0 (legalizado) fora > porque ele n�o mais abre os arquivos do Word 97/2000/XP ? Ou pior: > Aplicativos feitos no Access 2.0 que rodavam sem problemas passaram a n�o > funcionar ao mudar para o Access 2000 ? Isso eu acho horrivel e > altamente conden�vel! No Linux isso ocorre com menos frequ�ncia... Por isto devemos lutar para que formatos de documentos sejam algo p�blico... V�rios programas poderiam ler e atender as necessidades dos clientes que tem base de documentos no formato antigo em grande quantidade. > O driver PCTel s�o dois m�dulos que s�o carregados junto ao kernel. > Se os m�dulos funcionam no kernel 2.2 e n�o no 2.4, significa que n�o foi > respeitada a retro-compatibilidade. Em teoria, ele deveria funcionar. Mas a pol�tica �: o kernel deve manter sua ABI de acesso a user level est�vel e sem mudan�as _durante uma s�rie est�vel_, i.e. n�o pode mudar do 2.4.1 para o 2.4.2 ou 10, mas _pode_ e muda de um 2.4 para um 2.6, manter retrocompatibilidade n�o � algo que o Linus aceite... Por isto a import�ncia de todos os drivers serem Open Source _e_ estarem na �rvore do kernel, assim quando algo for justificado tecnicamente que mude uma api, todos os drivers s�o modificados para refletir isto, evitando o ac�mulo de remendos e tratamentos de casos especiais na vers�o 10 para algo que existia na vers�o 2... Drivers PCTel, NVidia, etc, somente bin�rios, _n�o_ s�o suportados e v�o continuar quebrando quando mudan�as t�cnicas justificadas e discutidas publicamente, durante uma s�rie de desenvolvimento, que dura pelo menos um ano, tempo suficiente para o mantenedor do driver bin�rio se mexer e lan�ar uma vers�o que seja compat�vel com a nova vers�o do kernel. Ah, um ano ou mais para mudar n�o � suficiente? Contrate uma empresa especializada para acompanhar o desenvolvimento do kernel e manter seus drivers bin�rios em dia com as mudan�as. Ah, n�o posso, � caro? Entao libere os fontes! 8) Uma op��o que est� sendo mais utilizada � a de deixar um "core" bin�rio e liberar somente a cola entre este core bin�rio e o kernel, sendo esta cola recompil�vel pelo usu�rio, AFAIK � isto que a VMware faz, com sucesso j� ha bastante tempo... > >Minha receita de bolo: > > > >Fico estritamente dentro das vers�es da minha distro: CL. Se precisar > >instalar programas que n�o est�o na distro, consulto a documenta��o do > >programa para saber quais s�o os pr�-requisitos (kernel isso, glibc > A receita do Edgar � muito boa, e vou continuar a seguir. S� tem > essa ressalva quanto a se fechar em uma distro. Primeiro que nem sempre � > poss�vel. Segundo: As distros est�o tendo o (mau) h�bito de for�ar o > upgrade mesmo quando a gente n�o quer. No meu caso, eu fui for�ado a > enfiar um KDE 2.0 na minha m�quina porque precisei instalar o Conectiva 7.0 > no meu Pentium 200, de 32Mb. Com o KDE 1.1, a m�quina funciona muito bem, > obrigado, e gostava do bom e velho kfm. S� que fazer o downgrade � t�o > dif�cil que � praticamente invi�vel. Resultado: O KDE 2.0 fica entulhado > no meu HD, s� porque eu gosto de usar o kpackage, que � do KDE. Nem fa�o > quest�o dos joguinhos... E o konqueror eu acho pesad�ssimo, mesmo com 64Mb > RAM. Nunca gostei (e nem uso) dele. Uso o xwc (e o gmc) para gerenciador > de arquivos, pois s�o melhores e mais r�pidos. Pensei que iria me livrar > desse h�bito microsoftiano maldito... Mas voc� pode se livrar! Os fontes das vers�es anteriores est�o dispon�veis, arregace as mangas, recompile as vers�es anteriores, corrigindo-as para que algo que n�o funcione com uma distro moderna passe a funcionar e disponibilize no site que o Manuel Pinho e outros est�o trabalhando 8) Note que com o versionamento de bibliotecas que a Conectiva adotou isto tudo � minimizado. - Arnaldo Assinantes em 24/05/2002: 2266 Mensagens recebidas desde 07/01/1999: 168242 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
