Jump to content
  • 0

instalar en debian 8 x64 compatibilidad con la arquitectura i386 puede ser fuente de conflitos?


alguien
 Share

Question

Acabo de hacer una instalación de prueba de debian 8 en una maquina de 64 bits, me dispongo a instalar wine a través de jessie-backports

apt-get install -t jessie-backports wine

pero al intentar ejecutar una aplicación de windows me sale este mensaje en consola diciendo que debo ejecutar:

dpkg --add-architecture i386 && apt-get update && apt-get install wine32

Luego he habilitado los repositiorios multimedia e instalado "libav-tools" que es un paquete para debian que contiene ffmpeg y un buen numero de codec multimedia.

Pero aptitude me da este mensaje:

Las acciones siguientes resolverán estas dependencias

     Eliminar los paquetes siguientes:
1)     i965-va-driver:i386
2)     libasound2-plugins:i386
3)     libavcodec56:i386
4)     libva1:i386
5)     mesa-va-drivers:i386
6)     va-driver-all:i386

     Dejar las siguientes dependencias sin resolver:
7)     libwine:i386 recomienda libasound2-plugins:i386


¿Acepta esta solución? [Y/n/q/?]

Lo que me hace pensar que avisa de cierta incompatibilidad con la arquitectura i386, y pide desinstalar ciertos paquetes de esa arquitectura.

 

También observo que algún que otro repositorio como el de proxmox o google chorme me intenta instalar las versiones para i386, y tengo que especificar la arquitectura de 64 bits para que no me de error: "deb [arch=amd64] http://......."

 

Todo esto me genera una duda, sobre si es causa de conflictos dificiles de controlar el tener instalada la compatibilidad con la arquitectura i386

 

Me gustaría saber vuestra opinión.

 

Saludos.

Link to comment
Share on other sites

7 answers to this question

Recommended Posts

  • 0

No y sí.

No debería haber ningún problema con el soporte multiarquitectura. Puedes tener un sistema x86_64 (x64 no existe) e instalar paquetes i386 sin mayor inconveniente. Salvo que te dediques a hacer experimentos muy raros, lo más que puede pasar es que "pises" alguna librería y el sistema te diga que o metes una o metes la otra pero no las dos arquitecturas a la vez, pero en esos casos es casi que indiferente

 

Ahora... Wine en sí mismo, sí, es un dolor de huevos importante por todo lo que implica, así que mucha aptitude y ojo con las librerías que tocas :sweat:

Link to comment
Share on other sites

  • 0

Entonces la fuente de posibles quebraderos de cabeza no es el soporte multiarquitectura, sino el propio wine.

 

Para priorizar la estabilidad del sistema lo mejor sera prescindir de wine. Por eso encuentro interesante los sistemas de virtualizacion, la idea de aislar los procesos en maquinas virtuales me gusta.

 

En los mac de apple leí hace tiempo que hay una aplicacion que empaqueta un programa de windows junto con las librerias necesarias de wine, de manera que dicho programa se ejecuta en un mac sin tocar nada del sistema anfitrión, porque ya esta encapsulado dentro de una instancia de wine.

 

Es una especie de contenedor similar a una maquina virtual, y creo que en linux tambian hay contenedores de este tipo, pero para tareas mas generales, no para un programa especifico.

 

Creo que es a lo que se deberia tender, hablando desde mi propia ignorancia, a que las aplicaciones se ejecutaran encapsuladas con sus propias librerias de forma que el sistema anfitrion fuese intocable e incorruptible.

 

Quiero decir que esas dependencias de las que tanto se hablan en el mundillo de gnu/linux estubiesen contenidas en cada aplicacion para que sea autonoma.

Edited by pprico
Link to comment
Share on other sites

  • 0

Esto ya está presente en gnu Linux, por una parte hay programas que supuestamente son nativos, pero si los destripas ves a wine por dejado, eso se llama un falso empaquetado, y por otro lado Ubuntu a partir de la versión 16.04 tiene un nuevo sistema de paquetes, que hace lo que ya comentas, cada paquete tiene sus propias librerías. Yo la virtualización la veo bien, pero siempre que sea de nivel 1 como lo hace xen. Las de nivel 2 son las del tipo virtual box

 

