Artigo traduzido: Aplicativos e bibliotecas no mesmo pacote?
Enviado por Julio Cesar Bessa Monqueiro (julioΘgdhpress·com·br):
“O assunto é polêmico. O texto, mais interessante ainda. Confira mais uma tradução de Roberto Bech, a partir de um artigo de Jake Edge no LWN.net:
“Quando se fala em instalação de pacotes, é tradição no Linux separar bibliotecas e binários de aplicativos em pacotes diferentes, de modo que apenas uma versão de uma biblioteca seja instalada e compartilhada entre os aplicativos que fazem uso dela. Outros sistemas operacionais, como o Windows e o MacOS X, costumam incluir uma versão da biblioteca em questão no mesmo pacote do aplicativo, o que pode resultar em diversas cópias e versões de uma mesma biblioteca coexistindo no sistema. Por Jake Edge”” [referência: guiadohardware.net]
• Publicado por Augusto Campos em
2010-04-01
@brlinuxblog
Feed RSS
Do meu ponto de vista leigo, o método do Windows permite uma distribuição/instalação dos programas mais fácil do ponto de vista do usuário final.
Do jeito que as distribuições Linux fazem, permite um tamanho menor da instalação dos programas e do sistema operacional em si, mesmo tendo uma distro Linux popular muito mais programas instalados por padrão. E de quebra, afunilando os meios de baixar programas na internet, permite filtrar de forma mais eficiente os malwares que existem por aí. Porém, isso não impede que empresas como o Skype distribuam binários para Linux em formato de pacotes .deb e .rpm.
Agora é pesar os prós e os contras de cada método.
O Ubuntu querendo copiar o Mac e windows até no que eles têm de ruim ! Só falta quererem colocar as configurações do sistema num registro binário como no windows e fazerem com que cada programa tenha o seu instalador e atualizador próprio.
Sou a favor de facilitar as coisas para usuários leigos mas cometer esse tipo de besteiras que quebram a filosofia unix é dose.
O problema não é quebrar a filosofia do Unix, o problema é haver várias versões de um mesmo programa e, quando aparece um bug ou problema de segurança, aí fica mais difícil de atualizar tudo. Mantendo uma cópia de cada biblioteca apenas, basta atualizar esta cópia e o problema já era, aí fica atualizado para todos os programas que usam aquela biblioteca.
O gasto de espaço em disco a mais não é lá um grande problema nos dias atuais, mas ainda assim, é bom economizar espaço deixando apenas uma cópia de cada biblioteca.
Em caso das tais versões modificadas das bibliotecas, creio que o melhor a fazer é tratar essas versões modificadas como sendo bibliotecas diferentes.
Isto é uma coisa que para mim, mesmo nao sendo um usuario leigo ja me incomoda no linux. As vezes tenho um linux em uma versao mais antiga digamos etch, e quero atualizar um programa, digamos clamav. Vou procurar no repositorio do etch, nao tem a ultima versao. Tem no repositorio do lenny, mas ai se tento instalar da muita dependencia com versoes mais novas de biblioteca. Qual a solucao? Recompilar do source? Vou ter q instalar um monte de pacote devel alem de ferramentas de compilacao (pessima opcao para servidores expostos na web).
Isto nao é um minimo prb em um modelo como o do windows onde uma instalacao q funcione no winxp funciona sem problemas ate no windows 7 e viceversa a nao ser q seja nescessario algo muito especifico do sistema.
Se tem uma versão antiga, de duas, uma: ou atualiza a distribuição, ou instala o programa via backports.
Mas a vantagem do linux, pelo menos das distribuições voltadas para desktop, é justamente a de sair em 6 em 6 meses ou pelo menos todo ano e o upgrade é gratuito e indolor (se o cara mantiver o /home separado e for safo ele nem precisa fazer backup dos seus dados) !
Não tem paciência para esperar sair uma nova versão de sua distribuição e quer atualizar os programas toda vez que sai uma versão mais nova ? Use uma distribuição rolling release tipo Gentoo, sidux e outras.
E se a distribuição que o cara usa for popular, é bem provável que quem desenvolveu o software coloque binários prontos para download.
Usuário windows é que tem que ficar esperando 5 anos por uma nova versão, que não vem com nada e ainda por cima tem que pagar quase o preço cheio para fazer upgrade.
A forma com que os programas são instalados no linux faz com que a execução do programa no sistema tenha rendimento quase que ‘maximo’. Aliás, isso é apenas um dos procedimentos que fazem com que o linux seja muito leve.
Porque não disponibiliza então dois pacotes? Um com e outro sem… Na hora do gerenciador de pacotes resolver a dependência ele decide o que é melhor.
Assim você elimina o problema de ter que instalar milhões de pacotes se precisar instalar um programa em outra distro/versão, além de facilitar na primeira instalação daquele pacote, e mesmo o transporte.
A ainda evita que seja instalado mais de uma versão da mesma biblioteca.
No Windows existe algo assim, se chama .MSI. Quando você você tenta instalar o .msi ele verifica se no sistema já existe as “dependências” se não baixa e instala dentro do contexto. (Salvo exceções onde a licença da dependência não permite).
O usuário pode até “perder tempo” tendo que baixar alguma dependência adicional dentro do pacote, porém garante que o programa vai funcionar.
> Mas a vantagem do linux, pelo menos das distribuições voltadas para desktop, é justamente a de sair em 6 em 6 meses
Vantagem?
É uma faca de 2 gumes(ou pelo menos era assim no passado):
1) Colocar as bibliotecas embutidas na aplicação:
- Torna a aplicação mais estável (teoricamente)
- Sua aplicação não vai quebrar outra
- Outra aplicação não vai quebrar a sua
- Sua aplicação vai inchar bastante (requer mais espaço)
- As atualizações serão mais demoradas pelo tamanho da aplicação
- Suas bibliotecas não serão atualizadas/corrigidas
- Se a aplicação é excluída, não deixa arquivos perdidos no sistema.
2) Usar bibliotecas compartilhadas:
- Sua aplicação pode quebrar com a atualização de bibliotecas
- Sua aplicação pode não funcionar com bibliotecas antigas/novas
- Sua aplicação pode quebrar outras aplicações se atualizar as bibliotecas
- Se as bibliotecas forem corrigidas (vulnerabilidades ou bugs), isto pode beneficiar a sua aplicação e outras
- Excluir a aplicação pode deixar arquivos perdidos no sistema (e assim o sistema envelhece, vai ficando lento e problemático).
No passado, quem programava para Windows teve um período chamado DLL’s Hell (O inferno das DLL’s) e o que era recomendável colocar disponível para todo o sistema passou a ser recomendado colocar apenas no caminho da aplicação, devido aos problemas de atualização, conflito de versões, desinstala/instalava um programa e outros já não funcionavam mais… era uma zona…
Quem quer disponibilizar um aplicativo auto-suficiente pode sempre fazer como a Opera faz: lança uma versão compilada estaticamente. Esse negócio de ficar querendo avacalhar o linux acabando com o inteligente sistema de instalação de pacotes é que não dá.
Quando tenho que pegar um windows hoje em dia e ter que dar 3 ou 4 reinicializações só porque uma é para instalar 20 aplicações antes de um Service Pack, outra para instalar o Service pack e depois outra para instalar mais umas 30 atualizações depois do service Pack, fora as atualizações manuais e diferentes para cada um dos aplicativos instalados, sinto calafrios. Se tivermos que fazer o mesmo numa distribuição linux eu parto para outra distribuição.
@devnull,
Lançar a cada 6 meses é vantagem sim para quem não é apressadinho e quer sempre a última versão de tudo mas não quer também ficar com um sistema totalmente obsoleto ou ter que ficar atualizando milhares de programas. Quem não concorda com isso use o debian stable ou qualquer outra distribuição mais conservadora que garanta um tempo maior entre as versões.
Ou então fique com o windows mesmo, que tem um tempo entre versões maior até do que o debian.
Sempre achei o sistema de distribuição de binários do GoboLinux (http://www.gobolinux.org/) mais inteligente. Cada pacote traz as suas próprias dependências, é instalado em uma sandbox, e não conflita com o resto do sistema.
Só o fato de existirem N diferentes sistemas de empacotamento para sistemas Linux (e BSD) mostra como seguir o standard Unix é uma tarefa árdua. Cada distribuição precisa manter periodicamente builds encadeados para manter tudo dentro de uma mesma versão, é um retrabalho desperdiçado.
Sem contar que só funciona para open source, onde você pode compilar tudo dependendo de uma mesma versão do GCC. Empacotar e distribuir binários multi-distribuição para o Linux, e garantir que funcionem, é uma tarefa praticamente impossível. Não espanta que nenhuma fabricante de software tem interesse em dar suporte além do necessário (a Adobe faz o plugin Flash, e só… a Skype faz um build a cada 2 anos… etc.).
“De dentro do apê de vocês não dá pra ver o que acontece lá fora; vocês andam muito mal informados”.
O Mac OS X tem algumas bibliotecas dinâmicas que são compartilhadas, porque fazem parte do core do sistema. É uma API estável, coisa que o Linux não procura ter, mas voltando. Essa API é o Cocoa e outros componentes chamados de “frameworks” (libs/includes/docs/etc). Um aplicativo pode conter bibliotecas que fazem mais sentido pra ele e estão contidas dentro do diretório do aplicativo (chamado de bundle) e com isso facilita a vida do usuário para 1) instalar o aplicativo 2) mover o aplicativo pra qq canto, porque está tudo.
Bom, tem mais, mas continuem nos seus apt-gets e yums…
Bom, moderem ai como troll , gurizada linux zealot.
O interessante disso tudo é que somente distribuidores de pacotes proprietário possuem, QUASE SEMPRE, uma política de distribuir pacotes com dependências in place: skype e outros estão no mercado para provar isso.
O que me parece acontecer é o fato dos pacotes proprietários não acompanharem a evolução dos programas open-source: alguém já parou para pensar como é desenvolver para as diferentes versões do glibc ou mesmo gcc? As estruturas mudam e compilar um pacote no gcc 4.2 pode ser diferente no 4.3 e 4.4; para as empresas isso gera um custo maior tanto em tempo quanto em recursos.
A questão passa a ser: esse modo de instalação única das bibliotecas unix e derivados serve para um mercado de desktop que espera aplicações com dependencias agregadas igual ao q acontece no windows? Afinal, quem demanda da área da infra-estrutura? A TI ou o negócio? Ou, quem sabe talvez, o sistema que nesse momento possui a maior fatia de mercado?
Vou ser sincero aqui antes que os flammer’s caiam em cima: sou administrador unix e linux já a alguns anos e trabalho ESPECIFICAMENTE
O interessante disso tudo é que somente distribuidores de pacotes proprietário possuem, QUASE SEMPRE, uma política de distribuir pacotes com dependências in place: skype e outros estão no mercado para provar isso.
O que me parece acontecer é o fato dos pacotes proprietários não acompanharem a evolução dos programas open-source: alguém já parou para pensar como é desenvolver para as diferentes versões do glibc ou mesmo gcc? As estruturas mudam e compilar um pacote no gcc 4.2 pode ser diferente no 4.3 e 4.4; para as empresas isso gera um custo maior tanto em tempo quanto em recursos.
A questão passa a ser: esse modo de instalação única das bibliotecas unix e derivados serve para um mercado de desktop que espera aplicações com dependencias agregadas igual ao q acontece no windows? Afinal, quem demanda da área da infra-estrutura? A TI ou o negócio? Ou, quem sabe talvez, o sistema que nesse momento possui a maior fatia de mercado?
Vou ser sincero aqui antes que os flammer’s caiam em cima: sou administrador unix e linux já a alguns anos e trabalho ESPECIFICAMENTE com soluções livres, sem nem mesmo em 6 anos ter instalado uma solução proprietária.
Bem acho que é isso.
De qq forma um abraço a todos, principalmente por doarem parte de seu tempo para publicar uma opinião aqui no vol lol
Também achei interessante a alternativa apresentada pelo Gobolinux, pena que esta distro não seja mais popular (trazendo mais programas e mais “testadores”) ou que outras distros populares não adotem esta abordagem(eles disponibilizam inclusive os softwares/scripts para mudar a organização do sistema de arquivos). Embora no site fique bem claro que a intenção da distro não seja ser facilitar a vida de usuários leigos a sua abordagem se conjugada com outras ideias usadas em distros populares poderia simplificar muito a vida dos usuários.
Acho que deverei migrar para GoboLinux!
NÃO HÁ NADA no linux que impeça alguém fazer um aplicativo compilado estaticamente ou que instale por exemplo em /usr/local/programa e tenha a seguinte estrutura:
/usr/local/programa/bin <- executáveis
/usr/local/programa/lib <- bibliotecas necessárias para o programa
/usr/local/programa/etc <- configurações do programa
Isso PODE ser feito e já vi programas assim. Inclusive muitas vezes é o default na hora de rodar o configure antes da compilação. Só não é o que normalmente se faz nos programas incluídos na distribuição, que são normalmente instalados em /usr e cujas bibliotecas são colocadas em /usr/lib. compartilhadas por outro aplicativos e normalmente empacotadas em pacotes separados dos programas como é falado no artigo.
O que vejo muito é empresa que faz software proprietário simplesmente DESINTERESSADA de portar seus programas para linux ou por preconceito, por achar que não vai ter mercado ou por incompetência pura, não sabendo realmente trabalhar em ambientes Unix. Aqui no mercado nacional é bem mais claro esse problema. As empresas nacionais de software proprietário na sua grande maioria simplesmente não sabem programas em ambientes unix (nem mesmo macs), porque se habituaram por anos a fio a programar usando windows, IDEs e linguagens disponíveis somente no windows.
Muitas dessas empresas se tornaram dependentes e reféns de ferramentas de desenvolvimento e APIs exclusivas da Microsoft e/ou da Apple e com isso fica difícil portar seus aplicativos para qualquer outra plataforma, não apenas linux. É o caso dos jogos, com a dependência do DirectX, por exemplo.
Cara, posso estar falando algo MUITO leigo, mas não acho ruim pacotes completos ( programa + biblioteca) acho que seria o ideal isso e o instalador ( synaptic, gdebi, yast, etc) é que deveria fazer a busca pela existência da biblioteca e só instalar o necessário ( leria o conteúdo do pacote e faria uma descompactação seletiva do necessário)
@Linux boy
Atualizar ou instalar um sistema de seis em seis meses é indolor nada! Pelo menos se vc tem mais de uma conta de usuário em um computador. aqui em casa são 4 pessoas para um pc e cada um tem sua própria conta de usuário e ja aconteceu mais de uma vez de, depois de uma atualização/instalação os dados de um ou dois usuário ( não todos) ficarem inacessíveis e é um saco corrigir isso para voltar a funcionar.
Ja aconteceu comigo no lançamento do kurumin e em cada atualização do ubuntu e do mandriva.
Sou favoravel em certas situações, como modems 3g e Device drivers que dele depanda sua conexão.
@Allan Taborda dos Santos Mas ai está o grande problema, atualizar a distro, cara, se no windows isso as vezes é complicado devido a quantidade de programas que temos instalados e configurações feitas, imagina no linux. Não sabe quanta raiva eu já passei com isso no linux. E pra quem fala, atualizar parece tão simples, isso depende muito do caso.
Pra leigos, a opçõa existente no windows e não esqueçamos do MacOS, são muito melhores.
@lordtux,
Não acho que você deve estar fazendo o upgrade corretamente, porque para fazer backup de configurações no linux basta fazer um backup do /etc. Se o /home estiver numa partição separada, nem backup dos seus dados é necessário.
O que vejo é muita gente reinventando a roda instalando um monte de programas manualmente que na maioria das vezes estão disponíveis nos repositórios de pacotes oficiais ou não oficiais da distribuição. São pessoas que cismam em fazer as coisas do modo windows e antes de procurar se o programa está empacotado na sua distribuição, vão baixando código-fonte e apanhando para instalar as coisas. Como não sabem nem como funciona o processo de compilação de um programa e nem o que são bibliotecas, apanham ou não conseguem instalar o programa e aí ficam chorando como bebês querendo fazer as coisas do modo windows ou mac.
Essas pessoas normalmente nem se preocupam em saber se o código-fonte está disponível, que é o cerne de qualquer software livre. Sendo freeware e com um instalador binário Next, Next, Finish já está ótimo para elas. Só pensam no “Free” como “grátis”, não como “livre”.
No Linux, ou melhor, nas distribuições GNU/Linux, principalmente nos derivados do Debian e do Ubuntu, há a possibilidade de atualizar a distribuição de uma versão para outra sem grandes traumas.
“alguém já parou para pensar como é desenvolver para as diferentes versões do glibc ou mesmo gcc? As estruturas mudam e compilar um pacote no gcc 4.2 pode ser diferente no 4.3 e 4.4;”
O pior é quando a 4.2.0 é diferente da 4.2.1.
Já aconteceu comigo várias vezes, principalmente com bibliotecas do KDE.
São os dois lados da moeda, só não considero espaço em disco vantagem nos dias de hoje, já que até celular vem com bastante memória e os computadores então…Mas o restante é verdade. Talvez algum modelo misto, com um “núcleo” de bibliotecas mais estáveis e que uma política clara de versões. Assim, se alguma empresa quisesse desenvolver, saberia que as distros que usassem a versão x desse “núcleo” seriam compatíveis com a sua aplicação desde que você trabalhasse com essas APIs e que somente alguma adicional é que teria de ter essa preocupação.
“Como não sabem nem como funciona o processo de compilação de um programa e nem o que são bibliotecas”
Exato, a maioria das pessoas não precisam e nem querem saber disso. Querem usar seus programas e pronto.
O Windows e o Mac OS já descobriram isso há anos, os desenvolvedores do Linux parece que ainda não…por isso esse tipo de debate é interessante.
Concordo com a solucao apresentaad pelo Wallacy, fazer dois pacotes e deixar a scolha do usuario seria muito bom. Um usuario iniciante que tem por exemplo o KDE 4.4.1 e quiser atualizar para o 4.4.2 ficaria muito mais feliz se poegasse todo o pacote de uma so vez do que baixar pacote por pacote para resolver as dependencias…
Seria interessante se criasse um instalador .algumacoisa para instalar pacotes completos de uma so vez no Linux, e esse veru=ificasse a existencia dos mesmos no sistema, afim de nao dar conflitos depois.
@Renatim
Por que vocês insistem que um usuário DEVA atualizar o KDE de uma versão para outra ? Depois dizem que o linux é difícil… Não vejo nenhum usuário de windows atualizando o explorer.exe do windows xp para o do windows vista ou o do windows 7 !
Entendam o que eu quero dizer: quem quer ficar sempre na “crista da onda”, use uma distribuição rolling release como eu falei ou APRENDA a compilar o código-fonte que está disponível no projeto KDE. Ele será compilado e instalado separadamente no /usr/local ou no /opt e não vai sobrescrever nada do seu sistema.
Não quer ter esse trabalho ? Então espere 6 meses para sair a nova versão da sua distribuição desktop !
Qualquer distribuição traz MILHARES de programas nos seus repositórios de pacotes e ficar mudando de uma versão para outra em programas críticos (como o KDE citado) leva a aparecimento de bugs que não existiam, mudanças no modo de operação, etc.
Infelizmente eu chego à conclusão de que a maioria dos atuais usuários de software livre não possuem conhecimentos suficientes para apreciar a beleza dos sistemas unix e do conceito de gerenciamento de pacotes, assim como o próprio conceito do software livre.
Se uma distribuição quiser permitir que o usuário atualize o KDE 4.4.1 para a 4.4.2 na versão estável, o que não é o normal (normalmente as distribuições aplicam apenas alguns patches sobre a versão anterior corrigindo eventuais bugs e problemas de segurança), basta ela compilar o código e colocar os novos pacots no repositório. Um simples comando ou clique de mouse vai atualizar o KDE inteiro de uma versão para outro, muito facilmente.
Não disponibilizou essa atualização e você ficou chateado com isso ? Veja o que eu falei logo acima.
Já falei aqui ha bastante tempo que o problema do linux é o sistema de pacotes.
Primeiro , deve haver diferenciação de pacote e aplicativo .
E segundo , deve existir uma base estável que nunca é removida pelo o usuário ,assim como as pessoas não podem remover o menu iniciar do Windows.
@Linux Boy
Olhe para o ceu aprecie a vista, depois vista se melhor e saia e veja pessoas, pergunte para elas como vão a vida.
Pc é uma ferramenta e as pessoas usam como elas querem e como elas querem. Eu sei que, na minha visão, um avanço no HTML é uma vitória, mas as pessoas não querem saber, elas querem o site pronto, fico chateado? Fico um pouco, mas é a vida.
Quanto o artigo, acho o sistema atual do Linux muito bom (visão leigo), mas acho que alguns pacotes de programas mais de uso dia a dia, deveriam poder ser instalados sem a senha do root, eu já tive que instalar programas via wine para ter acesso a coisa que poderia fazer no linux (7zip), mas isto para muitos mata a “pureza” do sistema.
Atualmente estou usando o Fedora e adorei o sistema de upgrade dele que me deixou o sistema todo funcional (todos programas de volta! Eu não esperava por isto!), só irei dar um fresh-install quando mudar de distro e isto não vai ser logo.
Acho que uma coisa que deveria ser feita e acontece no openSUSE é que ele na instalação já separa o /home do resto do sistema, isto deveria ser feito em todas as distros de forma transparente para o usuário.
E quem reclama do Fedora é porque não conhece o presto. :)
@Fabio Ortolan
É um engano comum as pessoas pensarem que não podem compilar e instalar programas no linux apenas como usuário comum, sem ser root. Se a pessoa, na hora do configure, colocar como local de instalação o $HOME do usuário ou um diretório qualquer onde tem pode de escrita, o aplicativo e as bibliotecas relacionadas serão instaladas lá.
Se o desenvolvedor do programa colocar no código-fonte também o código de todas as bibliotecas da qual o programa depende e fazer com que o make install se preocupe em copias essas libs para o diretório ou um subdiretório de onde está o programa, vai funcionar da maneira “windows” ou Mac.
Mas por que isso não é o que se vê no mundo linux ? Porque máquinas windows ou mac têm meia dúzia de programas apenas feitos por desenvolvedores independentes que não compartilham nada além das bibliotecas básicas integrantes do sistema operacional. Já desenvolvedores de softwares livres têm a mentalidade de cooperação e reutilização de código e por isso as bibliotecas são compartilhadas entre vários programas.
Como eu disse, é perfeitamente possível se adotar um esquema híbrido no linux, onde apenas alguns programas mais importantes e voltados para usuários leigos não usem bibliotecas compartilhadas por outros programas, mas fazer isso para TODOS os milhares de programas que integram uma distribuição linux de uso geral de hoje em dia é loucura. Haveria um enorme desperdício de espaço em HD e também de RAM.
O PC-BSD, por exemplo, além dos sistema de instalação de programas via ports (o normal do FreeBSD), tem os pacotes PBI
http://www.pcbsd.org/content/view/20/26/
que empacotam as libs além do programa num pacote único e auto-suficiente. Mas notem que eles não fazem pbis para TODOS os programas, apenas para os mais utilizados e que têm maior apelo para usuários finais.
E o linux já tem a mesma idéia no formato do autopackage
http://www.guiadohardware.net/tutoriais/dominando-autopackage/
http://en.wikipedia.org/wiki/Autopackage
e outros como o klik e zeroinstall.
“Acho que uma coisa que deveria ser feita e acontece no openSUSE é que ele na instalação já separa o /home do resto do sistema”
Não sabia. Ótimo isso, já que facilita muito quando for atualizar um sistema. Nem todo mundo sabe fazer isso na mão na hora de instalar.
Muito bem lembrado pelo Lunox Boy de que no FreeBSD/PC-BSD o formato PBI é um pacote só autosuficiente!
E sabem do que mais sinto falta? De aplicativos portáteis, que rodem do Pendrive. Por exemplo, no Windows posso ter Firefox, OpenOffice, Gimp na opção portátil. Por exemplo posso ter o Gimp 2.0 no HD e 2.4Portable no Pendrive, sem conflitos.
Aí você procura por coisa parecida no Linux. Só vi opção de atualizar o pacote, talvez hackeando dê para deixar 2 versões antiga e velha e um no HD e outro no pendrive, mas provavelmente é trabalhoso (e tem de ser hacker mesmo…)
O que tem de portátil no Gimp são as distros que rodam pelo Pendrive. Mas aí é 8 ou 80! Não tem aplicativo portable mas tem distros inteiras portable! quero algo intermediário!
acredito para quem já usou um mac, gosta muito do sistema de instalação, apenas arrastando o icone do programa, para atualizar o sistema a mesma coisa, sem dor de cabeça, isso e claro falando na questão desktop, agora para servidores… não sei não, acho que não confiaria muito sendo que uma biblioteca pode quebrar todo o OS.
@Célio Ishikawa
E o windows só tem aplicações portáteis porque as pessoas é que fizeram versões portáteis dos aplicativos. Não foi a Microsoft nem os fabricantes dos aplicativos.
No linux dá para fazer perfeitamente também um aplicativo portável. Não é uma limitação do linux, assim como não é uma limitação do windows. Inclusive já existe um projeto para isso
http://www.portools.com/
Tem poucos aplicativos ?! Sim, mas porque poucas pessoas contribuem. Além disso, o esforço maior acontece em transformar os aplicativos windows porque há muito mais máquinas windows no mundo e portanto há uma maior chance de se poder usar as aplicações portáteis nelas.
Quer coisa mais portátil do que poder rodar uma distribuição linux inteira através de um livecd ou pen drive usb ?
Essa separação, além de tudo garante uma maior qualidade daquilo que é desenvolvido. Os programas devem ser desenvolvidos de modo a possibilitar que bibliotecas, por vezes, nem existam ou que sejam substituídas por outras versões. Os desenvolvedores fazem código muito mais portável e o mais independente possível da versão da biblioteca.
No começo é mais difícil, mas as técnicas para administração dessas bibliotecas vão sendo aperfeiçoadas e tudo vai se tornando mais independente.
Aliás, não é verdade que você não pode ter duas versões de uma mesma biblioteca. O problema é quando essas versões conflitam, de acordo com o gerenciador de pacotes. Ou seja, o grande objetivo deve ser o de trabalhar em função de reduzir esses conflitos, reduzindo a necessidade dos backports.
O ideal seria você poder misturar, no caso do Debian, stable/testing/unstable. Já tive problemas com isso antes, quando a libc foi mudada, mas hoje em dia não dá problemas ter um sistema misto.
O windows vai continuar sendo a porcaria que é, e os sistemas livres vão ficando cada vez mais portáveis, mais fáceis de serem administrados/atualizados.
Só pra enfatizar, o ideal não é que as distros venham com todos os pacotes “mega bloated” com tudo o que é dependência inclusa. O ideal é que as diferentes versões das bibliotecas não conflitem e que os aplicativos façam o correto uso do que está disponível para ligação dinâmica.