Enviado desde mi Aquaris E4

Edited by pacoeloyo
Link to comment
Share on other sites

  • 0

Los empaquetados con Wine son muy, pero que muy malos. Tanto por la vagancia de quien los hace, que se cree que nos engaña, como porque al ejecutarlos seguimos teniendo que lidiar con wine :muro:

 

En cuanto a las librerías, piensa que si bien a grandes rasgos puede sonar más "cómodo", cada (mega)paquete debería incluir TODAS las dependencias, con lo que su tamaño sería también mucho mayor. Además de eso, en el sistema estaría la misma librería repetida tantas veces como aplicaciones hayamos instalado que la requieran, ocupando espacio en disco y en memoria, porque cada aplicación cargaría la suya.

La diferencia, utilizando librerías dinámicas únicas, es que todas las aplicaciones utilizan las mismas librerías, no haciendo falta volver a instalarla miles de veces, ni tenerlas cargadas en memoria tantas veces como aplicaciones la necesiten. Siendo todo mucho más eficiente.

 

La cuestión es siempre cómo se gestione. Dependencias mejor definidas, megapaquetes que no repitan librerías... Cuando las cosas se hacen mal, sale mal, ya sean librerías dinámicas o reduntantes :sweat:

Link to comment
Share on other sites

  • 0

Está interesante la conversación, a ver si se apunta alguien más. No sabía que es virtualización de nivel 1 y 2, y haciendo una busqueda rapida diría a groso modo que en el tipo 1 el software se ejecuta directamente sobre el hadware, y el tipo 2 se ejecuta sobre el sistema operativo.

 

Sobre "librerías dinámicas" tampoco conocía el concepto, pero parece ser que es sinónimo de "librería compartida". Totalmente de acuerdo (es de cajón) que las librerias compartidas ahorran espacio de disco y de memoria RAM, pero en gnu/linux cada vez que he intentado asomarme, desde que empecé a mirar Ubuntu (que me dijeron era la distro mas fácil para novatos) me he encontrado al instalar alguna aplicación con situaciones en las que parece haber algún tipo de conflicto o tema no resuelto con las llamadas "dependencias", que supongo son librerías que necesita instalar la aplicación, que a veces sobrescribe o entra en conflicto con otras librerías ya instaladas. Más los problemas de versiones de librerias compartidas ya existentes que determinadas aplicaciones necesitan actualizar a otra version mas reciente, que es como desvestir a un santo para vestir a otro, pues siempre quedará la duda de si esa actualización está dejando huerfano a algún que otro proceso que no funcionará con la versión más reciente de dicha librería.

 

Algunos usuarios de Mac achacan a gnu/linux ese problema de las "dependencias" que dicen no tiene las aplicaciones para Mac OS. En lo que he experimentado con Mac OS me da la sensación que las aplicaciones van en mega-paquetes que ya traen incluidas las librerías no disponibles en el sistema operativo. Es decir, usan tanto de librerias compartidas como de librerías añadidas en el propio mega-paquete de la aplicación, con lo cual ocupará algo mas de espacio en disco y memoria, pero a cambio ninguna aplicación modifica ni sobrescribe ninguna de las librerías compartidas, quedando resuelto el fastidiosos problema de las dependencias a la vez que supone una protección contra intrusiones y modificaciones de las librerías ya incluidas, que podría dar lugar a nuevas incompatibilidades o conflicto con otras aplicaciones ya instaladas, o eso me imagino, que tampoco serán tres dioses.

 

Aunque leyendo este breve artículo: http://www.elarraydejota.com/administracion-de-librerias-estaticas-y-dinamicas-en-sistemas-gnulinux/ ya me doy cuenta que en los sistemas gnu/linux ya se gestionan tanto las librerías compartidas o dinámicas como las estáticas o redundantes.

Edited by pprico
Link to comment
Share on other sites

  • 0

Esta mañana he echado unas horas en instalar Qubes OS, la versión 3.2 que he descargardo de su web https://www.qubes-os.org/downloads/

y que me aspen si entiendo esa interfaz gráfica que parece los mandos de avión ultrasónico. Lo he instalado en un disco duro de quita y pon, a ver si algún día me veo con ánimos de enfrentarme a esa piedra roseta de la virtualización. :sweat:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...